ADL: An Activity Description Language for Real-Time ... - CiteSeerX

ADL: An Activity Description Language for Real-Time Networks Stephen Payntera , Jim Armstrongb , and Jan Havemanc

a Matra BAe Dynamics (UK) Ltd, Filton, Bristol, UK b Flour Global Services Consulting, Farnham, UK

c Motorola Worldwide Smartcard Solutions Division, UK

November 8, 2000 Abstract

This paper introduces and motivates ADL, a new formal notation for the speci cation of the temporal and functional behaviour of concurrent processes. ADL is tailored to be directly compatible with the DORIS design method. It combines a graphical Activity State-Machine (ASM) notation and a model-based Activity Functional Behaviour (AFB) notation. The abstract syntax, and static and dynamic semantics for the ASM notation are given, the dynamic semantics being given proof-theoretically in many-sorted logic extended with the RTL òccurrence' relation, , and the ERTL `holding' relation, . ADL is used to specify a small network, and proofs are given of its timeliness and safety properties.

1 Introduction Safety-critical software (SCS) should be kept simple to ease the demanding task of validating and verifying its behaviour to a sucent level of con dence. This means that, ideally, SCS should not contain the complexity of concurrency. Unfortunately, concurrency cannot always be avoided. It is inherently present when the SCS is part of a larger system which has to be implemented on multiple processors, or when it is implemented on its own processor in order to protect it from corruption from software developed to lower integrity levels. Concurrency also arises when diverse or replicated systems are used for fault-tolerance, or computationally intensive tasks have to meet tight deadlines. Furthermore, concurrency is often the most natural way to structure systems which are responsible for controlling multiple variables at the same time, as is usually the case in embedded real-time systems. Therefore, since much safety-critical software is also embedded real-time software, concurrency is often unavoidable. Correspondence to: S.E. Paynter, Matra BAe Dynamics (UK) Ltd, FPC 450, P.O. Box 5, Filton, Bristol, BS34 7QW, UK. E-mail: [email protected]

1

Formal speci cation notations, and the formal discharging of validation conjectures about speci cations expressed using such notations, although they have limitations [Kne97], are widely recognised as technologies which can be used to contribute to the con dence that can be put in the correctness of the safetycritical software [BaM92] and [MoD97]. Therefore, there is a need to be able to specify and reason formally about concurrent real-time behaviour. The authors have argued elsewhere that if formal techniques for large systems are to be successfully transferred into industrial practice, they need to be integrated into an architectural design method [PAH99]. DORIS, the DataOriented Requirements Implementation Scheme [Sim94a] and [Sim94b] is an architectural design method being developed in Matra BAe Dynamics for complex high-integrity real-time systems based on the real-time network computational model [Sim90]. DORIS needs to be extended with a formal language for specifying the real-time behaviour of concurrent processes. Single-threaded processes are known as activities in DORIS. This Activity Description Language, or ADL, proposed in this paper consists of a textual model-based Activity Functional Behaviour (AFB) notation and a graphical Activity State-Machine (ASM) notation. This section continues with an informal introduction to ADL. Section 2 introduces the well-formedness rules of the ASM notation. Section 3 de nes the proof-theoretic dynamic semantics of the ASM notation. Section 4 shows how ADL speci cations are formally embedded in concurrent designs, and Section 5 illustrates the use of ADL on a small case study. Two activities are speci ed, and proofs are given of the network's timeliness and safety properties. Section 6 contains a brief discussion of the tool support being developed for ADL, and conclusions and further work are identi ed in Section 7. There are four appendices: the rst formalises the abstract syntax and static semantics of the ASM notation; the second de nes the logic used in the dynamic semantics; the third contains the theory generated from the example; and the fourth contains proofs of the lemmas used in the timeliness proof.

1.1 Overview of the ADL

DORIS is based on the successful MASCOT-3 design method [Sim86] [JIM87] [Woo96], which was the UK Ministry of Defence's preferred design approach [MoD85] and [MoD91]. There are two main features of DORIS designs that have an impact on ADL. Firstly, DORIS provides a rich set of protocols by which activities can communicate with each other [Sim99a-c], and secondly, DORIS distinguishes between application network designs, which de ne the logical architecture of the system, and execution network designs, which extend the application network to include all the extra design components needed to support its distribution across a particular processor network. This separation supports the re-mapping of a design to the hardware platform, as the hardware evolves during the life of the project [Woo96]. Both application and execution networks may contain activities. The ADL needs to be suitable for use at both levels of abstraction. This means that the 2

deadline progress assumption, (as used in the Temporal Agent Model [ScZ92]), is the most appropriate for the ADL: it states that an activity may make any degree of progress providing it nishes within its deadlines. The scheduling progress assumption, which explicitly models the scheduling algorithm [Hoo91], is inappropriate because neither the mapping of activities to processors, nor the extra activities needed to support the distribution, are identi ed until after the execution network is designed. The maximum progress assumption, which requires an activity to advance when it is not waiting to engage in a synchronous communication, is not suitable because it will not normally be the case that each activity will be mapped to a dierent processor. Although it is possible to model deadline progress using maximal progress, such modelling is not appropriate in a speci cation language, where the constructs provided should match the users' concerns. It is necessary for an activity's functional and temporal properties to be handled in a common semantic framework, as they will often interact. Since activities are reactive [MaP92] (i.e. the relative progress of an activity through its algorithm with respect to the changes in its environment will in uence its behaviour), a model-based speci cation language alone is not adequate to express this behaviour. The ADL therefore should be integrated into the DORIS design notation; able to handle synchronous and asynchronous communication; be based on the deadline progress assumption; and combine reactive functional and temporal behaviour within a common framework. Ideally, it would be directly based on a standardised, tool-supported, formal speci cation language. In practice, this can only be partly achieved at present, by partitioning the ADL into the AFB notation, which is based on VDM-SL [Jon90] and [ISO96], and the new ASM notation, which supplements the AFB notation in the ways needed.

1.2 Activity State-Machine (ASM) Notation

In the ASM notation, static and dynamic states are distinguished. Static states are used to model the potential descheduling points in an activity's algorithm. An activity is not executing when in a static state. Either it is attempting to communicate using a synchronous protocol, or it is engaged in a timed delay. Transitions from a static state are labelled either with the event indicating that the communication may continue or nish, or with the lower and upper time bounds of the delay. Dynamic states are used to model an activity's computation. Each dynamic state encapsulates some non-reactive functionality. Composite and simple dynamic states are distinguished. A simple dynamic state has only one operation associated with it, and hence only references at most one input port and one output port. The input is read when the state is entered, and the output produced when it is left. The restriction to a single input and output per state is made to enable the functionality of a dynamic state to be expressed by a single VDMSL operation. VDM-SL, which is without explicit support for inter-conditions, history variables, or timed variables, is unable to capture the order and relative 3

timing of interactions. It is therefore inappropriate for simple dynamic states to have multiple inputs or outputs. This restriction keeps the description and semantics of dynamic states simple, but has the eect of requiring more states to be identi ed. A dynamic state may freely update the activity's local state (i.e. its variables), because it can only be modi ed by dynamic states within that activity, and a DORIS activity is sequential. A composite dynamic state has two or more operations associated with it, and these may be executed in any order. Only mutually non-interfering operations may be aggregated in this way. A dynamic state has lower and upper time bounds. The speci ed system is required to exit a state within these bounds if the pre-condition of its associated operation holds upon entry, (i.e. the deadline progress assumption is adopted). An implementation can be veri ed against such a speci cation by, for example, worst-case-execution-time and schedulability analysis [CBW96], [ABR93] and [Bur95], but only once the execution network has been designed and mapped to a processor network, the activity code written, and the scheduling algorithm de ned. Being non-reactive, dynamic states cannot be aborted by the occurrence of an event. Transitions from a dynamic state can only be labelled with conditions over the activity's local state, and these are evaluated when a dynamic state terminates. Because synchronous communications do not necessarily entail a wait, an activity may pass through a static state instantaneously. To support this interpretation, transitions are assumed to take zero (negligible) time. Dynamic states, in contrast, because they must perform some computation, have positive lower time bounds. In an ASM, a static state is represented by an oval and a dynamic state by a rectangle. The data- ows to and from an activity are referenced by `port names', and if there is an input or output associated with a dynamic state, it is recorded by the appropriate port name in the top left and right hand corners of the rectangle, respectively. A port de nes the interface that an activity requires of a data- ow connection. This enables the activity to be considered independently from particular networks. Although in DORIS linking activities into networks using ports can be complex [JIM87], in this paper the relation of ports to protocols is always one-to-one. The labels in the bottom left and right hand corners of a dynamic state record its lower and upper time bounds, respectively. A composite dynamic state is represented like a simple dynamic state, except it is partitioned using dotted lines. There is one partition for each operation, and each partition may refer to an input and output port. The graphical presentation of an ASM speci cation is illustrated in Fig. 1. The activity is represented by the circle; its ports by solid spots on its circumference, and the data ows by arrows to or from a port annotated with a symbol representing one of the DORIS protocols. This is standard DORIS design notation. The initial state is the target of a transition with no source; e.g. state A in Fig. 1. 4

Wp5

A

F

p4

Sp1a

p1 p2 p3 p2

l3

p5 E

u3

l2

p2

c2 p4

D

C

G

u1 c1

p3 p3

Sp1g

B

l1

u2

p5

Figure 1: An ASM Speci cation of a DORIS Activity The activity in Fig. 1 starts in state A. It stays there until a stimulus event Sp1a from port p 1 occurs. It then enters state B and reads port p 2. Within u1 time units later state B is exited, conditions c1 and c2 are evaluated, and the appropriate transition is taken (non exclusive conditions entail non-determinism). If the transition labelled with c1 is taken, the operations corresponding to states C and D are executed in an unspeci ed order, with state D reading from p 2 and writing to p 4, and state C reading from p 3. Within l2 and u2 time units of the composite state being entered, it is left, and state E is entered. State E reads from p 3 and writes to p 5 between l3 and u3 time units later. p 5 is connected to a `channel' protocol, which means that there may not be any space for the value E generates. In that case, the activity waits in state F for the release event from the channel which indicates that space is now available.

1.3 Activity Functional Behaviour (AFB) Notation

The AFB notation is interpreted in a timed context, while standard VDM-SL is untimed. The AFB is based on a subset of VDM-SL which we have found to be sucient for our needs, and which has a simpler proof-theory than full VDM-SL [BFL94] and [Lar95]. An AFB description of an activity efectively consists of a VDM-SL module, whose types and state are used to describe the local state of the activity (i.e. its variables). The module's operations are related to the ASM's dynamic states. An operation will have a single input parameter if and only if the corresponding dynamic state has an input; and an output result if and only if the dynamic state has an output. A full de nition of the AFB notation is beyond the scope of this paper, although one can be found in [Pay99]. 5

Table 1: The Basic DORIS Protocols Read data not consumed Read data consumed (Never held up) (Held up when no data) Old data overwritten (Never held up) Signal Pool Old data not Overwritten (Held up when no space) Constant Channel

2 Well-formed ADL Speci cations ADL's raison d'être is proper integration into the DORIS design method. There are numerous well-formedness constraints needed to ensure that a composite DORIS design and ADL speci cation is meaningful. The ADL abstract syntax and static semantics are given formally in Appendix 1, but here the principle restrictions and their rationale are introduced. To state the well-formedness constraints requires the introduction of a few of the DORIS communication protocols. The three basic protocols are the signal , pool , and channel , and these can be understood as imposing dierent synchronisation constraints on the reader and writer of the protocol, depending on whether or not they allow data to be destroyed when it is read or written; this is summarised in Table. 1. The pool is similar to a shared variable and the channel to the one-place bounded buer. The other important class of protocols from the ADL point of view are those which only allow the communication of `void' or `null' data; this is represented by a solid circle at the centre of the protocol symbol, (an example can be seen on the data- ow to port p 1 in Fig. 1). Only the signal and channel protocols (of the ones introduced in this paper) can be extended in this way, when they are known as the stimulus and dataless channel protocols, respectively. A dynamic state may only read from ports which are connected to data- ows into the activity, and write to ports which are connected to data- ows from the activity. There are three kinds of event labels which may annotate transitions from static states, known as `S', `W', and `R' events. Any port associated with an `S' `stim' event must be one that is connected to a data- ow with a `void data' protocol. No port with a void data- ow may be read by any dynamic state, as there can be no data to read. (See Appendix 1, 20.4) A transition labelled with an `R' or `read' event must terminate at a dynamic state which reads from the same port. If a dynamic state reads from a holding protocol, each transition into it must originate from a static state. These static states model the wait for data. The intuition is that entering the preceding static state marks the start of the attempt to read, and that the `R' event indicates 6

that data is now present. The dynamic state's rst task is to read that value. Event labels on transitions from dierent static states must be dierent (Appendix. 1, 43.21), as this uniqueness helps simplify the resulting theory, (see Ax 7, below). This explains the Sp1a and Sp1g events in Fig. 1. A dynamic state which writes to a port with a channel protocol must be followed by a static state which is itself the source of a transition with a `W' or `write' event associated with the same port. This captures the possibility of descheduling should the channel be full, (Appendix 1, 43.14). This is illustrated by states E and F in Fig. 1. Hence, the aggregated operations in a composite dynamic state may neither write to a port associated with a channel protocol, nor read from one associated with anything other than a pool, because of the need to model synchronisation points by explicit static states, (Appendix 1, 26.5-.12). Finally, a static state may have only one exit transition, (Appendix 1, 43.11). This is in keeping with the DORIS design philosophy, which requires that the fact that an activity is waiting upon events from more than one source be recorded explicitly. This is achieved by combining these data- ows into a single

ow outside of the activity. We have found that this improves the comprehensibility of a DORIS design.

3 ADL Dynamic Semantics This section gives the proof-theoretic dynamic semantics for the ASM notation and discusses the semantics of the AFB notation. An axiomatic style of semantics was chosen over a constructive `de nitional' style for practical reasons. The engineering practicalities of using a proof theory was our immediate concern, rather than absolute formality. Informal assurances of consistency and completeness (e.g. by inspection) suce, but only until the cost of formal assurances can be justi ed in terms of the likely integration of the proof technology into the development process.

3.1 Semantic Logic

The ADL semantics are expressed in this paper in classical many-sorted logic [Man93] extended with arithmetic, the Real-Time Logic (RTL) òccurrence' relation, [JaM86] and [JMS88], and the Extended Real-Time Logic (ERTL) `holding' relation, [HaL96]. The sorts are used, amongst other things, to model the data-types used in the AFB notation. The RTL occurrence relation, , relates events, occurrence numbers, and times. That is, (e i t ) is the proposition that event e occurs for the i th time at time t . is characterised by two axioms given in Appendix 2. The ERTL holding relation, , asserts that an untimed predicate (one that does not contain the occurrence or holding relations) holds at a particular time. That is, (P i t ) is the proposition that predicate P is true for the i th time ;

;

;

;

7

at time t . is characterised by four axioms [HaL96], which are also given in Appendix 2. It is assumed that there are sucient RTL events so that disparate things are not con ated, for example that the entry of one state is not the same event as the exit of another (although, of course, they may be asserted to occur at the same time.)

3.2 Semantic Function

The semantics of the ASM notation are de ned in this section by describing the semantic function, . It consists of a series of axiom schemata, each of which has the form: every syntactic entity in the ASM speci cation, (for example, each state, transition, etc.) which satis es certain static connection properties, will exhibit some speci ed dynamic behaviour. As an aid to make the dynamic behaviour more visible in the following presentation, the quanti cation over the syntactic entities of the speci cation is left implicit, and the static syntactic guards are presented in square brackets at the start of each schema.

is de ned using the following total injections " and # with disjoint ranges. They return the events which correspond to the entering and leaving of a state, respectively:

"; # : State ! Event The following functions de ne when an ASM is in a dynamic or static state: ind : DynamicState Occ Time ! B ind (s ; i ; t ) 4 9 t1 : Time t1 t ^ (" s ; i ; t1 ) ^ 8t2 : Time t1 t2 t ) : (# s ; i ; t2 ) ins : StaticState Occ Time ! B ins (s ; i ; t ) 4 9 t1 : Time t1 t ^ (" s ; i ; t1 ) ^ 8t2 : Time t1 t2 < t ) : (# s ; i ; t2 )

Note that an activity leaves a dynamic state at the moment a transition from it is taken, while an activity remains in a static state at the moment it is exited. This follows from static states being able to be passed through instantaneously. An ADL speci cation is a 6-tuple, given by mk-ADL(ports, variables, operations, states, transitions, initial). Transitions in turn are characterised by their source and target states (denoted by the elds, src and tgt ), and by their label, (denoted by the label eld). See Appendix 1 for details. For brevity in the axiom schemata below, the set of transitions in the ASM will be referred to as ts . The following four functions de ne syntactic properties of ASMs, and are used in the guards to the axiom schemas below. :

:

TransitionsOut : State Transition -set ! Transition -set

8

:

TransitionsOut (s ; ts ) 4 ft j t 2 ts t :src = s g TransitionsIn : State Transition -set ! Transition -set TransitionsIn (s ; ts ) 4 ft j t 2 ts t :tgt = s g Successors : State State -set Transition -set ! State -set Successors (s ; states ; ts ) 4 fs 0 2 states j 9 t 2 ts t :src = s ^ t :tgt = s 0 g Predecessors : State State -set Transition -set ! State -set Predecessors (s ; states ; ts ) 4 fs 0 2 states j 9 t 2 ts t :src = s 0 ^ t :tgt = s g

The function Enabled returns the set of transitions from a state which have true conditions at a given time. Enabled : State Transition -set Time ! Transition -set Enabled (s ; ts ; t ) 4 ftr 2 ts j tr :src = s ^ 9 i : Occ (tr :label :c ; i ; t )g

The following four functions characterise whether a state has a single or multiple entry transitions, and single or multiple exit transitions: SE ; ME ; SX ; MX : State State -set Transition -set ! B SE (s ; states ; ts ) 4 card Predecessors (s ; states ; ts ) = 1 ME (s ; states ; ts ) 4 card Predecessors (s ; states ; ts ) > 1 SX (s ; states ; ts ) 4 card Successors (s ; states ; ts ) = 1 MX (s ; states ; ts ) 4 card Successors (s ; states ; ts ) > 1

where SE stands for single entry ; ME stands for multiple entries ; SX stands for single exit ; and MX stands for multiple exits . The abstract syntax ensures there is at most one transition between a given pair of states, (Appendix 1, 43.20). The axiom schemas which de ne are partitioned into the following families: Startup ; State Exit ; State Entry ; Progress and Stability axioms, following the state-machine axiomatisation in [ArB96].

3.2.1 Startup Axiom

At start-up, an ASM enters the initial state (for the rst time):

Ax 1 [true ] (" initial ; 1; 0)

3.2.2 State Exit Axioms

If a static state is exited, its successor state will be entered at the same instant.

Ax 2 [is-StaticState (s :s ); TransitionsOut (s ; ts ) 6= ;; st 2 Successors (s ; states ; ts )] 8i : Occ ; t : Time (# s ; i ; t ) ) ((SE (st ; states ; ts )st = 6 initial ^ (" st ; i ; t )) _ (SE (st ; states ; ts )st = initial (" st ; i + 1; t )) _ (ME (st ; states ; ts )st = 6 initial 9 j : Occ j i ^ (" st ; j ; t )) _ (ME (st ; states ; ts )st = initial 9 j : Occ j i + 1 ^ (" st ; j ; t ))) 9

Note, the conditions in the square brackets at the top of the schema, are its guards. The complexity of this schema derives from the fact that it de nes the relationship between the number of times the source state has been exited, and the number of times the target has been entered. This depends upon the number of transitions into the target state, and the fact that the guard and static semantics together ensure that the source state will have a single exit transition, (Appendix 1, 43.11). This information is static, and may be exploited when instantiating the schema for each pair of states which satisfy the guard to determine which clause of the schema applies. Exploiting this information when instantiating the schema is helpful; trivial proofs about the relationship between target and source indexes need not be repeated for each separate ASM speci cation; and the resulting theory presentation is more elegant. When a dynamic state is exited, a non-deterministic choice of one of its successors is made, and that state is entered. Only the targets of transitions whose conditions are true when the dynamic state is exited are considered.

Ax 3 [is-DynamicState (s :s )]

8i : Occ ; t : Time (# s ; i ; t )9 tr : ts tr 2 Enabled (s ; ts ; t ) ) let st = tr :tgt in (s = st (" st ; i + 1; t )) _ (s = 6 st SX (s ; states ; ts )SE (st ; states ; ts )st =6 initial ^ (" st ; i ; t )) _ (s = 6 st SX (s ; states ; ts )SE (st ; states ; ts )st = initial ^ (" st ; i + 1; t )) _ (s = 6 st SX (s ; states ; ts )ME (st ; states ; ts )st =6 initial ^ 9 j : Occ j i ^ (" st ; j ; t ) _ (s = 6 st SX (s ; states ; ts )ME (st ; states ; ts )st = initial ^ 9 j : Occ j i + 1 ^ (" st ; j ; t ) _ (s = 6 st MX (s ; states ; ts )SE (st ; states ; ts )st =6 initial ^ 9 j : Occ j i ^ (" st ; j ; t ) _ (s = 6 st MX (s ; states ; ts )SE (st ; states ; ts )st = initial ^ 9 j : Occ j i + 1 ^ (" st ; j ; t ) _ (s = 6 st MX (s ; states ; ts )ME (st ; states ; ts )st =6 initial ^ 9 j : Occ (" st ; j ; t ) _ (s = 6 st MX (s ; states ; ts )ME (st ; states ; ts )st = initial ^ 9 j : Occ (" st ; j + 1; t ))) The relationship between the occurrence of entry and exit events when leaving a dynamic state is complicated by the possibility of multiple exits. Furthermore, a dynamic state may be both the source and target of a transition. Clearly, when the exit transitions are mutually exclusive, or there is only one exit transition labelled with a tautology, the schema can be simpli ed.

3.2.3 State Entry Axioms

If the initial state is entered, either it is entered for the rst time, or one of its predecessor states will be exited.

Ax 4 [s = initial ]

8i : Occ ; t : Time (i > 1 (" s ; i ; t ) ) 9 ss 2 Predecessors (s ; states ; ts )) (ss = si > 1 ^ (# ss ; i ? 1; t )) _ 10

(ss 6= sSX (ss ; states ; ts )SE (s ; states ; ts ) (# ss ; i -1; t )) _ (ss 6= sSX (ss ; states ; ts )ME (s ; states ; ts )9 j : Occ j i ? 1 ^ (# ss ; j ; t )) _ (ss 6= sMX (ss ; states ; ts )SE (s ; states ; ts )9 j : Occ j i ? 1 ^ (# ss ; j ; t )) _ (ss 6= sMX (ss ; states ; ts )ME (s ; states ; ts )9 j : Occ (# ss ; j ; t )))

Note this schema depends on all states being reachable, and on there only being one transition between any pair of states, (Appendix 1, 43.9 and 43.20). If a non-initial state is entered, one of its predecessor states will be exited. Ax 5 [s =6 initial ] 8i : Occ ; t : Time (" s ; i ; t ) ) 9 ss 2 Predecessors (s ; states ; ts ) ((ss = si > 1 (# ss ; i ? 1; t )) _ (ss = 6 sSX (ss ; states ; ts )SE (s ; states ; ts ) (# ss ; i ; t )) _ (ss = 6 sSX (ss ; states ; ts )ME (s ; states ; ts )9 j : Occ j i ^ (# ss ; j ; t )) _ (ss = 6 sMX (ss ; states ; ts )SE (s ; states ; ts )9 j : Occ j i (# ss ; j ; t )) _ (ss = 6 sMX (ss ; states ; ts )ME (s ; states ; ts )9 j : Occ (# ss ; j ; t )))

3.2.4 State Progress Axioms

Dynamic states are always exited within their time bounds.


8i : Occ ; t : Time (" s ; i ; t ) ) 9 t1 : Time t + s :timing :dmin t1 t + s :timing :dmax (# s ; i ; t1 ) The assumption is that the pre-condition of the operation associated with the dynamic state will hold on entry. See below for a discussion of the resulting proof obligation. Static states are left when the event or timeout on their exiting transition is true: Ax 7 [is-StaticState (s :s ); tr 2 TransitionsOut (s ; ts ); is-Event (tr :label :l ); tr :label :l = e]

8i : Occ ; t : Time (e ; i ; t ) ) (# s ; i ; t ) It should be noted that the link axioms, (see Section 4.2), ensure that an event only occurs when the ASM is in the appropriate static state. (The implication can be strengthened to an equivalence, because of uniqueness of event names, Appendix 1, 43.21)

Ax 8 [is-StaticState (s :s ); is-TimeBounds (tr :label :l ); tr :label :l = (l ; u )]

8i : Occ ; t : Time (" s ; i ; t ) ) 9 t1 : Time t + l t1 t + u (# s ; i ; t1 )

3.2.5 State Stability Axioms

States are only exited under the conditions speci ed by the progress axioms.


8i : Occ ; t : Time (# s ; i ; t ) ) 9 t1 : Time t ? s :timing :dmax t1 t ? s :timing :dmin (" s ; i ; t1 ) 11

Ax 10 [is-StaticState (s :s ); card Successor (s ; states ; ts ) 6= ;; is-TimeBounds (tr :label :l ); tr :label :l = (l ; u )] 8i : Occ ; t : Time (# s ; i ; t ) ) 9 t1 : Time t ? u t1 t ? l (" s ; i ; t1 )

Ax 11 [is-StaticState (s :s ); card Successor (s ; states ; ts ) 6= ;; is-Event (tr :label :l ); tr :label :l = e ] 8i : Occ ; t : Time (# s ; i ; t ) ) 9 j : Occ ins (s ; i ; t ) ^ (e ; j ; t )

Ax 12 [is-StaticState (s :s ); card Successor (s ; states ; ts ) = ;] 8i : Occ ; t : Time : (# s ; i ; t )

3.3 AFB Notation

AFB operations are interpreted within the timed framework de ned by the ASM notation. In particular, the post-condition will hold when the state is left (again assuming the pre-condition held on entry). Consider the operation, OpS , which is associated with a dynamic state, s , and which reads a value of type p 1 datatype domain from port p 1, and writes a value of type p 2 datatype domain to port p 2. :

:

:

:

operations

1.0 OpS (s :s :in : p 1:datatype :domain ) s :s :out : p 2:datatype :domain .1 ext wr vs : Var -set .2 pre s :s :Pre (s :in ; vs ) .3 post s :s :Post (s :in ; ( vs?; vs ; s :out )


8i : Occ ; t : Time (# s ; i ; t ) ) 9 j : Occ (s :s :Post (s :s :in ; ( vs?; vs ; s :s :out ); j ; t )

When s is a composite state, if all the pre-conditions of the operations hold upon entry, all the post-conditions will hold upon exit. Our approach to ensuring this conjunction is consistent is to enforce a static semantic constraint on the AFB. We require that the operations of a composite state to operate on disjoint portions of the local state and access dierent ports (See Appendix 1, 26.4-.12).

3.4 Proof Obligations

It is evident that can only produce a consistent theory from ADL speci cations satisfying certain proof obligations: namely, for each dynamic state, the precondition must hold on each entry; the operation to be carried out must be satis able; and on its completion, at least one exit condition must be true. See, for example, axioms 3, 6, 9, and 13. Each operation has to be satis able in the VDM sense [Jon90]. With a slight abuse of notation, this can be formalised as: PO 1 8op : Operation 9 x : Data Value*op :Pre (x ) 8x : Data Value*op :Pre (x ) ) 9 y : Data Value*op :Post (x ; y ) 12

If Appendix 1 covered the whole ADL, and not just the ASM, this could be properly formalised as part of the static semantics. It is noted that this property is independent of the structure of the ASM speci cation. The same is not true of precondition satisfaction. The proof obligation is:

PO 2 8s : State ; i : Occ; t : Time

is-DynamicState (s :s ) (" s ; i ; t ) ) 9 j : Occ (s :s :Pre ; j ; t )

The use of axioms generated by in discharging this proof obligation is in keeping with the normal practice in program veri cation [PVL92] [Bar97], where programs are proved correct assuming all procedures used in the algorithm are satis able and are called within their pre-conditions (i.e. their post-conditions are used). A subsequent step establishes that each procedure is indeed called within its pre-condition, again using the post-conditions of any called procedures. When s is a composite dynamic state, s s Pre is the conjunction of the preconditions of the operations. The availability of a valid exit on completion of each dynamic state is guaranteed by establishing: : :

PO 3 8s : State ; i : Occ; t : Time

is-DynamicState (s :s ) (# s ; i ; t ) ) 9 tr : Transition tr 2 Enabled (s ; ts ; t )

This property can be established independently of the ASM behaviour if the disjunction of each exit condition forms a tautology. We have not included this constraint in the static semantics, and the axioms do not assume it (e.g. Ax. 3), as we wish to retain the option of exploiting dynamic properties in its proof.

4 Reasoning about Networks In many systems it is not enough to be able to specify and reason about isolated activities. Unfortunately, a complete solution to reasoning about a network of activities would require the DORIS language and semantics to be formally de ned. This will be the subject of a future paper, in the interim, it is noted that DORIS activities cannot be connected together directly; they must communicate via routes which have a particular protocol. (The DORIS protocols have a proof-theoretic semantics in RTL [Sim99a] and are currently undergoing standardisation with the BSI.) The axioms which characterise one particular protocol, the channel, are given in this section; and are used in the next to illustrate how two activities connected via a channel can be reasoned about. The DORIS channel protocol is similar to an one-place bounded buer, and can be characterised by axioms expressed in terms of three write and three read events. The write events are: write-data-start, (wds ); write-data-end, (wde ); and write-end, (we ), and the read events are read-start, (rs ); read-data-start, (rds ); and read-data-end, (rde ). Each protocol is also characterised by two 13

events: item-written, (iw ), and item-read, (ir ): these are the events which record that an item has been written into or read from a protocol. A DORIS channel is novel in that it provides two extra storage elements: one in which a data item may be placed when the channel is full and one in which data is in while being read. Although the producer may write into the extra element, it is not released until the consumer starts to read some data. This explains the distinction between wde , which records that the data has been written, and we , which records that the data has been accepted. They are coincident when the channel is not full. The rs and rds events are distinguished, as rs occurs when an attempt is been made to start reading, (although there may not be any data in the channel), and rds occurs when data is starting to be read. When data is present when the read starts, rs and rds are coincident. The extra read storage element, allows the start of a read event, rs , to release a held writer.

4.1 The Channel Axioms

The rst axiom de nes the ordering of events within a read, and prevents later reads from starting before earlier reads have nished, and the second does the same for writes.

ChAx 1 8i : Occ; t1 ; t2 ; t3 ; t4 : Time

( (rs ; i ; t1 ) ^ (rds ; i ; t2 ) ^ (rde ; i ; t3 ) ^ (rs ; i + 1; t4 )) ) (t1 t2 < t3 < t4 )

ChAx 2 8i : Occ; t1 ; t2 ; t3 ; t4 : Time

( (wds ; i ; t1 ) ^ (wde ; i ; t2 ) ^ (we ; i ; t3 ) ^ (wds ; i + 1; t4 )) ) (t1 < t2 t3 < t4 )

It is only possible to start reading data from a channel once it has been placed in the channel.

ChAx 3 8i : Occ

(9 t3 : Time (rds ; i ; t3 )) , (9 t1 ; t2 : Time (rs ; i ; t1 ) ^ (wde ; i ; t2 ))

The start of read data is coincident with the start of a read if there is already data in the channel, otherwise it is coincident with the data becoming available after it has been written.

ChAx 4 8i : Occ; t1 ; t2 ; t3 : Time ( (rs ; i ; t1 ) ^ (wde ; i ; t2 ) ^ (rds ; i ; t3 )) ) ((t1 < t2 ) t3 = t2 ) ^ (t1 t2 ) t3 = t1 ))

The (i + 1)th write can only end once the i th read has started.

ChAx 5 8i : Occ (9 t3 : Time (we ; i + 1; t3 )) , (9 t1 ; t2 : Time (wde ; i + 1; t1 ) ^ (rs ; i ; t2 ))

The end of the (i + 1)th write is coincident with the corresponding end of write data, if there is space in the channel, otherwise it is coincident with space becoming available. 14

ChAx 6 8i : Occ; t1 ; t2 ; t3 : Time

( (wde ; i + 1; t1 ) ^ (rs ; i ; t2 ) ^ (we ; i + 1; t3 )) ) ((t1 < t2 ) t3 = t2 ) ^ (t1 t2 ) t3 = t1 ))

The rst write is not constrained, as there will be space for the data. ChAx 7 8t : Time (wde ; 1; t ) ) (we ; 1; t ) For a channel protocol, the start of a read is coincident with an item being read, and the end of write is coincident with an item being written. ChAx 8 8i : Occ; t : Time (rs ; i ; t ) , (ir ; i ; t ) ChAx 9 8i : Occ; t : Time (wde ; i ; t ) , (iw ; i ; t ) When the i th read starts, the value read is the i th value written. ChAx 10 8i : Occ; t1 : Time (ir ; i ; t1 ) ) 9 x : Data Value ; t2 : Time (iw ; i ; t1 ) ^ t2 t1 ^ val (ir ; t1 ; x ) ^ val (iw ; t2 ; x ) Where val (e t x ) is a predicate which is true whenever x is the data value associated with the item event e (i.e. e is either event ir or iw ) at time t. There is a value axiom which applies to all the protocols, not only the channel. It states that a value cannot be read if has not previously been written. Val-Ax 1 8x : Data Value ; i : Occ; t1 : Time (ir ; i ; t1 ) ^ val (ir ; t1 ; x ) ) 9 j : Occ ; t2 : Time (iw ; j ; t2 ) ^ val (iw ; t2 ; x ) ^ t2 t1 For simplicity, the channel axioms given here assume instantaneous communication (e.g. the eect of an rs event is detected by the writer as soon as it occurs), however they can easily be modi ed to capture delays. ;

;

4.2 Protocol and ADL Integration

To integrate DORIS and the ADL it is necessary to de ne the relationship between the protocol events and the ADL events. In this paper, this is only done for this speci c example, but it is planned to de ne link axiom schemas in a later paper. In particular, consider the read event Rp3 in Fig. 2; it occurs whenever activity A2 is in state D and the channel has data in it. In this example, this can be adequately formalised by the following link axiom: Lax 1 8i : Occ; t1 : Time (Rp3; i ; t1 ) , ins (D ; i ; t1 ) ^ : empty (t1 ) where empty de nes when the channel has no data in it: empty : Time ! B empty (t1 ) 4 8j : Occ ; t2 : Time t2 t1 ^ (wde ; j ; t2 ) ) 9 t3 : Time t3 < t1 ^ (rs ; j ; t3 )

Note: a channel is not empty at the moment a read starts. A similar relation holds between event Wp2 in activity A1, and the channel not being full: 15

A1: Identify Target

A2: Calculate Target Vector

Raw Sensor Data A

D Rp1

p1

p1

p2

B: Image

Rp3

Target Position

Target Vector p3

p2

p3

Proceesing to l1

Identify Target

Target vector

u1 l2

from new and old positions

Wp2

p4

E: Calculate

p4

C

u2

State:: Previous_Target_Position

Figure 2: A Target Tracker

Lax 2 8i : Occ; t1 : Time (Wp2; i ; t1 ) ,

ins (C ; i ; t1 ) ^ : full (t1)

where full de nes when the channel has no space in it: full : Time ! B full (t1) 4 9 i :Occ ; t2 :Time t2 t1 ^ (wde ; i +1; t2 )^8t3 :Time t3 < t1 ) : (rs ; i ; t3 ) The next link axiom asserts that leaving state B is coincident with wde .

Lax 3 8i : Occ; t : Time (# B ; i ; t ) , (wde ; i ; t )

A link axiom is needed which asserts that entering state D event is coincident with rs . This is consistent with the role static states have in modelling descheduling points.

Lax 4 8i : Occ; t : Time (" D ; i ; t ) , (rs ; i ; t )

There is a need for axioms which relate the values written and read by the dynamic states (as captured in the AFB notation), with the value handling properties of the protocol. In these axioms, `.out' is the result of the operation associated with the dynamic state, and `.in' the input parameter.

Lax 5 8i : Occ; t1 : Time (# B ; i ; t1 ) )

9 x : p 2:datatype ; j ; k : Occ (B :out = x ; j ; t1 ) ^ j i ^ (iw ; k ; t1 ) ^ val (iw ; t1 ; x ) Lax 6 8i : Occ; t1 : Time (" E ; i ; t1 ) ) 9 x : p 3:datatype ; j ; k : Occ (E :in = x ; j ; t1 ) ^ j i ^ (ir ; k ; t1 ) ^ val (ir ; t1 ; x ) An axiom is needed which states that entering state E is the start of a data read from the channel.

Lax 7 8i : Occ; t : Time (" E ; i ; t ) , (rds ; i ; t ) 16

And nally, an axiom is needed which states that leaving state C is associated with the channel write end event.

Lax 8 8i : Occ; t : Time (# C ; i ; t ) , (we ; i ; t )

It is noted that Lax 7 implicitly assumes that activity A2 is the highest priority process on its processor. This is because èntering state E ' (which is coincident with Rp3 ) should be coincident with the `ready to be scheduled' kernel event, and rds coincident with the àctually scheduled' event. If this is not the desired behaviour a weaker Lax 7, which only required the rds event to occur before the state was left, could be given instead.

5 A Small Example The network in Fig. 2 is used to illustrate how an ADL speci ed real-time system can be reasoned about. The network consists of two activities linked by a channel, and is a typical fragment of a DORIS design which might be found in many tracking systems. The arrival of a fresh target image from some input sensors triggers activity A1, which performs some image processing to determine the coordinates of the target. These coordinates are then passed to A2 via the channel, and A2 calculates how the target is moving, and outputs this vector to the rest of the system. Typical constraints on such a system are that it should produce the updated vector information within some time of a new image arriving, and that it should not produce a vector update if there has not been a new image. In other words, it should exhibit both a timeliness property, and a safety, no spurious outputs, property. This section includes a formalisation of the postulated theorems and associated environmental assumptions, and an outline of the rigorous proofs of the theorems.

5.1 Functional Speci cation

Space does not allow a full AFB speci cation for the system to be given. Instead it is noted that it would consist of a VDM module for each activity, with an operation for dynamic state B in one, and one for state E in the other. In this example, the main impact the functional behaviour on the proof of the temporal and safety properties is through the pre-conditions of the operations. In this example the preconditions will be assumed to be tautologies. However, in systems where dierent branches can be taken according to the truth of conditions de ned over the activity's local state, the functional speci cation will have a much greater impact.

5.2 Rigorous Proof

The timeliness property the system should exhibit can be formalised as: 17

Theorem 1

i : Occ ; t1 : Time (Rp1 ; i ; t1 ) ) 9 t2 : Time (# E ; i ; t2 ) ^ t2 t1 + x

8

This states that every input should give rise to an output within x milliseconds, where x is the system deadline. The safety property the system should exhibit can be formalised as:

Theorem 2

i : Occ ; t1 : Time (# E ; i ; t1 ) ) 9 t2 : Time (Rp1 ; i ; t2 ) ^ t2 < t1

8

This states that every output should be in response to an earlier input. To be able to prove the system has these properties it is necessary to know some facts about the system and its environment. The following assumptions are adopted:

Assumption 1 8i : Occ; t1 ; t2 : Time ( (Rp1; i ; t1 ) ^ (Rp1 ; i + 1; t2 )) ) t2 > t1 + y Assumption 2 y x Assumption 3 x u1 + u2

where y is the minimum inter-arrival time between sporadic inputs. It should be noted that assumption 2 means that the system will only be proved to have the desired properties under particularly benign conditions. This has been done as the objective is to validate the axiomisation and illustrate how the ADL speci cations can be reasoned about, rather than to reveal the complexities involved in reasoning about realistic systems.

Proof of Theorem 1 Informally, theorem 1 holds because, at start-up, activity A1 is in state A, ready for an input. As soon as it occurs it moves to state B , and this outputs the target position within u1 seconds. Activity A2 starts in state D , so immediately responds to the new target data, and calculates the output vector within u2 time units. The output is therefore produced within u1 + u2 seconds of the input, and this is within the deadline. On the rst time, there will be space for the target position data in the channel, so A1 will be able to immediately return to state A. A2 will also return to state D after leaving state E . The system will return to its initial state before the next input, so all outputs will be within the deadline. The following rigorous proof of theorem 1, has been abstracted from a fully formal proof carried out in PVS [OSR99b], with a shallow embedding of the RTL and ERTL logic.

18

from Assumptions ; Activity Theories ; Link and Channel Axioms from i : Occ ; t1 : Time ; (Rp1 ; i ; t1 ) (# B ; i ; t2 ) ^ t1 + u1 t2 t1 + l1 Lemma A1Steps(1) (wde ; i ; t2 ) Lax3(1.1) (Rp3 ; i ; t2 ) Lemma RW-Coord(1.2) (# E ; i ; t3 ) ^ t2 + u2 t3 t2 + l2 Lemma A2Steps(.8) t3 t1 + u 1 + u 2 Arith(1.1, 1.4) (# E ; i ; t3 ) ^ t3 t1 + x Assump 3(1.5), 1.4 infer 9 t2 : Time (# E ; i ; t2 ) ^ t2 t1 + x 9 -intro (1.6) 2 (Rp1 ; i ; t1 ) ) 9 t2 : Time (# E ; i ; t2 ) ^ t2 t1 + x Implies(1) infer 8i : Occ ; t1 : Time (Rp1 ; i ; t1 ) ) 9 t2 : Time (# E ; i ; t2 ) ^ t2 t1 + x 8-intro (2)

1 1.1 1.2 1.3 1.4 1.5 1.6

The above proof uses the following lemmas:

Lemma 1 A1Steps 8i : Occ; t1 : Time (Rp1; i ; t1 ) )

9 t2 : Time (# B ; i ; t2 ) ^ t1 + u1 t2 t1 + l1 Lemma 2 A2Steps 8i : Occ; t1 : Time (Rp3; i ; t1 ) ) 9 t2 : Time (# E ; i ; t2 ) ^ t1 + u2 t2 t1 + l2 Lemma 3 RW -Coord 8i : Occ; t1 : Time (wde ; i ; t1 ) ) (Rp3; i ; t1 ) Rigorous proofs of these lemmas are given in Appendix 4. It is noted that the bulk of the proof eort is involved in establishing the RW -Coord lemma.

Proof of Theorem 2 Informally, theorem 2 can be seen to hold by realising that an output can only occur if activity A2 leaves state E , which in turn can only occur if E is entered because of data being present in the channel. As data in a channel is consumed when it is read, there will be a corresponding exit from state B for every data item read from the channel. Therefore, there will be a corresponding input event causing state B to be entered. Hence, every output will be the result of an earlier input.

19

from Assumptions ; Activity Theories ; Link and Channel Axioms from i : Occ ; t1 : Time ; (# E ; i ; t1 ) (Rp3 ; i ; t2 ) ^ t1 ? u2 t2 t1 ? l2 A2StepsBack(1) (wde ; i ; t2 ) RW-Coord2(1.1) (# B ; i ; t2 ) Lax3(1.2) (Rp1 ; i ; t3 ) ^ t2 ? u1 t3 t2 ? l1 A1StepsBack(1.3) t3 t2 ? (l1 + l2 ) Arith(1.1, 1.4) infer 9 t3 : Time (Rp1 ; i ; t3 ) ^ t3 < t1 9 -intro (1.4) 2 (# E ; i ; t1 ) ) 9 t2 : Time (Rp1 ; i ; t2 ) ^ t2 < t1 Implies(1) infer 8i : Occ ; t1 : Time (# E ; i ; t1 ) ) 9 t2 : Time (Rp1 ; i ; t2 ) ^ t2 < t1 8-intro (2)

1 1.1 1.2 1.3 1.4 1.5

Lemma 4 A1StepsBack 8i : Occ; t1 : Time (# B ; i ; t1 ) )

9 t2 : Time (Rp1 ; i ; t2 ) ^ t1 ? u1 t2 t1 ? l1 Lemma 5 A2StepsBack 8i : Occ; t1 : Time (# E ; i ; t1 ) ) 9 t2 : Time (Rp3 ; i ; t2 ) ^ t1 ? u2 t2 t1 ? l2 Lemma 6 RW -Coord 2 8i : Occ; t1 : Time (Rp3; i ; t1 ) ) (wde ; i ; t1 ) Rigorous proof of these lemmas are not given, but they have been discharged formally in PVS.

5.3 Conclusions from the Proofs

The fact that both theorems could be proved from the theory obtained by applying provides some validation of the adequacy of the semantics, especially as both forward and backward chains of causality had to be established. The lessons about proof drawn in [ArB96] were found relevant in this work, in particular it helps to plan formal proofs before embarking on using a prover, and that formal proofs need to be reconverted to rigorous proofs for presentation and comprehension. The identi cation of suitable lemmas improves the modularity and clarity of a proof. RTL and the ASM axioms proved pleasingly intuitive to use, because they encoded clearly de ned behaviour. The eort required for these proofs was of the order of three man months, however, a signi cant proportion of this was spent on developing a number of standard theorems about RTL. Clearly, having developed these, subsequent proof eort will be eased.

6 Tool Support The ADL, as well as having the graphical syntax presented in this paper, also has a textual syntax. Work is currently underway to develop a tool which will automatically convert a textual ADL speci cation into a theory expressed in the PVS logic [OSR99a]. This tool encodes , and applies appropriate simpli cations, making interactive proof of properties of networks possible. Once 20

this tool has been used to validate the ADL on more extensive case-studies, it is planned to extend the Matra BAe Dynamics MADGE CASE tool, which supports DORIS, so that the graphical ADL syntax can be entered directly in an activity. A number of prototype animators for designs consisting of single and multiple activities with ADL speci cations have been developed [Hen98] [Bou99]. An extension of these tools to handle a DORIS network mapped to multiple processors is currently under development.

7 Conclusions and Related Work This paper has introduced ADL, a new formal notation for the speci cation of the temporal and functional behaviour of concurrent processes in DORIS designs. The abstract syntax, and static and dynamic semantics of the ASM notation have been given, and the notation has been used to specify a small system. The theory of the example was generated, and typical timeliness and safety properties were formalised and proven. The modest size of the example in this paper raises questions about whether this approach will scale up to realistic systems. It is not anticipated that the increased number of axioms that would result from a larger system would, in itself, be problematic, as the way the theories are structured means that it is easy to nd the axiom which encodes the desired property that one wants to exploit. Instead, it is the complexity of the interactions of the components which make it hard to understand whether the desired properties hold or not, and consequently, make it dicult to know how to prove that they do. Clearly, there is a need for further studies to determine how well the ADL scales up to slightly bigger systems, and especially to systems where functionality and timing interact more. The ADL is a development of earlier work on extracting an RTL theory of Timed Statecharts reported in [ArB96], which in turn was in uenced by work expressing the semantics of Modecharts in RTL [JLM88]. Closely related work on Statecharts has been described in [Arm98]. The ADL diers from the earlier work in the degree of integration of its functional and timing behaviour, made possible by the adoption of ERTL [HaL96]. It also diers in a number of choices made about its computational model and in its tight integration into the DORIS design notation. In particular, unlike Statecharts and Modecharts, ADL speci cations may not contain nested parallel state-machines, but are used within the concurrent environment de ned in DORIS. This has the advantage of making the rich set of prede ned DORIS synchronous and asynchronous communication protocols available to the speci er. The use of the DORIS protocols also allows the ADL to avoid the normal complexities of shared variable concurrency, such as explored in the relyguarantee work [XRH97]. We would see that approach as applicable to the detailed speci cation of the read and write actions of the protocols. In simple systems, like the one considered in this paper, it is probably the 21

case that model-checkers for timed automata [ACD90] or timed statecharts [BBD99] would perform as well as, if not better than, the techniques used here. However, the proof-theoretic framework which has been developed should handle the validation of systems with functional behaviour which cannot be conviently modelled by today's model-checkers, in spite of the recent advantages in the use of symbolic model-checking using BDDs [McM93]. It is considered important that the ADL contains an explicit model-based formal speci cation language, because it is the discipline of using such notations that brings many of the bene ts of formal speci cation. In particular, it is the extra scrutiny of considering pre-condition boundary behaviour and state invariants that has been shown experimentally to make an important contribution to speci cation completeness [FLB95] and [BFL96]. This is in contrast to the motivation behind formalising some graphical notations, which is to hide formal notations from the speci er. Future work will address the soundness and relative completeness of the axiomatic semantics with respect to the operational semantics [Val99] [Pay99], as well as addressing the semantics of the AFB functional notation in more detail. The integration of ADL into DORIS also needs to be put on a more systematic basis by de ning general link axiom schemas.

8 Acknowledgements Matra BAe Dynamics (UK) Ltd. and the BAe DCSC funded this research. Our ideas have bene ted from conversations with Drs H.R. Simpson and J.S. Fitzgerald, and Messrs. S.H. Valentine and N. Henderson. The authors wish to thank the referees who made many helpful suggestions.

References [ACD90] Alur, R., Courcoubetis, D.L. and Dill, D.L.: `Model-Checking for Real-Time Systems', Proc. 5th IEEE Symp. on Logic in Comp. Sci., IEEE Comp. Soc. Press, 1990, pp. 414-425 [ArB96] Armstrong, J.M., Barroca, L.: `Speci cation and Veri cation of Reactive System Behaviour: The Railroad Crossing Example', J. Real-Time Systems, 10 (2), March 1996, pp. 143-178 [Arm98] Armstrong, J.M.: Ìndustrial Integration of Graphical Formal Speci cations', J. Systems Software, 40, 1998, pp. 211-225 [ABR93] Audsley, N., Burns, A., Richardson, M., Tindall, K. and Wellings, A.J.: Àpplying New Scheduling Theory to Static Priority Pre-emptive Scheduling', Softw. Eng. J., 1993, 8, (5), pp. 284-292 [Bar97] Barnes, J.: `High Integrity Ada: The SPARK Approach', AddisonWesley 1997. 22

[BaM92] Barroca, L. and McDermid, J.A.: `Formal Methods: Use and Relevance for the Development of Safety Critical Systems', Comput. J. , 35 (6), December 1992 [BFL94] Bicarregui, J.C., Fitzgerald, J.S., Lindsay, P.A., Moore, R., and Ritchie, B.: `Proof in VDM: A Practitioner's Guide', FACIT, SpringerVerlag 1994. [BBD99] Bienmuller, T., Brockmeyer, U., Damm, W. Dohmen, Emann, C., Holberg, H.-J., Hungar, H., Josko, B., Schlor, R., Wittich, G., Wittke, H., Clements, G., Rowlands, J., and Sefton, E.: `Formal Veri cation of an Avionics Application using Abstraction and Symbolic Model Checking', Proc. 7th Safety-Critical Systems Symp., Huntingdon, In `Towards System Safety', Edited by F. Redmill and T. Anderson, Springer, 1999. [Bou99] Boukouvalas, A.: `The DORIS/ADL Animator', BSc Student Project Report, Department of Computing Science, University of Newcastle, April 1999. [BFL96] Brooks, T., Fitzgerald, J.S., and Larsen, P.G.: `Formal and Informal Speci cations of a Secure System Component: Final results of a Comparative Study', Proc. 3rd Int. Symp. of Formal Methods Europe, LNCS 1051, Springer 1996. [Bur95] Burns, A.: `Preemptive Priority-Based Scheduling: An Appropriate Engineering Approach', pp. 225-248, in Àdvances in Real-Time Systems', Edited by S.H. Son, Prentice-Hall, 1995. [CBW96] Chapman, R., Burns, A., and Wellings, A.: `Combining Static WorstCase Timing Analysis and Program Proof', J. Real-Time Systems, 11 (2), September 1996, pp. 145-172 [FLB95] Fitzgerald, J.S., Larsen, P.G., Brooks, T. and Green, M.: `Developing a Security-critical System using Formal and Conventional Methods', In Àpplications of Formal Methods', Edited by: M.G. Hinchey and J.P. Bowen, Prentice Hall International Series in Computer Science, 1995. [HaL96] Hall, J.G. and Lemos, R. de.: ÈRTL: An Extension to RTL for the Speci cation, Analysis and Veri cation of Hybrid Systems', Proc. of the IEEE EuroMirco'96 Conf., 1996. [Hen98] Henderson, N.: `The Syndie Animator', BSc Student Project Report, Department of Computing Science, University of Newcastle, April 1998. [Hoo91] Hooman, J.: `Speci cation and Compositional Veri cation of RealTime Systems', LNCS 558, Springer-Verlag, 1991. [ISO96] International Standards Organisation, Information Technology - Programming languages, their environments and system software interfaces Vienna Development Method - Speci cation Language { Part 1 Base Language, ISO / IEC 13817-1 , VDM-SL, December 1996. 23

[JaM86] Jahanian, F., and Mok, A.K: `Safety Analysis of Timing Properties in Real-Time Systems', IEEE Trans., 1986, SE-12, (9), pp. 890-904 [JIM87] Joint IECCA and MUF Committee on MASCOT (JIMCOM): `The Ocial Handbook of MASCOT', Version 3.1, Issue 1, Crown Copyright, June 1987 [JLM88] Jahanian, F., Lee, R. and Mok, A.K.: `Semantics of Modechart in Real-Time Logic', IEEE Proceedings of the 21st Annual Hawaiian International Conference on System Science, 1988 [JMS88] Jahanian, F., Mok, A.K., and Stuart, D.A.: `Formal Speci cation of Real-time Systems', Technical Report TR-88-25, Department of Computer Science, University of Texas at Austin, June 1988 [Jon90] Jones, C.B.: `Systematic Software Development Using VDM', Second Edition, Prentice-Hall International Series in Computer Science, 1990. [Kne97] Kneuper, R.: `Limits of Formal Methods', Formal Aspects of Comp., 1997, 9, (4), pp. 379-394 [Lar95] Larsen, P.G.: `Towards Proof Rules for the Full Standard VDM Speci cation Language', PhD Thesis, Technical University of Denmark, Lyngby, Denmark, March 1995 (Technical report ID-TR:1995-160, ISSN 0902-2821) [McM93] McMillan, K.: `Symbolic Model Checking', Kluewer Academic Publishers, 1993. [MaP92] Manna, Z. and Pnueli, A.: `The Temporal Logic of Reactive and Concurrent Systems', Springer, 1992. [Man93] Manzano, M.: Ìntroduction to Many-Sorted Logic', in `Many-Sorted Logic and its Applications', Edited by K. Meinke and J.V. Tucker, Wiley Professional Computing, 1993 [MoD85] Ministry of Defence, Defence Standard 00-17: `Modular Approach to Software Construction, Operation, and Test - MASCOT', Issue 1, October 1985. [MoD91] Ministry of Defence, Sea Systems Controllerate: `Requirements for Software for use with Digital Processors', Naval Engineering Standard, NES 620, Issue 4, June 1991. [MoD97] Ministry of Defence, Defence Standard 00-55: `The Procurement of Safety-Critical Software in Defence Equipment', 1997 [OSR99a] Owre, S., Shanker, N., Rushby, J.M., and Stringer-Calvert, D.W.J.: `PVS Language: Version 2.3', Computer Science Laboratory, SRI International, September 1999. 24

[OSR99b] Owre, S., Shanker, N., Rushby, J.M., and Stringer-Calvert, D.W.J.: `PVS System Guide: Version 2.3', Computer Science Laboratory, SRI International, September 1999. [PAH99] Paynter, S.E., Armstrong, J.M., and Haveman, J.: Èxploiting Formality within an Architectural Design Method', Technical Report, CS-TR-690, Department of Computer Science, Univerity of Newcastle, 1999. [Pay99] Paynter, S.E.: `The Syntax and Semantics of the Activity Description Language', DR 18159, Unclassi ed Matra BAe Dynamics Technical Report, 1999 [PVL92] Program Validation Limited: `Generation of Path Functions and Veri cation Conditions for SPARK Programs', Technical Report, Version 1.1b, Program Validation Limited, January 1992. [ScZ92] Schole eld, D. and Zedan, H.S.M.: `TAM: A Formal Framework for the Development of Distributed Real-Time Systems', Proc. of the Int. Symp. Formal Techniques in Real-Time and Fault-Tolerant Systems, LNCS 571, Springer, 1992. [Sim86] Simpson, H.R.: `The MASCOT Method', Softw. Eng. J., 1986, 1, (3), pp. 103-120 [Sim90] Simpson, H.R.: `MASCOT Real-Time Networks in Distributed System Design', IEE Colloquium on MASCOT and Related Issues., December 1990 [Sim94a] Simpson, H.R.: `Methodological and Notational Conventions in DORIS Real-time Networks', IED Supporting Predictable Implementation of Requirements in Timing and Safety (SPIRITS) Deliverable, 1994 [Sim94b] Simpson, H.R.: Àrchitecture for Computer Based Systems', IEEE Workshop on the Engineering of Computer Based Systems, Stockholm, 1994 [Sim96] Simpson, H.R.: `Layered Architecture(s): Principles and Practice in Concurrent and Distributed Systems', Proc. of the 8th IEEE Symp. on Parallel and Distributed Processing, New Orleans, October 1996. [Sim99a] Simpson, H.R.: `Protocols for Process Interaction: Part 1: Rationale and Speci cation', Submitted to IEE Proc. on Software, 1999. [Sim99b] Simpson, H.R.: `Protocols for Process Interaction: Part 2: Application', Submitted to IEE Proc. on Software, 1999. [Sim99c] Simpson, H.R.: `Protocols for Process Interaction: Part 3: Realisation', Submitted to IEE Proc. on Software, 1999. [Val99] Valentine, S.H.: `Formal Description and Axioms for the ASM', BAe DCSC Technical Report, DCSC/TR/1999/15, University of York, September 1999. 25

[Woo96] Woodward, G.: `Rapier 2000 Software Development Programme', Softw. Eng. J., 1996, 11, (2), pp. 82-87 [XRH97] Xu, Q., de Roever, W.-P., and He, J.: `The Rely-Guarantee Method for Verifying Shared Variable Concurrent Programs', Formal Aspects of Comput., 1997, 9, (2), pp. 149-174

Appendix 1: ASM Abstract Syntax and Static Semantics This appendix gives the (core) abstract syntax and static semantics of the ASM in VDM-SL [ISO96].

types 2.0 Variable ID = token ; 3.0 Event ID = token ; 4.0 Operation ID = token ; 5.0 State ID = token ; 6.0 Type ID = token ; 7.0 Data Value = token ; 8.0 A Type :: id : Type ID .1 domain : Data Value -set ; 9.0 Condition :: B ; 10.0 Duration = N1; 11.0 Time = N; 12.0 TimeBounds :: tmin : Time .1 tmax : Time .2 inv mk-TimeBounds (tmin ; tmax ) tmax tmin ; 13.0 Protocol = CHANNEL j POOL j SIGNAL j DATALESS CHANNEL j STIMULUS ; 14.0 Port :: dir : IN j OUT .1 protocol : Protocol .2 datatype : A Type 4

functions 15.0 InHolding : Port ! B .1 InHolding (p ) .2 p :dir = IN ^p :protocol 2 fSIGNAL; STIMULUS ; CHANNEL; DATALESS CHANNELg; 4

16.0 InNonholding : Port ! B .1 InNonholding (p ) .2 p :dir = IN ^ p :protocol = POOL; 4

26

17.0 OutHolding : Port ! B .1 OutHolding (p ) .2 p :dir = OUT ^ p :protocol 2 fCHANNEL; DATALESS CHANNELg; 4

18.0 OutNonholding : Port ! B .1 OutNonholding (p ) .2 p :dir = OUT ^ p :protocol 2 fPOOL; SIGNAL; STIMULUS g; 4

19.0 Stimming : Port ! B .1 Stimming (p ) .2 p :protocol 2 fDATALESS CHANNEL; STIMULUS g 4

types 20.0 Event :: id : Event ID .1 port : Port .2 type : READ j STIM j WRITE .3 inv mk-Event (id ; port ; type ) .4 (type = READ , InHolding (port ) ^ : Stimming (port )) ^ .5 (type = STIM , InHolding (port ) ^ Stimming (port )) ^ .6 (type = WRITE , OutHolding (port )); 21.0 DurationBounds :: dmin : Duration .1 dmax : Duration .2 inv mk-DurationBounds (dmin ; dmax ) dmax dmin ; 22.0 Var :: id : Variable ID .1 var type : A Type .2 value : Data Value .3 inv mk-Var (id ; t ; v ) v 2 t :domain ; 23.0 Operation :: id : Operation ID .1 readable vars : Var -set .2 writable vars : Var -set .3 parameter type : [A Type ] .4 result type : [A Type ] .5 Pre : is not yet de ned .6 Post : is not yet de ned ; 24.0 Op Localisation :: op : Operation .1 in p : [Port ] .2 out p : [Port ] .3 inv mk-Op Localisation (op ; in p ; out p ) .4 (in p 6= nil ) in p :datatype = op :parameter type ^ in p :dir = IN ^ : Stimming (in p )) ^ .5 (in p = nil ) op :parameter type = nil ) ^ .6 (out p 6= nil ) out p :dir = OUT ^ out p :datatype = op :result type ) ^ .7 (out p = nil ) op :result type = nil ); 25.0 StaticState :: token ; 4

4

4

4

27

26.0 Dynamic State :: id : State ID .1 ops : Op Localisation -set .2 bounds : DurationBounds .3 inv mk-Dynamic State (id ; ops ; bounds ) .4 (card ops 1) ^ .5 (8 op1 ; op2 2 ops .6 op1 :op :id 6= op2 :op :id ) .7 (op1 :out p 6= op2 :out p _ op1 :out p = op2 :out p ^ op2 :out p = nil ) ^ .8 (op1 :in p 6= op2 :in p _ op1 :in p = op2 :in p ^ op2 :in p = nil ) ^ .9 (op1 :op :readable vars \ op2 :op :writable vars = ;) ^ .10 (op1 :op :writable vars \ op2 :op :writable vars = ;)) ^ .11 (card ops > 1 ) 8 op 2 ops (op :in p = nil _ InNonholding (op :in p )) ^ .12 (op :out p = nil _ OutNonholding (op :out p ))) .13 {{ All ports that are read by operations in a composite state must be non-holding .14 {{ inputs, and all ports that are written by operations in a composite state must .15 {{ be non holding outputs, and must be distinct (or null). Operations must access dierent .16 {{ parts of the local state space; 27.0 State :: s : StaticState j DynamicState ; 28.0 Label Type :: l : Condition j Event j TimeBounds ; 29.0 Transition :: src : State .1 tgt : State .2 label : Label Type .3 inv mk-Transition (src ; tgt ; label ) .4 (is-Condition (label :l ) , is-DynamicState (src :s )) ^ .5 ((is-Event (label :l ) ^ label :l :type = READ ) ) card tgt :s :ops = 1) ^ .6 ((card tgt :s :ops = 1 ^ 9 op l : tgt :s :ops InHolding (op l :in p )) , .7 (9 op l : tgt :s :ops label :l :port = op l :in p ^ label :l :type = READ )) .8 {{ Conditions only label transitions from dynamic states, while events and timebounds .9 {{ never label transitions from dynamic states. Read events may not label transitions .10 {{ which end in composite or static states. Any transition into a state which reads .11 {{ from a holding port (containing data), must be labelled by a read event for that .12 {{ port. A read labelled transition ends in a simple state which reads from that port. 4

4

functions 30.0 reachable from : State State -set Transition -set ! State -set .1 reachable from (s ; states ; ts ) .2 fs 0 : states j .3 s 0 2 Successors (s ; states ; ts ) _ .4 9 s 00 2 Successors (s ; states ; ts ) s 0 2 reachable from (s 00 ; states ; ts )g .5 {{ This is de ned in terms of the function Successors de ned in the body of the paper; 4

31.0 static reachable from : State State -set Transition -set ! StaticState -set .1 static reachable from (s ; states ; ts ) .2 fs 0 : states j (is-StaticState (s 0 :s ) ^ s 0 2 Successors (s ; states ; ts )) _ .3 9 s 00 2 Successors (s ; states ; ts ) is-StaticState (s 00 :s )^s 0 2 static reachable from (s 00 ; states ; ts )g; 4

28

32.0 reachable from initial state : State State -set State Transition -set ! B .1 reachable from initial state (s ; states ; initial ; ts ) .2 s = initial _ s 2 reachable from (initial ; states ; ts ) .3 {{ All states are reachable from the initial state; 4

33.0 only static stop states : State Transition -set ! B .1 only static stop states (s ; ts ) .2 ft j t 2 ts s = t :src g = ; ) is-StaticState (s :s ) .3 {{ Only static states can be states with no exit transition; 4

34.0 single exit static states : State Transition -set ! B .1 single exit static states (s ; ts ) .2 is-StaticState (s :s ) ) card ft j t 2 ts s = t :src g 1 .3 {{ Static states can have at most one exit transition; 4

35.0 no static state cycles : State Transition -set ! B .1 no static state cycles (s ; ts ) .2 is-StaticState (s :s ) ) s 62 static reachable from (s ; ts ) .3 {{ Static states may not be connected in cycles without intervening dynamic states; 4

36.0 only valid ports accessed : Dynamic State Port -set ! B .1 only valid ports accessed (s ; ports ) .2 (8 op l 2 s :s :ops .3 ((op l :in p = nil _ op l :in p 2 ports ) ^ .4 (op l :out p = nil _ op l :out p 2 ports ))) .5 {{ Operations only refer to ports de ned in the ASM; 4

37.0 valid transitions from a write : Dynamic State Transition -set ! B .1 valid transitions from a write (s ; ts ) .2 ((card s :s :ops = 1 ^ .3 9 op l : s :s :ops .4 OutHolding (op l :out p )) ) .5 9! t 2 ts (t :src = s ^ .6 (9 t 0 2 ts ; id 2 Event ID ; op l : s :s :ops .7 t 0 :src = t :tgt ^ t 0 :label :l = mk-Event (id ; op l :out p ; WRITE )))) .8 {{ If s writes to a holding port, there must be a single following state which is .9 {{ static, and which is left by a transition labelled with the appropriate write event; 4

38.0 transition links valid states : Transition State -set ! B .1 transition links valid states (tr ; states ) .2 tr :src 2 states ^ tr :tgt 2 states .3 {{ Transitions only link states de ned in the ASM; 4

29

39.0 write labelled transition leaves appropriate states : Transition Transition -set !

B

.1 write labelled transition leaves appropriate states (tr ; ts ) .2 tr :label :l :type = WRITE ) .3 (8 t 2 ts t :tgt = tr :src ) .4 (card t :src :s = 1 ^ 9 op l : t :src :s tr :label :l :port = op l :out p )) .5 {{ Every transition into a state which is left by a transition labelled with a write event .6 {{ must come from a dynamic state which writes to the appropriate port; 4

40.0 ports on events are valid : Transition Port -set ! B .1 ports on events are valid (tr ; ps ) .2 is-Event (tr :label :l ) ) tr :label :l :port 2 ps .3 {{ All labels on transitions which mention ports, should only refer to .4 {{ ports of the ASM; 4

41.0 only one transition between two states : Transition Transition ! B .1 only one transition between two states (t ; t 0 ) .2 (t :tgt = t 0 :tgt ^ t :src = t 0 :src ) ) t = t 0 .3 {{ There may only be one transition between any pair of states; 4

42.0 transitions have unique event labels : Transition Transition ! B .1 transitions have unique event labels (t ; t 0 ) .2 (t :src 6= t 0 :src ^ is-Event (t :label :l ) ^ is-Event (t 0 :label :l )) ) t :label :l :id 6= t 0 :label :l :id .3 {{ Event labelled transitions from dierent states must be dierent event identi ers 4

types 43.0 ADL :: ports : Port -set .1 variables : Var -set .2 operations : Operation -set .3 states : State -set .4 transitions : Transition -set .5 initial : State

30

.6 inv mk-ADL (ports ; variables ; operations ; states ; transitions ; initial ) .7 (initial 2 states ) ^ {{ The initial state is a state of the ASM .8 (8 s 2 states .9 reachable from initial state (s ; initial ; transitions ) ^ .10 only static stop states (s ; transitions ) ^ .11 single exit static states (s ; transitions ) ^ .12 no static state cycles (s ; transitions ) ^ .13 is-Dynamic State (s :s ) ) only valid ports accessed (s ; ports ) ^ .14 is-Dynamic State (s :s ) ) valid transitions from a write (s ; transitions ))^ 4

.15 .16 .17 .18 .19 .20 .21

(8 t 2 transitions transition links valid states (t ; states ) ^ write labelled transition leaves appropriate states (t ; transitions ) ^ ports on events are valid (t ; ports )) ^ (8 t ; t 0 2 transitions only one transition between two states (t ; t 0 ) ^ transitions have unique event labels (t ; t 0 ))

Appendix 2: RTL and ERTL Axioms This appendix contains the axioms for the occurrence and holding relations.

RTL-Ax 1 8i : Occ; t1 ; t2 : Time ; e : Event ( (e ; i ; t1 ) ^ (e ; i ; t2 )) ) t1 = t2 RTL-Ax 2 8i : Occ; t1 : Time ; e : Event ( (e ; i ; t1 ) ^ i > 1) ) 9 t2 : Time (e ; i ? 1; t2 ) ^ t2 < t1

ERTL-Ax 1 8i : Occ; t1 ; t2 : Time

( (P ; i ; t1 ) ^ (P ; i ; t2 ) ^ t1 < t2 ) ) 8t3 : Time t1 < t3 < t2 ) (P ; i ; t3 )

ERTL-Ax 2 8i : Occ; t1 ; t2 : Time

( (P ; i ; t1 ) ^ (P ; i + 1; t2 )) ) 9 t3 : Time t1 < t3 < t2 ^ (:P ; i ; t3 )

ERTL-Ax 3 8i ; j : Occ; t : Time ((P ; i ; t ) ^ (P ; j ; t )) ) i = j ERTL-Ax 4 8i : Occ; t1 : Time (P ; i + 1; t1 ) ) 9 t2 : Time t2 < t1 ^ (P ; i ; t2 ) where P is an untimed predicate.

Appendix 3: Generated Theory for ASM Speci cations in Fig. 2. These axioms were generated by applying of the semantic function, , to the two ASM speci cations of the example. As advocated in the paper, the obvious simpli cations were made when instantiating the axiom schemas. The theory for activity A1 is:

A1ax1: (" A; 1; 0) A1ax2a: 8i : Occ; t : Time (# A; i ; t ) ) (" B ; i ; t ) A1ax2b: 8i : Occ; t : Time (# C ; i ; t ) ) (" A; i + 1; t ) 31

A1ax3: 8i ; j : Occ; t : Time ( (# B ; i ; t ) ^ (true ; j ; t )) ) (" C ; i ; t ) A1ax4: 8i : Occ; t : Time (" A; i ; t ) ) (i = 1 _ (i > 1 (# C ; i ? 1; t )) A1ax5a: 8i : Occ; t : Time (" B ; i ; t ) ) (# A; i ; t ) A1ax5b: 8i : Occ; t : Time (" C ; i ; t ) ) (# B ; i ; t ) A1ax6: 8i ; j : Occ; t : Time (" B ; i ; t ) ) 9 t1 : Time t + l1 t1 t + u1 (# B ; i ; t1 )

A1ax7a: 8i : Occ; t : Time (Rp1 ; i ; t ) ) (# A; i ; t ) A1ax7b: 8i : Occ; t : Time (Wp2; i ; t ) ) (# C ; i ; t ) A1ax9: 8i : Occ; t : Time (# B ; i ; t ) ) 9 t1 : Time t ? u1 t1 t ? l1 (" B ; i ; t1 )

A1ax11a: 8i : Occ; t : Time (# A; i ; t ) ) ins (A; i ; t ) ^ (Rp1; i ; t ) A1ax11b: 8i : Occ; t : Time (# C ; i ; t ) ) ins (C ; i ; t ) ^ (Wp2; i ; t ) The theory for activity A2 is:

A2ax1: (" D ; 1; 0) A2ax2: 8i : Occ; t : Time (# D ; i ; t ) ) (" E ; i ; t ) A2ax3: 8i ; j : Occ; t : Time ( (# E ; i ; t ) ^ (true ; j ; t )) ) (" D ; i + 1; t ) A2ax4: 8i : Occ; t : Time (" D ; i ; t ) ) (i = 1 _ (i > 1 (# E ; i ? 1; t ))) A2ax5: 8i : Occ; t : Time (" E ; i ; t ) ) (# D ; i ; t ) A2ax6: 8i ; j : Occ; t : Time (" E ; i ; t ) ) 9 t1 : Time t + l2 t1 t + u2 (# E ; i ; t1 )

A2ax7: 8i : Occ; t : Time (Rp3; i ; t ) ) (# D ; i ; t ) A2ax9: 8i : Occ; t : Time (# E ; i ; t ) ) 9 t1 : Time t ? u2 t1 t ? l2 (" E ; i ; t1 ) A2ax11: 8i : Occ; t : Time (# D ; i ; t ) ) ins (D ; i ; t ) ^ (Rp3; i ; t )

Appendix 4: Proof of the Lemmas for Theorem 1 Lemma 1 (A1Steps) is proved as follows:

32

from Activity A1 Theory from i : Occ ; t1 : Time ; (Rp1 ; i ; t1 ) (# A; i ; t1 ) A1ax7a(1) (" B ; i ; t1 ) A1ax2a(1.1) (# B ; i ; t2 ) ^ t1 + u2 t2 t1 + l2 A1ax6(1.2) infer 9 t2 : Time (# B ; i ; t2 ) ^ t1 + u2 t2 t1 + l2 9 -intro (1.3) 2 (Rp1 ; i ; t1 ) ) 9 t2 : Time (# B ; i ; t2 ) ^ t1 + u2 t2 t1 + l2 Implies(1) infer 8i : Occ ; t1 : Time (Rp1 ; i ; t1 ) ) 9 t2 : Time (# B ; i ; t2 ) ^ t1 + u2 t2 t1 + l2 8-intro (2)

1 1.1 1.2 1.3

Lemma 2 (A2Steps) is proved similarly: from Activity A2 Theory from i : Occ ; t1 : Time ; (Rp3 ; i ; t1 ) (# D ; i ; t1 ) A2ax7(1) (" E ; i ; t1 ) A2ax2(1.1) (# E ; i ; t2 ) ^ t1 + u2 t2 t1 + l2 A2ax6(1.2) infer 9 t2 : Time (# E ; i ; t2 ) ^ t1 + u2 t2 t1 + l2 9 -intro (1.3) 2 (Rp3 ; i ; t1 ) ) 9 t2 : Time (# E ; i ; t2 ) ^ t1 + u2 t2 t1 + l2 Implies(1) infer 8i : Occ ; t1 : Time (Rp3 ; i ; t1 ) ) 9 t2 : Time (# E ; i ; t2 ) ^ t1 + u2 t2 t1 + l2 8-intro (2)

1 1.1 1.2 1.3

The RW-Coord lemma is the crux of the proof, as it links the occurrence number of a write into the channel, with the occurrence number of activity A2's response. This has to be established by induction over the occurrence of inputs.

33

1 2 2.1 2.2 2.3 2.4 2.5 2.6 3 4 5 5.1

from Assumptions ; Activity Theories ; Link and Channel Axioms 1 : Occ Base Case(1) from t1 : Time ; (wde ; 1; t1 ) (# B ; 1; t1 ) Lax3(2) (ins (D ; 1; t1 ) ^ : empty (t1 )) ) (Rp3 ; 1; t1 ) Lax1 from : ins (D ; 1; t1 )

:::

see below Logic(2.3)

infer false ins (D ; 1; t1 ) from empty (t1 )

:::

infer false see below : empty (t1 ) Logic(2.5) infer (Rp3 ; 1; t1 ) Logic(2.2, 2.4, 2.6) (wde ; 1; t1 ) ) (Rp3 ; 1; t1 ) Implies(2) 8t1 : Time (wde ; 1; t1 ) ) (Rp3 ; 1; t1 ) 8-intro (3) from j : Occ ; 8t2 : Time (wde ; j ; t2 ) ) (Rp3 ; j ; t2 ) Ind. hypothesis from (wde ; j + 1; t3 )

:::

infer (Rp3 ; j + 1; t3 ) 5.2 (wde ; j + 1; t3 ) ) (Rp3 ; j + 1; t3 ) infer 8t1 : Time (wde ; j + 1; t1 ) ) (Rp3 ; j + 1; t1 ) infer 8i : Occ ; t1 : Time (wde ; i ; t1 ) ) (Rp3 ; i ; t1 )

see below Implies(5.1) 8-intro (5.2) Induction(4, 5)

The proof that : ins (D 1 t1) leads to a contradiction in line 2.3 is: ;

;

34

from : ins (D ; 1; t1 ) : (9 t2 : Time t2 t1 ^ (" D ; 1; t2 )^ 8t3 : Time t2 t3 < t1 ) : (# D ; 1; t3 )) dfn. ins (2.3) .2 8t2 : Time t2 > t1 _ : (" D ; 1; t2 ) _ 9 t3 : Time t2 t3 < t1 ^ (# D ; 1; t3 ) deMorgan(.1) .3 0 > t1 _ : (" D ; 1; 0) _ 0 t3 < t1 ^ (# D ; 1; t3 )8-elim (t2=0), 9 -elim .4 from case : (" D ; 1; 0) .4.1 (" D ; 1; 0) A2ax1 infer false Contra(.4, .4.1) .5 0 t3 < t1 ^ (# D ; 1; t3 ) cases(.3, .4) .6 ins (D ; 1; t3 ) ^ (Rp3 ; 1; t3 ) A2ax11(.5) .7 : empty (t3 ) Lax1(.6) .8 : (8j1 : Occ ; t4 : Time t4 t3 ^ (wde ; j1 ; t4 ) ) 9 t5 : Time t5 < t3 ^ (rds ; j1 ; t5 )) dfn empty(.7) .9 t4 t3 ^ (wde ; j1 ; t4 ) ^ 8t5 : Time t5 t3 _ : (rds ; j1 ; t5 ) deMorgan, 9 -elim (.8) .10 (# B ; j1 ; t4 ) Lax3(.9) .11 (# B ; 1; t1 ) ^ t4 t3 < t1 2.1, .9, .5 .12 j1 < 1 RTL-prev(.10, .11) infer false Contra(.12, Occ)

.1

The above proof used the following basic RTL lemma:

Lemma 7

RTL-Prev

8e : Event ; i ; j : Occ ; t1 ; t2 : Time ( (e ; i ; t1 ) ^ (e ; j ; t2 ) ^ t1 < t2 ) ) i < j A proof of this lemma is not given here, but has been carried out in PVS from the RTL axioms given in Appendix 2. The proof that empty (t1 ) leads to a contradiction in line 2.5 is:

35

from empty (t1 ) 8j2 : Occ ; t2 : Time t2 t1 ^ (wde ; j2 ; t2 ) ) 9 t3 : Time t3 < t1 ^ (rds ; j2 ; t3 ) dfn empty(2.5) .2 t1 t1 ^ (wde ; 1; t1 ) ) 9 t3 : Time t3 < t1 ^ (rds ; 1; t3 ) 8-elim (t2=t1, j2=1)(.1) .3 9 t3 : Time t3 < t1 ^ (rds ; 1; t3 ) Logic(2, .2) .4 t3 < t1 ^ (rds ; 1; t3 ) 9 -elim (.3) .5 (" E ; 1; t3 ) Lax7(.4) .6 (# D ; 1; t3 ) A2ax5(.5) .7 ins (D ; 1; t3 ) ^ (Rp3 ; 1; t3 ) A2ax11(.6) .8 : empty (t3 ) Lax1(.7) .9 : (8j3 : Occ ; t4 : Time t4 t3 ^ (wde ; j3 ; t4 ) ) 9 t5 : Time t5 < t3 ^ (rds ; j3 ; t5 )) dfn empty(.8) .10 t4 t3 ^ (wde ; j3 ; t4 ) ^ 8t5 : Time t5 t3 _ : (rds ; j3 ; t5 ) deMorgan, 9 -elim (.9) .11 t4 t3 ^ (wde ; j3 ; t4 ) ^ t3 < t1 ^ (wde ; 1; t1 ) .10, .4, 2 .12 j3 < 1 RTL-prev(.11) infer false Contra(.12, Occ)

.1

Line 5.1 of the RW-Coord lemma proof is proved as follows:

36

from (wde ; j + 1; t3 ) (wde ; j ; t4 ) ^ t4 < t3 RTL-ax2(5.1) ins (D ; j + 1; t3 ) ^ : empty (t3 ) ) (Rp3 ; j + 1; t3 ) Lax1 from : ins (D ; j + 1; t3 ) case 1 of .2 (wde ; j ; t4 ) ) (Rp3 ; j ; t4 ) 8-elim (t2=t4)(5) (Rp3 ; j ; t4 ) Logic(.1, .3.1) ins (D ; j ; t4 ) ^ : empty (t4 ) Lax1(.3.2) (# E ; j ; t5 ) ^ t4 + u2 t5 t4 + l2 A2Steps(.3.2), 9 -elim (" D ; j + 1; t5 ) A2ax3(.3.4) t5 ? u2 t6 t5 ? l2 ^ (" E ; i ; t6 ) A2ax9(.3.4), 9 -elim t3 t4 + y ? (u1 ? l1 ) SGBW(5.1, .1) : (9 t7 : Time t7 t3 ^ (" D ; j + 1; t7 )^ 8t8 : Time t7 t8 < t3 ) : (# D ; j + 1; t8 )) dfn. ins (.3) .3.9 8t7 : Time t7 > t3 _ : (" D ; j + 1; t7 ) _ 9 t8 : Time t7 t8 < t3 ^ (# D ; j + 1; t8 ) deMorgan(.3.8) .3.10 t5 > t3 _ : (" D ; j + 1; t5 ) _ 9 t8 : Time t7 t8 < t3 ^ (# D ; j + 1; t8 ) 8-elim (t7=t5) .3.11 from t5 > t3 .3.11.1 t4 + u2 > t4 + y ? (u1 ? l1 ) arith(.3.4, .3.7) .3.11.2 y u1 + u 2 assump 2 and 3 .3.11.3 t4 + y ? (u1 ? l1 ) t4 + u2 + l1 arith(.3.11.1, .3.11.2) .3.11.4 t4 + u2 > t4 + u2 + l1 arith(.3.11.1, .3.11.3) infer false arith(.3.11.4) .3.12 from : (" D ; j + 1; t5 ) infer false Contra(.3.12, .3.5) .3.13 9 t8 : Time t7 t8 < t3 ^ (# D ; j + 1; t8 )last case(.3.10, .3.11, .3.12) .3.14 t7 t8 < t3 ^ (# D ; j + 1; t8 ) 9 -elim (.3.13) .3.15 ins (D ; j + 1; t8 ) ^ (Rp3 ; j + 1; t8 ) A2ax11(.3.14), 9 -elim .3.16 : empty (t8 ) Lax1(.3.15) .3.17 : (8j3 : Occ ; t2 : Time t2 t1 ^ (wde ; j3 ; t2 ) ) 9 t3 : Time t3 < t1 ^ (rds ; j3 ; t3 )) dfn empty(.3.16) .3.18 t9 t1 ^ (wde ; j3 ; t9 ) ^ : 9 t3 : Time t3 < t1 ^ (rds ; j3 ; t3 ) deMorgan(.3.17), 9 -elim .3.19 (" D ; j + 1; t9 ) ^ (wde ; j + 1; t10 )^ (t9 < t10 ) t8 = t10 ) ^ (t9 t10 ) t8 = t9 )lemma Channel(.3.18) .3.20 t9 = t5 RTLax1(.3.5, .3.19) .3.21 t10 = t3 RTLax1(5.1, .3.19) .3.22 t5 t3 Logic(.3.11) .3.23 t8 = t3 Logic(.3.19, .3.20, .3.21, .3.22) .3.24 t8 < t3 .3.14 infer false Contra(.3.23, .3.24) .4 ins (D ; j + 1; t3 ) Contra(.3) .5 from empty (t3 )

.1 .2 .3 .3.1 .3.2 .3.3 .3.4 .3.5 .3.6 .3.7 .3.8

See below Contra(.5) Logic(.2, .4, .6)

infer false .6 : empty (t3 ) infer (Rp3 ; j + 1; t3 )

37

The Shortest Gap Between Writes (SGBW) lemma used above, is the following crucial lemma which exploits the information about the minimum interarrival time between inputs (assumption 1) upon which the whole proof rests. It encodes the fact that the shortest time between writes occurs when the input events occur as fast as possible, and a slow execution of state B is followed by a fast execution of it. Its proof is given below.

Lemma 8

Shortest Gap Between Writes

8i : Occ ; t1 ; t2 : Time (wde ; i ; t1 ) ^ (wde ; i + 1; t2 ) ) t2 t1 + y ? (u1 ? l1 ) The other lemma used above is Channel ; its proof is also given below.

Lemma 9

Channel

8i : Occ ; t3 : Time (# D ; i ; t3 ) ) 9 t1 ; t2 : Time (" D ; i ; t1 ) ^ (wde ; i ; t2 ) ^ (t1 < t2 ) t3 = t2 ) ^ (t1 t2 ) t3 = t1 ) The proof of line .5 is: from empty (t3 ) 8j4 : Occ ; t10 : Time t10 t3 ^ (wde ; j4 ; t10 ) ) 9 t11 : Time t11 < t3 ^ (rds ; j4 ; t11 ) dfn empty .2 t3 t3 ^ (wde ; j + 1; t3 ) ) 9 t11 : Time t11 < t3 ^ (rds ; j + 1; t11 ) 8-elim (t10=t3, j4=j+1) .3 9 t11 : Time t11 < t3 ^ (rds ; j + 1; t11 ) implies(5.1, .2) .4 t11 < t3 ^ (rds ; j + 1; t11 ) 9 -elim (.3) .5 (" E ; j + 1; t11 ) Lax7(.4) .6 (# D ; j + 1; t11 ) A2ax5(.5) .7 ins (D ; j + 1; t11 ^ (Rp3 ; j + 1; t11 ) A2ax11(.6) .8 : empty (t11 ) Lax1(.7) .9 : (8j5 : Occ ; t12 : Time t12 t11 ^ (wde ; j5 ; t12 ) ) 9 t13 : Time t13 < t11 ^ (rds ; j5 ; t13 )) dfn empty(.8) .10 9 j5 : Occ ; t12 : Time t12 t11 ^ (wde ; j5 ; t12 )^ 8t13 : Time t13 t11 _ : (rds ; j5 ; t13 ) deMorgan(.9) .11 t12 t11 ^ (wde ; j5 ; t12 ) 9 -elim (.10) .12 9 t14 : Time t14 t11 ^ (" D ; j + 1; t14 )^ 8t15 : Time t15 t15 < t11 ) : (# D ; j + 1; t15 ) dfn. ins (.7) .13 t14 t11 ^ (" D ; j + 1; t14 ) 9 -elim (.12) .14 (" D ; j + 1; t16 ) ^ (wde ; j + 1; t17 )^ (t16 < t17 ) t11 = t17 ) ^ (t16 t17 ) t11 = t16 ) lemma Channel(.6) .15 t16 = t14 RTLax1(.13, .14) .16 t17 = t3 RTLax1(5.1, .14) .17 t14 < t11 < t3 .13, .4 .18 t16 < t17 arith(.14-.17) .19 t11 = t3 logic(.14,.18) infer false Contra(.19,.4)

.1

The proof of Shortest Gap Between Writes (SGBW) lemma is: 38

from Assumptions ; Activity A Theory from (wde ; i ; t1 ); (wde ; i + 1; t2 ) (# B ; i ; t1 ) Lax3(1) (# B ; i + 1; t2 ) Lax3(1) (" B ; i ; t3 ) ^ t1 ? u1 t3 t1 ? l1 A1ax9(1.1) (" B ; i + 1; t4 ) ^ t2 ? u1 t4 t2 ? l1 A1ax9(1.2) (# A; i ; t3 ) A1ax5a(1.3) (# A; i + 1; t4 ) A1ax5a(1.4) ins (A; i ; t3 ) ^ (Rp1 ; i ; t3 ) A1ax11a(1.5) ins (A; i + 1; t4 ) ^ (Rp1 ; i + 1; t4 ) A1ax11a(1.6) (Rp 1; i ; t3 ) ^ (Rp 1; i + 1; t4 ) ) t4 > t3 + y 8-elim (assump 1) t4 > t3 + y Logic(1.7, 1.8, 1.9) t2 t3 + y + l 1 arith(1.4, 1.10) infer t2 t1 + y ? (u1 ? l1 ) arith(1.3, 1.11) 2 (wde ; i ; t1 ) ^ (wde ; i + 1; t2 ) ) t2 t1 + y ? (u 1 ? l 1) Logic(1) infer 8i : Occ ; t1 ; t2 : Time (wde ; i ; t1 ) ^ (wde ; i + 1; t2 ) ) t2 t1 + y ? (u1 ? l1 ) 8-intro (2)

1 1.1 1.2 1.3 1.4 1.5 1.6 1.7 1.8 1.9 1.10 1.11

The proof of the channel lemma is: from Channel ; A2 Theory ; i : Occ ; t3 : Time from (# D ; i ; t3 ) (Rp3 ; i ; t3 ) A2ax11(1) ins (D ; i ; t3 ) ^ : empty (t3 ) Lax1(1.1) : (8i1 : Occ ; t4 : Time t2 t3 ^ (wde ; i1 ; t4 ) ) 9 t5 : Time t5 < t3 ^ (rds ; i1 ; t5 )) dfn empty(1.2) 1.4 9 i1 : Occ ; t4 : Time t4 t3 ^ (wde ; i1 ; t4 )^ : (9 t5 : Time t5 < t3 ^ (rds ; i1 ; t5 )) deMorgan(1.3) 1.5 t4 t3 ^ (wde ; i ; t4 ) 9 -elim (1.4) 1.6 9 t6 : Time t6 t3 ^ (" D ; i ; t6 )^ 8t7 : Time t6 t7 < t3 ) : (# D ; i ; t7 ) dfn. ins (1.2) 1.7 t6 t3 ^ (" D ; i ; t6 ) 9 -elim (1.6) 1.8 (rs ; i ; t6 ) Lax4(1.7) 1.9 9 t8 : Time (rds ; i ; t8 ) ChAx3(1.8, 1.5) 1.10 (rds ; i ; t8 ) 9 -elim (1.9) 1.11 (t6 < t4 ) t8 = t4 ) ^ (t6 t4 ) t8 = t6 ) Chax4(1.10, 1.5, 1.8) 1.12 (" E ; i ; t8 ) Lax7(1.10) 1.13 (# D ; i ; t8 ) A2ax5(1.12) 1.14 t8 = t3 RTLax1(1, 1.13) infer 9 t6 ; t4 : Time (" D ; i ; t6 ) ^ (wde ; i ; t4 )^ (t6 < t4 ) t3 = t4 ) ^ (t6 t4 ) t3 = t6 ) 9 -intro (1.14, 1.11, 1.7, 1.5) infer (# D ; i ; t3 ) ) 9 t1 ; t2 : Time (" D ; i ; t1 ) ^ (wde ; i ; t2 )^ (t1 < t2 ) t3 = t2 ) ^ (t1 t2 ) t3 = t1 ) Implies(1)

1 1.1 1.2 1.3

39

ADL: An Activity Description Language for Real-Time ... - CiteSeerX

ADL: An Activity Description Language for Real-Time ... - CiteSeerX

Suggest Documents

DAOP-ADL: An Architecture Description Language for ... - CiteSeerX

Ï-ADL: An Architecture Description Language based on ... - CiteSeerX

Ï-ADL: An Architecture Description Language based on ... - CiteSeerX

Automatic Architecture Description Language (ADL)-Based Toolchain ...

An Architecture Description Language for Massively ... - CiteSeerX

MAML - An Architecture Description Language for ... - CiteSeerX

An Architecture Description Language for Massively ... - CiteSeerX

ADL - An Algebraic Database Language 1 Introduction - CiteSeerX

ADL: An Algorithm Definition Language for ... - University College Dublin

An Integrated Approach for Realtime Floodmap ... - CiteSeerX

An XML description language for web-based network ... - CiteSeerX

ISDL: An Instruction Set Description Language for ... - CiteSeerX

25 adele: an attack description language for

Towards an Infrastructure Description Language for Modeling ...

A Description Language For Composable Components - CiteSeerX

A Method-Description Language - CiteSeerX

Human Activity Language - CiteSeerX

Resource Description Language: A Unified Description Language for ...

LePUS3: An Object-Oriented Design Description Language - CiteSeerX

An Enhanced Hardware Description Language ...

Analog Boundary-Scan Description Language (ABSDL ... - CiteSeerX

Roll your own Hardware Description Language - CiteSeerX

Architecture Description Language Driven Design Space ... - CiteSeerX

A Universal Service-Semantics Description Language - CiteSeerX

ADL: An Activity Description Language for Real-Time ... - CiteSeerX