A CSP Model for Hybrid Automata

. This contribution aims to combine hybrid automata with CSP establishing a connection between the elements of hybrid automata and CSP processes using an approach for the decomposition of hybrid systems. As a result we obtain a transformation from hybrid automata into CSP processes, written in Hoare-CSP in the untimed parts and in real-time CSP or HCSP in the timed parts. These processes provide a basis to build up analysis mechanisms like animation and testing, converging in tool support for the speci(cid:12)cation, transformation, animation, implementation and test of hybrid systems


Introduction
The Bremen Institute for Safe Systems BISS aims to develop safe systems using formal methods and provides feasible system development support which i s also practicable in industrial applications.One focus in our research i s "automated test support for reactive systems" which includes generation, execution, monitoring and evaluation of test cases, as introduced by P eleska and Siegel in 15 .This approach i s based on CSP by Hoare 13 and on Hennessy's testing methodology 10 .Currently available tools which deal with CSP speci cations only provide a textual representation to describe systems.Here, it would be a useful improvement t o h a ve a graphical representation language for the specication process.
Hybrid systems seem to be appropriate to be described in a graphical way.Here, we h a ve continuous components as well as discrete ones.In particular the continuous behaviour can be better speci ed and investigated with the help of graphical elements, but we w on't lose the bene ts of the CSP based test automation approach 15 .The solution arises by the combination of test automation for reactive systems based on CSP with the approach o f h ybrid automata cf. 1 .The model of automata is a w ell known and wide spread one, which is in our case very suitable, especially with regard to the presentation of speci cations to industrial partners which might not be familiar with other more abstract speci cation models.
In this paper we rst introduce hybrid systems and explain an approach t o decompose them into appropriate components.Then hybrid automata are introduced.Following the decompositional approach for hybrid systems, we develop a CSP model for hybrid automata, which is used to realize a work bench which includes existing tools like HyTech 12 , FDR 8 and VVT-RT 15 to provide speci cation, animation, debugging and testing facilities for hybrid systems.

Hybrid Systems | A Decompositional Approach
Hybrid Systems consist of discrete and continuous components.Usually, they are modelled as reactive systems, i. e. digital controllers interact with a continuously changing environment.Several variables can be observed in a hybrid system representing e. g. temperature, light intensity or noise level.This leads us to several questions concerning hybrid systems, e. 3rd Northern Formal Methods Workshop, 1998 One way to nd answers to these questions is to analyse the hybrid system and separate the parts relating to certain questions.An appropriate approach to achieve this aim is the decomposition of hybrid systems as shown in gure 1.
Following this, information about variables can be found in a separate module.In order to observe the evolution of variables this particular module has to beinvestigated.The external communication between the components of a hybrid system builds another block.Further, every component o f a h ybrid system consists of an untimed, timed and hybrid part.
In the hybrid part one nds the functions which c hange the variables' values continuously over a time interval.Sometimes one would like to distinguish the hybrid behaviour from the so-called timed behaviour.In this case it is useful to locate the discrete change of variables within the so-called timed part.Often, it is more useful to include the timed behaviour into the hybrid behaviour, so one can omit the dashed region of g. 1.A little example illustrating this aspect is the modelling of a timer.Usually, it is modelled to be discrete in time and value.Initialized with a value, e. g. 5, it is decreased stepwise by one until its value is zero or an interrupt, perhaps a timer reset, occurs.But it is also convenient t o consider it as follows: again it is set with a value, then it is continuously changed by the function _ t=-1 as long as the condition t 0 holds or it is interrupted.At last, we get an untimed system which is solely focused on the description of actions within the system and which is connected with the hybrid part and with the timed part via internal communication event synchronization.
Because of this strict separation it is possible to use model checking in the untimed part with FDR.This allows also more comfortable testing from the behavioural view, because in the untimed part pure access to the events actions of the system is possible, which cause the hybrid behaviour of the system by synchronization.Further, the decompositional approach can be used to ensure that an untimed part which has been checked beforehand can be integrated into the overall system without losing the validity of the results obtained, paying attention to side conditions related to the decomposition.This proposal also leads to a decompositional implementation concept which allows easy approaches to animation and monitoring mechanisms.Finally, the components of a decomposed hybrid system could be included into a library for their reuse for another hybrid development.These components should be used like templates that have only to be lled, which means the stepwise extension of a system, starting with the untimed system, modelling the hybrid part, declaring the variables and de ning the external communication.
3rd Northern Formal Methods Workshop, 1998 3 Hybrid Automata Hybrid Systems can be modelled as the parallel composition of hybrid automata representing the hybrid systems' components 1 .These automata model the continuous activities of analog variables such as temperature, time, distance, etc. as well as discrete events such as interrupts or output signals.Communication between automata is modelled through event synchronization and shared variables.
A h ybrid automaton consists of vertices connected by edges.A vertex is called location representing control modes where variables can be changed continuously.Edges are also called transitions which represent discrete events.

Fig. 2. Thermostat Automaton.
A small example is the one of an thermostat automaton see g. 2 2 .The hybrid system includes only one variable temp representing the temperature and one hybrid automaton called thermostat.It starts at location init and takes the outgoing transition immediately because of its jump condition asap assigning 20 to temp.This leads the automaton to location off where temperature falls according to the ow rate condition dtemp=-1.Here, the automaton may g o o n when the temperature falls below 17 degrees and it must go on at the latest when it falls to 15 degrees.In control mode on according to the invariant condition temp =25 temperature rises till 25 degrees at the most.Its outgoing transition to off may be taken when temperature has reached more than 23 degrees.
Variables are real-valued and shared.In every state of the automaton there exists a valuation for each v ariable mapping it to its value.
Locations are used to model control modes.A state of an automaton consists of a location and a valuation.A region is a set of states.Usually, a location has a name, an invariant condition and a ow rate condition.The automaton control may reside in a location only while its invariant condition is true.The rate condition de nes the rates of change of the variables' values.In the original model of hybrid automata the initial location is denoted by a small incoming arrow labelled with an initial condition.We omit it by de ning the initial location as the vertex with no incoming edges.A state is called admissible when its valuation satis es the location's invariant condition.
Transitions model discrete events and connect locations.Each transition is labelled with an update set and with a jump condition.It is enabled if its jump condition is true and if it reaches an admissible state after it took place, i. e. the variables in the update set have c hanged their values.Transitions may b e assigned the urgency ag asap 3 .As soon as they are enabled, these transitions must take place.Finally, each transition can be given a synchronization label.These labels are used to de ne the parallel composition of hybrid automata and must be taken simultaneously by t wo automata sharing the same synchronization label.

A CSP Model for Hybrid Automata
After the introduction of hybrid automata, we would like to present a CSP model that corresponds to the approach of the hybrid system's decomposition.The general structure of such a CSP process which models a hybrid automaton is shown in gure 3. Here, one can recognize the separation of the hybrid automata, the external communication between them and the global variables.The CSP model for a hybrid automaton includes several processes which can be expressed in di erent kinds of CSP.First, we h a ve the processes ELEMENTS and NEXT modelled with untimed CSP 13 .They include the vertices and edges with their connections to model the structure of the automaton and to de ne the causal behaviour of the automaton's components.Further, some processes can be written in hybrid CSP 6 .They are used to access and to change the continuous variables.To observe the continuous change of variables a certain granularity i s i n troduced by a timer process, which can also be modelled with real-time CSP 7 instead of hybrid CSP.All components are connected by c hannels, which are used in CSP to model communication between processes.In the following we like to describe each process and its interaction with the others more detailed.According to the hybrid system's decomposition, rst, we devide the composition of hybrid automata into several pieces: the global variables, the hybrid automata and the external communication.Then each h ybrid automaton will be translated into CSP using the CSP model.The resulting CSP process includes elements from untimed, hybrid and real-time CSP, but only the processes modelled in untimed CSP are taken to generate a transition graph with the FDR tool.All other parts have to be implemented otherwise, to realise animation of the whole hybrid system.Nevertheless the other parts are described with CSP4 in the following, too, but we don't try to feed FDR with them because on the one hand to avoid state-explosion and on the other hand the tool cannot cope with speci cations including time.

Variables and External Communication
A suitable way of modelling variables in CSP is the following.The process VAR has two parameters varname and value.A possible initialization might be VARx,1, v ariable x has the initial value one.Further, one can set or get values using the channels write and read, which are uni-directional.If a message value arrives for variable x over channel write, then x is set to newValue.Otherwise, if another process requests the current v alue of x, then VAR passes it over the read channel.Here, we h a ve the advantage that the two processes P1, P2 are only interleaved, this means, that we can now model them independently from the others.In the end this allows us to get a small transition graph for each h ybrid automaton instead of a very large one for all.
Finally, the recomposition of all components is the following parallel composition, where COMMUNICATION is the process containing the interleaving of all COMM processes appearing in the system and sync_1,...,sync_m are the belonging synchronization events.HA_1, ..., HA_n are the hybrid system's components modelled with hybrid automata.The timer process used in the LOCATION process is a nice example where one can take either hybrid CSP or real-time CSP to model it.In this case, the real-time modelling seems to be more compact.In the hybrid modelling the local timer variable t is set to zero at the beginning.Then the value is continuously increased till the condition t=1 becomes true and the timer elapses.TIMER = startTimer ; t:=0 ; _ t = 1 !t=1 ; timerElapsed ; TIMER Transitions are used to model discrete actions, like the discrete assignment of values to variables or like commands modelled through synchronization.The TRANSITION process starts with the doTrans.ievent.Then it also reads the variables' values which are necessary for the following computation.Further, a synchronization event may precede or succeed the assignment part, but it is optional.Finally, the doneTrans.ievent occurs.
3rd Northern Formal Methods Workshop, 1998 TRANSITION_i = doTrans.i; readVariables ; synchronization-event ; x 1 := f 1 ; :::; x n := f n ; synchronization-event ; writeVariables ; doneTrans.i; TRANSITION_i Additionally, w e need processes to evaluate the conditions in locations and transitions.This is done in the CONDITION process.It is activated by the event evalCond.i.Then all variable values are read which are needed in the condition cond_i.According to the evaluation of the condition the events evalTrue.ior evalFalse.itake place.CONDITION_i = evalCond.i; readVariables ; cond i !evalTrue.i; CONDITION_i ; notcond i !evalFalse.i; CONDITION_i The untimed parts model the structure of the automaton and the causal behaviour of the components in general.One part of the idea is to build a process E for every element of the automaton identi ed by an identi cation numberi and classi ed as edge e o r a s v ertex v.The process E can be started by synchronization over start.i.In case of a vertex c==v the continuous change of variables takes place by executing the corresponding LOCATION process by synchronization over doLoc.iand doneLoc.i; in the case of an edge the discrete assignments of an edge are done using the TRANSITION process by synchronization over doTrans.iand doneTrans.i.
During the execution of the automaton it has to be decided how long the automaton stays at a vertex and which outgoing edge shall be taken leaving the vertex or having executed an edge which vertex is the destination where the edge points at and is it allowed to enter the vertex.These decisions are made in process N which is started by E synchronizing over startNext.i.Then N uses the CHOOSE process to get a list of the automaton elements which can be chosen in the next step to continue the automaton's execution.For every automaton element there exists a process N containing the elements which are reachable from it considering the automaton structure.Usually, for an edge this is the destination vertex and for a vertex it is the vertex itself plus all its outgoing edges.
3rd Northern Formal Methods Workshop, 1998 N i, ol = startNext.i-CHOOSE i, ol, ; N i, ol CHOOSE i, ol, cl = if nullol then if nullcl then stopAutomaton.i-STOP else |~| x : setcl @ start.x-SKIP else evalCond.headol-evalTrue.headol-CHOOSE i, tailol, cl^ headol evalFalse.headol-CHOOSE i, tailol, cl Now, it can be detected by the use of the CONDITION process, started by evalCond.i,which o f the elements are enabled at the current state.The process CONDITION evaluates the condition of a certain automaton element and returns the result by synchronization over evalTrue.ior evalFalse.i.In the case of true the element is added to the list of the next possible events cl otherwise not.Finally, it is decided by non-deterministic choice |~| which element is taken from cl to continue the automaton's execution and it is started by start.i.When cl is empty the automaton is not able to continue and the event stopAutomaton.iappears.The composition of the E and N processes shall be explained by the above example.The automaton consists of two v ertices v0,v1 and three edges e0,e1,e2 declared in ve E processes which are interleaved in a process ELEMENTS.V ertex v0 has two outgoing edges e0,e1, v ertex v1 has e2.The edges e0,e1 lead to v1, e2 leads back t o v0.These relations are de ned in the N processes which are interleaved in a process NEXT.Additionally, an INIT process is included in the interleaving of NEXT to ensure that the automaton begins at vertex v0.Finally, the processes ELEMENTS and NEXT are composed in parallel in AUTOMATON and they are synchronized over start and startNext.

A Development Environment for Hybrid Systems
The decompositional approach for hybrid systems and the CSP model for hybrid automata have been used for several parts of HySC -a development e n vironment for hybrid systems, which allows us to specify, transform, animate, implement and test hybrid systems cf. 3 .The implementation combines tools like HyTech cf. 12 | a symbolic model checker for hybrid systems | FDR 1.42 cf. 8 for the untimed CSP parts and MATLAB cf. 14 with its mathematical support.Further, it includes also a graphical user interface with a graph editor both written in Tcl Tk.HySC tries to include the ideas of well known programming work benches and debuggers, still used in the programmer's life.In this section we focus on the speci cation and animation part of HySC, showing the usage of the tool with little examples.The speci cation process starts by creating a hybrid system with the graph editor g. 4. Objects like v ertices, edges, etc. can be drawn and annotated with labels.In the main window one can de ne the parallel composition of several hybrid automata.Here, also the variables of the system have to be declared.Then, every automaton has to be modelled in its own window.
One bene t of HySC is the graphical representation of hybrid systems, additionally, one gains another output -a textual representation in a so-called ha-le 3rd Northern Formal Methods Workshop, 1998 see g. 5.This ha-le is needed as input for halib, a C-library which contains functions for the analysis of hybrid automata.First, the text of ha-le is parsed, to extract informations like: vertex and edge parameters, occuring variables, conditions and functions.Secondly, these informations are used to produce a so-called csp-le, which includes the untimed CSP representation of the speci ed system according to the above i n troduced CSP model.The FDR tool and another C-library, vvtamlib, produce a transition graph TG from the csp-le and o er functions for graph navigation, which is essential for the animation part.In the end, the libraries halib and vvtamlib allow us to: 1. load a hybrid system speci ed as the parallel composition of hybrid automata, 2. translate it into a CSP process, 3. generate the transition graph of this process and 4. execute the hybrid system by traversing the transition graph of the underlying CSP model.Di erent kinds of animation can be done in HySC to execute the speci ed hybrid system: animation for all or for only several components and graphical or event based animation.The amount of hybrid system's components can increase very quickly.So, the animation of the whole system might not be observable in an appropriate way.Therefore, the animation of only one or little more components should be also possible.In this case the components which are not animated have t o be compensated by additional interaction of the user.
In the event based animation session, events from the transition graph generated from the system can be chosen from the user via a dialog window g. 6, where the left list box contains the next possible events and a trace of all chosen events is listed in the right list box.
The graphical animation is also based on the transition graph.But here, every event is related to an element of an automaton.So, instead of o ering an event to the user, the related automaton element is highlighted in green color.
3rd Northern Formal Methods Workshop, 1998 The graphical trace is realized by highlighting the executed elements in blue.Additionally, a separate textual trace log might be helpful, too.During the animation execution of the hybrid system, one is able to observe the values of selected variables in the variable display.When a variable is continuously changed, MATLAB is started and the value change is drawn in a coordinate system.Here, MATLAB is very useful, because curves can be drawn without di culty g. 7 and the conditions of vertices and edges can be evaluated with this tool, too.In this paper we presented a combination of a decompositional approach for hybrid systems with hybrid automata and CSP to provide CSP-based animation for hybrid systems modelled with hybrid automata.The main contribution of this proposal is the development of a CSP model for hybrid automata.We h a ve show n a w ay h o w to transform a system described by the parallel composition of hybrid automata into a CSP process which can then be used for the system's animation, traversing the transition graph of the process.These ideas nally led to the implementation of HySC -a development e n vironment for hybrid systems -with speci cation and animation facilities.
The next goal is to support test automation for hybrid systems.In this case again the CSP model can be used as basis for deriving test cases from the CSP process which represents a hybrid system.These test cases might then be applied to an implementation which has been derived from the speci ed hybrid system.
Another topic of future work is the modelling of hybrid systems in general.Usually, the controller environment C E-model described in g. 8 is often used.

Critical
Variable Actuator Controller Fig. 8.The Controller Environment Model.
Considering the example of a heat control system the C E-model can be applied as follows.Temperature is the critical variable which is measured by the sensor.According to the measured value the controller uses the actuator, e. g. a heating, to increase the temperature.The aim is now to identify more components which are also that important to be modelled in a separate part.One point might be to separate the critical variables strictly from the endangered plants.This could be an advantage when many variables and or many plants are involved in the system, because then the change of the variables' values can be better modelled and observed.
Finally, the translation of hybrid automata into CSP can be used to integrate speci cations described with hybrid automata into a written CSP speci cation.
Locations are used to model the continuous change of a variable.The process is started by synchronization over doLoc.i,then it gets the values from the variables which are used in the functions f_1,...,f_n.With the synchronization event startTimer the timer process is started.Further, the continuous change of the variables goes on as long as the timer is not elapsed.The timer induces a certain rate granularity to the continuous change process.Having received the timerElapsed event the new variable values are sent to the VARIABLES process.Then the end of the location process is denoted by doneLoc.i.