The architectural specification of an avionic subsystem

The Architectural Specification of an Avionic Subsystem L. M. Barroca J. S. Fitzgerald L. Spencer Dept. Computing The Open University Milton Keynes MK7 6AA U.K. Centre for Software Reliability University of Newcastle upon Tyne U.K. British Aerospace Defence Ltd Military Aircraft Division, Warton Aerodrome, Warton Preston PR4 1AX U.K. Abstract The work of the British Aerospace Dependable Computing Systems Centre includes the development of formal techniques for use in defining and tracing requirements for software systems at the system architecture level. A basic repertoire of techniques proposed so far includes the graphical representation of timing requirements allied to model-oriented specifications of functionality. This paper gives an overview of these techniques and reports on a small study in their application conducted by British Aerospace Defence. The study uses a realistic example of an avionics system: the pilot data entry system for a waypoint database. The example is described with some technical detail. Formally analysing a timing requirement for the rate of data entry yields local timing requirements for the cockpit equipments. Conclusions assess the value of these techniques, as perceived by BAe systems developers, and propose further work in providing tool support. 1 Introduction Part of the work of the British Aerospace Dependable Computing Systems Centre (BAe DCSC) is the development of formal techniques for use in the design of realtime avionics systems. The main aim of this work is to encourage rigorous consideration of aspects of the intended behaviour of a system at earlier stages in the development process than is generally the case. It is important that the techniques developed are accessible to avionics engineers, allow for the production of rigorous arguments about the correctness of design decisions and support the tracing of design decisions against the requirements they purport to satisfy. These last two points are particularly important for the production of arguments in the assessment process. In developing formal techniques for use in industry, we have not chosen to begin by proposing a new specification language, but are instead building a repertoire of applicable methods, based on those which already have some history of successful application in BAe and other parts of the aerospace industry. A group of techniques has been proposed, under the name of the Architectural Specification Method (ArchSM), for the formal specification of real-time systems [1] at the logical architecture level [2]. The ArchSM uses a graphical notation and Real Time Logic (RTL [3, 4]) for describing the system’s temporal properties and the model-oriented specification language Z [5] for describing functionality. In this paper, we illustrate the techniques which go to make up the ArchSM, concentrating on specification and proof of timing behaviour. Section 2 provides an overview of these techniques. The main part of the paper describes one example of their experimental use: the construction of arguments about timing requirements for a waypoint data entry system, described in Section 3. Section 4 shows how ArchSM techniques were used in BAe to describe the system behaviour and conduct a proof justifying splitting a system-level timing requirement into allocations of time bounds to operations running on the various equipments participating in the system. The technical detail of the proof is omitted in this paper. In Section 5, we report the experience of the study within BAe and discuss areas of future work, including tool support. 2 The Architectural Specification Method The ArchSM is intended to support modelling and reasoning about three important aspects of a putative system’s behaviour: its timing properties, its functionality and its system structure. This paper principally concentrates on the first aspect. However, in this section we review the techniques employed in all three areas. 2.1 Temporal Behaviour and Formal Verification of Temporal Properties Timed Statecharts State-transition diagrams have been widely used as a design tool in avionics projects for some time. In our work with BAe, we have chosen to represent the timing be- haviour of systems with a graphical notation, based on the language of Timed Statecharts. This has the advantage of being accessible to people with a less mathematical background, while being sufficiently expressive and formal. A further consideration was that some BAe engineers are already familiar with the notation through experience of the Statemate tool [6]. Statecharts [7, 8, 9, 6] are an extension of state machines and state diagrams for the specification of reactive systems. Timed Statecharts [10] take this further to deal with time constraints. E/ev1 S1 S2 tation. Real Time Logic [3],[4] is a formal language for capturing the time constraints of real-time systems. It deals with time quantitatively, rather than just relative temporal order: RTL has no modal operators. Its basic concepts are actions, state predicates and events. The occurrence relation θ captures the notion of time: θ(ev , i, t ) asserts that the ith occurrence of event ev happens at time t . Formulas in RTL use the universal and existential quantifiers and first order logic. In the ArchSM in order to produce rigorous statements and proofs of timing properties, statecharts are interpreted as theories in RTL. Each state S in the statechart has an associated entry event →S and exit event S→ (c.f. the Modechart semantics [4]). We can, for example, record that the state B is entered if and only if the state A is exited: [l,u]/ev2 ∀ t • ∃ i • θ(→B , i, t ) ⇔ ∃ i • θ(A→, i, t ) Figure 1: Example of a simple timed statechart Each box in the diagram represents a system state, each arrow a transition between states. There is a distinguished initial state, indicated by the little arrow without a source state. The transitions are labelled with the trigger before the slash (“/”) and with the names of any events raised by the transition after the slash. External events (caused by agents outside the system of interest) are shown in upper case. In the case of an immediate transition, the trigger is the name of an event, as in the transition from S1 to S2 in Figure 1. The trigger may also be a condition (shown between square brackets). Immediate transitions are taken as soon as the trigger occurs while the condition holds. For a delayed transition, the trigger is a time bound, as in the transition from S2 to S1 . The time bounds [l , u] define the minimum and maximum time for which the transition may be enabled before being triggered, indicating where the engineer considers there might be some time delay on taking a transition due to some data processing. Thus in Figure 1, the transition from S1 to S2 occurs the instant E happens, raising the event ev 1, which may in turn trigger transitions in other state machines. The transition from S2 to S1 occurs between l and u time units of entry to S2 , raising the event ev 2. Reasoning about Timed Statecharts We have already indicated that the production of rigorous arguments is important for the assessment process. In the ArchSM, Real Time Logic (RTL) is used to construct such arguments about timing properties of systems whose timing behaviour is expressed using the Timed Statechart no1 In We have developed a systematic, but as yet not automated, approach to deriving the axioms for a chart. We consider each state in turn, and write down appropriate axioms for the initial condition, entries, exits, progress and stability of each state as discussed below. Initial State Axioms If the state S is an initial state (Figure 2, diagram (i)) then we assert: θ(→S , 1, 0) If S is not the initial state, we assert θ(S→, 1, 0) We need to distinguish the initial state from the others and to establish that the system is not in non-initial states at time 0. This decision affects all the following axioms; entering the initial state for the ith time is followed by the corresponding ith exit, while for any non-initial state entering it for the ith time will be followed by the i + 1th exit of the state. Exit Axioms If state S1 has a single exit transition (Figure 2, diagram (ii)) to state S2 there will be the following set of axioms: • SO1 : leaving the source state S1 entails entering the target state, S2 . Formally, we write1 : ∀ i, t • θ(S1→, i, t ) ⇒ ∃ j • θ(→S2 , j , t ) all RTL formulas in this paper, i, j and k range over occurrence numbers, time Occ domain, (non-zero T (Natural Naturalnumbers). numbers), and t ranges over the RTL discrete • SO2 : an axiom that relates leaving the source state, S1 , with the trigger of the transition. For transitions triggered by events, this axiom says that if S1 is exited there has to be an occurrence of the event (and the condition, if it is the case, be true): (i) Initial State S1 ∀ i, t • θ(S1→, i, t ) ⇒ ∃ j • θ(trigger , j , t ) For delayed transitions where the trigger is [l , u], say, this axiom says that if S1 is exited, this happens at a time within the lower and upper bounds, counted from the entry to S1 : ∀ i, t • θ(S1→, i, t ) ⇒ ∃ t1 • θ(→S1 , i, t1 ) ∧ t1 + l ≤ t ≤ t1 + u Note that that in this case we consider S1 as being initially true; for an initially false state this axiom would be slightly different: ∀ i, t • θ(S1→, i, t ) ∧ i > 1 ⇒ ∃ t1 • θ(→S1 , i − 1, t1 ) ∧ t1 + l ≤ t ≤ t1 + u • SO3 : when leaving the source state, S1 , the effect of the transition has to occur (an event is generated): ∀ i, t • θ(S1→, i, t ) ⇔ θ(effect , i, t ) The right hand side is weakened to ∃ j • θ(effect , j , t ) if the same event can be generated by a number of different transitions in the statechart. We omit the formal versions of the remaining axioms. See the waypoint data entry example in Sections 3, 4, and in the appendix, for examples. For each state S1 with multiple exit transitions (Figure 2, diagram (iii)), the following axioms are derived: • MO1 : leaving S1 implies that one of the exit triggers is enabled and the corresponding target state is entered (this axiom corresponds to SO1 and SO2 combined); • MO2 : leaving S1 implies that one of the effects (shown in the transition labels) is generated and the corresponding target state is entered (this axiom corresponds to SO1 and SO3 combined). (ii) Single Exit/ Single Entry trigger/effect S2 (iii) Multiple Exit trigger2/effect2 S2 S1 S1 ... triggern/effectn Sn (iv) Multiple Entry S2 trigger2/effect2 ... Sn S1 triggern/effectn Figure 2: Some possible statemachines Entry Axioms If state S2 has a single entry transition from state S1 the following axioms will be asserted: • SI1 : entering the target state, S2 coincides with leaving the source state, S1 ; • SI2 : an axiom that relates entering the target state, S2 , with the trigger of the transition; • SI3 : entering the target state, S2 coincides with the effect of the transition. For each state S1 that has multiple entry transitions transitions (Figure 2, diagram (iv)), there will be the following axioms: • MI1 : entering S1 implies that one of the entry labels is enabled; • MI2 : entering S1 implies that one of the effects on the entry labels has been generated. Progress Axioms Progress axioms ensure that, when a state has been entered, an exit, if available, is taken. For a single-exit transition, axiom PSO1 asserts that if the transition is immediate (i.e. the trigger is of form e[c]) the state has to be left when the event e occurs if condition c is true; if the transition is delayed (i.e. the trigger is of form [l , u]) the transition has to be taken after the lower bound has elapsed but before the upper bound, counting time from entry of the state. If there are several exit transitions from a state, some of them delayed and some immediate, axiom PMO1 imposes that when an immediate transition is enabled a transition out of the state is taken (that immediate transition or any other enabled at the same time). If there are delayed transitions out of a state, the progress axiom implies that the state has to be left at or before before the minimum of all the upper bounds (u2 , . . . , un ) of the delayed transitions has elapsed. If several transitions are enabled at the same time there is no guarantee on which one is taken. Stability Axioms Symmetrically to the progress axioms, the stability axioms state that if no transition out of a state is enabled, the state will not be left. A stability axiom (named SSO1 ) is generated for each single-exit immediate transition. The stability axiom for multiple exits (SMO1 ) says that: • if we are in a state at a certain point in time and no immediate transition (e[c]) is enabled at that time, and • that time is before the minimum of the lower bounds, of the delayed transitions, has elapsed, then the state will not be left. Using the general principles above, the set of axioms generated for a timed statechart will certainly contain some redundancy, for example the event causing an exit appears both in the entry and exit axioms. For example, in a delayed transition, the obligation of leaving the state within a certain interval is repeated in both the exit and progress axioms for the source state. 2.2 Functionality We have chosen Z [5] as a formalism for representing the functionality of a system, again because of its familiarity to some groups of BAe engineers. The operations associated with each agent in a system are described as relations on state type, input and output values. In relating the Timed Statechart model of a component of the system, we associate an operation (action) to a state in a state machine model. In this case the operation is invoked when the state is entered, and the invariant of the operation is related to the system being in that state. If there is a time bound on an outward transition out of that state, this time interval usually represents the minimal and maximal time allowed for the execution of the operation. Conditions on labels refer to the values of variables changed by the actions within the states. Another approach is to associate a single operation with a whole state machine. In this case the specification of the functionality will correspond to a moded definition in the sense that the functionality will change according to the state the system is in. This form of moded definition is common in aerospace systems where one equipment may provide different functions during, say, different phases of flight. 2.3 Structure—Partitioning the System A specification at the logical architecture level partitions the system into independent agents that interact in a well-defined way. In later stages of the development process, the communication initially defined in simple terms of signals between the components will be realised by more complex communication protocols. One notation which can be used to represent system structure is a subset of the DORIS Real Time Networks [11]. Its structural aspects can be used to define an initial high level design of the system in terms of the agents/activities of which it is composed and their interactions. At detailed design levels, the DORIS methodology allows communication between agents to be described via a rich repertoire of shared data structures. However, at the level of specification in the study described here, communication between agents is identified only in terms of the events that trigger and are raised by each agent. 3 The Waypoint Data Entry Example In this and the following section, we describe how the ArchSM formalisms introduced in Section 2 were applied to a case study in the analysis of an avionic system. The case study concerns a system for the entry and display of waypoint data by a pilot. Waypoints are geographical locations to be visited by an aircraft on its journey. The aircraft’s on-board computer contains a database of such waypoints—the Destination List—which may be modified by the pilot in flight. Four main equipments are used by the pilot for entering and displaying data. These are shown informally in Figure 3. The Multi-purpose Display (MPD) is a headdown display and pilot interface for the Display Processor (DPMC). The pilot uses the MPD softkeys to choose DPMC Stores Dest List Dest list updated data item Validates new waypoints Updates Dest List Dest list request MPD Displays data list Pilot format data item Selects format selected data item Selects data item to edit Edits data item data HUD Scratchpad DEP data Displays current data item Figure 3: Informal picture of data flows in the waypoint entry system the required display, in this case the Destination List. The pilot then selects the position in this list at which a new waypoint is to be entered or selects an existing waypoint for modification. The selected waypoint is displayed on the Head-Up Display (HUD) scratchpad. The Data Entry Panel (DEP) is used to enter new data and submit this to the DPMC for validation and storage. Avionics systems are required to meet a wide range of requirements. Some of these are concerned with the pilot entering data into the system within a specific time period (typically tens of seconds). In this example, a typical requirement in the top-level requirements document would read as follows: . . . It shall be possible to manually enter/modify navigation data at the rate of one waypoint in not more than 30 seconds . . . The study reported here raised a number of questions about this rather incomplete statement of a requirement: What are the start and end points of the data entry sequence? How many iterations are included in the sequence? How many failed attempts can be made, and should this be limited? Could the data entry sequence be interrupted if, for example, the pilot has to respond to a warning? If so, how does this impact the requirement? early in the development process, it is helpful to be able to design code around known timing limitations. At the higher level of architectural specification, the allocation of timing budgets to processes or equipments has great potential value in influencing the choice of algorithms, process priorities or scheduling policies. In the pilot data entry example, the top-level timing requirement given above influences the implementations of the operations performed by each of the agents involved. For the purposes of the timing analysis, the system boundary was drawn around the four equipments. For each of these, a statechart was drawn up describing the behaviour of the agent when a data entry sequence is carried out by the pilot. Figure 4 shows the charts for the Multi-Purpose Display and the Display Processor. The original requirement is imprecise regarding how many items of data (parts of waypoints) can be entered or modified within the data entry sequence, or how many times the pilot might enter and then correct data, perhaps because the DPMC rejects it as invalid. In order to allow for these possible iterations, the waypoint data entry procedure was broken down into a number of steps: 1 2 3 4 Formal analysis of the example This section gives an overview of the use of formal techniques in the analysis of the 30-second requirement as it affects the waypoint entry system. BAe engineering staff suggested and carried out the study with the support of researchers developing the ArchSM techniques. The system structure used was that of Figure 3. The following sections describe the representation of timing and functionality. Given the timing requirement, we concentrate on the former. The principal object of this case study was to gauge the feasibility and value of the Timed Statechart and RTL notations in the analysis of a realistic avionics subsystem. Would it, in the view of BAe engineers, be worth further developing the methods proposed by defining formal proof theory, designing tools etc.? Additional objectives were to obtain evidence of the kinds of analysis which engineers want to perform on architectural specifications; to determine the forms of support which should be available and to expose limitations of the techniques used. 4.1 Timing Behaviour Correctly predicting timing behaviour is essential to the success of many aerospace applications. Where the implementation technology (e.g. processor clock speeds) is fixed 2 The 4 5 Display Destination List (within m time units) Complete data entry (within n time units) Reject data entered and correct data (within p time units) Accept data entered and update Destination List (within q time units) Exit Destination List format (within r time units) Since each step must be completed before the next can begin, the engineers felt it reasonable to apportion time among the steps. The overall requirement was deemed to be met if m + x ∗ (n + (y ∗ p) + q) + r ≤ 30 where x is the number of valid data modifications that the pilot makes to a waypoint, and y is the number of invalid data entries which must be corrected before proceeding. The values of x and y depend on the number of data items in a waypoint and the likelihood of pilot error. The examples in the rest of this section deal with step 4, i.e. accepting the data entered and updating the destination list. To keep the display consistent with the data changed, the accepted data has to be displayed within q time units. The MPD displays the destination list when the destination list format is selected using the DEST LIST key and the data is accessed by the DPMC2 . It also allows the event, MPD triggering betweenthe l 2 and retrieval u2 time of the units destination after it islist retrieved. by the DPMC while transition on the MPD triggered by DEST LIST raises the retrieve the the MPD is in state DestListPage. The retrieval takes between l 1 and u1 time units and raises the accessed event. The destination list is displayed on MPD FORMAT_SELECT DEST_LIST/ StartMPD DestListPage accessed retrieve Display Dest List [l2,u2] Dest List Displayed WAYPOINT_SELECT Selecting Waypoint ENT Entering new data ENT/validate accepted Data Entered DPMC retrieve StartDPMC [l1,u1]/ accessed Get Dest List validate [l4,u4]/ accepted Validate Data Entry [l3,u3] Validation Complete Update Dest List [data_valid] [data_invalid]/rejected Figure 4: Charts showing timing properties of multi-purpose display and display processor rejected ini : State × Occ × T → Bool pilot to select a waypoint and enter new data for that waypoint. We will be looking at the behaviour of the MPD from the point when new data has been entered. The pilot selects one waypoint and then presses the MPD ENT key to display it; he then enters data using the DEP control panel, after which he presses the ENT key again to have the data validated. We do not show the Data Entry Panel behaviour. The DPMC performs a validation function on the input data and updates the destination list. RTL was used to prove conjectures about the relationship between the delays on transitions in the individual equipments and the overall time budget. The statecharts are interpreted as RTL rules. For example, consider the DPMC. The event StartDPMC → occurs if and only if the system is in that state (→ StartDPMC has occurred and retrieve or validate have not occurred since then) and retrieve or validate occur. We record this as the following rule: ∀ i, t .θ(StartDPMC→, i, t ) ⇔ ini(StartDPMC , i, t ) ∧ ∃ j .θ(retrieve, j , t ) ∨ θ(validate, j , t ) where ini is a function that decides if a state machine is in a given state at a given time, for the ith iteration: ∀ S : State, i : Occ, t : T • ini(S , i, t ) ⇔ θ(S→, 1, 0) ∧ ∃ t1 : T • θ(→S , i, t1 ) ∧ t1 ≤ t ∧ ∀ t2 : T • t2 < t1 ⇒ ¬θ(S→, i + 1, t2 ) ∨ θ(→S , 1, 0) ∧ ∃ t1 : T • θ(→S , i, t1 ) ∧ t1 ≤ t ∧ ∀ t2 : T • t2 < t1 ⇒ ¬θ(S→, i, t2 ) Time bounds are recorded on the exit from ValidateDataEntry. This results in a progress assumption that, if ValidateDataEntry is entered, it will be left between l3 and u3 time units after entry3 : ∀ i, t .θ(→ValidateDataEntry, i, t ) ⇒ ∃ t1 .θ(ValidateDataEntry→, i + 1, t1 ) ∧ t + l3 ≤ t1 ≤ t + u3 Full sets of axioms were recorded for each of the statecharts, using the systematic approach mentioned above. The full set of axioms is shown in the appendix for one of the statecharts. The resulting theory was used to construct rigorous proofs of temporal properties of the whole system. For example, the following formal conjecture states that the maximum delay on Step 4 of the accept and display new data procedure is u3 + u4 + u2 time units. More rigorously, if data is entered at time t , and the data is validated, then there will be a later re-displaying of the modified data list within t + u3 + u4 + u2 time units. When we record this property rigorously, we need to include some more detail. The conjecture is stated as follows: i : Occ; t : T θ(EnteringNewData→, i, t ) ∧ i > 1 ∃ j • ini(StartDPMC , j , t ) ∀ tn • next (t , ValidationComplete→, tn ) ⇒ data valid (tn ) ∃ j , t ′ • θ(DisplayDestList→, j + 1, t ′ ) ∧ t ≤ t ′ ≤ t + u3 + u4 + u2 The hypotheses state that: 1. i and t are an occurrence number and time respectively; 3 Since 2. the state EnteringNewData, in the MPD, is left at time t ; 3. at time t the DPMC is in state StartDPMC ; ValidateDataEntry is a state that is initially false, the occurrence index for leaving the state after the ith entrance is i + 1. 5 follows: that in Figure 4 the state ValidationComplete is an artificial state; it is shown 1 , E , t2 ) states that the next occurrence of E after t1 is t2 ; it is defined asNote anything between l3 and u3 time units, one of the conditions data valid or data inval next : T × Events × T 4 next(t next(t1 , E , t2 ) ⇔ ∃ i : Occ • θ(E , i, t2 ) ∧ ¬(∃ t • t1 < t < t2 ∧ ∃ i : Occ • θ(E , i, t)) 4. the data entered by the pilot is valid: the next4 time ValidationComplete is left the condition data valid is true5 . An informal argument of this conjecture would run as follows: On leaving EnteringNewData, the event validate is raised. Since the DPMC is in state StartDPMC (by Hypothesis 4), ValidateDataEntry is entered and, after a maximum delay of u3 time units, state ValidationComplete is entered. Because the data is valid (Hypothesis 5), state UpdateDestList is entered, followed by StartDPMC again: the maximum delay so far is u3 + u4 . The transition to StartDPMC raises the event accepted , which releases the MPD from DataEntered into DisplayDestList. After a further delay of up to u2 units, the destination list has been redisplayed. The total delay has been up to u3 + u4 + u2 time units. A rigorous proof of the conjecture follows the same lines of argument, but naturally deals with much more semantic detail. In the case study, a straightforward rigorous proof was constructed by hand, using the full list of rules derived from the statecharts (see Appendix). Formally recording the timing behaviour allows the allocated time budget to be distributed among the various actions and equipments in the system. For example, it is now known that q must be at least u3 + u4 + u2 . Most importantly, it provides a means of arguing formally whether or not the initial time budget will be satisfied and supports the tracing of design decisions which contribute to the satisfaction of the overall requirement (e.g. the choice of validation algorithm contributes to the value of u3 and hence to q, and hence to the overall 30-second requirement). 4.2 Specifying Functionality The functionality of the waypoint database was recorded formally using Z. For each equipment, local state data and the functions which operate on them have been identified. Data flow between the different equipments and the pilot is treated via inputs and outputs to the local operations. The data flow given on the structure diagram (Figure 3) helps to identify the main data structures required. For example, the local state associated with the DPMC is the waypoint list: DPMC State Waypoint list : seq Waypoint #Waypoint list = maxwaypoints One of the operations associated with the DPMC is Update Dest List . There are two inputs, the number of the waypoint being modified and the new waypoint. This operation is associated with the UpdateDestList box in Figure 4, where it is allocated between l4 and u4 time units to complete: Update Dest List ∆DPMC State waypoint no? : N1 new waypoint ? : Waypoint 1 ≤ waypoint no? ≤ max size Waypoint list ′ = Waypoint list⊕ {waypoint no? 7→ new waypoint ?} Before the list of waypoints is updated the waypoint has to be validated; the relation valid lats shows the validation of the latitude; similarly for the longitude and height. The latitude is expressed in degrees and minutes and it is valid if it is between 0 and 90 degrees and 0.0 and 59.9 minutes. Latitude degrees : N minutes : R valid lats : P Latitude l ∈ valid lats ⇔ 1 ≤ l .degrees? ≤ 90 ∧ 0.0 ≤ l .minutes ≤ 59.9 The other operations on the database are specified similarly. 5 Conclusions Use of the ArchSM The principal object of this case study was to gauge the feasibility and value of using the Timed Statechart and RTL notations in the analysis of a realistic avionics system. It was felt after the study that the techniques themselves were valuable, and further work in making them easier to use in an industrial-scale development were justified. The BAe engineer involved in the proof activities found that the use of statecharts and RTL was straightforward, once the effort had been made to gain familiarity with the notations and understand how RTL axioms relate to fragments of statecharts. The graphical component was well received when the work was described to other engineers who were familiar with a statechart approach. The analysis was also felt to be valuable in encouraging early consideration of timing issues, which might otherwise be left to implementation or test phases. It identified those interactions in the system which have an effect on the timing requirements and which could potentially prevent the overall timing requirements from being met. The use of Statecharts and RTL is related to existing techniques for performance analysis in which “chains” of functions are identified; performance budgets are then either apportioned to each of the functions so that the overall requirement is met, or the achievable performance is calculated from the performance of the functions and assessed against the required performance. Similarly, it would be possible to allocate timing budgets to the various bounds, or, where time bounds are already fixed (e.g. by display update rates), determine what time bound can be achieved for the overall system. The time bounds associated with pilot data input speed were useful in identifying the system developer’s assumptions about pilot behaviour. Although only a small part of the case study is described here, one criticism of the exercise is its small scale and comparative simplicity, in that the steps identified in the data entry procedure are sequential. It might be argued that the approach used is cumbersome in such cases, where the time delays are obvious by inspection or animation of the statechart. The waypoint entry system is also very dependent on the interactions between pilot and system. Machine Support An additional objective of the study was to determine the forms of support which should be available for architectural specification activities. The RTL rules were derived entirely by hand, but in a systematic way, strongly suggesting that a trusted tool could be devised to generate the axioms. This would embody a semantics for the graphical statechart language in RTL: the production of such a semantics is a current activity. We hope to learn from the RTL semantics of the Modechart language in this respect [4]. In the example presented here, the proof itself is also routine, effectively following a chain of transitions. Again, we can envisage a specialist tool to perform time bound calculations on statecharts of the simple kind used in this example, effectively animating the proof. For more general validation and verification, full proof support is required. Colleagues in the DCSC [12] have encoded RTL in Proofpower HOL [13]. In proofs about applications, it is suggested in [14], that arguments in RTL usually involve inequalities imposing lower/upper time bounds on occurrences of events. Our application of RTL bears this out, as shown in Section 4. PVS [15], with its powerful decision procedures for simple arithmetic, is also under investigation. Other Future Work The study has suggested a number of other areas of future work: description of temporal be- haviour under error conditions and the interaction of timing and functionality specifications, for example. Furthermore, the analysis done here is still some way from being able to ensure that the specification can be implemented within fixed resource limits. To do this it would be necessary to take account of the scheduling model and the communication services. Our aim in the ArchSM work has been to introduce a systematic approach to stating timing and functionality requirements at stages in the development process when the system’s logical architecture is fixed. This case study addressed a very limited problem, but it did indicate that our use of familiar structuring mechanisms and graphical techniques is accessible to avionics developers. The formal use of RTL and Z contributes to assessment by providing a basis for rigorous validation and verification arguments and improving the traceability of timing requirements. Areas for further work on tool support and the formal basis of the techniques used have been identified. Acknowledgments A number of colleagues have done work which supports that reported here, in particular Jim Armstrong and Amer Saeed. JSF gladly acknowledges the support of the UK EPSRC and the University of Manchester through Research Fellowships. References [1] L. Barroca and J. McDermid, “Specification of real-time systems—a view-oriented approach,” in Proceedings of XIII Congresso da Sociedade Brasileira de Computação, XX SEMISH, Seminário Integrado de Software e Hardware, Florianópolis, Brasil, Sociedade Brasileira de Computação, 1993. [2] A. Burns and A. Lister, “A framework for building dependable systems,” Computer Journal, vol. 34, no. 2, pp. 173– 181, 1991. [3] F. Jahanian and A. K. Mok, “Safety analysis of timing properties in real-time systems,” IEEE Transactions on Software Engineering, vol. SE-12, no. 9, pp. 890–903, 1986. [4] F. Jahanian, A. K. Mok, and D. Stuart, “Formal specification of real-time systems,” tr-88-25, Dept. of Computer Sciences, The University of Texas at Austin, Austin, Texas 78712, 1988. [5] M. Spivey, The Z Notation: A Reference Manual. Prentice Hall International, 1992. [6] D. Harel, H. Lachover, A. Naamad, and A. Pnueli, “Statemate: A working environment for the development of complex reactive systems,” IEEE Transactions on Software Engineering, vol. 16, no. 4, pp. 403–414, 1990. [7] D. Harel, “Statecharts: A visual formalism for complex systems,” Science of Computer Programming, vol. 8, pp. 231– 274, 1987. [8] D. Harel, A. Pnueli, J. Schmidt, and R. Sherman, “On the formal semantics of statecharts,” in 2nd IEEE Symposium on Logic in Computer Science, (New York), IEEE, 1987. [12] J. Armstrong and L. Barroca, “Specification and verification of reactive system behaviour: The railroad crossing example,” DCSC/TN/93/20, DCSC, 1993. [9] D. Harel, “On visual formalisms,” Communications of the ACM, vol. 16, no. 4, pp. 514–530, 1988. [13] FST Group, ICL Computers Ltd., Proofpower User Documentation, 1992. DS/FMU/IED/USR006, issue 1.9. [10] T. Henzinger, Z. Manna, and A. Pnueli, “Timed transition systems,” in Proceedings of the REX Workshop–Real-Time: Theory and Practice, 1991. [11] H. Simpson, “Methodological and notational conventions in DORIS real time networks,” tech. rep., Dynamics Division, British Aerospace, 1993. [14] F. Jahanian and A. K. Mok, “A graph-theoretic approach for timing analysis and its implementation,” IEEE Transactions on Computers, vol. C-36, no. 8, pp. 961–975, 1987. [15] N. Shankar, S. Owre, and J. M. Rushby, “The PVS Proof Checker: A Reference Manual,” tech. rep., Computer Science Laboratory, SRI International, Menlo Park, CA 94025, USA, 1993. Appendix: Rules for MPD statechart A set of rules has been defined for the translation of the subset of Timed Statecharts used in this paper, into RTL axioms. This set of rules is the basis for the automatic derivation of the axioms. The derived RTL axioms fall into six categories: initial state axioms (Ii ), exit axioms (SOi for single exit, and MOi for multiple exits), entry axioms (SIi for single entry, and MIi for multiple entries), progress axioms (PSOi for single exit, and PMOi for multiple exits), and stability axioms (SSOi for single exit, and SMOi for multiple exits). The rules for the DPMC are omitted. MPD StartMPD (I1 ) θ(→StartMPD , 1, 0) (SO1 ) ∀ i, t • θ(StartMPD→, i, t ) ⇒ ∃ j • θ(→DestListPage, j , t ) (SO2 ) ∀ i, t • θ(StartMPD→, i, t ) ⇒ ∃ j • θ(DEST LIST , j , t ) (SO3 ) ∀ i, t • θ(StartMPD→, i, t ) ⇔ θ(retrieve, i, t ) (SI1 ) ∀ i, t • θ(→StartMPD , i, t ) ∧ i > 1 ⇒ ∃ j • θ(DestListDisplayed→, j , t ) (SI2 ) ∀ i, t • θ(→StartMPD , i, t ) ∧ i > 1 ⇒ ∃ j • θ(FORMAT SELECT , j , t ) (PSO1 ) ∀ i, t • ini(StartMPD , i, t ) ∧ ∃ j • θ(DEST LIST , j , t ) ⇒ θ(StartMPD→, i, t ) (SSO1 ) ∀ t , ∄j • θ(DEST LIST , j , t ) ⇒ ∄i • θ(StartMPD→, i, t ) DestListPage (I1 ) θ(DestListPage→, 1, 0) (SO1 ) ∀ i, t • θ(DestListPage→, i, t ) ∧ i > 1 ⇒ ∃ j • θ(→DisplayDestList, j , t ) (SO2 ) ∀ i, t • θ(DestListPage→, i, t ) ∧ i > 1 ⇒ ∃ j • θ(accessed , j , t ) (SI1 ) ∀ i, t • θ(→DestListPage, i, t ) ⇒ ∃ j • θ(StartMPD→, j , t ) (SI2 ) ∀ i, t • θ(→DestListPage, i, t ) ⇒ ∃ j • θ(DEST LIST , j , t ) (SI3 ) ∀ i, t • θ(→DestListPage, i, t ) ⇒ ∃ j • θ(retrieve, j , t ) (PSO1 ) ∀ i, t • ini(DestListPage, i, t ) ∧ ∃ j • θ(accessed , j , t ) ⇒ θ(DestListPage→, i + 1, t ) (SSO1 ) ∀ t , ∄j • θ(accessed , j , t ) ⇒ ∄i • i > 1 ∧ θ(DestListPage→, i, t ) DisplayDestList (I1 ) θ(DisplayDestList→, 1, 0) (SO1 ) ∀ i, t • θ(DisplayDestList→, i, t ) ∧ i > 1 ⇒ ∃ j • θ(→DestListDisplayed , j , t ) (SO2 ) ∀ i, t • θ(DisplayDestList→, i, t ) ∧ i > 1 ⇒ ∃ t1 • θ(→DisplayDestList, i − 1, t1 ) ∧ t1 + l2 ≤ t ≤ t1 + u2 (MI1 ) ∀ i, t • θ(→DisplayDestList, i, t ) ⇒ ∃ k , j • k > 1 ∧ θ(accessed , j , t ) ∧ θ(DestListPage→, k , t ) ∨ ∃ k , j • k > 1 ∧ θ(accepted , j , t ) ∧ θ(DataEntered→, k , t ) (PSO1 ) ∀ i, t • θ(→DisplayDestList, i, t ) ⇒ ∃ t1 • θ(DisplayDestList→, i + 1, t1 ) ∧ t + l2 ≤ t1 ≤ t + u2 DestListDisplayed (I1 ) θ(DestListDisplayed→, 1, 0) (MO1 ) ∀ i, t • θ(DestListDisplayed→, i, t ) ∧ i > 1 ⇒ ∃ j , k • θ(FORMAT SELECT , j , t ) ∧ θ(→StartMPD , k , t ) ∨ ∃ j , k • θ(WAYPOINT SELECT , j , t ) ∧ θ(→SelectingWaypoint , k , t ) (SI1 ) ∀ i, t • θ(→DestListDisplayed , i, t ) ⇒ ∃ j • θ(DisplayDestList→, j , t ) (SI2 ) ∀ i, t • θ(→DestListDisplayed , i, t ) ⇒ ∃ t1 , j • θ(→DisplayDestList, j , t1 ) ∧ t1 + l2 ≤ t ≤ t1 + u2 (PMO1 ) ∀ i, t • ini(DestListDisplayed , i, t ) ∧ ∃ j • θ(WAYPOINT SELECT , j , t ) ∨ θ(FORMAT SELECT , j , t ) ⇒ θ(DestListDisplayed→, i + 1, t ) (SMO1 ) ∀ t , ∄j • θ(WAYPOINT SELECT , j , t ) ∨ θ(FORMAT SELECT , j , t ) ⇒ ∄i • i > 1 ∧ θ(DestListDisplayed→, i, t ) SelectingWaypoint (I1 ) θ(SelectingWaypoint→, 1, 0) (SO1 ) ∀ i, t • θ(SelectingWaypoint→, i, t ) ∧ i > 1 ⇒ ∃ j • θ(→EnteringNewData, j , t ) (SO2 ) ∀ i, t • θ(SelectingWaypoint→, i, t ) ∧ i > 1 ⇒ ∃ j • θ(ENT , j , t ) (SI1 ) ∀ i, t • θ(→SelectingWaypoint , i, t ) ⇒ ∃ j • θ(DestListDisplayed→, j , t ) (SI2 ) ∀ i, t • θ(→SelectingWaypoint , i, t ) ⇒ ∃ j • θ(WAYPOINT SELECT , j , t ) (PSO1 ) ∀ i, t • ini(SelectingWaypoint , i, t ) ∧ ∃ j • θ(ENT , j , t ) ⇒ θ(SelectingWaypoint→, i + 1, t ) (SSO1 ) ∀ t , ∄j • θ(ENT , j , t ) ⇒ ∄i • i > 1 ∧ θ(SelectingWaypoint→, i, t ) EnteringNewData (I1 ) θ(EnteringNewData→, 1, 0) (SO1 ) ∀ i, t • θ(EnteringNewData→, i, t ) ∧ i > 1 ⇒ ∃ j • θ(→DataEntered , j , t ) (SO2 ) ∀ i, t • θ(EnteringNewData→, i, t ) ∧ i > 1 ⇒ ∃ j • θ(ENT , i, t ) (SO3 ) ∀ i, t • θ(EnteringNewData→, i, t ) ∧ i > 1 ⇔ θ(validate, i − 1, t ) (MI1 ) ∀ i, t • θ(→EnteringNewData, i, t ) ⇒ ∃ k , j • k > 1 ∧ θ(rejected , j , t ) ∧ θ(DataEntered→, k , t ) ∨ ∃ k , j • k > 1 ∧ θ(ENT , j , t ) ∧ θ(SelectingWaypoint→, k , t ) (PSO1 ) ∀ i, t • ini(EnteringNewData, i, t ) ∧ ∃ j • θ(ENT , j , t ) ⇒ θ(EnteringNewData→, i + 1, t ) (SSO1 ) ∀ t , ∄j • θ(ENT , j , t ) ⇒ ∄i • i > 1 ∧ θ(EnteringNewData→, i, t ) DataEntered (I1 ) θ(DataEntered→, 1, 0) (MO1 ) ∀ i, t • θ(DataEntered→, i, t ) ∧ i > 1 ⇒ ∃ j , k • θ(rejected , j , t ) ∧ θ(→EnteringNewData, k , t ) ∨ ∃ j , k • θ(accepted , j , t ) ∧ θ(→DisplayDestList, k , t ) (SI1 ) ∀ i, t • θ(→DataEntered , i, t ) ⇒ ∃ j • θ(EnteringNewData→, j , t ) (SI2 ) ∀ i, t • θ(→DataEntered , i, t ) ⇒ ∃ j • θ(ENT , j , t ) (SI3 ) ∀ i, t • θ(→DataEntered , i, t ) ⇔ θ(validate, i, t ) (PMO1 ) ∀ i, t • ini(DataEntered , i, t ) ∧ ∃ j • θ(rejected , j , t ) ∨ θ(accepted , j , t ) ⇒ θ(DataEntered→, i + 1, t ) (SMO1 ) ∀ t , ∄j • θ(rejected , j , t ) ∨ θ(accepted , j , t ) ⇒ ∄i • i > 1 ∧ θ(DataEntered→, i, t )