Duration Calculus with Iteration and Software Graph in an Embedded Control Application

Duration Calculus with Iteration and Software Graph in an Embedded Control Application Pham Tran Nhu , Nguyen Van Truong Institute of Information Technology, P.O Box A3, 18 Hoang Quoc Viet, Hanoi, Vietnam ptnhu@ncst.ioit.ac.vn Thai Nguyen University of Education, Luong Ngoc Quyen Road, Thai Nguyen, VietNam nvtruongtn@hn.vnn.vn Abstract We present a syntactical approach given in a formal design technique for combining Duration Calculus with Iteration (DC*) and software graph (sgraph) The technique is used for designing real-time embedded systems Integrating these two formal methods to work together in the spirit of hardware/software co-design may allow co-operating their strengths, while alleviating some of their weaknesses Keywords: DC*, s-graph, formal methods Introduction Each of the software methods has typical advantages and disadvantages For example, automatic verification methods are desirable since they are exhaustive and require minimal human intervention; however, the effectiveness of such methods decreases rapidly with the size of the checked systems Integrating formal methods to work together may allow combining their strengths, while alleviating some of their weaknesses [5] Duration Calculus (DC), a logic based on Interval Temporal Logic, is powerful enough for specifying and reasoning about the behavior of real-time systems in continuous time model It has been used successfully in many case studies as specification language Duration Calculus with Iteration (DC*) is an extension of DC with the iteration operator to play the role of interface between DC and timed automata model However, the design technique using DC* can be solved successfully only under some assumptions about the behavior of the environments and the relationship between continuous variables and discrete ones This idea leads to the natural choice of combining DC* with other methods to evaluate and estimate exactly environment and system restrictions In this paper, we present a syntactical approach for combining DC* and s-graph from a formal specification of the requirements of real-time systems The main idea is to model the discretization at the state level by introducing the discrete states approximating the continuous ones, and then derive a specification of the system over discrete states Moreover, the approach provides a logical framework that can handle effectively consumptions about the time latency in designing steps, which were not solved in many case studies using DC*, see e.g [1, 2, 13] The remaining of the paper is organized as follows In Section we give a brief summary of DC* and s-graph The combination technique is presented in Section Section concludes the paper DC* and S - Graph It is not the purpose of this paper to give a complete description of these formalisms but just a simple introduction to make easier the understanding of the following Readers may find more details in [1, 12] about DC* and in [7] about s-graph 2.1 DC* A language for DC* is built starting from the following sets of symbols: a set of constant symbols {a, b, c, }, a set of individual variables {x, y, z, }, a set of state variables {P, Q, }, a set of temporal variables {u, v, }, a set of function symbols {f, g, }, a set of relation symbols {R, U, }, and a set of temporal propositional letters {A, B, } A DC* language definition is essentially that of the sets of state expressions S, terms t and formulae of the language These sets can be defined by the following BNFs: S ≙0PSS S t ≙cxu∫ Sf(t, , t) ≙AR (t, , t)( )(◠)(*)x + A state variable P is interpreted as a function I(P): IR  {0,1} (a state) I(P)(t) = means that state P is present at time t, and I(P)(t) = means that state P is not present at time t We assume that a state has finite variability in any finite time interval A state expression is interpreted as a function, which is defined by the interpretations for the state variables and boolean operators For an arbitrary state expression S , its duration is denoted by ∫ S Given an interpretation I of the state variables and an interval, duration ∫ S is interpreted as the accumulated length of time within the interval at which S is present So for any interval [t, t’], the interpretation I(∫ S)([t, t’]) is defined as t'  t I(S)(t)dt A formula is satisfied by an interpretation in an interval [t, t’] when it evaluates to true for that interpretation over that time interval This is written as I,[t, t'] ⊨ Given an interpretation I, a formula ◠’ is true for [t, t’’] if there exists a t’ such that t t’t’’ and and ’ are true for [t, t’] and [t’, t’’], respectively We consider the following abbreviations: ≙0, ≙∫ 1,  S≙(∫ S= ) (> 0), ◊≙(true◠◠true), □≙◊, k ≙ ◠ ◠  (k times, for k > 0) The proof system for DC* consists of a complete Hilbert-style proof system for first order logic (cf e.g [8]), axioms and rules for interval logic, Duration Calculus axioms and rules and axioms about iteration (cf e.g [12]) The proof system of DC* is complete for sentences where iteration is allowed only for a restricted class of formulas called simple Definition Simple DC* formulas are defined inductively by the following BNF  ≙ = 0 S a  a( )()(◠)* Definition Given a simple DC* formula , we define a simple DC* formula PREF() as follows PREF (  S) ≙  S * PREF (a ) ≙0 PREF (a) ≙a PREF (’) ≙ PREF () PREF (’) PREF ( ’) ≙ PREF () PREF (’) PREF( ◠ ’) ≙ PREF ( )  ( ◠PREF(’)) PREF ( *) ≙ * ◠PREF ( ) Intuitively, PREF() is a simple DC* formula that holds for all prefixes of an interval that validates  A simple DC* formula denotes exactly a Timed Regular Expression and therefore a time automaton Moreover, it has an interesting property that it is decidable [1] 2.2 S-graph Definition An s-graph G is a directed acyclic graph with one source and one sink Its vertex set V contains four types of vertices: BEGIN, END, TEST and ASSIGN The source has type BEGIN, the sink has type END All other vertices are of type TEST or ASSIGN Each TEST vertex v has two children true(v) end false(v) Each BEGIN or ASSIGN vertex u has one child next(u) only Any non-source vertex can have one or more parents An s-graph is associated with a set of m input and l out put variables z1, , zm+l, ranging over finite domains D(z1), , D(zm+l), respectively Fig A simple s-graph The s-graph model resembles order binary decision diagrams (OBDD) [7], which based on a decomposition of Boolean function called the Shannon expansion A function f can be decomposed in terms of a variable as follows f = x fx=1 + x f x= The manipulation of s-graph is also similar to that of OBDD It means that, one can operate logic operators on variables (AND, OR and NOT) Fig illustrates a simple example of an s-graph Each ASSIGN vertex v is labeled with an output variable zv, and a D(zv)-valued function av(z1, , zm+l) In the graphical representation of s-graphs, we label such a vertex with zv:= av(z1, , zm+l) to indicate the meaning of ASSIGN Each TEST vertex v is labeled with a predicate pv(z1, , zm+l), whose truth value determines which child will be executed The evaluation of the multioutput function computed by an s-graph with BEGIN node v, m input variables and l output variables In an s-graph, we present the transition function as a composition of the following: - Set T of tests on input and state variables - Set A of actions, which can be either output emissions or assignments to states variables - The reactive function mapping subsets of T to subsets of A, represented by its |T| + |A| characteristic function F: {0, 1}  {0, 1} For example, in the Figure, tests are present_c and a = ?c; actions are a’:= a, a’:= 0, a’:= a + and emit_y; and the reactive function is: present_c 0 1 a=?c; 1 a’:= a 1 0 a’:= 0, 0 a’:= a+1 0 emit_y 0 Conceptually, the transition function is executed in three phases: - Tests are evaluated to determine the values of input variables of the reactive function - The s-graph of the reactive function is evaluated to determine the values of its output variables - Actions corresponding to output variables are executed S-graph is built recursively starting from reactive function based on the Shannon decomposition ([16]) Theoretically, dynamic calculation of software performance can be done with realistic inputs Both the structure of the synthesized code and the architecture of the target system can be considered Static calculation, useful for example for worst case execution time analysis, can be done by using graph traversal algorithms Assume that E is the number of edges in the s-graph and N the number of nodes The minimumcost path based on Dijkstra's shortest path algorithm from the BEGIN to END vertex of the s-graph is O(ElogN)) Combining the methods 3.1 The technique description The combination process can be formalized by consecutive steps Firstly, a state variables model of the system should be defined The state variables model comprises continuous state variables and discrete state variables Secondly, the requirement of the system is formalized as a DC formula Req over continuous state variables A design decision must be established so that the requirement of the system will be met and refined into a detailed design Des over continuous state variables such that A ⊦Des  Req, where A stands for some assumptions about the behavior of the environment and the relationship between continuous state variables Finally, the discrete step follows We approximate continuous state variables by discrete ones and formalize the relationship between them based on the general behavior of the sensors and actuators The control requirement is derived from the detailed design and refined into a simple DC* formula Cont over discrete state variables such that Ac⊦Cont  Des, where Ac stands for some assumptions about the behavior of the environment and the relationship between continuous state variables, and relationship between discrete state variables and continuous ones The assumptions in the last two phases include ones about time latency of hardware and software, which were computed and estimated exactly by the corresponding s-graph The discrete formula Cont is the formal specification of the controller 3.2 A case study: designing a single lift control system We will illustrate the technique in the remaining of this section with a simple case study The readers are referred to [2, 13] for more details on the designing steps, Discrete Interface, Refinement and Verification Rules We now define three concepts for formalizing the relationship between continuous state variables and discrete ones Definition (Stability) Given a state variable s and a positive real number , we say s is - stable iff the following formula is satisfied by any interval -stable(s) ≙□(  s◠  s◠  s  s◠ (  s> ) ◠  s) Definition (Control state) Given two state variables r and s, and a non-negative real number , we say r - controls s iff the following formula is satisfied by any interval r ⊲s ≙□(  r>  ()◠  s) Definition (Observation state) Given two state variables r and s, and a nonnegative real number  , we say r - observes s iff the following formula is satisfied by any interval  r  s ≙(s ⊲r) (s⊲r)  3.2.1 Problem domain description The logical control of a lift system studied in this paper consists of a simple, single lift system It allows movement of a single lift cage between a finite numbers of floors Components: a lift cage with send buttons, one for each floor; a motor; n + floors, each with a floor door, a call button and a close button; sensors and actuators; a controller Attributes: - The lift cage is either stopped at floor j for j lying between and n inclusive, or is moving up (or down) between floors i and i +1 (i and i - 1), for i lying between and n - (n and 1) - A floor door is either open or closed - The motor is either running up (or down) or is stopped - The motor, when running, runs at a constant speed - which causes the lift cage to move between immediately neighboring floors in tm time units Events: - A send button is pressed for floor k, for k = 0, , n - A call button on floor k is pressed, for k = 0, , n - A close button is pressed for the door at floor k, for k = 0, , n - The opening (and closing) of floor doors - The starting and stopping of the motor - implying the same for the cage Procedure: - Servicing a floor k means that a send button is pressed for floor k, or a call button on floor k is pressed or the lift cage is running upwardly or downwardly (towards floor k) - There is a request on floor j, means that a call or a send button at floor j is pressed, iff there does not exist any services of floors and the floor door is closed; or a close button at floor j is pressed when the floor door is open This implies that the lift system services floors successively This dogma makes our design simple Invariants: - There are at least two floors (a component invariant) - The cage has exactly one send button for each floor (a component invariant) - Pressing a call button at floor i or pressing a send button for floor i causes the lift to service that floor within ts time units (a procedural, functional invariant) - A floor door may only be open if the lift cage is at that floor (a component safety invariant) - The floor door is open for at least t0 time units and at most tmax time units The lift system presented in this paper shall be monitored and controlled by a controller that shall respect the components, handle the events, and satisfy the usual procedures and invariants enumerated above 3.2.2 Formalizing the requirements of the system We introduce the following continuous state variables: variable c i holds if the call button on floor i is pressed, variable si holds if the send button for floor i is pressed, variable di holds if the door at floor i is open, and variable fi holds if the lift is at floor i, for i ranges over interval [0, , n]; variable motor holds if motor is on (and this makes the lift cage move); variable closei holds if the close button on floor i is pressed The requirements of the system are defined by Req ≙□(SafetyReq FunctReq) The safety property for the lift control system is: for every floor, the door must only be opened if the lift is at that floor This is equivalent to stating that “if the lift is not at floor i, then door i must be closed” SafetyReq ≙ di  fi The function requirement is the following conjunction FunctReq ≙F1 F2 F3 Pressing a send button causes the lift to service the corresponding floor within ts time units F1 ≙  si≙ true  ts(ts◠  di◠ true) This requirement states that for every observation interval for which si holds initially, i.e the send button for the i’th floor is pressed, either the interval is shorter than or equal to ts or it may be divided into three subintervals where the first lasts at most ts , in the second the door at floor i is opened, and a final subinterval which is unconstrained A similar condition must hold when pressing a call button: pressing a call button causes the lift to service the corresponding floor within ts time units F2 ≙  ci◠ true  ts (ts ◠  di◠ true) The system must guarantee that when a floor is serviced, the door is open for at least t0 time units and at most tmax time units F3 ≙ (  di◠  di◠  di t0) (  di tmax) We now present a design decision, which implements the requirements 3.2.3 Design decision We define the design decision by the predicate Des Des ≙ □(D1 D2 D3 D4 D5 D6 D7) The following formula is derived directly from the assumptions of the behavior of the system D ≙ ((= a  si c i)◠(= b (  di◠  di))  (= a)◠(b  (si ci sj cj))◠ true)  (close i di)  (c i di) (ci si) (si di) (c i dj) (ci cj)  (c i sj) (si sj) (si dj) If for every interval for which a send button for floor i is pressed initially, and the lift is at floor j, and j i, then the interval may be divided into three subintervals The first lasts at most time units, in the second the motor is on, and an unconstrained final subinterval; in the condition of i = j, then the door at floor i must be opened within time units, where stands for a response time of the system A similar condition must hold when pressing a call button at floor i D2 ≙ (si ci) fj◠ true  ()◠  motor◠ true D3 ≙ (si ci) fi◠ true  () ◠  di◠ true If a send button for floor i is pressed while lift is at floor j, the lift may reach the destination floor and then the motor is off and the door at the floor is opened within  time units A similar condition must hold when pressing a call button at floor i D4 ≙(  (si c i) fj◠ true  ()◠= |i - j|t m◠  (◠  di)   fi◠ true) (  (si ci) fj◠ true  ()◠= |i - j|t m ◠  (◠  motor)  fi◠ true) If the close button at floor i is pressed it may make the door at the floor open within time units D5 ≙  close i◠ true  ()◠  di◠ true Two following formulas will help satisfy the requirement of the maximum and minimum time units for which a door is open D6 ≙ di◠  di◠ true   di◠< t0◠  closei◠ true D7≙ (  ditmax - tmax) ◠ true   di◠  di◠ true Initially the lift is idle at the ground floor with the doors close, motor stops, and no requests for the lift Init ≙ motor f0 di si ci closei◠ true  The maximum time it may take to service a floor corresponds to the time it takes to move across n + floors and the response time it takes to open doors A1 ≙ (ts (n +1) tm + 2) The following formula is derived directly from the attribute of the motor as described in Section 3.2.1 A2 ≙  (si ci) fj◠ true  ◠= |i - j|t m ◠  fi◠ true We assume that the response time is small enough in order to the lift, having reached the destination floor, can be at the floor within at least time units while the motor is still running A3 ≙  fi◠  fi motor◠ true   fi◠ fi◠ true A4 ≙ (t0 + + tmax) Let A ≙Init A1 A A3 A4 3.2.4 Discrete design For any continuous state variable s, let sc be the discrete state variable used by the controller to observe s via the sensors Then the relationships between continuous f , state variables and discrete state ones are formalised as following formulas: fic  i      c ic  c , dic  d , sic  s , and closeic  close i, where is the sampling step  i  i  i  Let Dopeni, Dclosei, Mon, and Moff be discrete state variables, which hold when the controller requests the actuators to open the door at floor i, close the door at floor i, start the motor, and stop the motor, respectively The relationship between them and the continuous state variables di and motor are expressed by Dopeni ⊲ di, Dclosei ⊲di, Mon ⊲motor, and Moff ⊲motor, where stands for the response time of the plant via the actuators Besides, we also introduce a symbol as one described above Let 1 ≙(  (c icsic) fjc Mon=  ) ◠ (|i - j|tm + |i - j|tm )◠  Moff 2 ≙ (  (cic sic ) fjc Mon=  ) ◠ (|i - j| tm  + |i - j|tm )◠  Dopeni 3 ≙  (cic sic ) fic Dopeni(=  ) 1 ≙ (t0 - ) ◠  closeic Dclosei 2 ≙ (tmax - - tmax - ) ◠  Dclosei 1 ≙(  (c icsic) fic ◠(+ |i - j| tm ) ◠  c icsiccjc sjc) 2 ≙ (c ic djc ) (cic cjc ) (c ic sjc ) (sic sjc )  (sic djc ) (close ic dic ) (c ic d ic) (cic sic)  (sic dic ) ≙ c ic sic  * ◠ (( 12 ) 3◠1 2)* ≙ c ic sic  * c ic sic ◠ ((12) 3◠1 2 )* A discrete design for the controller is defined as following formula Cont ≙ (* ◠PREF (*)) 1 2      Let A c ≙ A (fic  f ) (c ic  c ) (dic  d ) (sic  s ) (closeic  closei)   i  i  i  i  (Dopeni ⊲d i) (Dclosei ⊲di) (Mon ⊲motor) (Moff ⊲motor)  ( + ) (  Dopeni ) (  Dclosei ) The following Theorem establishes the correctness of the discrete design, under the assumption about the relationship between discrete state variables and continuous ones, and the behavior of the environment Theorem Ac⊦Cont  Des (Proof See [13]) In the design process, we must choose and satisfying the hardware and software latencies, which were evaluated and estimated easily by using s-graph We have implemented s-graph in C language and tested it successfully Conceptually, the input for initial s-graph need not always be a function but could also be a relation In the paper, we consider that s-graph comes at the end of the technique design simply to fill in the estimated values for parameters of DC* The readers are referred to [2] for details on how to write a real-time program for the controller and verify its correctness w.r.t the formula Cont using extended Hoare triples Conclusion We consider DC* as specification language to reason about the design of the system, which has been used successfully in many case studies, see e.g [1, 2, 13] However, these had not mentioned about how to choose assumptions about environment, especially about time latency We used s-graph associated with DC* to resolve the problem Using the technique will make our system design move closer to real world compares to one given in [10], and it is useful for programmers to implement it in some programming languages Besides, it is not difficult to prove the correctness of the design of the system by using the technique In general, we just have considered the system with simple requirements and the dogmatic assumption In the future, we will use the technique to design more complex and practical systems with optimized processes of s-graph combining with DC* Moreover, we are planning to integrate DC* formal language with Co-design Finite State Machine to build a better synthesizable and verifiable model References 10 11 12 13 14 15 16 Dang Van Hung and Dimitar P Guelev, Completeness and Decidability of a Fragment of DC* Technical Report 163, UNU/IIST, P.O.Box 3058, Macau, 1999 Dang Van Hung et al., Formal Design Technique For Real-Time Embedded Systems Technical Report, Institute of Information Technology, Hanoi, Vietnam, 2001 Dang Van Hung et al., Deriving Real-Time Programs from Duration Calculus Specifications Technical Report 222, UNU/IIST, P.O Box 3058, Macau, 2000 Derek N Dyck and Peter E Caines: The Logical Control of an Elevator IEEE Transactions on Automatic Control, 40, (1995) 480-486 Doron A.Peled, Software Reliability Methods Springer-Verlag, USA, 2001 Edward A.Lee, Embedded Software Advances In Computers, 56, (2002), 55-90 Felice Balarin et al., Synthesis of SW Prog for Embedded Control Apps IEEE Trans on Computer-aided Design of Integrated Circuits and Systems, 18(6), 1999, 834 - 849 J Shoenfield, Mathematical logic Addison-Wesley, Massachusetts, 1967 Jan Vytopil, Formal Techniques In Real-Time And Fault-Tolerant Systems Kluwer Academic Publishers, USA, 1993 Kirsten Mark Hansen et al., Designing Verified Real-time Systems Technical Report, Dept of Computer Science, Technical Uni of Denmark, EuroMicro ’92, Paris, 1992 Michael Schiebe, Saskia Pferrer, Real-Time Systems Engineering And Applications Kluwer Academic Publishers, USA, 1992 Michael R Hansen, Zhou Chaochen, Duration Calculus: Logical Foundations Formal Aspects of Computing, 9, (1997), 283-330 Pham Tran Nhu, Nguyen Van Truong, Designing a lift control system Journal of computer science and cybernetics, 3, (2004), 205-218 Rajesh Kumar Gupta, Co-synthesis of Hardware And Software For Digital Embedded Systems Kluwer Academic Publishers, USA, 1995 S Edwards, L Lavagno, E A Lee, and A Sangiovanni-Vincentelli, Design of Embedded Systems: Formal Models, Validation, and Synthesis Proc of the IEEE, 85, 1997 Varery Viatkin et al., Optimazed Processing of Complex Events in Discrete Control Systems Using Binary Decision Diagrams Proc of the IFAC workshop, 1997  ... [13]) In the design process, we must choose ? ?and satisfying the hardware and software latencies, which were evaluated and estimated easily by using s -graph We have implemented s -graph in C language... Moreover, it has an interesting property that it is decidable [1] 2.2 S -graph Definition An s -graph G is a directed acyclic graph with one source and one sink Its vertex set V contains four types... simple introduction to make easier the understanding of the following Readers may find more details in [1, 12] about DC* and in [7] about s -graph 2.1 DC* A language for DC* is built starting from