Formal Verification with Timed Automata and DEVS Models - CiteSeerX

H. Dacharry, N. Giambiasi/Proc. of Argentine Symposium on Software Engineering (2005) 251-265 251

Formal Verification with Timed Automata and DEVS Models: a case study Hern´an P. Dacharry ⋆1 and Norbert Giambiasi2 1 2

E-mail: [email protected] E-mail: [email protected] LSIS - UMR CNRS 6168 University Paul C´ezanne

Abstract. A methodology for the design of control systems that allows the formal verifications of its properties is presented, this is achieved using Timed Automata to describe the desired high-level properties of the control to be designed, and DEVS for modeling the low-level implementation of the control. The formal verification problem consists in proving that the behaviour described by the DEVS model is contained in the one specified by the Timed Automaton, this is achieved through the concept of simulation relations between DEVS models and Timed Automata. Furthermore, using as an example a barrel filling system, the advantages and adequacy of this methodology are shown. A full description of the system is presented, as well as a safety property that the control to be implemented should meet, furthermore the implementation of the control as a DEVS model is given, and it is formally verified that it conforms the safety requirement using the methodology proposed.

1

Introduction

The design of discrete event control systems is a process that needs dedicated formalisms and adapted tools. These formalisms may differ considerably in their syntax, semantics, and representation. However, the basic concepts of discrete event models can be found in all these different formalisms. First of all, the input-output variables have discrete event trajectories and the state variables have piecewise constant trajectories. Certain formalisms impose explicit states (named), other ones have implicit states (states defined by a set of state variables). The state set can be finite or infinite according to the formalism chosen and the system to be considered. Finally, the time can be represented implicitly (untimed formalisms) or by actual values (timed formalisms). Considering the continuous growth in functionality and importance of control systems, it becomes relevant the use of formal methods as a complement of simulation to improve the quality of the design process. Some formalism seems better adapted in the first phases of the design process whereas others aim towards low-level models with a more precise representation ⋆

Supported by STMicroelectronics - 13106 Rousset - France

252 H. Dacharry, N. Giambiasi/Proc. of Argentine Symposium on Software Engineering (2005) 251-265

of the system dynamics. For example, the DEVS [1–3] formalism is well adapted to represent timed behavior of real systems. But DEVS is not well suited to highlevel specifications of discrete event control systems. This is due to the fact that in high-level specifications, the corresponding models can be nondeterministic and the occurrence times of events may not be defined precisely. DEVS defines a method of abstraction of dynamic systems that allows building timed discrete event simulation models (deterministic models) with a good accuracy. DEVS is a symbolic specification of system semantics and there is only one way to execute a DEVS model. DEVS models are deterministic and this can pose an inconvenience for high-level specifications of real-time systems. Indeed, DEVS is well adapted to build models at low levels of abstraction. The conventional procedure in the design of control systems within the DEVS community consists in building the model of the control in addition to the model of the system to be controlled, and validating its behaviour through the simulation of the coupled model. On the other hand, the Timed Automata formalisms, [4–7] among others, are oriented to high-level specifications of real-time systems. These formalisms are appropriate to qualitatively describe models by way of expressing the timed constraints between events. The standard techniques for checking Timed Automata models encompass formal methods and model-checking tools. We propose linking the DEVS and Timed Automata worlds, in order to extend the current design methodology for control systems, using DEVS to specify the low-level behaviour of the control being designed, and Timed Automata to specify the high-level behaviour or properties that the control should meet. In order to verify that the control meets the specification the concept of simulation relations between DEVS models and Timed Automata [8] is introduced. This concept is based in an analogous approach generally found in the Timed Automata theory where it is used for formal reasoning about the behaviour of Timed Automata. Using this approach, it is possible to augment the design quality, increasing at the same time the understanding of a system by counting on with validation and verification techniques consisting of not only simulation, but as well formal methods and model-checking. The rest of the paper is structured as follows. In the next section we recall the basic notions of the DEVS and Timed Automata formalisms. Then in the same section we give the principal definitions and results over simulation relations between DEVS models and Timed Automata (properly defined in [8]). Subsequently in the following section we show the benefits of the methodology using it for the design of the control of a barrel filling system. Finally we discuss the implications of the methodology proposed.


2

Preliminaries

In this section we briefly recall the basic concepts of Timed Automata theory, and the DEVS formalism, that constitutes the grounds for the design methodology proposed. Finally for closing this section, we recall the concepts of simulation relations between DEVS models and Timed Automata and successively the main formal results introduced in [8]. This constitutes the theoretical base for the design methodology proposed in this article. 2.1

Timed Automata

In the literature [4–7] many different definitions of Timed Automata can be found with varying expressive power and properties. Although the definition given in [4] (clock timed automata) is the most frequently used, in the following when we mention Timed Automata we will be making reference to the class of Timed Automata introduced in [6] (timed transition systems). This one corresponds to a general class of Timed Automata in the sense that other classes of Timed Automata can be expressed in terms of timed transition systems. A timed automaton, A, then consists of: SA , a set of states, init(A), a set of initial states, EA , a set of discrete events, x DA , a set of discrete steps or transitions, noted s → s′ , asserting that “from state s the system can instantaneously move to state s′ via the occurrence of the event x, and, t TA , a set of time-passage steps s → s′ asserting that “from state s the system can move to state s′ during a positive amount of time t in which no discrete events occurs”. A timed automaton is assumed to satisfy two axioms. t′

t

t+t′

S1 If s → s′ and s′ → s′′ , then s → s′′ . t S2 Each time-passage step, s → s′ , has a trajectory. Where a trajectory describes the state changes that can occur during timepassage steps, if I is any closed interval of ℜ+ 0 beginning with 0 (we are only interested in finite behavior), an I-trajectory is defined as a function, υ : I → SA such that: t′ −t

υ(t) → υ(t′ ) ∀ t, t′ ∈ I | t < t′ The behavior of a timed automaton is given by the set of all possible executions it defines, and its visible external behavior is defined by the traces of those executions.

254 H. Dacharry, N. Giambiasi/Proc. of Argentine Symposium on Software Engineering (2005) 251-265

We will restrict our attention to finite executions and finite traces implied by a timed automaton, since our objective is to compare the behavior of a lowlevel view of a real system (the DEVS model) against a high-level specification or property. Moreover, we will firstly concentrate only in safety properties (not considering liveness properties), and as a consequence, executions, runs, or simulations of infinite time are not relevant when focusing in real systems. We now introduce the definition of executions and the corresponding traces of a timed automaton. An execution fragment of a timed automaton, A, is a finite alternating sequence Υ = υ0 x1 υ1 x2 υ2 . . . xn υn , where: 1. Each υi is a trajectory and each xi ∈ EA is an event. xi+1 2. If υi is not the last trajectory in Υ then υi (sup(Ii )) → υi+1 (0) , where Ii denote the domain of the trajectory υi . Suppose Υ = υ0 x1 υ1 x2 υ2 . . . xn υn is an execution fragment of a timed automaton A. Then for each xi of Υ we define the time of occurrence ti to be P (sup(I j )). So we define the trace associated with the execution frag0≤j > > > (ErrorS, tl, 0) > > > > (Stop, tl, 0) > > > > > > > (ErrorS, tl, 0) > > > > >(Close, tl − Vfill(tl) ∗ e, 0) > > > > (Close, tl − Vfill(tl) ∗ e, 0) > > : (Close, tl − Vfill(tl) ∗ e, 0)

If ph = Error If ph = Filled If ph = Conveyor1 If ph = Conveyor2 ph = BarrelArrived If ph = BarrelReady If ph = Filling1 If ph = Filling2 If ph = Filling3

δext (ph, tl, σ, e, Barrelfull ) = 8 (Error, tl, ∞) If ph = Error > > > > (ErrorS, tl, 0) If ph = Filled > > > > >(Stop, tl, 0) If ph = Conveyor1 > > > > > (Stop, tl, 0) If ph = Conveyor2 > > (ErrorS, tl, 0) If ph = BarrelReady > > > > (Close, tl − Vfill(tl) ∗ e, 0) If ph = Filling1 > > > > >(Filling3, tl − Vfill(tl) ∗ e, σdel ) > > > > If ph = Filling2 > > : (Close, tl − Vfill(tl) ∗ e, 0) If ph = Filling3

δext (ph, tl, σ, e, Tankrefilled ) = (ph, Tfull , σ − e)

262 H. Dacharry, N. Giambiasi/Proc. of Argentine Symposium on Software Engineering (2005) 251-265 δint (ph, tl, σ) = 8 > >(Close, 0, 0) > > If ph ∈ {Filling1, Filling2, Filling3} > > > > > and tl − Vfill(tl) ∗ σ ≤ Vempty > > > > > (Filling2, tl − Vfill(tl) ∗ σ, > > > > min(tl − Vfill(tl) ∗ σ, 2 ∗ Btol )/ Vfill(tl) − σdel ) > > > > > If ph = Filling1 > > > > (Close, tl − Vfill(tl) ∗ σ, 0) If ph = Filling2 > > > > > > > (Conveyor2, tl, Bdmax /Cvel ) If ph = Conveyor1 > > > > >(Stop, tl, 0) If ph = Conveyor2 > > > > (BarrelReady, tl, σdel ) If ph = BarrelArrived > > > > > >(Filling1, tl, min(tl, Bcap − Btol )/ Vfill(tl)) > > > If ph = BarrelReady > > > > > (ErrorS, tl, 0) If ph = Close > > > > If ph = Stop >(ErrorS, tl, 0) > : (Error, tl, ∞) If ph = ErrorS

λ(ph, tl, σ) = 8 Motorstart > > > > Λ > > > >Λ > > > > > >Motorstop > > > > Valveopen > > > > >Λ > > Valveclose If ph = Filling3 > > > > Valveclose If ph = Close > > > > > Motorstop If ph = Stop > > > > Errorev If ph = ErrorS > > > > > Λ If tl − Vfill(tl) ∗ σ ≤ Vempty > > > > > and ph ∈ {Filling1, Filling2, > : Filling3}

ta(ph, tl, σ) = σ

In the previous definitions, σdel is a parameter of the control modeling the time that takes to send the messages (events). It can be replaced by 0, meaning that there is not such delay. In a similar way, Vempty is a constant representing the minimum level of the reservoir tank. 3.5

Refinement between the control and the safety requirement

From the definition of the DEVS model of the control in the last section, C, it can be speculated that it complies with the safety requirement given in the Sect. 3.2 (the timed automaton R). Nevertheless in safety critical applications this level of confidence is not enough and a formal, more rigorous, proof of this property is desired. Exploiting the technique introduced [8], it is possible to formally proof that the control model meets the safety requirement. That is to say, the behaviour implied by the DEVS model of the control is included in the behaviour implied by the semantics of the timed automaton corresponding to the requirement. For proving this it suffices to proof the existence of a simulation relation between the DEVS model and the timed automaton. Given the definitions of the DEVS model of the control, and the timed automaton representing the formal requirement, we can define a relation f ⊆ Q C × SR where QC = {(s, e)|s ∈ SC , 0 ≤ e ≤ ta(s)}


is the set of total states of the DEVS model of the control, C, and SR the set of states of the timed automaton R. Given (s, e) ∈ QC we define the relation f as: ˘ ¯ f = (((Filling1, tl, σ), e), {(Valve, x)|x ≤ σ}) ∪ ˘ ¯ (((Filling2, tl, σ), e), {(Valve, x)|x ≤ σ}) ∪ ˘ ¯ (((Filling3, tl, σ), e), {(Valve, x)|x ≤ σ}) ∪ ˘ ¯ (((Close, tl, σ), e), {(Valve, x)|x ≤ σ}) ∪ ˘ ¯ (((Filled, tl, σ), e), {(Stopped, x)|x ≤ σ}) ∪ ˘ ¯ (((BarrelReady, tl, σ), e), {(Stopped, x)|x ≤ σ}) ∪ ˘ ¯ (((Stop, tl, σ), e), {(Conveyor, x)|x ≤ σ}) ∪ ˘ ¯ (((Conveyor1, tl, σ), e), {(Conveyor, x)|x ≤ σ}) ∪ ˘ ¯ (((Conveyor2, tl, σ), e), {(Conveyor, x)|x ≤ σ}) ∪ ˘ ¯ (((BarrelArrived, tl, σ), e), {(Conveyor, x)|x ≤ σ}) ∪ ˘ ¯ (((ErrorS, tl, σ), e), {(Stopped, x)|x ≤ σ}) ∪ ˘ ¯¯ (((Error, tl, σ), e), {(Error, x)|x ≤ σ})

This relation was constructed following the definition of forward simulation relations [8]. input event transitions For every internal transition of C, from a state s to another one s′ , with e = ta(s) and generating the output event λ(s), and for every state of R, u, contained in f [s, e], there exists another state, u′ , in f [s′ , 0] such that there is a transition with the label λ(s) from u to u′ . output event transition Similarly for every external transition of C, corresponding to an event x, from a state s to another state s′ , with e ≤ ta(s) the time since the last transition, and for every state u ∈ f [s, e], there exists another state, u′ ∈ f [s′ , 0], such that there is a transition with the label x from u to u′ . time passage steps Finally for every state s, of C, such that ta(s) > 0, and for every state u ∈ f [s, e], where e < ta(s), there exists another state, u′ ∈ f [s, e′ ], where e < e′ < ta(s), such that there is a time passage step from u to u′ labelled e′ − e. In the representation of the timed automata with clock variables this condition is equivalent to saying that all the constraints of the outgoing transitions are satisfied by the valuation obtained by adding e′ − e to all the clock variables. Since the only temporal constraint required by the timed automaton R is the constraint on the phase Valve, it is only necessary to check that the last of the three conditions is met in the relevant phases. It is easy to find superior limits of the time advance functions of the relevant phases of the DEVS model, and show that the addition of these limits is less than the constraint given by the requirement, tv . ta(Filling1, tl, σ) ≤ min(tl, Bcap − Btol )/ Vfill(tl) ≤ (Bcap − Btol )/Vmin

264 H. Dacharry, N. Giambiasi/Proc. of Argentine Symposium on Software Engineering (2005) 251-265 ta(Filling2, tl, σ) ≤ min(tl, 2 ∗ Btol )/ Vfill(tl) − σdel ≤ 2 ∗ Btol /Vmin − σdel ta(Filling3, tl, σ) ≤ σdel ta(Close, tl, σ) ≤ 0

And, in consequence, ta(Filling1, tl, σ)+ta(Filling2, tl, σ)+ta(Filling3, tl, σ)+ta(Close, tl, σ) ≤ (Bcap −Btol )/Vmin +2∗Btol /Vmin −σdel +σdel +0 ≤ (Bcap +Btol )/Vmin = tv As a result, it has been possible to state a formal proof of compliance, as required, but without the need of a very extended mathematical reasoning.

4

Conclusion

The extension to the methodology for the design of control systems proposed in this paper consists of three steps. – System requirements specification, described in terms of Timed Automata. – Design of the control implementation, using a DEVS model to express it. – Formal verification that the implementation conforms the requirements specification, finding a refinement between the implementation and the specification. This extended methodology allows the validation of the control implementation by simulation as commonly done in the design of control systems using the DEVS formalism. And also gives place to the verification of high-level properties of the control implementation. This process has feedback loops to revise the specification and correct design mistakes. Using this methodology in the Sect. 3 the control for a barrel filling system was designed, and it was proved, Sect. 3.5, that its behaviour conforms the safety requirement specified in the description of the system. As can be observed from the previous section, the proof of compliance given is not extremely large or difficult for atomic models of a certain complexity, suggesting that this technique is adequate for unit based verification (verification of the basic components of a system). Several results from Timed Automata theory can be directly exploited in the problem of automatic verification for DEVS models and Timed Automata. The automation of the formal verification of compliance is restricted by the unbounded state space of the models. The most important and discouraging result is that for the general case the problem of automatically verifying the compliance between a DEVS model and a timed automaton is known to be undecidable [4–7]. In our setting, this implies checking that the set of traces associated to a DEVS model is included in the set of traces accepted by a timed automaton. This problem becomes decidable when the timed automata are restricted to the class of clock timed automata that can be described, as in [4], and furthermore the timed automaton giving the formal requirement is restricted to use at most one clock [9].


In general it is not possible to translate a general DEVS model to a clock timed automaton as presented in [4], so it is not possible to construct a completely automatic procedure for proving that an arbitrary DEVS model meets a safety requirement given by a timed automaton. Nevertheless, if one can contruct a refinement between the DEVS model, and the timed automaton specification, then any results obtained by exploiting existing tools for model-checking timed automata can be extrapolated to the DEVS model (except for liveness properties which we did not take into account). One possible direction for future work within this methodology is exploiting the information given by the high-level specification of the control to generate test sequences for the DEVS model implementing the control in order to validate it.

References 1. Giambiasi, N., Escude, B., Ghosh, S.: Gdevs : a generalized discrete event specification for accurate modelling of dynamic systems. Trans. of S.C.S.I. 17-3 (2000) 120–134 2. Zeigler, B., Praehofer, H., Kim, T.G.: Theory of modelling and simulation, 2d edition. Academic Press, London (2000) 3. Zeigler, B.P.: Multifaceted Modelling and Discrete Event Simulation. Academic Press, London (1984) 4. Alur, R., Dill, D.L.: A theory of timed automata. Theoretical Computer Science 126 (1994) 183–235 5. Alur, R., Fix, L., Henzinger, T.A.: Event-clock automata: a determinizable class of timed automata. Theoretical Computer Science 211 (1999) 253–273 6. Lynch, N.A., Vaandrager, F.W.: Forward and backward simulations – part II: Timing-based systems. Technical report, Laboratory for Computer Science, Massachusetts Institute of Technology, Cambridge, MA, USA (1995) 7. Merritt, M., Modugno, F., Tuttle, M.R.: Time–constrained automata. In Baeten, J.C.M., Groote, J.F., eds.: Proceedings on Concurrency Theory (CONCUR ’91). Volume 527 of LNCS., Berlin, Germany, Springer (1991) 408–423 8. Dacharry, H., Giambiasi, N.: From timed automata to devs models: Formal verification. In: Proceedings of SpringSim’05 (to appear on), SCS - The Society for Modeling and Simulation International (2005) 9. Ouaknine, J., Worrell, J.: On the language inclusion problem for timed automata: Closing a decidability gap. In: Proceedings of the eightteenth Annual IEEE Syposium on Logic in Computer Science (LICS-04), Los Alamitos, CA, IEEE Computer Society (2004)