Using a Process Algebra to control B OPERATIONS - Semantic Scholar

Using a Process Algebra to control B OPERATIONS Helen Treharne and Steve Schneider

Department of Computer Science, Royal Holloway, University of London, Egham, Surrey, TW20 0EX, UK.

E-mail: [email protected] Abstract

The B-Method is a state-based formal method that describes system behaviour in terms of MACHINES whose state changes under OPERATIONS. The process algebra CSP is an event-based formalism that enables descriptions of patterns of system behaviour. This paper is concerned with the combination of these complementary views, in which CSP is used to describe the control executive for a B Abstract System. We discuss consistency between the two views and how it can be formally established. A typical avionics system motivates the work. Its speci cation and control executive are presented in the paper. The relationship with other approaches is also discussed.

1 Introduction The B-Method [1] has been successfully used to specify and implement the functionality of software modules in a system [5]. A B speci cation is concerned with the information contained within a system and how it can be manipulated and accessed by means of modules. In a system there will also be software which controls the order in which the modules are executed. This software is called a control executive. There is no explicit expression of this executive in the description of a system in the development process of [5] or indeed within the standard B-Method. Process algebras such as Communicating Sequential Processes (CSP) [9] are concerned with the evolution of systems as they execute sequences of events. They are appropriate for describing execution patterns. CSP and B are concerned with dierent aspects of a system description, and it seems natural to use CSP to specify the possible sequences of transitions, and B to specify the transitions individually. The two views will be consistent if the CSP control executive can never invoke a module outside its pre-condition. The relationship between state and event based formalisms is becoming better understood, see for example [8], [11], [12] among others. In this paper we will explore a formal basis for a relationship between B and CSP. This will provide a formal link for a system whose control executive has been de ned as a CSP process and whose functional behaviour has been speci ed in a B speci cation. De ning, verifying and exploiting this new relationship between state based and event based views of a system is the contribution of this paper.

The combination enables us to express complex safety properties of the system in the CSP description which would have been more dicult and cumbersome to model in the B description. In de ning this link we have been heavily in uenced by Back's Action Systems [3] and their correspondence with CSP. This correspondence is described by Morgan [10] in terms of weakest pre-condition semantics and the failures-divergences model. This paper is organised as follows. Section 2 gives an overview of the BMethod. Section 3 gives a brief introduction to the correspondence between Action Systems and CSP and shows how the B-Method can also be coupled with CSP. Section 4 presents the theoretical foundations of the speci c relationship between B and CSP. Section 5 illustrates a typical embedded avionics system in B whose functionality motivated the need for this work. Sections 6 and 7 detail a control executive for the example and model its safety properties. The nal section contains a discussion.

2 Overview of the B-Method The B-Method is a collection of mathematically based techniques for the speci cation, design and implementation of software modules. Systems are modelled as a collection of interdependent abstract machines. An abstract MACHINE is described using the Abstract Machine Notation (AMN). In the paper we adopt the convention that AMN keywords are indicated in bold uppercase letters. Large MACHINEs can be constructed from other MACHINEs using INCLUDES, SEES and other constructs. A MACHINE encapsulates some local state and a collection of modules called OPERATIONS. OPERATIONS in a MACHINE can be pre-conditioned. They have the form PRE P THEN T END, where P is a pre-condition and T describes the eect of invoking the OPERATION. Pre-conditions are predicates on the state of a MACHINE which constrain the cases when an OPERATION is entitled to be invoked. If an OPERATION is invoked within its pre-condition then the system will behave as expected with respect to the speci cation. However, if an OPERATION is invoked outside its pre-condition the resulting execution may be an incorrect behaviour of the system. The B-Method supports the design of software modules. This re nement transforms an abstract description of the software into a more concrete description. Hence, it can add more detail to the original speci cation, or it can be closer to an implementation. A REFINEMENT is a MACHINE which supports this transformation. It allows sequential composition of OPERATIONS, unlike abstract MACHINEs. In this paper we are interested in using CSP to describe control executives for B MACHINEs where the CSP events correspond to B OPERATIONS being called within their pre-conditions. In particular, we will refer to a B Abstract System, which is a MACHINE at the top of a hierarchy of MACHINEs which specify OPERATIONS to be implemented in software. It is these OPERATIONS which need to be constrained by a control executive.

3 Overview of the correspondence between Action Systems and CSP In this section Action Systems are de ned. We then de ne their relationship with CSP. More detailed introductions to these formalisms can be found in [3], [4] and [10]. Alongside these de nitions we note the dierence between the B-Method and Action Systems and a B Abstract System's relationship to CSP. An Action System is a transition system represented by variables, an initialisation and a set of actions which are represented by statements in an extended version of Dijkstra's guarded command language [6]. An action G ! S consists of a guard, G, and a statement, S, on the state variables. S can only be executed when G holds, that is, when the action is enabled, otherwise the action is blocked. A guard diers from a pre-condition in the B-Method because an OPERATION can still execute when its pre-condition does not hold, though no guarantees can be made of the resulting behaviour. The wp predicate, wp (S ; Q ), identi es the initial states from which any execution of statement S is guaranteed to terminate and establish the postcondition Q . For example, wp (T ; true ) holds of any initial state from which execution of T is guaranteed to terminate (establishing true). The weakest precondition semantics for a guarded command, G ! S , is given in [10] as follows: De nition 1 wp (G ! S ; Q ) =b G ) wp (S ; Q ) If the guard G is true, then any execution G ! S will establish a post-condition Q precisely when S will establish Q . If G does not hold there is no execution and so wp (G ! S ; Q ) is vacuously true. An action is only enabled when :wp (G ! S ; false ) holds. In the B-Method, an OPERATION can be viewed in terms of a guarded command. The guard G is always true and the statement S takes the form PRE P THEN T END. For the purposes of this paper T will be restricted to AMN constructs which are implementable. Therefore, SELECT statements are not permitted and the law of the excluded miracle holds for T : wp (T ; false ) = false . The weakest pre-condition semantics for a pre-condition statement in terms of a guarded command is as follows: De nition 2 wp (true ! PRE P THEN T END; Q ) =b P ^ wp (T ; Q ) An Action System exhibits the same behaviour as a Dijkstra guarded iteration statement. Firstly, the initialisation is executed, then repeatedly an enabled action is selected and the associated statement is executed. If no guard is enabled the system terminates. This diers from a MACHINE where all the OPERATIONS are always enabled. This fact will be important when we look at De nition 6. Morgan [10] uses a conjugate of the wp when relating Action Systems and CSP. This allows the predicate to capture the notion of identifying the existence of initial states from which the action can either terminate and establish the post-condition or alternatively not terminate.

De nition 3 wp(S ; Q ) =b :wp (S ; :Q ) For example, if wp (T ; false ) = false then wp (T ; true ) = true : any statement obeying the law of the excluded miracle can either terminate (establishing true) or else not terminate. Furthermore, wp (T ; false ) can only hold if T is not guaranteed to terminate: :wp (T ; true ), that is it has some non-terminating execution. An Action System consists of a pair (ini ; A), where ini is an action de ning the initialisation of the system and A is a set of actions. The wp semantics of sequences of actions tr : A is de ned inductively on the sequence, following the wp characterisation of sequential composition: wp (hi; Q ) = Q

wp (a ; tr ; Q )= wp (a ; wp (tr ; Q ))

where hi is the empty sequence, a ; tr is the sequence tr pre xed with the action a , and A is the set of all nite sequences of elements of A.

The correspondence between CSP and Action Systems or a B Abstract System is achieved by giving them a CSP semantics: identifying the traces, failures and divergences associated with an Action System or a B Abstract System. These are given in [10] as follows: De nition 4 The traces tr : A of a system are those for which wp (ini ; tr ; true ) holds A trace tr of a system is a nite sequential composition of enabled OPERATIONS or actions. It corresponds to an execution where none of the actions are blocked when invoked. In a B Abstract System (with implementable OPERATIONS) OPERATIONS are never blocked, so all traces are possible.

De nition 5 The divergences tr : A of a system are those for which wp (ini ; tr ; false ) holds

A trace tr is a divergence if execution of the sequence of actions or OPERATIONS listed in tr might not terminate. In an Action System a divergence can only occur if an enabled action is executed but fails to terminate. This can only happen from aborting the execution. Conversely, in a B Abstract System divergence can result from executing one of its OPERATIONS when its pre-condition was false. De nition 6 The trace tr : A and set R  A constitute a failure (tr ; R) of a system if wp (ini ; tr ; :gd (R )) holds In an Action System R is the refusal set of actions. The actions in R can be refused when the initialisation followed by a nite trace tr results in a state in which none of the guards in R are enabled. In a B Abstract System however, there are never any refusals (unless tr is a divergence). For non-divergent traces, R will always be ? since all guards are always true; and for divergent traces, any refusal set is possible. Non-divergent traces are those for which

:wp (ini ; tr ; false ) = wp (ini ; tr ; true ) holds: execution of the sequence of OPERATIONS in tr is guaranteed to terminate.

The failures-divergences semantics of a B Abstract System (with implementable OPERATIONS) is thus completely characterised by its divergences. The B Abstract System will always exhibit all traces, and the refusals associated with any trace are determined by whether or not that trace is a divergence. The following gure is an example of two OPERATIONS with its traces and associated divergences.

INITIALISATION traces = fon ; o g n := 0 div = ftr j tr = o _ OPERATIONS On =b PRE n = 0 THEN n := 1 END hon ; on i 4 tr _ ho ; o i 4 tr g O =b PRE n = 1 THEN n := 0 END END Figure 1: Example OPERATIONS with traces and divergences 0

This section has considered B OPERATIONS as actions whose guards are always true. Hence, Morgan's correspondence can be used to identify those traces and divergences associated with a B Abstract System.

4 A new coupling between B and CSP loops As described in the previous section, the guards of an action can control the order of execution of actions in an Action System. Abrial [2] has a notion of guarded substitutions based on SELECT statements. These statements are akin to actions and have been used to control the execution of OPERATIONS in speci cations of distributed systems. However, this technique in the B-Method is not in general implementable; SELECT statements cannot be re ned to code. We restrict ourselves to using pre-conditioned substitutions which describe the conditions under which the OPERATIONS of a B Abstract System should execute. The aim is to build a control executive based on these OPERATIONS which discharge their pre-conditions. The executive will ultimately run on a sequential processor. This section is split into two parts. Firstly, we describe the events that can be part of a control executive. Then, we identify some conditions to show that both these views of the system are consistent.

4.1 Developing a Control Executive

Consider a recursive CSP process, LOOP . In general this will be de ned as a parameterised mutual recursion. A family of processes S (p ) is used to de ne

LOOP , where p is a collection of expressions for keeping track of which process to execute. Each process de nition represents a sequence of B OPERATIONS to be executed. The information in p is only being carried where it aects the possible executions of the process. In the simple case they will simply be indices represented by numbers and the initial state would be 0 follows: LOOP = S (0) S (0) = R0 S (n ) = Rn The syntax of the CSP terms in the process bodies is given by the following pseudo-BNF rule: R ::=a ! R j R1 u R2 j if x then R1 else R2 end j

?

!

?!

a ?x : T ! R (x ) j a x ! R j a w ! R (w ) j a x w ! R (w ) j S (p )

The a ! R represents a system which is prepared to engage in an event a and then immediately behave as term R . Depending on which process the environment is prepared to co-operate with, the internal choice, R1 u R2 , is resolved to behave either as R1 or R2 . The conditional statement will perform R1 provided x holds otherwise process R2 executes. The S (p ) is a process name and p is a collection of expressions. Each process body will be bound by an S (p ). For example, in the above process S (n ) the last event in its de nition could be S (0) in order to provide a binding for the mutual recursive case. All the processes would need similar bindings for the recursion to be mutually recursive. You will notice that the terms for inputs and outputs are not standard CSP syntax. The aim of the CSP control executive is to drive the B OPERATIONS. There are two environments to consider with respect to the control executive, as shown in gure 2. Firstly, the environment of the whole system which is external to both the CSP and B descriptions. Secondly, the CSP description is part of the environment of the B description of the Abstract System. We make this distinction in the CSP syntax so that it is clear which environment the inputs and outputs are being communicated from. Since the inputs and outputs will correspond to values of parameters of B OPERATIONS their syntax in the CSP description is understood from the point of view of the B Abstract System. The term a ?x ! R (x ) is the standard CSP term which describes a process that is initially ready to accept any value of x of type T . Its subsequent behaviour depends on the value x it receives as input. The input x is from the environment of the whole system and is passed into the B speci cation. This

ow of information is shown in gure 2. The term a ?x ! R represents an input into the B speci cation which has come from the control executive and not from the environment of the whole system. The CSP semantics of this term will be the same as an event communicating over an output channel (for example a !c ) because it can be viewed as

External Environment CSP CSP Description

?

? B Description

! B

KEY ? from External Environment

?

!

from B Description

from CSP Description

Figure 2: Environment and I/O distinctions passing the information from the CSP description into the B description. Such terms are used in order to pass information across OPERATIONS. Furthermore, the event is visible and can appear in the trace of the control executive and so it is also passed to the external environment. The term a !w ! R (w ) is willing to output w and subsequently behave as R (w ). This identi es that the output value comes from the B speci cation. The CSP description has no control over determining the value of the output. The CSP semantics of this term will be the same as a CSP event with an input channel because it can be viewed as accepting input from the B speci cation. In our restricted language there is no term with the standard CSP syntax for output over a channel. In our combination this would correspond to both the CSP control executive and the B description setting the output value. The CSP is simply driving the OPERATIONS and has no part in constraining the values of the outputs. The term a ?x !w ! R (w ) accepts input x and outputs w and then behaves as R (w ). In practice we never combine inputs from the external system with inputs and outputs from the B Abstract System in a CSP event in order to reenforce the distinction between the environments. However, the syntax could be extended to handle this if required. The LOOP will be well-formed only if all the variables are bound. This is the case because either inputs are from the external environment or from the B description or else given as parameters of the mutual recursion.

4.2 Consistency of a CSP Control Executive and a B Abstract System

Now that we have a CSP control executive, we need to demonstrate that it is appropriate for a particular B Abstract System. It will be a suitable executive

for an Abstract System, M , if traces (LOOP ) \ divergences (M ) = ?

Since LOOP is driving the OPERATIONS that are executed, it is suitable as a control executive if it ensures that any call of one of M 's OPERATIONS is within its pre-condition. This property is preserved by re nement, which means that suitable control executives can be re ned further within CSP and remain appropriate. The aim of this section is to provide conditions on LOOP and M which establish this appropriateness. Consider the Abstract System M with OPERATIONS such that each operation name corresponds to a CSP event Ename . In order to establish that LOOP is appropriate for M we must discuss the events in the family of processes of LOOP as OPERATIONS. Therefore we translate the body of each process de nition into the equivalent sequence of AMN OPERATIONS. In order to demonstrate consistency we de ne an AMN construct BBODYS (p ) to be the translation of the body of the CSP process S (p ) into the equivalent AMN. There will be one BBODYS (p ) for each CSP process body. The translation fS (p )g = BBODYS (p ) is de ned inductively as follows:

fEname ! P g = name ; fP g fP u Q g = CHOICE fP g OR fQ g END fif xc then P else Q end g = IF [xc ] THEN fP g ELSE fQ g END fEname ?xc : T ! P (xc )g = @xb  xb 2 T =) name (xb ) ; fP gfx 7!x g fEname ?xc ! P g = name ([xc ]) ; fP g fEname !wc ! P (wc )g = wb name ; fP gfw 7!w g fEname ?xc !wc ! P (wc )g = wb name ([xc ]) ; fP gfw 7!w g fS (p 0 )g = cb := [p 0] c

c

b

b

c

b

In each body of a process S (p ) the last event is a call to another process, S (p 0 ), within the recursive de nition. This is why there is a mapping from a process S (p 0 ) in the translation. The translation of the CSP process name parameterised with a collection of expressions, S (p 0 ), corresponds to an AMN

assignment. The assignment is made to a collection of AMN control variables,

cb . The control variables are not part of the Abstract System M but their importance will be discussed shortly. AMN variables are subscripted with b so

that it is clear that they are AMN variables. There will be one control variable for each CSP parameterised expression. If there is only one CSP expression the mapping will be a simple assignment. However, if there are many expressions the mapping will be a multiple assignment. The assignment is made to the

value of the expressions at that point in the translation which will be contained in . Use of the environment binding, , is a standard technique in denotational semantics [13]. In our case it is de ned as a function from variables to values:  : VAR ! VAL We can lift  to apply to expressions in the usual way. For example, for (x ) = 3 and (y ) = 4 we can de ne (x > y ) = TRUE if (x ) is greater than (y ) and (x > y ) = FALSE otherwise. Then VAL will include naturals and booleans. The translation mapping containing the event Ename ?xc : T inputs a value from the environment and updates . The variables of the CSP channels are subscripted with c , in order to reinforce the distinction between CSP and B variables. Following the input the binding is updated with the new value for the variable xc . The condition for x to be of a particular type in the CSP is embedded in the AMN as a guarded statement to ensure that the pre-condition of the OPERATION is met. The translation mapping containing Ename ?xc passes an input into the B description having rst evaluated the value of xc under the current binding. We do not need a guard in this translation because if CSP passes a value of the wrong type to the B description the proof obligation to discharge the fact that the pre-condition is met will be unprovable. When outputting a value from the B description into the CSP description, Ename !wc , we see that the binding is updated to re ect the new value for the variable wc from the value of the output wb . Given a sequence of OPERATIONS corresponding to a CSP control executive we need to nd a control loop invariant, CLI , in order to prove consistency. This invariant need not necessarily hold after individual OPERATIONS but must hold at the end of every pass through the loop. It can refer to the control variables, discussed above, and state variables from the Abstract System M . Therefore for each BBODYS (p ) the CLI will meet the following condition: (CLI ^ I ^ cb = [p ]) ) [BBODYS (p ) ]CLI

(1)

This condition states that CLI is preserved by BBODYS (p ) within the context of the Abstract System, which has invariant I and given the value of the control variables. I is already known to be preserved by all OPERATIONS, by the internal consistency of M . In addition to the above, the following condition ensures that CLI is true following the initialisation of the Abstract System M and the initial state of the control variables. The initialisation of M does not refer to the control variables but CLI may be dependent on the initial state of the parameters of the mutual recursion. [Init ; cb := [p ] ]CLI

(2)

These conditions will be sucient to guarantee that LOOP is appropriate for M as stated below in Theorem 1. The existence of CLI yields that BBODYS (p ) is non-divergent, which means that all the OPERATIONS are called within their pre-conditions. The following lemmas are steps towards proving Theorem 1. The proofs for these lemmas are given in [14]. Lemma 1 8 tr  ((CLI ^ I ^ cb = [p ]) ) wp (tr ; true )) ) ((CLI ^ I ^ cb = [p ]) ) wp (tr ; I )) If tr is a non-divergent trace then executing the trace from a state in which CLI , I and the current state of the control variables hold will establish the invariant of the Abstract System.

Lemma 2 If P ) [fBBODYF g ]Q then 8 tr  tr a hupdatep ; Xi 2 traces (F (UPDATE )) ) (P ) wp (tr ; cb := [p 0]; Q )) 0

This lemma provides the formal link between the behaviour of the B Abstract System and the traces of the CSP process. In essence it con rms that the translation of CSP terms is sensible. fBBODYF g represents a sequence of OPERATIONS resulting from the translation of the terms in F under the environment binding , where F is used to indicate the body of a process S (p ). It states that a terminating execution of BBODYF under  from a state satisfying P is guaranteed to establish the post-condition Q . Likewise any terminating trace of the corresponding CSP process, F (UPDATE ), together with the update of the control variables is guaranteed to establish the postcondition Q . We are concerned with terminating traces but the termination event, X, will not appear in a trace of a sequence of OPERATIONS. Therefore by viewing the function as the process body and passing Skip as its argument we can introduce termination explicitly. Thus we can de ne an arbitrary terminating trace in order establish a post-condition for all traces. However, by passing the simple process Skip into the function argument we lose the information about the update of the control variables, since the next call to a parameterised process is replaced by Skip . The control variables re ect which process body to execute. At the beginning of the sequence they evaluate to the value of the current parameterised process. At the end of the sequence of events they should re ect the value of the next parameterised process to execute. The post-condition Q may refer to these updated variables, following a sequence of OPERATIONS. Therefore we need an explicit way of introducing the update in the CSP analysis. We de ne a vector UPDATE where each element is de ned as UPDATEp = updatep ! Skip to correspond to a process which explicitly updates the control variables to the value p 0 and then terminates. Therefore if a trace together with the explicit update of the control variables is a terminating trace of the process body F , it must establish the post-condition Q . Observe that in the lemma we have mixed the notations of wp and generalised substitution. We want to make the distinction between a sequential 0

composition of OPERATIONS establishing a post-condition and a sequence of events, corresponding to OPERATIONS, terminating to establish a postcondition. We could not have modelled the control executive as a sequential composition of terminating process de nitions using Skip because we would have lost the information needed for the control variables.

Corollary 1 If tr ahupdatep ; Xi 2 traces (Fp (UPDATE )) then (CLI ^I ^cb = [p ]) ) wp (tr ; cb := [p 0 ]; CLI ) 0

This follows from the previous lemma where the process body F is subscripted by p to highlight which process body is referred to within a family of processes. Therefore, if a trace together with the explicit update of the control variables is a terminating trace of the process body Fp , it must establish the control loop invariant.

Corollary 2 If tr ahupdatep ; Xi 2 traces (Fp (UPDATE )) then (CLI ^I ^cb = [p ]) ) wp (tr ; cb := [p 0 ]; CLI ^ I ) 0

Terminating traces of the process body Fp together with the explicit update of the control variables establish the control loop invariant and the invariant of the B Abstract System. These results are enough to establish the following lemma.

Lemma 3 If Y = G (Y ) is a mutual recursive CSP process then (i) 8 p  Stop sat (CLI ^ I ^ cb = [p ]) ) wp (tr ; true ) and (ii) if 8 p  Y p sat (CLI ^ I ^ cb = [p ]) ) wp (tr ; true ) then 8 p  G (Y )p sat (CLI ^ I ^ cb = [p ]) ) wp (tr ; true ) 1

These conditions enable CSP recursion induction to be applied. It states that the required speci cation that all traces are terminating is true for Stop and preserved by recursive calls. The following theorem follows from this lemma, where LOOP is a particular mutual recursive process. Theorem 1 LOOP sat (CLI ^ I ^ cb = [p ]) ) wp (tr ; true ) Hence if a CLI can be found to make conditions (1) and (2) hold, then traces (LOOP ) \ divergences (M ) = ?. The above theorem refers to a trace as a sequence of OPERATIONS of the Abstract System. These OPERATIONS make no reference to control variables. The control variables are only needed in the theory when demonstrating that the translation of the bodies of CSP processes into their AMN equivalent establish the control loop invariant, since the invariant can include predicates based on these control variables. 1

P sat S means 8 tr  tr 2 traces (P ) ) S

Lemma 3 and Theorem 1 are concerned with whether the traces are divergent or not. The updates to control variables need not form part of these statements. However, having control variables within these statements would make no dierence to whether the traces are divergent or not. Since they do not appear in the traces of the CSP control executive it is more natural not to include them. S (0) = on ! S (1) S (1) = o ! S (0) CLI : c = n ^ c 2 0 : : 1





on ! X1 o ! X0   on ! update1 ! Skip F (UPDATE ) = o ! update0 ! Skip F (X ) =

Figure 3: Example control loop and vector Figure 3 illustrates a control executive for an Abstract System containing the OPERATIONS de ned in Figure 1. CLI is de ned as the predicate that the control variable, corresponding to the value of the parameter in the process B , equals the state variable n . We also illustrate the use of the UPDATE vector needed in the CSP analysis. In the above we considered a sequence of OPERATIONS satisfying a control loop invariant. In [14] we show how we map the control executive description from CSP into an AMN REFINEMENT so that we can prove the CLI mechanically.

5 Example System This section presents a typical embedded avionics system which is a simple interlock. The inputs and outputs to the Interlock System are shown in gure 4. INPUTS

OUTPUTS

(maxStatus, checkData) critOutput1 Simple

critOutput2

Interlock sensorA

softwareOutput

sensorB

Figure 4: Simple Interlock Example The Interlock receives input from two sensors and a message from a serial

data-bus. The message contains data and check data values. The data, maxStatus, is the maximum value that the sensors can take, which is either LOW, MEDIUM or HIGH. The sensors, sensorA and sensorB, are valid if their re-

spective readings are less than or equal to the data value in the message. The check data, checkData, is used to ensure the authenticity of the message. The software must provide operations to copy the inputs from the hardware dual port memory into software so that the information can be processed. The main software function of the system processes the inputs and sets two critical outputs, critOutput1 and critOutput2, according to some algorithm. If the message and the sensors are invalid then both critical outputs are set to o. When the message and the sensors are valid there are two dierent behaviours. If both sensors are equal the rst critical output is set to on to activate a potentially hazardous mode of the system. However, if the sensors are not equal the second critical output is set to on to prevent a potentially hazardous mode from being reached. This leads to the rst safety property which states that both critical outputs cannot be on at the same time. There is a second safety constraint on the functionality which states that if the inputs are processed and a hazardous mode is reached, the next time inputs are received a hazardous state cannot be reached. In addition to the main function, the Interlock must also stimulate a software output, softwareOutput. This demonstrates to a watchdog component that the software is still operational. When the inputs are invalid the softwareOutput must state that no action has taken place; whereas when they are valid it must transmit information about the mode of the system. There is a control constraint which states inputs cannot be overwritten until processing has occurred.

5.1 AMN Speci cation

This section outlines an AMN speci cation for the Interlock software. The full speci cation is presented in [14]. The functionality is described in four separate MACHINEs which are combined into one top level MACHINE, as shown in gure 5. TopLevel

Validate Input Sensors

Processing

KEY INCLUDES

Input Message

SEES

Figure 5: AMN Speci cation Structure

The inputs to the Interlock System are modelled separately in the InputMessage and InputSensors MACHINEs. OPERATIONS in the Validate and Processing MACHINEs use these input values to derive the values of the

output and internal states. The Validate MACHINE contains the OPERATION ValidateMessage which sets a boolean variable to indicate the validity of an input message and sensor values. The main function in the Processing MACHINE is ProcessCrit, as shown in gure 6. ProcessCrit sets and outputs the rst critical output, critOutput1, provided the input message and sensors are valid and that both sensors are equal. It also sets the second critical output, critOutput2, provided the input message and sensors valid but the sensors values are not equal. The pre-condition on ProcessCrit states that the OPERATION should not be called when critOutput1 is already on and that performing the operation would set it on again. This pre-condition must be met when calling the operation in the control executive in order to meet the second safety constraint.

MACHINE Processing SEES

Bool TYPE , Types , InputMessage , InputSensors

VARIABLES

critOutput1 , critOutput2 , softwareOutput

haz ? ProcessCrit ( result ) =b PRE result 2 BOOL _ critOutput1 = o _ result = TRUE ^ sensorA 6= sensorB THEN IF result = TRUE ^ sensorA = sensorB

THEN INVARIANT critOutput1 := on k critOutput1 2 OUTPUT ^ critOutput2 := o k haz := on critOutput2 2 OUTPUT ^ ELSE : ( critOutput1 = on ^ critOutput1 := o k critOutput2 = on ) ^ critOutput2 := on k haz := o softwareOutput 2 SOFTWAREINFO END INITIALISATION END ; critOutput1 := o k TransmitMode ( result ) =b critOutput2 := o k PRE result 2 BOOL THEN softwareOutput := no event IF result = TRUE THEN OPERATIONS IF sensorA = sensorB THEN softwareOutput := active SetSafe =b ELSE BEGIN softwareOutput := inactive softwareOutput := no event k END critOutput1 := o k END critOutput2 := o END END ; END Figure 6: Processing Machine

The functionality of ProcessCrit is such that critOutput1 and critOutput2 are never set to on at the same time. We explicitly state this property as an INVARIANT of the Proccessing MACHINE. This speci es the rst safety property of the system. The OPERATION SafeState sets the output variable, softwareOutput in order to demonstrate the software is operational. It also sets the critical outputs to o. The OPERATION TransmitMode also sets the output variable, softwareOutput, to record information about the state of the Interlock software. The TopLevel MACHINE, shown in gure 7, combines the lower level MACHINEs to de ne a B Abstract System of the software. The ValidateMessage and ProcessCrit OPERATIONS are PROMOTEd directly which means they become OPERATIONS of TopLevel.

MACHINE TopLevel OPERATIONS ControlLoad ( inputStatus , inputData , SEES inputSensorA ,inputSensorB ) =b Types , PRE inputStatus 2 SENSORSTATUS ^ Bool TYPE inputData 2 CHECKDATA ^ INCLUDES inputSensorA 2 SENSORSTATUS ^ InputMessage , inputSensorB 2 SENSORSTATUS ^ InputSensors , enableInputs = TRUE Processing , THEN Validate LoadInputMessage ( inputStatus , inputData ) k PROMOTES LoadCritSensorA ( inputSensorA ) k ValidateMessage , LoadCritSensorB ( inputSensorB ) k ProcessCrit enableInputs := FALSE VARIABLES END ; enableInputs

INVARIANT enableInputs 2 BOOL INITIALISATION

enableInputs := TRUE

ControlSetSafe =b

BEGIN SetSafe k enableInputs := TRUE END ; ControlTransmitMode ( result ) =b

PRE result 2 BOOL THEN

TransmitMode ( result ) k enableInputs := TRUE

END END

Figure 7: Top Level Machine The new OPERATIONS in TopLevel specify the control constraint on loading input values. This imposes a constraint on a control executive for this system. A boolean state variable, enableInputs, is used as a ag to control when inputs can be read. In order to read inputs the enableInputs ag must

be true. This dictates the pre-condition of the ControlLoad OPERATION. The ag is reset to FALSE in the body of the OPERATION so that processing must occur before inputting values again. The functionality for loading inputs has already been speci ed in InputMessage and InputSensors. Therefore ControlLoad is speci ed as a parallel composition of setting the ag and the appropriate OPERATIONS. In order to allow inputs to be read again enableInputs is set to TRUE in ControlSetSafe and ControlTransmitMode. It is set in both OPERATIONS because the system will only execute one of these OPERATIONS depending on the validity of the inputs.

6 Control Executive Example Figure 8 is a suitable control executive for controlling the interlock example. It describes the possible orders in which OPERATIONS can be invoked. LOOP = S(0) S(0) = EControlLoad ?(inputStatus,inputData,inputSensorA,inputSensorB) ! EValidateMessage !result ! if result = TRUE then

!

EProcessCrit haz ! EControlTransmitMode (result ) ! S(1) else EControlSetSafe ! S(0) end

?

S(1) = if haz = on then EControlLoad ?(inputStatus ; inputData ; inputSensorA; inputSensorB ) ! EControlSetSafe ! S(0) else S(0) end CLI: enableInputs = TRUE ^ c 1 2 0 : : 1

Figure 8: Example Control Executive We choose EControlLoad to be the rst event in our control loop so that inputs are read and ready to be processed. The corresponding ControlLoad OPERATION has a non-trivial pre-condition which contains a control constraint. It states that the input ag must be enabled. Control constraints in uence how the loop is developed. The next time an iteration of the loop occurs the ag again has to hold true. We know that the speci cation of ControlSetSafe and ControlTransmitMode set the ag to be true. Thus their corresponding events should be called before a call to another process. This control constraint also provides a signpost as to a predicate which will be in the control loop invariant, CLI , i.e. enableInputs = TRUE . The inputs are then validated in the event EValidateMessage and the result is output. The remainder of process de nition S(0) is determined by whether result was valid or not. If it is invalid the system will always go into a safe state

by engaging in the event EControlSetSafe followed by the events of the process S(0) again. If it is valid the inputs are processed. In the AMN the pre-condition of the ProcessCrit OPERATION, which performs the processing, is not trivial. Therefore, the constraints must be modelled as conditional expressions in the CSP. This will ensure that the complex pre-condition is met. The rst time the loop is called it is allowable to carry out the events EProcessCrit !haz ! EControlTransmitMode ?(result ) ! : : : as de ned in S(0). However, the value of haz must be taken into account in subsequent sequences. Therefore, we de ne another process, S(1) which tests the value of haz. If it has not been set then we are allowed to iterate back to process S(0). However, if it has been set, process S(1) speci es that the event to load the input values should occur. After that the system will always be set into a safe state. Only after it has been set in a safe-mode will the system be able to resume performing sequences of events as de ned in S(0). Given this behaviour the pre-condition will always be met because we will never try to set critOutput1 to on after it has just been set to on. This would invalidate the pre-condition. Note that LOOP constrains the behaviour of the system more than the AMN speci cation. The AMN allows the system to enter into a non-hazardous mode (critOutput 2 = on ) following a hazardous mode (critOutput 1 = on ) whereas the CSP loop enforces a safe mode (critOutput1 = o & critOutput2 = o) following a hazardous mode. This constriction is admissible provided the safety constraint detailed in section 5 is still met. If we were to allow the same behaviour as the AMN, we would have to model more state in the CSP and the loop would be signi cantly more complex. The theory in section 4 states that any sequence of OPERATIONS corresponding to a trace of LOOP are all called within their pre-conditions. For example, if we had a trace in which the inputs were invalid we would have the following trace:

hEControlLoad ?(LOW ; valid ; MEDIUM ; LOW ); EValidateMessage !result ; EControlSetSafei We can con rm that it is a non-divergent trace since wp (INITIALISATION ; ControlLoad (LOW ; valid ; MEDIUM ; LOW ); result ? ValidateMessage ; ControlSetSafe ; false ) = false

It is also the case that the sequence of OPERATIONS does preserve the

CLI , which includes the control constraint discussed earlier. It also contains a

control variable which can take values of the parameterised processes.

[ControlLoad (LOW ; valid ; MEDIUM ; LOW ); result ? ValidateMessage ; ControlSetSafe ; c 1 := 0]enableInputs = TRUE ^ c 1 2 0 : : 1

7 Safety Properties of Example The safety properties of the system were introduced in section 5. The rst safety property, that both critical outputs may not be on simultaneously, has already been captured in the AMN speci cation. This section discusses the second safety property. It states that if the value of critOutput1 in the last iteration of the loop is on then it cannot equal on in this iteration. This could be speci ed in AMN using history variables to model the history value of critOutput1. Instead of using history variables in AMN, we can state this property as a speci cation in CSP which LOOP must satisfy. We can de ne a trace speci cation as follows: tr = tr1 a hProcessCrit !on i a tr2 a hProcessCrit !on i a tr3 ) tr2  fControlSetSafe ; ProcessCrit !o g 6= hi In other words, if the trace has ProcessCrit !on appearing in it twice, then the trace tr2 in between those two occurrences must contain ControlSetSafe or ProcessCrit !o . The control loop satis es this because tr2 would always contain ControlSetSafe .

8 Discussion In this section we brie y discuss our approach in relation to other approaches. We take a B description and a CSP description and demonstrate their consistency. In Butler's paper [4] an Action System is de ned together with an event ordering term which is comparable to our CSP control executive. Our executive is a separate description which can be analysed independently, whereas the event ordering term is another clause in the Action System written in a process algebra style. These terms are then translated into expressions which augment the guards of an action. These expressions are similar to the introduction of our control variables which are used when verifying the CLI mechanically. In Fischer's paper [7] combinations of Z and a process algebra are categorised into two basic styles. The syntactic combination de nes a new language as a combination of syntax from both languages with a new underlying semantics. The semantic combination preserves consistency of the original semantics of both languages so that each description could be analysed separately, but links are drawn between them so that the events in a process can be interpreted from a dierent viewpoint. The CSP cannot contribute to the computation of the individual state transitions. In our combination we preserve the original semantics of both B and CSP. We have shown that a coupling between B and CSP allows traces of events in a recursive loop to correspond to sequences of AMN OPERATIONS. Therefore, if we had a MACHINE M and a CSP executive R , they are compatible if the only traces of R are not divergences of M , and so all the OPERATIONS are called appropriately. In this paper we described conditions on M and R which yield this compatibility. Thus our combination can be categorised as a semantic integration.

Many of the combinations split the input and output from the speci cation of the individual state transition. For example, Roscoe et al. [12] divide every schema into two events, one with input parameters and one for output. Our style is akin with Smith [11] and Fischer [8] where each event maps to one OPERATION. We agree with Fischer's [7] guideline which states that the characteristics of the input and output parameters should be made clear and captured in the semantics. Our approach de nes two kinds of input parameters so that there is a clear distinction between inputs from the external environment of the system and the environment of the B component. In addition, we state that all the outputs originate from the B description. Smith [11] and Fischer [8] introduce simple parameters so that the system can provide extra constraints to inputs which come from the external environment. With these simple parameters the system deadlocks if the conditions of the inputs are not met. Where they have deadlock we would have divergence if the condition for inputs from the external system environment is not met. In practice this will never happen, since the input will come along a data bus and will always be of the correct type. It will be physically impossible to input values which are not of the correct type. Furthermore, the pre-condition in the B description only constrains the types (as in the CSP description) and will always be met. However, in general if the pre-condition did constrain the inputs more than just being of the correct type, we would have divergence. Thus in practice, events with inputs from the external environment would not be found in the divergent traces of LOOP . However, it is the case that events with inputs along a ? channel could result in divergent behaviour. The various combinations of Z and CSP also make a distinction in the preconditions of the schema as to whether they will be the blocking or non-blocking view. The B-Method allows us to have both views in the same speci cation. This is de ned in the guard of the OPERATION and is clearly separated from the state transition. Therefore we do not need to add extra syntax to the existing method as was done for Z in Fischer [8]. However, we restrict ourselves to the non-blocking view, since in general this is the only implementable view in a sequential system. Then we rely on the divergent traces to demonstrate whether all the pre-conditions are met. Finally, the focus of our work was to develop CSP control executives for sequential processors. Therefore we did not include the parallel operator in our CSP syntax. Extending the approach to include other operators would be an interesting topic for future research.

Acknowledgements Thanks to Andy Galloway for useful comments on an earlier version of this work.

References [1] Abrial J. R.: The B Book: Assigning Programs to Meaning, Cambridge University Press (1996). [2] Abrial J. R.:Extending B without Changing it (for Developing Distributed Systems). In H. Habrias, editor, Proceedings of the 1st B Conference, Nantes, France, November (1996). [3] Back R.J.R. and Kurki-Suonio R.:Decentralization of process nets with centralized control. In proceedings 2nd ACM SIGACT-SIGOPS Symposium on Principles of Distributed Computing, Montreal (1983). [4] Butler M.J.:Event Ordering in Action Systems. In J. Grundy, M.Schwenke, T. Wickers, editors, International Re nement Workshop/Formal Methods Paci c'98, Canberra, Springer Series in Discrete Mathematics and Computer Science, Springer (1998). [5] Draper J., Treharne H. et al.: Evaluating the B-Method on an Avionics Example. In proceedings of DASIA, Data Systems in Aerospace, Rome (1996). [6] Dijkstra J.:A Discipline of Programming, Prentice-Hall (1976). [7] Fischer C.:How to combine Z with a Process Algebra. In J. Bowen, A. Fett, and M.Hinchey, editors, ZUM'98 The Z formal Speci cation Notation, volume 1493 of LNCS, Springer Verlag (1998), pp 5-23. [8] Fischer C.: CSP-OZ: A combination of Object-Z and CSP. In H. Bowman and J. Derrick, editors, Formal Methods for Open Object-Based Distributed Systems (FMOODS'97), volume2, Chapman & Hall (1997), pp 423-438. [9] Hoare C.A.R.: Communicating Sequential Processes, Prentice Hall (1985). [10] Morgan C.C.:Of wp and CSP. In W.H.J. Feijen, A.J.M. van Gasteren, D. Gries and J. Misra, editors, Beauty is our business: a birthday salute to Edsger W. Dijkstra. Springer Verlag (1990), pp 319-326. [11] Smith G.:A semantic integration of Object-Z and CSP for the speci cation of concurrent systems. In J. Fitzgerald, C. B. Jones and P. Lucas, editors, Proceedings of FME 1997, volume 1313 of LNCS, Springer Verlag (1997), pp 62-81. [12] Roscoe A. W., Woodcock J. C. P. and Wulf L.:Non-interference through determinism. In D. Gollmann, editor, ESORICS 94, volume 875 of LNCS, Springer Verlag (1994), pp 33-54. [13] Stoy, J. E.: Denotational Semantics, MIT Press (1977). [14] Treharne H., Schneider S.: Using a Process Algebra to control B OPERATIONS (Full Version). Technical Report CSD-TR-99-01, Royal Holloway, University of London, February (1999).