Using B to Design and Verify Controllers for

Using B to Design and Verify Controllers for Chemical Processing K. Lano, J. Bicarregui? , A. Sanchez?? Abstract. This paper is concerned with bridging the gap between ap-

proaches for the synthesis of controllers in the process industries and formal methods of specifying, designing and verifying reactive and realtime systems. We present a method which integrates techniques for the synthesis of procedural controllers [24] with speci cation and veri cation techniques for B [1]. The combined method enables a systematic approach to be taken to the creation of formalised designs for process controllers and proof obligations for the correctness of these designs against speci cations to be generated. The techniques have been applied to a part of an industrial plant [20]. In this paper we present the approach using the well-known gas burner example [22]. We also propose extensions to B which would allow more abstract and expressive speci cation of the requirements and designs of such systems.

1 Introduction The chemical process industries are some of the world's most successful and signi cant industries, with world-wide sales in 1993 of 1250 billion US dollars [7]. Process control is a key element in improving the eciency of these industries and enabling more advanced and exible plants to be developed [3]. As in other domains, the progress of the theory and practice of process control for chemical plants involves a collaboration between application engineers, control engineers and software engineers. This is particularly marked when aspects such as safety of the resulting plants is considered: analysing the hazards that may arise from a process, and how these may be minimised, inevitably involves consideration of the interactions between elements of each of these domains. A formal process of software speci cation and design for process controllers introduces the possibility of verifying some safety requirements on the basis of a well-de ned mathematical theory. In the case of the B ? ??

Dept. of Computing, Imperial College, 180 Queens Gate, London SW7 2BZ Centre for Process Systems Engineering, Dept. of Chemical Engineering, Imperial College

Abstract Machine Notation (AMN) [1], this means that safety requirements expressed as module invariants can be shown to be preserved by each low-level controller action (under the assumption that higher level controllers invoke low-level controller actions within their preconditions), and that these invariants are preserved in the re nement process towards an executable implementation. The combination of formal methods and controller synthesis gives the following advantages: { A systematic way of obtaining the controller speci cation and design is provided by the synthesis process; { The formal method provides a means of de ning and verifying highlevel controller states representing goals (eg: lling or levelling in the case of the tank example [20]) which are more suitable for an operator to deal with than the atomic level states used in the procedural controller; { The formal notation and its tool support provides veri cation of the controller after its design, and validation of the requirements before controller synthesis. The modularity mechanisms of B in particular support a decomposition of veri cation into a number of steps: showing that the low-level controller operations maintain the safety invariants (that undesired states are avoided), provided they are called within their preconditions, and that higher-level controllers invoke these low-level operations within their preconditions. In the rest of this section we introduce the concepts of procedural control and give an overview of the proposed method combining controller synthesis and formal speci cation and veri cation. Section 2 describes the steps of the method for the gas burner case study. Section 3 compares the B approach with other speci cation approaches for reactive systems. Section 4 summarises our proposed enhancements of B.

1.1 Procedural Control A procedural controller is a nite state machine in which each state either has: (i) a unique transition leaving it which is controllable (i.e., which corresponds to an output from the controller to the controlled system); or (ii) only uncontrollable transitions leaving it. Uncontrollable transitions are triggered by inputs from the controlled system to the controller. States

in case (ii) are termed \wait states" { they are states where the controller is waiting for some input event before proceeding. The standard process for the synthesis of procedural controllers is [24, 25]: 1. Input Information: { Input-output models for elementary components (i.e. nite state machine (FSM) or statechart models for valves, timers switches, etc) in which transitions are classi ed as process responses (uncontrollable transitions) or control commands (controllable transitions) { Static Speci cations. Speci cations describing forbidden states (i.e. states that must be avoided during operation). These states are modelled as logic statements. In particular, hazard states would normally be speci ed as forbidden states. { Dynamic Speci cations. Speci cations describing dynamic behaviour to be imposed upon the process. These include normal, abnormal and emergency operation. They can be captured as temporal logic (RAL [18]) formulas. 2. Model building using a model-checker such as SMV [5] 3. Synthesis of controller superstructure, including the controllability analysis of the resultant superstructure 4. Synthesis of a procedural controller, which de nes the ordering of sequences of controllable transitions in response to uncontrollable transitions occurring from each reachable state.

1.2 Method The following steps are taken in the synthesis and implementation of a controller for a reactive system using the combined method (Figure 1): { Identify the elementary components of the system { the sensors, controls and actuators which it involves, and give their behaviour via statecharts. Notice that this implies that all components are modelled as nite state machines: this is an abstraction away from continuous behaviour, which could be modelled via the time variables of VDM++ [9].

{ Identify the controllable and uncontrollable actions of the system com-

ponents. The latter will usually form the list of events to which the controller must respond, whilst the former will correspond to events generated by the controller. { Identify invariants of the system which must be maintained at all times, and which can be maintained by the inhibition of controllable actions. { Identify the marked system states { states of particular signi cance for the system, such as an initial state, or a state of desired activity. { Identify the procedural speci cations { these de ne the expected order of occurrence of actions. Using this information, the synthesis of a procedural controller is a toolsupported process [24], yielding a statechart which satis es the constraints given above. This statechart yields the de nition of a high-level controller as follows. The high-level controller has states which correspond to the wait states of the procedural controller, and transitions corresponding to the paths between successive wait states in the procedural controller. These transitions are triggered by the uncontrolled events at the start of these paths. We may also group controller states into higher-level modes representing goals [20]. A group of wait states connected only by uncontrolled transitions may be combined into a single high-level state (for example, consider the alarmed state in the gas burner controller). A B machine speci cation can be derived for each of the elementary components using their statechart descriptions. The aggregate of all of these modules forms the basis for an abstract speci cation of the uncontrolled system. In this module we can place logical constraints which express the assumptions which are being made about the physical properties of the system (these are properties which inevitably hold, and which do not need to be ensured by the controller). The aggregate of all those machines which correspond to actuators controlled by the controller forms a model of the output part of the controlled system. In this aggregate we can place the invariants identi ed in the analysis stage, and place restrictions (preconditions) on the operations corresponding to controllable actions which ensure the preservation of these invariants. Temporal constraints and procedural speci cations are also included in this aggregate module (in the extended language), if they refer only to controlled actions. This constrained aggregate is termed

Elementary Components (Statecharts)

Invariants (Forbiddon States)

Procedure Specifications (LTL)

Non-automated Process

Automatable Process

Controller Synthesis

Events & Marked States

DCF Diagram

Procedural Controller Statechart B AMN spec. of unconstrained system

Validation via animation; Verification of internal consistency

B spec of constrained system LL_Controller

High-level Controller Statechart

Verification: LL actions called within preconditions/ specified B spec of orderings high-level controller

Controller Design

Refinement: verification of refinement steps Executable System

Fig. 1. Documentation and Steps of Process

the \low-level controller". Proof obligations for internal consistency can be generated in order to obtain a check on the consistency of the static and dynamic constraints expressed in the analysis: internal consistency of this machine shows that the preconditions on atomic actions are sucient to ensure that they cannot lead to a forbidden state, and that the procedural and timing constraints are satis able in principle. Animation of this machine can also assist in enhancing the models before controller synthesis. A model-checking system such as SMV [5] can be used to determine if the procedural requirements are consistent. A machine and implementation corresponding to the high-level controller can be derived from the statechart of the procedural controller. These modules have operations for each event to which the controller must react, with the dierent transitions for each event becoming dierent cases in the de nitions of these operations. These operations invoke operations of the low-level controller machine in order to initiate actuator

actions. Thus there are additional proof obligations that the high-level controller implementation invokes the low-level controller operations in such a way that the static, dynamic and temporal constraints in the lowlevel controller are ensured. In the present B notation and method, only the static constraints are checked. For more complex systems, we may need to decompose the high-level control algorithm into a hierarchy of controllers which manage individual components or the interactions between small groups of components. The production cell case study [19] illustrates this decomposition, which was also considered in the lling tank example [20]. A data and control ow diagram can be developed from the initial analysis models, and used to de ne an architecture for the design of the system in B. However, the restrictions of the B language imply that a direct approach to design may not be possible. For example, sensors or controls which send signals to the controller should be represented as clients of (that is, importing) the high-level controller, whilst the highlevel controller is a client of the low-level controller. However, if there are components which both receive and send messages to the controller (cf. the Timer in the gas burner example), then we must de ne an intermediary machine which polls the sensor side of such components, and informs the high-level controller of any change in their state. The controller is then responsible for updating its record of their state.

2 Gas Burner Case Study The process to be controlled in this case study is the simpli ed burner system shown in gure 2. It consists of the following process items { An on/o valve to feed air { An on/o valve to feed fuel (gas) { A ame igniter { A ame detector { An on/o switch to start/stop the operation of the burner { An alarm indicator to indicate abnormal/emergency conditions in the burner { A timer to time the start-up operation.3 3

Strictly speaking the timer is not a process item. It is an add-on that the controller will use. But from the point of view of the controller it can be seen as a signal

Switch (on|off)

Flame detector (present | absent)

air valve (open | closed)

ignitor (on | off)

gas valve (open | closed)

Alarm (on|off) Timer (idle | running | expired)

Fig. 2. Gas Burner Components

2.1 Process Model A model is constructed to represent the input-output behaviour of each given element. Each item is modelled as a nite state machine (FSM). Table 1 lists all the models. The FSM must give a description of the process component behaviour in terms of operational states and transitions of the component. The transitions represent the inputs and outputs of the given system. Input transitions are commands issued by the controller, thus being controllable whilst output transitions represent process responses and disturbances, therefore being uncontrollable by the controller. For instance, the air valve is described by two states. The state-variable identi es whether the valve is open or closed. The states are connected by transitions indicating if the valve is opening (going from closed to open) or closing (going from open to closed). Both transitions describe the commands being sent by the controller to the valve (i.e. process) to execute a task They are labelled as controllable (i.e. by an exogenous signal). A statechart of the combined behaviour of the air valve, gas valve, ignitor, timer and ame detector is shown in Figure 3. In this example, transitions ame detected (41) and ame out (42) generator as any other process item.

Gas Burner: Domain Model Air Valve

Gas Valve

Closed

Timer

Closed close_av

Idle

close_gv open_gv

open_av Open

Open

Flame Detector

start_ timer

reset abort_ timer

Ignitor Running Off

Absent flame_off

ignite_off expire

ignite_on

flame_on Present

On

Expired

Fig. 3. Statechart of Gas Burner Components

represent the process responses causing the change in the ame detector. They are labelled as uncontrollable. The detection of the ame is an event that can occur during normal startup as a consequence of other (controllable) transitions but may also occur when the burner is on re caused by a fuel leak or improper operation. In addition, after ignition the ame may go o at any moment, either as a part of the normal shutdown or due to abnormal circumstances in the operation (e.g. fuel line blockage). The unconstrained B model of these components can be immediately generated from the nite state machines, together with some choices over the naming of states and transitions being supplied by the developer. For example, the model of the actuator (controllable) components is formalised by the following machine: MACHINE GB_Actuators /* Represents controlled part of unconstrained system */ SEES GB_data VARIABLES avstate, gvstate, istate, astate INVARIANT avstate: AVState & gvstate: GVState & istate: IState &

elementary state{variable state component description value label air valve 0: closed 1 valve position 1: open 2 gas valve 0: closed 1 valve position 1: open 2 igniter igniter 0: o 1 valve status 1: on 2

ame detector 0: ame detected 1 detector status 1: ame not detected 2 emergency alarm 0: o 1 alarm status 1: on 2 switch switch 0: o 1 status 1: on 2 timer timer 0: idle 1 status 1: running 2 status 2: expired 3

transition label description from st to st 11 opening 1 2 12 closing 2 1 21 opening 1 2 22 closing 2 1 31 switching on 1 2 32 switching o 2 1 41* ame being detected 1 2 42* ame extinguishing 2 1 51 alarm being activated 1 2 52 alarm being deactivated 2 1 61* switching on 1 2 62* switching o 2 1 71 starting 1 2 72 aborting 2 1 73* expiring 2 3 74 reseting 3 1

Table 1. List of elementary models of the burner system (* = uncontrollable transition).

astate: AState INITIALISATION avstate := av_closed || gvstate := gv_closed || istate := off || astate := alarm_off OPERATIONS open_av = PRE avstate = av_closed THEN avstate := av_open END; close_av = PRE avstate = av_open THEN avstate := av_closed END; ....

/* Similarly for the gas valve */

ignite_on = PRE istate = off THEN istate := on END;

ignite_off = PRE istate = on THEN istate := off END; raise_alarm = PRE astate = alarm_off THEN astate := alarm_on END END

where: MACHINE GB_data SETS AVState = {av_open, av_closed}; GVState = {gv_open, gv_closed}; IState = { on, off }; FDState = { present, absent }; AState = { alarm_on, alarm_off }; SState = { switch_on, switch_off }; TState = { idle, running, expired } END

encapsulates shared type de nitions. The overall process model has seven state-variables describing the status, which are given in the order (air valve, gas valve, igniter, ame detector, alarm, switch, timer) The resultant FSM contains 192 states. Some relevant states for the operation are de ned in Table 2. These are the initial state of the system and safe goal states that may be reached during normal or abnormal operation. The data and control- ow diagram of the system is given in Figure 4.

2.2 Static Speci cations The safest procedure for starting up the burner is to minimise the time in which the air/fuel mixture is present in the chamber without the occurrence of ame. Therefore, the gas valve must be open only when the air valve is open because either the system is starting up and the igniter

state

state{variables air valve gas valve igniter ame detector alarm switch timer initial closed closed o not detected o o idle normal operation open open o detected o on idle safe alarm closed closed o unde ned on unde ned unde ned

Table 2. List of important states during operation Alarm Flame Detector

flame_on flame_off

raise_alarm

Air Valve

open_av, close_av Controller

open_gv, close_gv

switch_on switch_off

Switch

Gas Valve

start_timer, reset, abort_timer

expire

ignite_on, ignite_off

Ignitor

Timer

Fig.4. Data and Control Flow Diagram of Burner System

is on, or the system is operating normally. This means that the gas valve must never be open if the air valve is closed irrespective of the state of any of the other process components. This is described by the statement:

s1 : (0; 1; 13; 14; 15; 16; 17) = FALSE (1) Where 1i means that the i-th variable may take on any value in its state

space. In B we capture this constraint by an invariant gvstate = gv open ) avstate = av open. Likewise, in order to maximise the life of the igniter, it must be used

only when the system must ignite. Therefore, if the air valve is closed, the igniter must under no circumstances be on, regardless of the status of other system components. This is expressed in a compact way by the following statement:

s2 : (0; 12; 1; 14; 15; 16; 17) = FALSE In B this is avstate = av closed ) istate = o .

(2)

These additional constraints eliminate 72 states from the 192 of the unconstrained system. They are expressed in the invariant clause of a low-level controller machine: MACHINE GB_Control /* Low-level Controller */ INCLUDES GB_Actuators PROMOTES open_av, close_gv, ignite_off, raise_alarm SEES GB_data INVARIANT (avstate = av_closed => istate = off) & (gvstate = gv_open => avstate = av_open) OPERATIONS c_close_av = PRE avstate = av_open & istate = off & gvstate = gv_closed THEN close_av END; c_open_gv = PRE avstate = av_open & gvstate = gv_closed THEN open_gv END; c_ignite_on = PRE avstate = av_open & istate = off THEN ignite_on END END

The operations close av, etc are rede ned in this machine to ensure that they preserve the new invariant, provided they are called in states which satisfy their preconditions. Other operations are simply promoted from the unconstrained system.

The preconditions in the low-level controller can be calculated from the invariants and de nitions of the atomic transitions. They are:

Pre  (Inv ) [Def ]Inv) where [ ] is the weakest precondition operator [1], Pre is the precondition of an action with code Def , and Inv is the invariant to be maintained. For example, for the action close av, with invariant gvstate = gv open ) avstate = av open, we can calculate:

Preclose av  [avstate := av closed](gvstate = gv open ) avstate = av open) which is (gvstate = gv open ) av closed = av open) which is equivalent to gvstate = gv closed.

2.3 Dynamic speci cations These are the speci cations for the desired behaviour of the controlled system. First, there is a short description of what is desired to be speci ed. Then a TL formula expressing the behaviour is given, in terms of the states and actions that can take place in the complete system (comprising both the controller and the controlled components).

Normal Operation The normal start-up sequence begins with the sys-

tem in the initial state and is triggered by the switch changing to on: { Open air valve { Switch on igniter { Open gas valve { Launch timer Symbolically: [(1; 1; 1; 1; 1; 1; 1) ^  = 61 )

( = 11) ^ ( = 31) ^

( = 21) ^ ( = 71)

 identi es the current action.

This constrains the sequences of atomic actions which can take place in the system. In RAL it would be written: (avstate = av closed ^ gvstate = gv closed ^ istate = o ^ fdstate = absent ^ astate = alarm o ^ sstate = switch o ^ tstate = idle ^ switch pressed) )

open av ^ ignite on ^ open gv ^

start timer

Similarly, if the system is starting up and ame is detected, we must: { Switch o ignitor { Abort timer In temporal logic: (avstate = av open ^ gvstate = gv open ^ istate = on ^ fdstate = absent ^ astate = alarm o ^ sstate = switch on ^ tstate = running ^ detected) )

ignite o ^ abort timer

A further 9 dynamic constraints of a similar form are formalised as part of the constrained system speci cation. The dynamic speci cations are always of the form

current state = val ^



) 

where  is an uncontrolled action, and  contains only controlled actions. This suggests that only a subset of temporal logic notation is necessary in the history clause of an extended machine as described in Section 4. Timing constraints could include that the gas valve is never open for a continuous period of more than 30 seconds with the ame being absent:

8 t1; t2 : TIME
t1 < t2 ) (gvstate = gv open ^ fdstate = absent)}[t1 ; t2] ) t2 ? t1  30 where '}I means that ' holds throughout the interval I.

An abstract speci cation of the controller for the system can be built using a copy of the data of the unconstrained system. Its operations correspond to the events which are inputs to the controller on the control and data ow diagram:

MACHINE GasBurner /* Abstract controller */ INCLUDES GB_Actuators, Timer SEES Bool_TYPE, GB_data SETS CState = { c_idle, try_ignite, c_running, try_shutdown, try_restart, alarmed } VARIABLES cstate INVARIANT cstate: CState & (cstate = c_idle => (avstate = av_closed & gvstate = gv_closed & istate = off & astate = alarm_off & tstate = idle) ) & (cstate = try_ignite => (gvstate = gv_open & avstate = av_open & astate = alarm_off & istate = on & tstate = running) ) & ... /* Other definitions of controller states in terms of low-level states */ ... & (cstate = alarmed => astate = alarm_on) INITIALISATION cstate := c_idle OPERATIONS switch_pressed = PRE cstate = c_idle or cstate = try_shutdown THEN IF cstate = c_idle THEN open_av || open_gv || ignite_on || start_timer || cstate := try_ignite ELSE cstate := try_restart END END; switch_released =

... /* similar */;

flame_detected = PRE cstate = try_ignite THEN

or

cstate = c_idle

IF cstate = try_ignite THEN ignite_off || abort_timer || cstate := c_running ELSE raise_alarm || cstate := alarmed END END; flame_out = ... /* similar */; timed_out = PRE cstate = try_ignite or cstate = try_restart THEN IF cstate = try_ignite THEN start_timer ELSE raise_alarm || reset || close_av || cstate := alarmed END END

cstate = try_shutdown

or

END

This speci cation describes what the controller actions should achieve, not how they are implemented in terms of the atomic actions of the system. The preconditions again express physical constraints which the developer can assume in order to simplify the process of implementation: timed out, for example, can only occur in the three states listed, since in other controller states the timer will not be running. The invariant of this machine de nes the meaning of the controller states. By separating out the high-level and low-level controller we have also separated the statement of this invariant from the speci cation of the safety invariants, which assists both proof and human comprehension.

2.4 Procedural Controller Synthesis A procedural controller for this system can be generated using the techniques of [24]. It has 39 states, and is shown in Figure 5. Wait states are shown as ovals.

Idle

flame_detected

1,1,1,1,1,1,1

1,1,1,2,1,1,1

switch_pressed 1,1,1,1,1,2,1

2,1,1,1,1,2,1

2,1,2,1,1,2,1

2,2,2,1,1,2,1 Try_ignite 2,2,2,1,1,2,2

switch_released

timed_out 2,2,2,1,1,2,3

flame_detected 2,2,2,1,1,1,2

2,2,2,2,1,2,2 2,1,2,1,1,2,3

2,1,2,1,1,1,2

2,2,1,2,1,2,2

2,1,1,1,1,1,2

2,2,1,2,1,2,1

Running

2,1,1,1,1,2,3

switch_released

flame_out

2,1,1,1,1,2,1

2,1,1,1,1,1,1 2,2,1,2,1,1,1 2,2,1,1,1,2,1

2,1,1,1,1,1,1

2,1,1,2,1,1,1 2,2,1,1,2,2,1 Try_shutdown

2,1,1,1,1,1,2

2,1,1,2,1,1,2 flame_out

switch_released

2,1,1,1,2,2,1

Try_restart

timed_out

switch_pressed

2,1,1,2,1,2,2

2,1,1,2,1,1,3 timed_out

flame_out

2,1,1,2,2,1,3

2,1,1,1,1,2,2 2,1,1,2,1,2,3 2,1,1,1,1,2,1

2,1,1,2,2,1,1 2,1,1,2,2,2,3

2,1,1,2,2,2,1

Alarmed 1,1,1,2,2,1,1

Alarmed

Alarmed 1,1,1,1,2,1,1

1,1,1,1,2,2,1

1,1,1,2,2,2,1

Fig. 5. Procedural Controller Statechart

From the procedural controller statechart we can derive the following high-level controller statechart (Figure 6). timed_out switch_pressed

try_ignite

c_idle 1,1,1,1,1,1,1 flame_detected

2,2,2,1,1,2,2 switch_released

flame_detected

flame_out

flame_out try_shutdown

switch_released c_running

2,1,1,2,1,1,2

switch_ released

2,2,1,2,1,2,1 switch_pressed

try_restart

timed_out

2,1,1,2,1,2,2

flame_out

timed_out

switch_pressed, switch_released, flame_out, flame_detected

alarmed 1,1,1,?,2,?,1

Fig. 6. High-level Controller Statechart

The corresponding B implementation is: IMPLEMENTATION GasBurnerI REFINES GasBurner SEES Bool_TYPE, GB_data IMPORTS Timer, GB_Control, cstate_Vvar(CState) INVARIANT cstate = cstate_Vvar INITIALISATION cstate_STO_VAR(c_idle) OPERATIONS switch_pressed = VAR currstate IN currstate