Classifying and Capturing Timing Requirements Helen Treharne and Steve Schneider Department of Computer Science, Royal Holloway, University of London, Egham, Surrey, TW20 0EX, UK. E-mail:
[email protected] Fax: +44 (0)1784 439786
Abstract. This paper classi es the timing requirements that arise in
embedded avionics systems. A typical avionics system motivates the work. Its timed speci cation is presented, from which we extract guiding principles for developing Timed Abstract Systems. A discussion focuses on the insights that can be gained when modelling the timed requirements formally within AMN.
Keywords: B-Method, Embedded Systems, Timing Requirements.
1 Introduction A requirements speci cation detailing what the system is required to achieve and its constraining timing requirements is the input to a software project. All too often the assumption is made at the beginning of a project that the requirements speci cation is correct and does not need checking. Making this assumption can result in errors being present in the software lifecycle from the earliest time. A typical formal software lifecycle [3] starts by re-specifying the requirements written in English in an abstract speci cation, such as a speci cation written in the B-Method [1]. The speci cation provides an operational description of the software with the timing requirements captured in the English commentary. This means that the timing information is still informal at this stage. It would be preferable to model the timing requirements within the Abstract Machine Notation (AMN). The purpose of modelling such timing requirements in AMN as part of the abstract speci cation is to improve our ability to analyse the system in the early stages of the software development lifecycle. It will enable us to detect some inconsistencies or de ciencies in the requirements speci cation. Our main interest in this paper is concerned with the question of what types of timing properties are expressible in AMN and whether AMN is powerful enough to express the relevant temporal properties of real-time embedded avionics systems. We explore an answer to the above question and in turn make two contributions. Firstly, we suggest a classi cation of timing properties that are typical
in avionics systems. In [6], we showed how the pre-conditions of AMN OPERATIONS could be discharged when the OPERATIONS corresponded to events of a control loop expressed in the process algebra Communicating Sequential Processing (CSP) [4]. The second contribution demonstrates the use of this existing theory to show that timing requirements which can be expressed in AMN may be checked to highlight contradictions. This paper is organised as follows. Section 2 de nes a classi cation of the timing properties that arise in avionics systems. Section 3 describes the speci cation style for embedded systems. Section 4 presents an example system, whose timing requirements are presented in section 5. Section 6 models the timing requirements of the software and the system assumptions in AMN and discusses the general principles for modelling these requirements. Section 7 checks the consistency of these timing requirements. The nal section contains a discussion. Knowledge of the B-Method is assumed when reading this paper. In the paper we adopt the convention that AMN keywords are indicated in italics.
2 Timing Classi cation All the timing requirements commonly found in avionics systems are linked to the functional requirements using events. At the lowest level of detail an event is a change of state. These events form the distinguishing points on a boolean waveform, which changes state from LOW to HIGH and vice versa. Higher level requirements refer to events as software modules. The concept of changing state still applies since the action of performing these modules may change the state of an output variable in the software. These timing requirements can be classi ed1 in three groups as follows:
2.1 Protocol Timing Requirements Protocol requirements constrain the interaction between the software and external hardware devices. They are in general of the lowest level of detail. The software and external hardware device communicate over a limited number of signals. Such protocols are usually speci ed using timing diagrams. The diagrams indicate the minimum and maximum delay between events, such as a change in an input signal to a change in an output signal or between a change in an input signal and the stability of another input signal. Examples of typical timing requirements from avionics include: { Communication with the software via a serial data-bus controlled by an external device. The serial data bus transmits an input signal clock across the bus to the software. The clock is used to synchronise the data transfer. The timing diagram in gure 1 shows that the input signal clock will change state from LOW to HIGH within a certain time, called the rising edge time 1
Classi cation developed with Jonathan Draper as part of ESPRIT SPECTRUM Project 23173
because signals do not change state instantaneously. After this change of state the clock signal must stay HIGH for an interval of time. The data is transmitted on the bus within this interval of time must also be stable. Therefore, if the software reacts to the rising edge of the clock the data is guaranteed to be valid whilst the clock signal is high.
CLOCK
DATA DATA STABLE
DATA CHANGE
Fig. 1. Data Validity
{ Provision of a stimulus to an external watchdog device. In order to inform the external system that the software is operational it produces an output which exhibits the behaviour of a square wave over time. This output is changed by the software at regular intervals. { Generation of a fault tolerant output. This ensures that an output signal is tolerant to simple failures such as short circuit to a high voltage.
2.2 Performance Timing Requirements This class of requirements are of the higher level. They are requirements on the response time of the software, the delay between an initiating events (such as a change in input or an interrupt) and the required response (such as updating an output). In the requirements speci cation they are usually speci ed in English as a maximum permitted delay between the initiating event and the required response or the duration of a software module. An example of a performance timing requirement is the minimumupdate rate for an output. The software must re-calculate an output at regular intervals. In other words there is a maximum time between one update of the output and the next.
2.3 Operational Timing Requirements As with the performance requirements this is a class of higher level requirements. They are requirements on the timed sequence of modules that a system is allowed to perform. They are usually negative requirements, disallowing certain timed sequences. Such requirements are usually speci ed in English by describing the unacceptable sequences.
An example of an operation spacing requirement is that a module must not be called too frequently. The time period between consecutive calls must be at least a certain time. This enables an external device to react to an output before it is changed again by a software module. In this paper we are interested in developing an AMN style of speci cation in order to capture the timing requirements of the above classes. In particular, we will identify which of the timing requirements are easily expressible at the abstract speci cation phase of the software lifecycle.
3 Abstract Systems in AMN In the introduction we referred to an abstract speci cation written in AMN as representing a formal description of the software requirements. It contains a MACHINE at the top of the hierarchy of MACHINEs which we will refer to as an Abstract System. The systems discussed in this paper are embedded systems. Therefore, not only does the Abstract System capture the functions to be implemented in software, it also includes abstract OPERATIONS to model the state of the external system, which the software will need to access. We make the distinction between these OPERATIONS by referring to them as software and system OPERATIONS. In the MACHINE hierarchy the system OPERATIONS and associated state will be in separate MACHINEs. Using the SEES clause the software OPERATIONS can read the values but not change them. This achieves the required separation of concerns between the software being modelled and the system context within which the software is viewed. This style is applied in the following section.
4 Example System This section presents the functional requirements of a typical embedded avionics system which was rst detailed in [6]. In addition, we highlight the OPERATIONS of the Abstract System which capture these requirements. In [6], the system did not address the timing requirements. This paper will capture the timing details in sections 5 and 6. The inputs and outputs to an Interlock System are shown in gure 2. 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 respective 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 OPERATION ValidateMessage de nes the validity checks on all the inputted data. 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
INPUTS
OUTPUTS
(maxStatus, checkData) critOutput1 Simple Interlock sensorA
critOutput2 softwareOutput
sensorB
Fig. 2. Simple Interlock Example system OPERATIONS LoadInputMessage, LoadCritSensorA and LoadCritSensorB captures this copying by setting state in their associated MACHINEs which model the various external system state. 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 di erent 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. The software OPERATION ProcessCrit captures the processing of the critical outputs. 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. The software OPERATION SetSafe models all the critical outputs begin set to o . 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. The software OPERATION TransmitMode de nes the appropriate watchdog stimulus. There is a control constraint which states inputs cannot be overwritten until processing has occurred. Figure 3 contains the Abstract System for this example, called TopLevel. It shows how a boolean state variable enableInputs is used as a
ag in pre-conditions of new OPERATIONS. These predicates provide the necessary conditions under which some of the above OPERATIONS should execute in order to achieve the required control constraint.
OPERATIONS
MACHINE TopLevel SEES
ControlLoad ( inputStatus , inputData , inputSensorA , inputSensorB ) =b
PRE
Types , Bool TYPE
inputStatus 2 SENSORSTATUS ^ inputData 2 CHECKDATA ^ inputSensorA 2 SENSORSTATUS ^ inputSensorB 2 SENSORSTATUS ^ enableInputs = TRUE
INCLUDES
InputMessage , InputSensors , Processing , Validate
THEN
LoadInputMessage ( inputStatus , inputData ) k LoadCritSensorA ( inputSensorA ) k LoadCritSensorB ( inputSensorB ) k enableInputs := FALSE
PROMOTES
ValidateMessage , ProcessCrit
END ; BEGIN
VARIABLES enableInputs
ControlSetSafe = b
INVARIANT
enableInputs 2 BOOL
INITIALISATION
enableInputs := TRUE
SetSafe k enableInputs := TRUE
END ; PRE result 2 BOOL THEN
ControlTransmitMode ( result ) = b TransmitMode ( result ) k enableInputs := TRUE
END END Fig. 3. Example Abstract System
5 Timed Requirements of System The previous section discussed the functional requirements. Here we detail the timing requirements of the Interlock System. In particular, we relate these requirements to the AMN OPERATIONS in the Abstract System. This includes de ning the constraints on the software OPERATIONS and recording assumptions about the external behaviour of the system which a ect the inputs to the software. These assumptions will form the constraints imposed on the system OPERATIONS. The timing requirements will also be categorised with respect to the classi cation presented in section 2.
5.1 System Operations
The following are assumptions on the external behaviour of the system: An input message is sent along the data bus at most every 15 time units. Similarly, each sensor interface is updated by the system at most every 15 time
units. Therefore, the operational timing requirement of the OPERATION ControlLoad which models these updates is that it is called at most every 15 time units.
5.2 Software Operations The following restrictions apply to the ve software OPERATIONS of the system: The ValidateMessage OPERATION has a performance timing requirement that says it must complete its function within 5 time units of receiving an input message. The ProcessCrit OPERATION has a performance timing requirement that says it must complete its function within 10 time units of receiving a validated message. The OPERATION sets critOutput1 and critOutput2. It is an example of a timed interlock. Its waveform is shown in gure 4 and has the following characteristics:
Both outputs cannot be set on at the same time. Both outputs can be set to o at the same time, If a critical output is set to on the di erence between the rising edge and the falling edge times of that output must be at least 2 time units. This is illustrated by (a) and (b), (e) and (f) in gure 4, The rising edge of a critical output to be set has to be greater than or equal to the falling edge time of the other critical output. For example, when setting critOutput2, (c) is equal to (b). Similarly when setting critOutput1, (i) is greater than (h), If one output is to be set to on the other output must have been stable for at least 2 time units since it was rst called. For example, critOutput2 can be set at (g) because there has been at least 2 time units since critOutput1 was set at (e), Either output can be set initially.
(a) critOutput1
_ 2 >
(b)
(e)
on off (c)
critOutput2
on off
(f)
(i) _2 >
_ 2 > (d) _2 >
(g)
(h) _ 2 >
time units
Fig. 4. Timed Interlock
The timed interlock is an operational timing requirement because it constrains how often an OPERATION should be called. However, the overall e ect can also be regarded as a protocol timing requirement on the outputs. The OPERATION ControlSetSafe has an operational timing requirement which states that it is performed within 5 time units of receiving an input message (i.e. within 5 time units of ControlLoad). It must also complete its function within a performance timing requirement of 5 time units. The OPERATION ControlTransmitMode has an operational timing requirement which states that it is performed within 5 time units of receiving an input message and completes its function within a performance timing requirement of 5 time units. The Abstract System speci es that if there is a valid message then the output variable, softwareOutput is be set to active or inactive. The timing requirement on softwareOutput is that it must be stable for 5 time units. The OPERATION should not be called again during this stable time. If the message is invalid softwareOutput is set to no event. The output in this state does not remain stable and the OPERATION can be called again. This stability constraint represents the limits in order to de ne an abstraction of a protocol requirement. In an implementation the setting of the softwareOutput variable, which represents a watchdog stimulus, would be a boolean waveform. If this limit was not present an implementation may not allow sucient time to ensure that a waveform could be signalled to the other parts of the system. Furthermore, the stability constraint could be viewed as a restriction on the time required between invocations of ControlTransmitMode and thus an operational timing requirement. In this section an OPERATION could have timing requirements related to more than one class of the classi cation. The requirements were mostly of the performance or operational timing requirements classes. The timing requirements that were viewed as protocol timing requirements on the state could also be considered as operational timing requirements. This is because state is always set by distinct OPERATIONS and so the constraints could also be regarded as restricting when the OPERATIONS should execute.
6 Modelling the Timing Requirements The purpose of a speci cation MACHINE, called TimedTopLevel, is to capture all the timing requirements and assumptions detailed in section 5. This MACHINE is structured as shown in gure 5. In general, we refer to this MACHINE as a Timed Abstract System. Collating all the timing requirements and assumptions in this one MACHINE will facilitate the identi cation of these requirements in the speci cation. It will also provide one focus point in order to detect some inconsistencies in the software requirements should they be present. However, this complete separation from the abstract speci cation cannot be fully realised and some concessions have to made. These exceptions are enforced in a controlled manner so that traceability of the requirements is not compromised.
Timed TopLevel
inputReceived endValidate
Timer
TopLevel
time
Processing critOutput1StableTime critOutput2StableTime Abstract Specification
softwareOutputStableTime
KEY: INCLUDES
Fig. 5. Timed Speci cation Structure with time sensitive VARIABLES MACHINE Timer VARIABLES time INVARIANT time 2 N INITIALISATION time := 0 OPERATIONS tt ? ReadTime =b BEGIN tt := time END ; SetTime ( tt ) =b PRE tt 2 N ^ tt > time THEN time := tt END END Fig. 6. Timer Machine
6.1 Timer Figure 5 shows that the timed speci cation INCLUDES a Timer. There is no notion of a maximum time or time cycle in this simple example system. Therefore, Timer simply de nes one state variable time of type natural number, NAT, which models the current time of the system. Initially this value is set to zero and then increases. Timer de nes operations to read the value, ReadTime, and to set the value of time, SetTime, as shown in gure 6. In the Timed Abstract System, TimedTopLevel shown in gures 7 and 8, the OPERATION ReadTime is not used. AMN structuring mechanisms allow variables to be inspected directly in speci cations. However, in designs enquiry operations have to be used to extract the values of variables because they are not directly visible. The following sections will show how the Timer MACHINE is used in OPERATIONS of TimedTopLevel when:
MACHINE TimedTopLevel SEES Types , Bool TYPE INCLUDES TopLevel , Timer VARIABLES inputReceived , endValidate INVARIANT inputReceived 2 N ^ endValidate 2 N INITIALISATION inputReceived , endValidate := 0 , 0 OPERATIONS TControlLoad ( inputStatus , inputData , inputSensorA , inputSensorB ) = b PRE inputStatus 2 SENSORSTATUS ^ inputData 2 CHECKDATA ^
inputSensorA 2 SENSORSTATUS ^ inputSensorB 2 SENSORSTATUS ^ inputReceived + 15 time
THEN
ControlLoad ( inputStatus , inputData , inputSensorA , inputSensorB ) k inputReceived := time
END ; rr ? TValidateMessage = b BEGIN rr ? ValidateMessage k ANY endTime WHERE endTime 2 N ^ endTime > time ^ endTime inputReceived + 5 THEN SetTime ( endTime ) k endValidate := endTime END END ; haz ? TProcessCrit ( result ) = b PRE result 2 BOOL ^
( result = TRUE ^ sensorA = sensorB ) critOutput2StableTime + 2 time _ critOutput2StableTime = 0 ) ^ ( result = TRUE ^ sensorA 6= sensorB ) critOutput1StableTime + 2 time _ critOutput1StableTime = 0 )
THEN ANY endTime WHERE endTime 2 N ^ endTime > time ^ endTime endValidate + 10 THEN SetTime ( endTime ) k haz ? ProcessCrit ( result , endTime ) END END ; Fig. 7. Timed Abstract System
TControlSetSafe = b PRE time inputReceived + 5
THEN ControlSetSafe k ANY endTime WHERE endTime 2 N ^ endTime > time ^ endTime time + 5 THEN SetTime ( endTime ) END END ; TControlTransmitMode ( result ) = b PRE result 2 BOOL ^ time inputReceived + 5 ^ ( softwareOutputStableTime + 5 time _ softwareOutputStableTime = 0 ) THEN ANY endTime WHERE endTime 2 N ^ endTime > time ^ endTime time + 5 THEN SetTime ( endTime ) k ControlTransmitMode ( result , endTime ) END END END Fig. 8. Timed Abstract System continued
{ { {
Checking timing requirements in pre-conditions of OPERATIONS in order to specify operational and the limits of protocol timing requirements, Memorising when time events have happened, Non-deterministically de ning nish times for OPERATIONS in order to specify performance timing requirements.
6.2 Modelling System Operations
The system OPERATION TControlLoad records new values for inputs by calling ControlLoad from within the OPERATION. Inputs, whether a new message
along a data bus or values from sensors interfaces, must be separated by at least 15 time units. We model this restriction by de ning the following pre-condition: inputsReceived + 15 time The state timing variable inputsReceived records when the last inputs were
received into memory. Figure 5 highlights all the timing variables that are required in this development and in which MACHINEs they are de ned. InputsReceived is initialised to zero because the time at the beginning of the system is set to zero. In the body of TControlLoad, inputsReceived is updated to the current time. Note that TControlLoad will not be implemented because it is only used to model the assumptions on the behaviour of the system to aid the speci cation of the software.
6.3 Modelling Software Operations Processing Critical Functions - The performance timing requirement in
TValidateMessage is modelled by stating that the time at the end of the OPERATION must be less than or equal to the current time plus 5 time units of receiving an input. This is achieved by an unbounded choice, ANY, substitution.
A local variable is introduced which satis es the following predicate:
endTime 2 NAT ^ endTime > time ^ endTime inputReceived + 5 This allows the implementor exibility to re ne the OPERATION and determine a value for endTime which satis es the above predicate. The timed OPERATION also sets the current time to endTime to show that time has advanced when performing a software ValidateMessage. The timing requirements in TProcessCrit are modelled in two parts. Firstly, the performance requirement states that ProcessCrit must complete its function
within 10 time units of receiving a validated message. Again we use an appropriate ANY clause and the state VARIABLE endValidate corresponds to the completion time of the validation checks. Secondly, we model the timed interlock for the two outputs derived from the ProcessCrit OPERATION. Both outputs cannot be set at the same time as stated in the TopLevel INVARIANT. In the speci cation ProcessCrit has an IF statement determining which output is to be set. We introduce two stability state variables, critOutput1StableTime and critOutput2StableTime to record when the respective outputs are set. The setting of these stability variables needs to be in accordance with the same control functionality. We could repeat the IF statement in the timed OPERATION but if we had deeply nested conditional this would result in a cumbersome Timed Abstract System. Thus the style of speci cation we adopt is as follows: { De ne a stability/history variable in the MACHINE where the associated state variable is de ned. Ensure that the Timer is visible in those MACHINEs, { Change the abstract OPERATION to an abstract OPERATION with a formal input parameter which represents a time value, { Call the abstract OPERATION in the body of the ANY clause in the timed OPERATION so that the endTime can be used as the actual parameter to the abstract OPERATION. This is used to set the history variable to the appropriate value, { Embed the assignment of the history variable to endTime, passed as a parameter, in the appropriate control branch of the body of the OPERATION. The OPERATION in gure 9 illustrates the updated ProcessCrit which includes a second input parameter and assignments to the stability variables which are de ned in the abstract Processing MACHINE. In order to avoid repetition and have a manageable timed speci cation, the above shows that the abstract speci cation cannot be a completely separate component of the timed speci cation. We can now use the above stability variables
haz ? ProcessCrit ( result , endTime ) = b PRE result 2 BOOL ^ endTime 2 N THEN IF result = TRUE ^ sensorA = sensorB THEN critOutput1 := on k critOutput2 := o k haz := on k critOutput1StableTime := endTime
ELSE
critOutput1 := o k critOutput2 := on k haz := o k critOutput2StableTime := endTime
END END
Fig. 9. Augmented ProcessCrit OPERATION from Processing MACHINE to de ne predicates in the pre-condition of TProcessCrit so that it should only be called under conditions which preserves the timed interlock. In particular, it can be called to set the rst critical output and its associated timing variable under two conditions: 1. The second output, critOutput2, has never been set which means that there is no interlock, 2. The second output has been stable for the appropriate amount of time, i.e. the current time is greater than or equal to the time the critOutput2 was set stable plus 2 time units. There are similar conditions for calling the OPERATION to set the second critical output depending on the value of critOutput1StableTime.
Transmitting non-critical Information - The timing requirements in TControlTransmitMode are modelled in three parts. Firstly, one predicate in the pre-
condition models the operational timing requirement stating that current time must be less than or equal to the last time a message was received plus 5 time units. Secondly, the performance timing requirement states that ControlTransmitMode must complete its function within 5 time units which is modelled within an ANY clause. Finally, the abstract protocol requirement a ects the pre-condition and the body of the ANY clause. A state variable, softwareOutputStableTime is introduced in the MACHINE where the associated state variable is de ned. In this case it would be within the hierarchy of the abstract speci cation in the Processing MACHINE as shown in gure 5. The call to ControlTransmitMode is de ned within the ANY so that the endTime is assigned to the stability variable. The pre-condition makes use of this VARIABLE to show that the output must be stable for at least 5 time units as follows: softwareOutputStableTime + 5 time
However, this will not always work. Suppose we call this OPERATION in the rst 5 time units of executing the system when time is zero, the pre-condition will not hold. Thus we must allow for the OPERATION to be called initially by adding the following disjunctive predicate: softwareOutputStableTime = 0
The timing requirements in TControlSetSafe are very similar to those of TControlTransmitMode. The only di erence is that there are no predicates containing stability VARIABLES to worry about.
6.4 Guiding Principles From the above we can extract the following principles: { A Timer MACHINE is de ned to capture a time VARIABLE so that the timed OPERATIONS read and advance its value, { A timed OPERATION is de ned for each OPERATION in an Abstract System. These OPERATIONS are contained in a Timed Abstract System. We adopt the convention that a T pre xes the timed OPERATION names, { The state model of the Timed MACHINE refers to when inputs to the system are received. The Abstract System is augmented with timed stability VARIABLES when constraints on outputs are necessary, { Each operational timing requirement is represented as a separate predicate in the pre-condition of the OPERATION to provide conditions about when an OPERATION should execute, { Each performance requirement is modelled using a non-deterministic ANY clause to specify how long an execution should take, { The details of a protocol requirement are abstracted and de ned in terms of state variables and their stability, { Software OPERATIONS advance the time of the system, { System OPERATIONS enquire about the system time but do not advance time. By adopting these principles a Timed Abstract System can be speci ed within AMN to capture the software functionality together with the associated timing requirements.
7 Checking consistency The internal consistency of the TimedTopLevel MACHINE is very simple, since the INVARIANT of the MACHINE only constrains the types of the timing VARIABLES. Therefore, the analysis on the timing requirements occurs when we consider the sequences of OPERATIONS that will execute. The outcome of the analysis is that we can identify:
1. Whether a sequence of software OPERATIONS can complete their function in order to preserve the system assumptions as modelled by the system OPERATIONS, 2. Whether in a given sequence of software OPERATIONS, they are carried out in the correct order, in order to satisfy their timing requirements. The following subsections provide an overview of the analysis that can be performed in order to validate the system to identify the above.
7.1 Checking execution rate Linking the assumptions made about the system and the timing requirements of the software, will enable us to make sure that all the inputs are being processed. One way of implementing this link is to identify an INVARIANT which holds before we read inputs from the system and holds after all the appropriate software processing of the inputs has been performed. This INVARIANT cannot be part of the TimedTopLevel MACHINE because it may not hold after executing a single OPERATION. However, it will hold after particular sequences of OPERATIONS. We refer to this INVARIANT as a control loop INVARIANT (CLI ), which was rst introduced in [6]. In our example, a possible CLI could be time inputReceived + 15
This would have to hold for all possible sequences of software OPERATIONS the system could perform following the receipt of inputs to ensure their execution nished before other inputs were received. One such sequence of OPERATIONS is a loading of inputs followed by its validation, transmission of the system mode of operation and nally the processing of the critical outputs. It is the case that this sequence preserves the CLI : [TControlLoad (MEDIUM valid MEDIUM LOW ); result TValidateMessage ; TControlTransmitMode (result ); haz TProcessCrit (result )] time inputReceived + 15 ;
;
;
The TControlLoad sets the inputReceived to the current time. All the other OPERATIONS advance time in turn which collectively is less than 15 time
units. However, if the performance timing requirement on ProcessCrit is weakened so that it only needs to complete within 12 time units of receiving a validated input message the CLI would not always hold. Consider this simpler sequence of OPERATIONS of loading inputs, performing the validation checks and processing. If inputs were received at time 20 the state inputReceived is assigned to this time value. When TProcessCrit executes it non-deterministically chooses an endTime of 36, which is within the required time bound (TValidateMessage nished execution at 25 time units and TProcessCrit nishes 11 time units after the validation check). The SetTime OPERATION is called to set the time variable
to 36 time units, and so invalidates the CLI . This means that there would be an inconsistency in servicing the inputs in the current model as shown in gure 10. In fact, the sixth incoming inputs would be validated but not processed, whereas the seventh message would process inputs which had not been validated. 1
2
0
3
15 V1
4
30
5
45
6
60
7
75
incoming inputs
90
P1 V2
P2 V3
P3 V4
P4
V5
P5 V6
Key
time units
Pn = Processing nth Inputs
Vn = Validating nth Inputs
P7
where n is NAT
Fig. 10. Message Processing In the above we referred to a sequence of OPERATIONS which was simpli ed in order to illustrate a possible incompatibility between the timed requirements of a system and the assumption about the rate of inputs from the external system. In practice, when checking consistency, sequences of OPERATIONS should be typical executions of a system. We would need to identify all the possible sequences of OPERATIONS in order to ensure that they preserved the CLI . In a system there will be software which controls the order in which in which OPERATIONS are executed. The software is called a control executive. In [6] we showed how a process algebra could be used to describe a control executive for software OPERATIONS with no timing information. The process algebra of Communicating Sequential Processes (CSP), [4], was used to develop a speci cation of a control executive to show events occurring in a de nite order. We believe that the approach discussed in [6] could be extended to deal with system OPERATIONS interacting with software OPERATIONS containing timing requirements. We could then extract all possible traces of the system, which are sequences of events corresponding to sequences of OPERATIONS, and demonstrate that they preserved the CLI . Then we could be sure that the software OPERATIONS could complete their function in order to maintain the system assumptions.
7.2 Checking execution order of OPERATIONS
In this section we show that the timing requirements can in uence the order in which OPERATIONS should execute. For example, in [6] the functional require-
ments were preserved when the software OPERATION ProcessCrit occurred before ControlTransmitMode in a sequence of OPERATIONS which processed valid inputs. The timing requirements provide extra constraints which means that the converse order must be observed in the equivalent sequence of the timed OPERATIONS. In [5] a correspondence between Action Systems, [2], and CSP was de ned. In [6] we exploited this theory to show that a very similar correspondence existed between B Abstract Systems and CSP. This meant that the CSP semantics of traces, failures and divergences could be associated with a B Abstract System and expressed in terms of weakest pre-condition formulae. The OPERATIONS within the B Abstract System were restricted to AMN constructs which are implementable. In general, SELECT statements are not implementable. Given this restriction, we showed that the failures-divergences semantics of a B Abstract System is completely characterised by its divergences. A trace, tr , is a divergence if execution of the sequence of OPERATIONS listed in tr might not terminate. In a B Timed Abstract System a divergence can result from executing one of its timed OPERATIONS when its pre-condition was false. In terms of weakest pre-condition formulae this would be when :wp (ini ; tr true ) holds, where ini is the INITIALISATION of the Timed Abstract System followed by a sequence of OPERATIONS fails to terminate. The following two formulae show a sequence of OPERATIONS de ning the order of timed OPERATIONS to process valid inputs. The rst shows a valid sequence which is not a divergence and so the timed OPERATIONS discharge their timing obligations. Conversely, the second formula shows that there is a divergence and so one of the OPERATIONS in the sequence is called outside its pre-condition which means that the timing requirements of the OPERATIONS are not met when they are composed in this order. ;
:wp (INITIALISATION ;
TControlLoad (MEDIUM ; valid ; MEDIUM ; LOW ); TValidateMessage ; TControlTransmitMode (result ); haz TPRocessCrit (result ); true ) = false
:wp (INITIALISATION ;
TControlLoad (MEDIUM ; valid ; MEDIUM ; LOW ); TValidateMessage ; haz TPRocessCrit (result ); TControlTransmitMode (result ); true ) = true
result
result
The above showed how we could use existing theory to ensure that the order in which OPERATIONS occur discharge their timing obligations.
8 Discussion In this section we discuss the insights that can be gained and important issues that arise from modelling the timing requirements formally within AMN.
Firstly, we show that we can gain further insights into how the timed OPERATIONS should execute within a system. The OPERATION TValidateMessage
captured the required performance constraint that is must nish within 5 of receiving an input using the following predicate in the body of the OPERATION: endTime inputReceived + 5
However, there is no pre-condition to prevent the OPERATION from being invoked after 5 time units of receiving an input, giving rise to the following scenario as shown in gure 11. The OPERATION is invoked at 21 time units but the non-deterministic choice of the endTime is resolved to equal 20 time units and so time is going backwards. incoming inputs 15 inputReceived = 15
validation 20 21 endTime = 20
time
Fig. 11. Executing TValidateMessage Scenario This contradicts the other predicate in the body, endTIME time , resulting in the OPERATION being blocked from execution. In order to resolve this con ict, we need to add a pre-condition to the OPERATION which ensures that the OPERATION is called early enough: >
time < inputReceived + 5
Alternatively, we could remove the predicate, endTime > time , from the ANY clause. The OPERATION TValidateMessage would then exhibit divergent behaviour in the above scenario, since the call to the OPERATION SetTime within its body would violate the pre-condition of the setting OPERATION.
Either way, the undesired behaviour would be highlighted. This new pre-condition now overlaps with the pre-condition of the TControlTransmitMode OPERATION. However, TControlTransmitMode makes use of the result, which is the state variable stating whether the validation was successful or not. Therefore, in a control executive we would want to execute the TValidateMessage before TControlTransmitMode. We could ensure that the implementor was aware of this by introducing a ag in the Timed Abstract System enforcing this order of execution. Secondly, we gain further insight into the required timed properties of the OPERATIONS in the system. For example, TProcessCrit has an upper limit of execution of 10 time units from receiving validated inputs. However, the timing requirements of TControlTransmitMode dictates that it must occur in between
TValidateMessage and TProcessCrit. Therefore, we can re ne the timing requirements on TProcessCrit to show that operational timing requirement needs
to take the execution time of transmitting mode information into account as well as the stability constraints of the outputs. In addition, the worst case performance timing requirement will be 5 time units, since we were initially allowed up to 10 time units but now TControlTransmitMode could take up to 5 time units. The following discussion focuses on the issues raised in the modelling style of timing requirements which were expressed as part of OPERATIONS in the Timed Abstract System. As well as de ning OPERATIONS to clearly model the separation of concerns, the grouping of functionality within these OPERATIONS must re ect the timing requirements which need to be modelled. For example, we could have had di erent timing requirements on the inputs to the interlock system, such as: { The input message is sent along the data bus at most every 10 time units, { Each sensor interface (sensorA and sensorB) is updated by the system at least every 10 time units and cannot change its value within 2 time units of receiving an input message. This would be a typical requirement if the hardware was discrete and we were required to freeze the updates each time. In the above case we could not have grouped all the inputs into one TControlLoad system OPERATION since the pre-conditions would need to be di erent for messages and sensors. We would need to have at least two system OPERATIONS, one for the message and one for both sensors. Alternatively, we could have one OPERATION for each system input. Separating system OPERATIONS in order to model complex timing requirements is allowable since they are only recording system assumptions and will not feature in the nal implementation. However, software OPERATIONS will form modules in the implementation and we may need to be group similar functionality together. Consider the following, suppose the ValidateMessage and ProcessCrit needed to form a composite OPERATION using the parallel operator (k). However, in order to express the required timing constraints we needed to record the time at the end of the ValidateMessage OPERATION. We only reason about time at the beginning and at the end of OPERATIONS. We cannot extract timing information during a parallel composition. In order to model this more complex requirement we de ne another variable in TimedTopLevel and derive its value within the existing ANY clause which includes additional constraining predicates. This new time variable could then be used in the speci cation of other timed OPERATIONS. We recognised the need to abstract away from the details of protocol timing requirements. For example, in the Processing MACHINE we set both critical outputs in a parallel composition in the OPERATION, ProcessCrit. The details of the stability of the outputs were left abstract but they were necessary because they a ected when an OPERATION should be called. There may be protocol timing requirements which do no a ect the operation spacing requirements, such as the second output is turned o within 2 +2/-0 time units from removing the
rst output. These details are unnecessary in the speci cation but would need to be considered when implementing the software OPERATION. The decision to model the timing requirements in one MACHINE was dictated by the need to advance time in the software OPERATIONS and use the new time values to set history variables. The INCLUDES mechanism allows a MACHINE to be INCLUDEd only once in a development. Therefore, we had to specify the OPERATIONS which changed time in one place. However, this restriction enabled us to achieve our goal of being able to easily reference the timing requirements in the Timed Abstract System. In section 7, we referred to a control executive. If we only had software OPERATIONS then it is possible to develop a control executive in an AMN IMPLEMENTATION. We argued in [6] that developing the executive in CSP allowed us to specify more complex safety properties which would have been cumbersome to write in AMN, without introducing several history variables. In the example discussed in this paper we would need to develop a control executive which interacted with the system OPERATIONS. An interesting topic for future research would be to extend the approach in [6] and identify whether it is indeed at all possible to do this in AMN. In this paper we developed an example system to illustrate a model of typical timing requirements and assumptions about the external system behaviour. Guiding principles were extracted from this example which could be used to develop Timed Abstract Systems of embedded avionics systems. We demonstrated that performance and operational timing requirements were captured easily but that we needed to abstract away from the details of the protocol requirements whilst retaining their essence. In addition, we showed how modelling timing requirements formally within AMN can provide insights into the control executive that would need to be developed for the system.
Acknowledgements Thanks to Jonathan Draper for his co-operation on early versions of this work and comments on an earlier draft of this paper.
References
1. Abrial J. R.: The B Book: Assigning Programs to Meaning, Cambridge University Press (1996). 2. 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). 3. Draper J., Treharne H. et al.: Evaluating the B-Method on an Avionics Example. In proceedings of DASIA, Data Systems in Aerospace, Rome (1996). 4. Hoare C.A.R.: Communicating Sequential Processes, Prentice Hall (1985). 5. 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. 6. Treharne H., Schneider S.: Using a Process Algebra to control B OPERATIONS. Integrated Formal Methods Workshop (IFM '99), York, Springer, June (1999), pp 437-456.
