Developing Correct Systems Jonathan Bowen
Oxford University Computing Laboratory 11 Keble Road, Oxford OX1 3QD, UK Email:
[email protected]
Ernst-Rudiger Olderog
FB Informatik, Universitat Oldenburg Postfach 2503, 2900 Oldenburg, Germany Email: Ernst.Ruediger.Olderog@ arbi.informatik.uni-oldenburg.de
Abstract
The goal of the Provably Correct Systems project (ProCoS) is to develop a mathematical basis for development of embedded, real-time, computer systems. This survey paper introduces novel speci cation languages and veri cation techniques for four levels of development: Requirements de nition and design; Program speci cations and their transformation to parallel programs; Compilation of programs to hardware; and Compilation of real-time programs to conventional processors.
1 Introduction An embedded computer system, e.g. an aircraft, a train control system, or a home heating system, is invisible for the end user. Why should a designer worry about its correctness, whatever that means? Seen from the outside, the total system is a physical process, a plant, characterized by a state that changes over real time. The role of the computer is to monitor this state through sensors, and on the basis of accumulated readings, to change the state through actuators. From this point of view, the computer is simply a convenient device that can be instructed to manipulate a mathematical model of the physical system and state. Correctness means that the program and the hardware faithfully implements the control formulas of the mathematical model for the total system, and nothing else.
This work is partially funded by the Commission of the European Communities (CEC) under the ESPRIT programme in the eld of Basic Research Project No. 7071: \ProCoSII: Provably Correct Systems". The hardware compilation work is partially funded by the UK Science and Engineering Research Council (SERC) under the InformationEngineering Directorate SAFEMOS project (IED3/1/1036).
Martin Franzle
Christian-Albrechts-Universitat zu Kiel Institut fur Informatik und Praktische Mathematik Preuerstrae 1{9,W-2300 Kiel 1, Germany Email:
[email protected]
Anders P. Ravn
Department of Computer Science Technical University of Denmark, bldg. 344 DK 2800 Lyngby, Denmark Email:
[email protected]
In simple cases, conventional control theory gives an adequate description of the system, and the design task is a fairly trivial translation of the di erence equations into a program loop that reads sensor values, computes some polynomials, writes some values to the actuators, and pauses till the start of the next cycle. However, the power and accuracy of digital computers have lead to much more sophisticated control strategies with several interacting control loops, mode changes, attempts to recover from sensor and actuator failures etc. This results in large, complex programs which are hard to relate to the objective of systems control. There is a need for a short and precise speci cation of the desired control requirements, independent of the actual hardware and software system. For that purpose ProCoS has investigated a real-time logic, that formalizes dynamic systems properties usually represented with a mixture of timing diagrams, state machines, di erence or di erential equations, or other ad hoc representations of the complex state trajectories of a system. This logic also provides a calculus such that a speci cation of a control strategy based on nite state machines can be veri ed. Similar ideas are found in [1, 20, 21, 26]. Note that the proposed requirements language o ers an interface to control theory. It is not intended in any way to replace well known notation and procedures of control engineering. A speci cation of a controlling state machine is a step towards an implemented program. The speci cation language SL is used not only to specify program components, but also to support transformations to an occam-like programming language PL. These programs are then the basis for transformation to hardware or machine code, cf. [6]. Each step has to be correct, and unless we want to have blind faith in the developer, we expect to see documents for a rational development process, cf. [31, 32]. Using a fairly stan-
dard division of a development into major activities, these documents can be organized as follows: Activity Concept
Documents Expectations
Requirements analysis System design Program design Either: Hardware synthesis Or: Compilation
Requirements System specs Program source
Language Natural (informal) RL (logic) SL PL
Circuit diagram Netlist Machine code
ML
Each major activity layer will use its own specially tailored languages and veri cation techniques. It shall also link to the next lower layer in the ProCoS development \tower" above. The inspiration for such a layered approach has been the CLI \stack", see e.g. [5, 12]. A detailed technical account of work during the rst 3 years is given in the report [3]. Overview. The following sections focus on central topics of each of the layers. In section 2 we use one of the ProCoS case studies to introduce requirements analysis and speci cation of a top level design. This design is in section 3 used to illustrate program speci cations and transformations to programs. Section 4 outlines some recent work on deriving a hardware description from a program. Section 5 is also a survey of new work on extending the program speci cation language and the programming language with speci cation of timing constraints for a processor.
@@?? ? @ Gas Valve Thermostat
`` h(h(( h Flame sensor
2.1 From expectations to requirements Properties of systems are expressed by constraining the states over time. For that purpose the Duration Calculus, a real-time interval logic, based on state durations [39] is used. We introduce the logic while formalizing the following expectations for the gas burner. Safe: Gas must not leak for more than 4 seconds (We shall use second as a unit of time throughout the example.) in any 30 second period. Stop: The gas must not burn when heat request has been o for 60 seconds. Start: The gas must burn when heat request has been on for 60 seconds, provided the gas ignites and burns without faults. Safe. A leak occurs whenever the state assertion Leak =b Gas ^ :Flame holds. When some bounded interval [b ; e ] of time is considered, Rthe duration of Leak within the interval is given by be Leak (t )dt , cf. the following timing diagram: Flame
1
2 Requirements and Design
Gas
1
The rst step in formalizing the requirements of a system is to construct a system model. The basis is the well-known time-domain model, where a system is described by a collection of states which are functions of time (the real numbers). We illustrate the state concept through our running example: a version of a computer controlled gas burner [33]. Another case, a railway crossing, is found in [37]. The gas burner is controlled through a thermostat, and can directly control a gas valve and monitor the
ame. The following discrete (Boolean valued) states are used to model the gas burner Heatreq ; Flame ; Gas : Bool They express the state of the thermostat, the ame, and the gas valve. We shall assume that Boolean values are represented by 0 and 1. This physical system is illustrated by the following diagram:
Time
0
0
Leak
b R
Leak
-
e
The symbol Leak denotes the duration of Leak ; for each particular interval it is a real number. An atomic duration formula is a predicate over intervals built from durations and real valued constants by a relation on real numbers. The 4 second constraint R on leaks is thus the atomic formula Leak 4. The duration of the constant state 1 will be the length Rof the interval under consideration, and we abbreviate 1 by `. Thus the fact that an interval is not longer than 30 seconds is given by the formula ` 30. Formulas can now be generated from atomic formulas using the logical connectives. The safetyRexpectation for a single interval is thus: (` 30) ) ( Leak 4). I.e., if the interval is shorter than 30 seconds then the duration of Leak is less than 4 seconds. A formula holds for a particular model (where each state denotes a function of time) just when the formula
is true for any interval [0; T ] with T ranging over the non-negative reals. A requirement R shall hold for an arbitrary interval of system lifetime. This can be expressed as: \there is no subinterval for which :R holds". Subinterval properties are expressed by the binary \chop" operator (written \;") of interval logic [25]. Given formulas D1 and D2 , the formula D1 ; D2 (which reads D1 \chop" D2 ) holds for the interval [b ; e ] just when this interval can be divided into an initial subinterval [b ; m ] where D1 holds and a nal subinterval [m ; e ] where D2 holds. The \chop" operator is associative, so the desired property for a requirement R is :(true ; (:R ) ; true ), abbreviated 2 R , and pronounced \always" R . The safety requirement speci cation is thus R Safe =b 2 (` 30 ) Leak 4) Stop. For this functional requirement, we consider a non-point interval where :Heatreq holds. This is R expressed by ( :Heatreq = `) ^ (` > 0), abbreviated d:Heatreq e. Using the \chop" operator the desired constraint is 2 ( (d:Heatreq e ^ ` = 60) ; (` > 0) ) (` = 60) ; d:Flame e ; true ) I.e., if an interval starts with :Heatreq for 60 seconds and continues with a non-point subinterval (` > 0), then the interval can also be divided into an initial interval of length 60, followed by an interval where d:Flame e holds, followed by an arbitrary interval (true ). Formulas of this kind occur so often that we introduce an abbreviation 60 Stop =b d:Heatreq e ?! d:Flame e Start. The last requirement has a precondition that Gas ignites, say within half a second 0:5 IgnitionOk =b dGas e ?! dFlame e and that Flame persists when Gas is present. I.e for any positive r r FlameOk =b dGas ^ Flame e ?! dFlame e The start requirement is now Start =b 2 ( IgnitionOk ^ FlameOk ) 60 (dHeatreq e ?! dFlame e)) and the total requirements are Req =b Safe ^ Start ^ Stop
2.2 Control strategy
A gas burner satisfying the above requirements may be designed in many ways. In the following we consider a speci c control function, where the system proceeds cyclically through the following phases: Idle: Initially and after a completed cycle. The gas is turned o (Output event GasO ). Heat request (input event HeatOn ) terminates the phase.
Purge: The system pauses for 30 seconds. Ignitea : The gas valve is opened. After 1 second the
phase is left.
Igniteb : If a Flame is sensed, proceed to Burn . If there is no ame for 1 second then return to Idle . Burn: Go to Idle if Flame or Heat request is o .
It is described by the following automaton:
- Idle?
HeatOn
fGasO
? Purge wait 30
? Ignitea fGasOn wait 1
wait 1
? Igniteb FlOn
? Burn
HeatO FlO
For each of the phases, a collection of simple phase requirements can be given. It can then be veri ed that they re ne the requirements. The phase requirements can be interpreted as speci cations of simple sensors and actuators. The link to a program speci cation in SL is the automaton illustrated above. The phase transitions have been marked with input events, corresponding to communication with sensor and timer components, and with output events corresponding to communication with actuators. Further details of this design and its veri cation are given in [33].
3 Speci cations to Programs In this section we present a speci cation language SL [28] for reactive systems and outline a transformational approach for the systematic design of programs in an occam-like [19] programming language PL. The purpose of a reactive system is to react to stimuli from its environment so that this is kept in a certain desirable condition. To this end, the system may communicate with its environment via directed channels. As our running example we use the gas burner introduced in the previous section.
For reactive systems a variety of speci cation formalisms have been developed, among them temporal logic [22], action systems [2], stream processing functions [8], and process algebra [24]. However, it remains a dicult task to design correct programs from such speci cations. The speci cation language SL enables us to formulate transformation rules for the stepwise design and implementation of both sequential and concurrent systems.
3.1 Speci cation language SL
In SL the description of the desired system behaviour is split into a trace part and a state part. Trace part. This consists of an interface declaring the communication channels ch of the system, for example
ch of type and a set of trace assertions of the form ta = trace in re where the alphabet is a subset of the interface channels and re is a regular expression over these channels. Informally, ta describes the order in which the channels in can occur in the sequences or traces of cominput
munications between system and environment: at any moment this order must correspond to a word in the language denoted by the regular expression re . Example. Consider the speci cation GB of a simple control for the gas burner, cf. the gure in section 2.2. GB = spec
HeatOn, HeatO , FlOn, FlO , Out30, Out1 of signal output GasOn, GasO , Set30, Set1 of signal trace HeatOn, HeatO , FlOn, FlO , GasOn, GasO , Set30, Out30, Set1, Out1 in pref (GasO . HeatOn. Set30. Out30. Set1. GasOn. Out1. Set1. (FlOn. (HeatO + FlO ) + Out1) ) input
end
In GB, communications are simple input and output signals, and we need only one trace assertion. The operator pref denotes pre x closure; it speci es the stepwise evolution of a system where one communication occurs after the other. Timing constraints are handled by symbolic timer communications between GB and separate timer pro-
cesses. Consider a process for a 30 second timer. At any moment it can be (re)started by receiving a signal \Set30", and 30 seconds after the last \Set30" signal the process is ready to send a signal \Out30". State part. This speci es which values are communicated over the channels; it consists of a set of local state variables and a set of communication assertions. A state variable x is declared as follows: var
x
com
ch write w
of
type init e :
The expression e represents the initial value of x . A communication assertion for a channel ch has the form read
r
when
wh then th
and describes the state transition that each communication induces. The lists w and r record the state variables that may modi ed or only read during the transition. The when predicate wh and the then predicate th represent a pre-post style assertional speci cation of the state transition. In th ,a primed variable x 0 refers to the value of variable x at the moment of termination. The communication value on the channel ch is speci ed by @ch . In communication assertions, empty variable lists and predicates being true are omitted. Example. Consider a gas burner that requires some service after a number of ignitions. A rst inspection is required after 1000 ignitions. When an engineer has checked the gas burner, he will determine when the next inspection is required. The user of the gas burner should be informed how many ignitions are safely possible before the next inspection. If the engineer is not called, no further \HeatOn" request will be granted. To specify this in SL we change the previous speci cation GB to a speci cation GBS. GBS = spec
. . . interface and trace assertion next of nat init 1000 com GasOn write next then next0 = next { 1 ^ @GasOn = next0 com HeatOn read next when next > 0 com Serve write next then next0 = @Serve
var
end
In the interface, the type of the channel \GasOn" is changed to nat standing for natural numbers, and we declare a new input channel \Serve" of type nat. Also, the trace assertion of GB is changed by replacing the symbol \HeatOn" with (HeatOn + Serve : HeatOn )
The gas burner with service has a state variable \next" that counts how many ignitions are still possible before service is required. For the channel \GasOn" we use a communication assertion stating that any communication on \GasOn" decrements the variable \next" and communicates this value. A communication on \HeatOn" is enabled only if \next" is positive. A communication on \Serve" resets \next" to the value input from channel \Serve".
3.2 Programming language PL
We consider an occam-like [19] programming language PL. Programs are constructed using programming operators like SKIP to continue immediately, assignment x := e , input ch ?x and output ch !e , and WHILE, SEQ, IF, ALT, PAR for loops, sequential, conditional, alternative and parallel composition. In inputs and outputs, the input destination x or output value e are omitted if the channel value type is signal.
A system is a pair : P consisting of an interface and a predicate P describing all observations that are considered relevant for the interaction of the system with its environment. A predicative semantics for SL and PL is then de ned as follows: every speci cation S 2 SL and program P 2 PL is identi ed with a system : P , a program P implements or is correct w.r.t. a speci cation S i P > S holds. Here > denotes system implication de ned by 1 : P1 > 2 : P2 i 1 = 2 and P1 ) P2 : Example. We have GBP > GB. This expresses formally that the gas burner program GBP implements GB.
3.5 Transformational approach
A subset of SL can be compiled automatically into PL using the syntax-directed transformation SDT [35]. The trace part is transformed into a communication skeleton and the state part completes this skeleton to an occam-like program by adding purely sequential parts. SDT proceeds by induction on the syntactic structure of regular expressions in the trace part: a letter is transformed into input or output, . is transformed into sequential composition, + is transformed into alternation, is transformed into iteration. Example. SDT is applicable to the gas burner speci cations GB and GBS. When applied to GB it yields the following PL program GBP. GBP = . . . interface copied from GB WHILE( true, SEQ[ GasO !, HeatOn?, Set30!, Out30?, Set1!, GasOn!, Out1?, Set1!, ALT[ FlOn? ! ALT[ HeatO ? ! SKIP, FlO ? ! SKIP ], Out1? ! SKIP ] ] )
SDT is applicable only to a restricted class of speci cations and yields only sequential programs. In general, we pursue a transformational approach where a given speci cation is transformed stepwise into a program. Our work is in the tradition of Dijkstra's approach to re nement, and of Burstall and Darlington's approach to transformational programming, but our target is reactive occam-like programs, as in [2]. To express the intermediate design stages we mix programming and speci cation notation using a language of mixed terms that contains SL and PL as proper subsets [27, 40]. A design of a program P from a speci cation S is then a sequence S Q1
