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 dierence 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, dierence or dierential 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 oers 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

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

ch

of

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 var 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

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 < . . . < Qn  P of (reverse) system implications between mixed terms Q1; . . . ; Qn where Q1 is the given speci cation S and Qn is the designed program P . Each implication in the sequence is generated by an application of a transformation rule. In speci c cases, several rules can be combined to strategies, i.e. recipes how to apply them systematically or even automatically. SDT is one such strategy. More widely applicable is an expansion strategy [28]. Both SDT and expansion yield only sequential programs, i.e. without any concurrent composition. No xed strategy is given for designing concurrent implementations. It is an \intuition-guided" activity where transformation rules are selected and applied [29].

3.4 Predicative semantics

4 Programs to Hardware

3.3 Compilation of SL to PL

The link between SL and PL is given by a statetrace-readiness model for reactive systems [28], presented in a predicative style [15].

In this section we outline a technique to compile programs written in PL directly into hardware via provably correct transformations. Crucial to our

method is the use of normal form PL programs [18] which re ne the semantics of the user program and yet provide a representation very close to the desired hardware. A nal, relatively direct, transformation is from the normal form into a netlist (a list of logic gates and latches with their interconnections) which is a standard form of hardware description. These netlists can be implemented in hardware in many ways. Currently, we use FPGAs (Field Programmable Gate Arrays) which can be dynamically recon gured by software. This enables us to build hardware implementations of modest-sized programs entirely by a software process. A prototype compiler in the functional language SML has been produced [30] which converts a PL-like language, cf. [9], to a netlist suitable for further processing using placement and routing software for an FPGA from Xilinx. [38]. This produces a synchronous design in which it is assumed that the longest delay in the combinational circuitry is shorter than the length of the clock cycle. The normal form approach is based on work on proving software compilation correct [16, 17]. Our compilation process preserves true concurrency which is represented in the user program by expressions, simultaneous assignment, and explicit parallelism. A signi cant feature of our hardware implementations is that only assignment and (ready-to-run) communication take time to execute, and they each take precisely one clock cycle. A simple timing calculus results which enables our programs to meet real-time guarantees. Alternative strategies include compilation to asynchronous delay-insensitive circuits [7] and into a set of special-purpose computers, each with just sucient resources and appropriate microcode [23]. The techniques above allow a microprocessor such as a transputer to be compiled into hardware from an interpreter description (speci cation) of the processor. What is more, the design may easily be parameterized for dierent word lengths, sets of instructions, etc. Since the compiling process itself may be proved correct, con dence in all the processors produced is increased. This is in marked contrast to the more traditional formal veri cation techniques, in which only a single processor is proved correct, and represents a novel aspect of this ongoing research work. The approach is also derivational rather than proof-oriented in nature.

4.1 Program transformations The programming language PL has been introduced in the previous section. The basic algebraic laws for occam programs are given in [34]. In [13] we have

presented some algebraic laws speci cally concerned with real-time properties of programs. The laws are in the form of equations (`=') and inequations (`v'). If P v Q then Q is considered to be an implementation of P . It is more deterministic and terminates more often. Although hardware never \terminates", here we deem termination to occur when the hardware generates a \ nish" output signal on a speci c wire.

4.2 Normal form implementation Normal form programs are a bridge between programs in PL and either software (traditional machine code) [18] or hardware (digital circuit) implementations of them; here the latter is outlined. With some further transformation, the hardware normal form may be interpreted as `netlist' hardware speci cations. It should be noted that this presentation is a snapshot of ongoing research and thus the normal form we eventually use is likely to change. A normal form program comprises three sequential programs where the rst one designates the initial control state of the circuit, and the last one the nal state. The middle program is a loop with a simultaneous assignment as its body which speci es state changes of the computation. The normal form is written in a shortened notation for convenience: c ; l : [s ^ : c ^ : f ^ L; b  STEP ; f ] =b VAR c ; l SEQ ASSUME s c WHILE b STEP ; ASSERT f END c ; l VAR c ; l ASSUME

[

(

^ : ^ : f ^ L;

]

)

Here declares a set of variables and END c ; l ends their scope. represents an assumption about the environment of the program and ASSERT represents an assertion by the program. Furthermore, c is a set of output wires of control latches, l is a set of local control wires, and s is an input wire accepting the start signal from the environment. f is an output wire delivering the nish signal, L gives the relation between s , c , f and l , and b is a Boolean condition on control wires. The condition b is true when the circuit is active and it becomes false once the circuit reaches the stable state. We require that b ) (s _ c ) since either the start signal or one of the control latches must be high for the circuit to be active. The program STEP gives the state change of a circuit within one clock cycle. Here we model it as a sequential program consisting of three substeps. STEP =b SEQ[STEP 1 ; STEP 2 ; SKIP1 ; STEP 3]

where SKIP1 models a delay of one clock cycle. The rst substep sends output readiness, given by OF , to its parallel partners, and at the same time it receives the corresponding readiness status of its partners on the other end of its channels. These communications are implemented by wire connections: STEP 1 =b SEQ[out ag := b ^ OF ; * * (ch1 ! out ag k dh1 ? outready )] * * where ch1 and dh1 are sets of wire names used to exchange the channel status and k represents parallel composition for asynchronous wire communications. The assignment out ag := b ^ OF is implemented by a combinational circuit with output wire out ag , where : b ) : out ag . I.e., once the circuit reaches the stable state, its output channels become idle. The second substep handles the readiness status of all input channels: STEP 2 =b SEQ[in ag := b ^ IF ; * * (dh2 ! in ag k ch2 ? inready )] After one time unit (clock cycle) a nal substep communicates on those channels where both parties are ready. It also assigns new values to control wires, and to the latches representing program variables: STEP 3 =b SEQ[ ALT [(out ag ^ inready ) & ch ! b ^ D ! SKIP ; (in ag ^ outready ) & dh ? data ! SKIP] ; hs ; c ; f ; v i := h0; ((b ^ C ) _ (: b ^ c )); b ^ F ; ((b ^ E ) _ (: b ^ v ))i ; l :2 L ] where l :2 L is a generalized assignment from a set of possible values rather than a single one. The normal form reduction theorems ensure that in the generated circuit, at any time only one of the alternatives of the alternation is available; i.e. only one channel is ready for communication. D ; C ; F ; E are outputs of combinational circuits. The wire data is used to receive the message from the channel dh . Both ch and dh can be implemented by either a wire or a register. When b is false, the output wire ch is at low voltage. The assignments on s , c , f and v have a form which ensures the stability of control wires and latches once the circuit becomes idle.

4.3 Reduction to normal form

Each of the constructs in a PL program may be reduced into normal form. Primitive PL processes such as assignment and communication may be converted directly to a normal form program. Compositional constructs of normal forms can be re ned by a single normal form description. Only a sample normal form theorem for sequential composition is included here. Sequential composition is implemented by connect-

ing the output wire fs of the rst circuit to the input wire of a subsequent circuit: s-

circuit1

fs- circuit 2

f-

It is essential that each circuit is only activated by a high signal on its input wire and thus that only one of the circuits is active at once (in sequence). Whilst the active circuit is \executing" the other circuit must remain quiescent. The following re nement law can then be proven SEQ[c1; l1 : [s ^ : c1 ^ : fs ^ L1 ; b1  STEP1 ; fs ]; c2; l2 : [fs ^ : c2 ^ : f ^ L2 ; b2  STEP2 ; f ]] v c1 ; c2; l1; l2; fs : [s ^ : c1 ^ : fs ^ : c2 ^ : f ^ L; (b1 _ b2 )  STEP ; f ] where OF =b (b1 ^ OF1 ) _ (b2 ^ OF2 ) and IF =b (b1 ^ IF1 ) _ (b2 ^ IF2) and D =b (b1 ^ D1 ) _ (b2 ^ D2 ) and E =b (b1 ^ E1 ) _ (b2 ^ E2 ) and L =b L1 ^ L2 and FS =b F1 and F =b F2 Theorems for the other constructs of the language can be formulated in a similar manner. Proofs of the theorems can be largely conducted using a library of algebraic laws in a calculational style. The laws themselves may be derived from a speci cation-oriented semantics. To prove each construct we must gradually transform the RHS to the LHS (or vice versa) of the relevant theorem using the algebraic re nement laws (equations and inequations), derived lemmas and Boolean logic, ensuring that inequations are applied only in the correct direction of re nement. Example proofs may be found in [5, 14].

4.4 Rapid prototype compiler All the theorems may be transformed into Horn clauses providing a circuit implementation of each language construct in terms of uninstantiated subprograms and other components. Thus it is feasible to prototype the theorems as a logic program in a language such as Prolog [4]. However, to produce an executable compiler, it is necessary to constructively generate each of the constructs of the language. This is easy for the normal formal reduction theorems concerning primitive constructs in the language. The definitions for elements of STEP may be coded as constraints in each of the clauses. Theorems for compositional constructs apply if all the components of the constructs are in normal form. However sequence, loop and conditional are monotonic w.r.t. v and also v is transitive. From these laws we

can derive theorems in the form of Horn clauses that may be easily encoded as a logic program [14].

4.5 Summary

The approach has been used to design the control of a robot arm for the Department of Engineering at Oxford. Using this for comparison, the gas burner PL program example is small enough to t onto a single FPGA even with today's technology of around 10,000 gate equivalents per chip. A bene t of compiling to synchronous circuits is the fact that the timing behaviour of programs is considerably simpli ed. In essence, each assignment and (unblocked) communication takes a single clock cycle (or some xed number of clock cycles if desired for eciency) and control constructs eectively take no time at all since the control signals are calculated between clock cycles (i.e., in parallel with assignments and communication). This means that the real-time reasoning about programs implemented directly in hardware, where true parallelism is possible, is much easier than for a traditional implementation using a scheduler on a single sequential processor. For our future work we plan to also consider hardware/software co-design. Currently only relatively small programs can be fully compiled in programmable hardware. Realistically, many programs will need to be compiled into a combination of machine code and hardware. The split could be automated to some extent, although human guidance may well be desirable as well.

5 Real-Time in Programs

Programming languages play the role of an interface between high levels of abstraction, where system development requires human ingenuity, and low levels of abstraction, where correctness preserving transformations can be applied fully automatic by compilers. In order to allow reasoning about the correctness of programs without knowledge about the particular implementation it is usual to make semantics of programming languages implementation-independent. Unfortunately, this does not hold for most real-time languages. Many of them (e.g. occam [19]) can only express lower bounds on execution times, whereas upper bounds can only be deduced from inspection of machine code generated by a compiler. Such languages are not very helpful in stepwise development of hard real-time systems, as they do not even provide means to specify upper bounds at program level. Thus, one of the immediate goals of the second phase of the ProCoS project, ProCoS II, is to pro-

vide a prototype of a real-time programming language designed to interface a system speci cation and a system implementation. It has to provide suciently expressive timing operators to allow for program correctness arguments without recurrence to a particular implementation, and it must also be implementable on hardware without having overly idealized timing properties.

5.1 Real-time speci cations

The speci cation language SLtime [36] extends SL as introduced in section 3 with a time restriction part. In SLtime , a lower bound of r on the time between communication on some channel in a set C1 of channels and communication on a channel in C2 is speci ed by wait from

C1 to C2 min r

An upper bound of r on the time from communication on a channel in the set C1 till readiness for communication on each channel in C2 is speci ed by C1 to C2 max r unless C3 The channel set C3 is an exception set becoming imwait from

mediately ready. Any communication on a channel in C3 preempts the construct. The timing properties of the control automaton given in section 2.2 can be expressed by these constructs wait from fHeatOng to fGasOn g min 30 wait from fHeatOng to fGasOn g max 30 unless fg wait from fGasOn g to fFlOn g min 1 wait from fGasOn g to fGasO g max 2 unless fFlOn g

5.2 Real-time programs

Such speci cations can be transformed to programs in PLtime [11], an extension of PL with operators for placing upper bounds on execution times of sequential processes and for delaying readiness of guards in alternatives. E.g., the control loop of the gas burner presented in section 2.2 can be implemented by the PLtime sequential process TGBP = WHILE(true;



SEQ[ GasO!

0

;

SEQ ; ALT WAIT

])

[ HeatOn? [ 30 : SKIP ! SKIP] ;  30; GasOn!] ALT[ WAIT 1 : FlOn? ! ALT[ WAIT 0 : HeatO? ! SKIP; 2 WAIT 0 : FlO? ! SKIP] WAIT 2 : SKIP ! SKIP]

where wait-guards introduce lower bound timing and j sequential process j t represents upper bound timing. This construct con nes the sequential process to spend at most the amount speci ed by t of time controlled by itself, i.e. not spent waiting for communication partners, until termination. If this contradicts with lower bounds imposed by inner timed alternatives, the semantics is miraculous. A timed alternative consists of processes guarded by input guards, where the readiness of the guarding communications is established when the delay time stated in the guard has elapsed. In contrast to occam, timing is hard, i.e. readiness is established at the moment the delay elapses, not arbitrarily thereafter. A SKIP-guard is passed immediately after the associated delay has elapsed. Sequential composition and evaluation of control constructs do not take time themselves, i.e. timing of compound processes is completely determined by the timing of the component processes.

5.3 Implementation dependencies In any implementation, timing properties, cf. TGBP, rely on hardware timers which do not accurately re ect real-world time due to clock drift and discretization. The consequences for synchronous systems can be drastic, as independent subsystems may loose synchrony due to the imperfection of clock devices. Thus, we have to model the eects of timer inaccuracies in the semantics of PLtime to achieve reliable designs. In [10], closure operators giving smooth and algebraically pleasant abstractions of clock drift and of time discretization have been de ned. Emphasis has been put on applicability of these operators to a variety of models of real-time concurrency. As a result, they can be consistently applied at all levels of development. In particular, tolerance against timing inaccuracies can be implanted into a system already at control design level, when satisfaction of safety and functionality requirements can be easily checked. Once introduced, inaccuracy closure operators can be handed down through all levels of development until the compiler takes advantage of them for implementing a program on actual hardware. The compiler can make sure that timing of the generated code on the target hardware will be at least as precise as stipulated by the inaccuracy operators. This implies that the implemented system will satisfy its safety and functionality requirements despite inaccuracy of hardware timing. In the following two paragraphs, we give a short account of these operators. The view we take is that real-world time T is continuous and that local time T l

of processes does not show the structural peculiarities of hardware time (e.g., discreteness), but is conceptually equivalent to real-world time, i.e. T l = T = R. This identi cation makes the same laws valid for all time domains, with inaccuracy being a loose coupling between two similar timing regimes. Drift of Hardware Clocks. Ideally, local time and real-world time should coincide. Now, by clock drift, local time may slightly dier from real time, and the deviation may accumulate the longer the system runs. Thus, the relation between readings of the local clock and the associated real-world times is no longer the identity, but a function mapping local time instants to in general dierent real-world times. If relative drift is bounded by ", i.e. if clock deviation may increase by at most " in any time interval of length   0, we may observe mappings tv : T l ! T from local to real-world time with tv (t l +  ) ; tv (t l ) 2 [ (1 ; ");  (1 + ")] (1) Indeed, we will apply mappings from local to global time only to sequential subsystems, where temporal order is total w.r.t. the local clock. Hence, we restrict ourselves to bijective increasing functions from T l to T . In the remainder, such functions are called time variations. We will use them to map timed behaviours which are timed using local time to their real-world time counterparts. Timed behaviours can be formalized in a variety of ways depending on the basic model used. However, application of time variations is always quite straightforward. E.g., consider a timed sequence s = < (o1 ; t1l ); (o2 ; t2l ); . . . > 2 (Obs  T l ) of observations with time stamps from machine time. It can be mapped to real time via a time variation tv by mapping local time stamps to their realworld counterparts associated via tv . I.e., tv (s ) =b < (o1 ; tv (t1l )); (o2 ; tv (t2l )); . . . >. Or, consider a time diagram d : T l ! Obs mapping time instants to observations. Here, change of the timing regime is simply done by functional composition, i.e. tv (d ) =b tv ;1  d . As a consequence, we can give a de nition for the drift closure modelling the eect of clock drift on timed systems. For a set Beh of behaviours it gives all the retimed behaviours that can be obtained from behaviours in Beh by applying time variations that may be observed under relative drift of at most ". The drift closure imposed by drift of at most " on Beh is 8 9 tv is a time variation, = < tv (beh ) tv satis es (1), and ; :

beh 2 Beh

Granularity of Hardware Time. Another char-

acteristic of hardware timing is granularity of time

which is introduced by both the limited precision of the representation of time and by synchronous hardware being responsive only at certain time instants. Granularity is a local inaccuracy which we assume to be of the same magnitude wherever in time we are. It imposes equivalence classes on real-world time, as the temporal order of observations which are too close together in real-world time cannot be recorded by the machine. We take granularity to be not only of the same magnitude wherever in time we are, but indeed completely homogeneous in time. Under a granularity of   0, a reading t l of the local clock may represent any realworld time in [t l ; t l +  ]. We may then observe any mapping tv : T l ! T from local to global time with tv (t l ) 2 [t l ; t l +  ] (2) The eect of a granularity on a set Beh of behaviours can be modelled by a non-deterministic closure operation similar to drift closure. The granularity closure imposed by granularity  on Beh is 9 8 tv is a time variation, = < tv satis es (2), and tv ( beh ) : ;

beh 2 Beh

Drift and Granularity speci cation. PLtime pro-

grams are systems of timed communicating sequential processes combined by outermost parallelism. It is assumed that there is at most one local clock per parallel component. The acceptable inaccuracy for the local clock of a parallel component is stated by pre xing it with a speci cation of the maximum allowed drift and granularity. Semantically, this is understood as application of the drift and granularity closures of the previous paragraphs to the locally timed subsystems. This represents a remapping of process behaviours to real-world time before applying parallel composition. Communication Latencies. Parallel components of PLtime programs use synchronous channels for communication. Often, such systems are understood under the maximum progress assumption, where a communication has to take place as soon as two communication partners are simultaneously ready for a communication. This gives nice timing properties, but is unrealistic even for systems with a processor for each parallel component, as hardware and protocol delays do not only limit reactivity, but may even blur the temporal order of events. In PLtime , parallelism is understood under an almost maximum progress assumption, i.e. if communication partners are simultaneously ready for a communication, communication of that or another competing event need not happen unless both commu-

nication partners have been simultaneously ready for the event for a certain amount of time, called the latency associated to that event. Communication latencies are assigned at a per-channel basis. Thus, PLtime programs consist of a channel declaration stating the available channels and their latencies, and a parallel system composed from internally sequential components by outermost parallelism. E.g., the complete PLtime code for the gas burner control program reads HrOn; HrO ; GasOn; GasO ; FlOn; FlO OF signal LATENCY 0:05; PAR[DRIFT 0:01; GRANULARITY 0:05; TGBP] CHAN

assuming a clock drift below 1%, and granularity and channel latencies of at most 201 of a second are tolerable in gas burner control. As inaccuracies may already be introduced during control design, these assumptions can be checked against the safety and functionality requirements in a provably correct development.

5.4 Compiling PLtime

In contrast to languages with only lower bound timing, where satisfaction of timing operators by generated machine code is always decidable, satis ability of an PLtime upper bound can be undecidable due to enclosed loops. When generating code for such a program, the compiler cannot assert correctness of the generated code, as this would amount to solving the halting problem. In this sense, only a subset of PLtime is compilable. Fortunately, translation of full PLtime to machine code can be decomposed into code generation for a compilable subset and veri cation condition generation for other programs. For any program to be translated, the compiler will yield machine code and a modi cation of the original program decorated with additional assertions on variable states. These assertions record assumptions on iteration counts and variable states during program execution which justify the generated code. Assertions are proof obligations to the programmer.

6 Conclusion We have presented various aspects of the work of the ProCoS project, most of which is intended to interface together to form a \tower" of veri ed levels in the design of safety-critical systems. Much of the ongoing work in ProCoS is directed at securing the interfaces that still needs elaboration. Currently, the main eorts are to get the already developed timed version of SL to link to the top level design, and to interface to real time at the machine level.

Another challenge is to develop tools to support the calculational style of veri cation applied at the dierent levels. The use of normal forms may be instrumental to the success of ongoing work in that direction, as developed from some of the earlier work on compiling speci cation in the project [17, 18]. Acknowledgements. Sincere thanks are due to Professors Dines Bjrner, C.A.R. Hoare and Hans Langmaack for giving birth to ProCoS. The authors here are grateful to the other researchers associated with the ProCoS project, in particular to the following for the work presented here: Lennart Andersson, Karl-Heinz Buth, Bettina Buth, Kirsten M. Hansen, Michael Hansen, He Jifeng, C.A.R. Hoare, Burghard von Karger, Paulo Masiero, Markus Muller-Olm, Ian Page, Hans Rischel, Stephan Rossig, Michael Schenke, Victoria Stavridou, Zhou Chaochen.

References

[1] R. Alur and D.L. Dill, Automata for modeling realtime systems, in M.S. Paterson (ed.), ICALP 90: Automata, Languages and Programming, SpringerVerlag, LNCS 443, pp. 322{335, 1990. [2] R.J.R. Back, Re nement calculus, part II: parallel and reactive programs, in J.W. de Bakker, W.-P. de Roever, G. Rozenberg (eds.), Stepwise Re nement of Distributed Systems: Models, Formalisms, Correctness, Springer-Verlag, LNCS 430, pp. 67{93, 1990. [3] D. Bjrner, H. Langmaack and C.A.R. Hoare (eds.), ProCoS I Final Deliverable, ProCoS Technical Report [ID/DTH DB 13], January 1993. [4] J.P. Bowen, From programs to object code using logic and logic programming, in R. Giegerich and S.L. Graham (eds.), Code Generation { Concepts, Tools, Techniques, Springer-Verlag, Workshops in Computing, pp. 173{192, 1992. [5] J.P. Bowen (ed.), Towards Veri ed Systems, Elsevier, Real-Time Safety Critical Systems Series, 1993. In preparation. [6] J.P. Bowen and V. Stavridou, Formal methods and software safety, in H. Frey (ed.), Safety of Computer Control Systems 1992 (SAFECOMP'92), Pergamon Press, pp. 93{98, 1992. [7] G.M. Brown, Towards truly delay-insensitive circuit realizations of process algebras, in G. Jones and M. Sheeran (eds.), Designing Correct Circuits, SpringerVerlag, Workshops in Computing, pp. 120{131, 1991. [8] M. Broy, Speci cation and top-down design of distributed systems, Journal of Computer System Science 34, 236{265, 1987. [9] G.V. Collis and E.J. Kappos, Occam as a hardware description language, BCS/IEE Software Engineering Journal 2(6), 213{219, November 1987.

[10] M. Franzle and M. Muller-Olm, Drift and Granularity of Time in Real-Time System Implementation, ProCoS II project document [Kiel MF 10], 1992. [11] M. Franzle, Proposal for a Programming Language Core for ProCoS II, ProCoSII project document [Kiel MF 11], 1993. [12] D.I. Good and W.D. Young, Mathematical methods for digital system development, in S. Prehn and W.J. Toetenel (eds.), VDM '91, Formal Software Development Methods, Volume 2: Tutorials, Springer-Verlag, LNCS 552, pp. 406{430, 1991. [13] He Jifeng and J.P. Bowen, Time interval semantics and implementation of a real-time programming language, Proc. 4th Euromicro Workshop on Real-Time Systems, IEEE Press, pp. 110{115, June 1992. [14] He Jifeng, I. Page and J.P. Bowen, Towards a provably correct hardware implementation of Occam, Proc. IFIP WG10.2 Advanced Research Working Conference on Correct Hardware Design and Veri cation Methods (CHARME'93), Arles, France, 24{ 26 May 1993. To appear, Springer-Verlag, LNCS. [15] C.A.R. Hoare, Programs are predicates, in C.A.R. Hoare and J.C. Shepherdson (eds.), Mathematical Logic and Programming Languages, Prentice Hall, pp. 141{155, 1985. [16] C.A.R. Hoare, Re nement algebra proves correctness of compiling speci cations, in C.C. Morgan and J.C.P. Woodcock (eds.), 3rd Re nement Workshop, Springer-Verlag, Workshops in Computing, pp. 33{ 48, 1991. [17] C.A.R. Hoare, He Jifeng, J.P. Bowen and P.K. Pandya, An algebraic approach to veri able compiling speci cation and prototyping of the ProCoS level 0 programming language, ESPRIT '90 Conference Proceedings, Kluwer, pp. 804{818, 1990. [18] C.A.R. Hoare, He Jifeng and A. Sampaio, Normal form approach to compiler design, Acta Informatica, 1993. To appear. [19] INMOS Ltd., Occam 2 Reference Manual, Prentice Hall, 1988. [20] M.S. Jae, N.G. Leveson, M.P.E. Heimdahl and B.E. Melhart, Software requirements analysis for real-time process-control systems, IEEE Trans. Software Engineering SE-17(3), 241{258, 1991. [21] O. Maler, Z. Manna and A. Pnueli, From timed to hybrid systems, in J.W. de Bakker, C. Huizing, W.-P. de Roever and G. Rozenberg (eds.) Real-Time: Theory in Practice, REX Workshop, Springer-Verlag, LNCS 600, pp. 447{484, 1992. [22] Z. Manna and A. Pnueli, The Temporal Logic of Reactive and Concurrent Systems { Speci cation, Springer-Verlag, 1991. [23] D. May, Compiling Occam into silicon, in C.A.R. Hoare (ed.), Developments in Concurrency and Communication, Addison-Wesley, University of Texas at Austin Year of Programming Series, chapter 3, 1990.

[24] R. Milner, Communication and Concurrency, Prentice Hall, 1989. [25] B. Moszkowski, A temporal logic for multi-level reasoning about hardware, IEEE Computer 18(2), 10{ 19, 1985. [26] X. Nicollin, J. Sifakis & S. Yovine, Compiling realtime speci cations into extended automata, IEEE Trans. Softw. Eng. SE-18(9), 794{804, 1992. [27] E.-R. Olderog, Nets, Terms and Formulas, Cambridge University Press, 1991. [28] E.-R. Olderog, S. Rossig, J. Sander and M. Schenke, ProCoS at Oldenburg: The Interface between Speci cation Language and Occam-like Programming Language, Bericht 3/92, Univ. Oldenburg, Fachbereich Informatik, Germany, 1992. [29] E.-R. Olderog and S. Rossig, A case study in transformational design of concurrent systems, in M.-C. Gaudel and J.-P. Jouannaud (eds.), Proc. TAPSOFT '93, 1993. To appear, Springer-Verlag, LNCS. [30] I. Page and W. Luk, Compiling Occam into eldprogrammable gate arrays, in W. Moore and W. Luk (eds.), FPGAs, Abingdon EE&CS Books, 15 Harcourt Way, Abingdon, UK, pp. 271{283, 1991. [31] D.L. Parnas and P.C. Clements, A rational design process: how and why to fake it, IEEE Trans. Software Enginering SE-12(2), 251{257, 1986. [32] D.L. Parnas and J. Madey, Functional Documentation for Computer System Engineering (version 2), CSL Report 237, TRIO, McMaster University, Hamilton, Ontario, Canada, September 1991. [33] A.P. Ravn, H. Rischel and K.M. Hansen, Specifying and verifying requirements of real-time systems, IEEE Trans. Software Engineering SE-19(1), 41{55, 1993. [34] A.W. Roscoe and C.A.R. Hoare, Laws of Occam programming, Theoretical Computer Science 60, 177{ 229, 1988. [35] S. Rossig and M. Schenke, Speci cation and stepwise development of communicating systems, in S. Prehn and W.J. Toetenel (eds.), VDM '91, Formal Software Development Methods, Volume 1, SpringerVerlag, LNCS 551, pp. 149{163, 1991. [36] M. Schenke, Model and Speci cation Language, ProCoS II project document [Old MS 5], 1993. [37] J.U. Skakkebk, A.P. Ravn, H. Rischel and Zhou Chaochen, Speci cation of embedded real-time systems, Proc. 4th Euromicro Workshop on Real-Time Systems, IEEE Press, pp. 116{121, June 1992. [38] Xilinx Inc., The Programmable Gate Array Data Book, San Jose, California, USA, 1991. [39] Zhou Chaochen, C.A.R. Hoare and A.P. Ravn, A calculus of durations, Information Processing Letters 40(5), pp. 269{276, 1991. [40] J. Zwiers, Compositionality, Concurrency, and Partial Correctness { Proof Theories for Networks of Processes and their Relationship, Springer-Verlag, LNCS 321, 1989.