Verification of Embedded Systems using Petri Nets: PRES+ Representation, Papers of Art

Download Verification of Embedded Systems using Petri Nets: PRES+ Representation and more Papers Art in PDF only on Docsity! Verification of Embedded Systems using a Petri Net based Representation Luis Alejandro Cortés, Petru Eles, and Zebo Peng Dept. of Computer and Information Science Linköping University, Linköping, Sweden {luico,petel,zebpe}@ida.liu.seAbstract The ever increasing complexity of embedded systems consisting of hardware and software components poses a challenge in verifying their correctness. New verification methods that overcome the limitations of traditional tech- niques and, at the same time, are suitable for hardware/ software systems are needed. In this work we formally de- fine the semantics of PRES+, a Petri net based computa- tional model aimed to represent embedded systems. We introduce an approach to formal verification of such sys- tems: we make use of model checking to prove the correct- ness of embedded systems by determining the truth of CTL and TCTL formulas that specify required properties with re- spect to a PRES+ model. An ATM server illustrates the fea- sibility of our approach on practical applications. 1. Introduction Modern electronic systems are typically constituted of application-specific hardware components and software running on programmable platforms. The inherent hetero- geneity of this kind of systems makes them very complex and consequently difficult to verify. Moreover, the increas- ing demand on high-performance products has boosted the levels of sophistication of such systems. For the levels of complexity typical to modern electronic systems, traditional validation techniques like simulation and testing are neither sufficient nor viable to verify their correctness. First, these techniques may cover just a small fraction of the system behavior. Second, long simulation times and bugs found late in prototyping phases have a neg- ative impact on time-to-market. Formal methods are be- coming a practical alternative to ensure the correctness of designs. They might overcome some of the limitations of traditional validation methods. At the same time, formal verification can give a better understanding of the system behavior, contributes to uncover ambiguities, and reveals new insights of the system. Formal methods have been extensively used in software development [8] and hardware verification [12]. However, they are not commonplace in embedded systems design. In this paper we present an approach to verification using mod- el checking for embedded systems represented in PRES+, a notation capable of capturing relevant information charac- teristic to such systems. We introduce a systematic proce- dure to translate PRES+ models into linear hybrid automata in order to use existing model checking tools. Model checking is an approach to formal verification that lets the designer prove whether certain design proper- ties hold in a given model of the system. Our approach al- lows to determine the truth of CTL (Computation Tree Logic) [5] and TCTL (Timed CTL) [1] formulas with re- spect to a PRES+ model. Thus it is possible to validate de- sign properties including timing requirements. The rest of this paper is organized as follows. Section 2 addresses related approaches to formal methods suitable for embedded systems. The underlying computational model that we use to represent such systems is formally defined in Section 3. Our approach to verification of embedded sys- tems is presented in Section 4. In Section 5 we illustrate our verification method using a real-life telecom system. Final- ly, some conclusions are drawn in Section 6. 2. Related Work Many models have been proposed to represent HW/SW systems. Particularly, Petri nets (PNs) have been extended to model such systems. Maciel et. al [13] introduce an inter- mediate model for hardware/software codesign, extending Petri nets to analyze certain properties used in the partition- ing process. Stoy [15] presents a modeling technique where timed Petri nets with restricted transition rules are used to represent control flow in both hardware and software. Though formal methods are not commonplace in hard- ware/software codesign, some coverification approaches have been proposed recently. Using the hybrid automata model, a coverification method is proposed in [10] where complex systems can be analyzed using a simplification strategy to verify individually the hardware, the software, and the interface. Balarin et. al [4] introduce a verification methodology based on Codesign Finite State Machines (CFSMs) in which CFSMs are translated into traditional state automata in order to check whether all possible se- quences of inputs and outputs satisfy the system properties. In [9], a partitioned system is the input to the proposed cov- erification framework in which CTL and TCTL formulas are evaluated in order to check behavioral and timing prop- erties. An approach to model checking of process networks This research is sponsored by the Swedish National Board for Indu- strial and Technical Development (NUTEK) in the frame of the SAVE project. is proposed in [16], where IDDs (Interval Decision Dia- grams) are used to represent multi-valued functions. Related approaches to formal verification using PNs in- clude [17], which presents a BDD-based model checker for safe nets. An interesting approach to analysis and verifica- tion of bounded Petri nets is presented in [14], where BDDs are used to represent sets of markings. 3. PRES+ The notation we use to model embedded systems is PRES+ (Petri net based Representation for Embedded Sys- tems). PRES+ is a slightly modified version of the model presented in [6]. It is a computational model based on Petri nets that allows to capture important features of embedded systems. Figure 1 shows a simple example that will help to illustrate the definition of this representation. In what fol- lows we introduce the formal definition of PRES+. Figure 1. A PRES+ model Definition 1. A PRES+ model is a five-tuple where is a finite non-empty set of places; is a finite non-empty set of transitions; is a finite non-empty set of input arcs which de- fine the flow relation between places and transitions; is a finite non-empty set of output arcs which define the flow relation between transitions and places; M0 is the initial marking of the net (see Definition 3). Like in classical Petri nets, places are graphically repre- sented by circles, transitions by boxes, and arcs by arrows. For the example in Figure 1, and . Definition 2. A token is a pair where v is the token value. This value may be of any type, e.g. boolean, integer, etc., or user-defined type of any complex- ity (for instance a structure, a set, or a record). The type of this value is referred to as token type; r is the token time, a non-negative real number representing the time stamp of the token. The set K denotes the set of all possible token types for a given system. Definition 3. A marking is a function that denotes the absence or presence of tokens in the places of the net. A PRES+ net N is safe or 1-bounded, that is, a place may hold at most one token for a certain marking. whenever the place p is marked, otherwise . Note that a marking M implicitly assigns one token k to each marked place. We introduce the following notation which will be useful in defining the dynamic behavior of PRES+: when a place is marked, denotes the token present in . The token value of the token is denoted , and the token time of the token is denoted . The initial marking M0 in Figure 1 shows and as places initially marked. The token has a value a and a time stamp 0. For the sake of simplicity, in the examples we use the short notation w to denote the token value . Definition 4. The type function associates a place with a token type. τ(p) denotes the token type associ- ated with the place p. The token type is the type of value that a token may bear in that place. It is worth pointing out that the token type related to a certain place is fixed, that is, it is an intrinsic property of that place and will not change during the dynamic behavior of the net. For the example in Figure 1, all places have token type real. Definition 5. The pre-set of a transition t is the set of input places of t. Similarly, the post- set of a transition t is the set of output places of t. Correspondingly, the pre-set and the post-set of a place p are given by and . Definition 6. All output places of a given transition have the same token type, if Definition 7. For every transition t, there exists a transition function associated to t. Formally, where and . Transition functions are very important when describing the behavior of the system to be modeled. They allow sys- tems to be modeled at different levels of granularity with transitions representing simple arithmetic operations or complex algorithms. In Figure 1 we inscribe transition func- tions inside transition boxes: the transition function associ- ated to , for example, is given by . We use inscriptions on the input arcs of a transition in order to denote the arguments of its transition function and/or its guard. Definition 8. For every transition t, there exist a minimum transition delay and a maximum transition delay , which are non-negative real numbers and represent, respec- tively, the lower and upper limits for the execution time (de- t 3 t 4 pa cp pd t 2t 1 pb pfpe c>3[ ] c<4[ ] c c+d c b/2 [3.8,4.1] a-2 3 c [1,2.7] 5 [2,3] d ba x <a,0> <b,0> N (P T ,,= I O M0), , P p1 p2 … pm, , ,{ }= T t1 t2 … tn, , ,{ }= I P T×⊆ O T P×⊆ P pa pb pc pd pe p f,, , , ,{ }= T t1 t2 t3 t4, , ,{ }= k v r,〈 〉= M : P 0 1,{ }→ M p( ) 1= M p( ) 0= pi ki pi ki vi ki ri pa pb ka a 0,〈 〉= vw τ : P K→ °t p P p t,( ) I∈∈{ }= t° p P t p,( ) O∈∈{ }= °p p° °p t T t p,( ) O∈∈{ }= p° t T p t,( ) I∈∈{ }= p q t° τ p( )⇒∈, τ q( )= f t T∈∀ f : τ p1( ) τ p2( ) … τ× pa( )×× τ q( )→∃ °t p1 p2 … p, a, ,{ }= q t°∈ t4 f 4 c d,( ) c d+= d- d+ then assign to each group of z edges synchronization labels corresponding to the transitions in . Define then one edge with synchronization label . Step 4b. If the transition is in conflict with another tran- sition ( could be disabled by the firing of ): Let and . In the automaton remove all the edges except . Split each one of the locations into and . Then define edges , , , , , , , with synchronization labels corresponding to those transi- tions in . Define edges , , , with synchronization labels correspond- ing to transitions in . Define then edges , , , with synchronization label . For instance, were not in conflict with , the autom- aton would have the locations and look like the one shown in Figure 3(a). However, because of such a conflict, Step 4b must be performed: location has been split into the locations and . Note that and . The edges and with synchroni- zation label are defined. Then the edges and with synchronization label are defined. Finally, the edges and with syn- chronization label are defined. After Step 4b, we get the automaton shown in Figure 3(b). It is easy to observe that is in conflict with . No lo- cations, however, are split in the automaton because it has just two locations ( and ). In this case only the edge with synchronization label must be add- ed. Let be the transition function associated to , the pre-set of , and and the minimum and maximum transition delays associated to . Step 5. Given the automaton , assign to every edge the activity . Define the invariant of loca- tion as in order to enforce the firing of before or at its latest trigger time. In Figure 2, the edge of automaton , for ex- ample, has the activity . is used to take into ac- count the time since becomes enabled and ensure the firing semantics of PRES+. For the sake of clarity, location invariants are not shown in Figure 2. Step 6. Given and its edge , assign to the condition . For every assign to such an edge the activity . For example, in the case of the automaton the condi- tion gives the lower and upper limits for the firing of , while the activity expresses that whenever the automaton changes from to , i.e. fires, the value is assigned to the variable c. Step 7. If is a transition with guard , assign the condi- tion to the edge of the automaton (so such an edge condition becomes ). Then add an edge with no synchronization label, condition (the complement of ), and activity . Note the condition in the autom- aton where is the guard of . Observe also the edge with condition and activity . Step 8. For every place define a hybrid automaton with two locations, on and off, corresponding to the marking . The initial location of will be either on or off de- pending whether the place is initially marked or not. For every transition in the post-set of the place , define an edge with synchronization label . For every transition in the pre-set of the place , define an edge with synchronization label . Note: When, given an automaton , a transition is both input and output of the place , define an edge and assign to it a synchronization label . In Figure 2 we only show the automaton . The other automata , , , , and are similar. The procedure that we have described above is general enough to translate any PRES+ model in which transition functions are linear and token types of all places are real. pre t( ) en dis0,( ) t Figure 2. Equivalent hybrid automata t 1 dis0 1<c <2 .7 1 t1 ~ en c:=a-2 t 3 t 4 t 1 on off pc~ t 2 dis0 2<c <32 t2 ~ en d:=b/2 dis0 dis1,a dis1,b ent 3 t 3 t 1 t 2 c := 0 4 c :=04 t 2 t 1 3. 8< c < 4. 1 & c< 4 4 c :=04 c>4 t 4 t4 ~ f:=c+d t 3 dis0 t3 ~ c = 5 & c> 3 3 t 1 c :=03 c :=03 c<3 t 4 en e:=3c t tc t tc A pre t( ) pre tc( )∩= B pre t( ) p– re tc( )= t̃ en dis0,( ) dis1 … disz 1–, , dis1,a … disz 1,a–, , dis1,b … disz 1,b–, , dis1,a dis2,a,( ) dis2,a dis3,a,( ) … disz 1,a– en,( ) dis0 dis1,b,( ) dis1,b dis2,b,( ) … disz 2,b– disz 1,b–,( ) B dis0 dis1,a,( ) dis1,b dis2,a,( ) … disz 1,b– en,( ) A dis1,a dis0,( ) dis2,a dis1,b,( ) … en disz 1,b–,( ) tc t4 t3 t4 ˜ dis0 dis1 en, , dis1 dis1,a dis1,b pre t4( ) pre t3( )∩ t1{ }= pre t4( ) p– re t3( ) t2{ }= dis1,a en,( ) dis0 dis1,b,( ) t2 dis0 dis1,a,( ) dis1,b en,( ) t1 dis1,a dis0,( ) en dis1,b,( ) t3 t4 ˜ t3 t4 t3 ˜ dis0 en en dis0,( ) t4 f i ti °ti q1 q2 … qa, , ,{ }= ti di - di + ti ti ˜ dis j en,( ) ci := 0 en ci di +≤ ti dis0 en,( ) t3 ˜ c3 := 0 c3 t3 ti ˜ ei en dis0,( )= ei di - c≤ i di +≤ p j ti°∈ ei v j := f i v1 v2 … va, , ,( ) t1 ˜ 1 c≤ 1 2.7≤ t1 c := a 2– en dis0 t1 a 2– ti Gi Gi en dis0,( ) ti ˜ di - c≤ i di + & Gi≤ en en,( ) Gi Gi ci := 0 3.8 c≤ 4 4.1 & c 4<≤ t4 ˜ c 4< t4 en en,( ) c 4≥ c4 := 0 p P∈ p̃ M p( ) p̃ p t j p° p e j on off,( )= t j ti °p p e j off on,( )= ti p̃ ti p ei on on,( )= ti pc ˜ pa ˜ pb ˜ pd ˜ pe ˜ p f ˜ Some optimizations may be performed to reduce the com- plexity of the resulting hybrid automata. For instance, in most cases, the automata corresponding to places are redun- dant and could be removed. Such optimizations are beyond the scope of this paper and therefore not discussed here. Figure 3. Illustration of Step 4 Once we have the equivalent hybrid automata, we can verify properties against the model of the system. For in- stance, in the simple system of Figure 1 we could check whether, for given values of a and b, there exists a reachable state in which is marked. This property might be ex- pressed as a CTL formula . An interesting feature of the HyTech tool [11] is its ability to perform parametric analysis. Then, for example, we can ask the model-checker which values of a and b make a certain property true. We get that holds if . If we want to check temporal properties we can express them as TCTL formulas. Thus, we could check whether will be possibly marked and the time stamp of its token is less than 8.4 time units, expressing this property as . The translation procedure introduced above is valid for PRES+ models in which transition functions are linear and token types of all places are real. In this case, we could even reason about token values. Recall, however, that we want to focus on reachability and time analyses. From this perspec- tive we can ignore transition functions if they affect neither the marking nor time stamps. This is the case of PRES+ models that bear no guards and, therefore, they can be straightforwardly verified even if their transition functions are very complex operations, because we simply ignore such functions. Those systems that include guards in their PRES+ model may also be studied if guard dependencies can be stated by linear expressions. This is the case of the system shown in Figure 1. There are many systems in which the transition functions are not linear, but their guard depen- dencies are, and then we can inscribe such dependencies as linear expressions and use our method for system verifica- tion. 5. Verification of an ATM Server In this section we illustrate the verification of a practical system, modeled using PRES+. The net in Figure 4 repre- sents an ATM-based Virtual Private Network (A-VPN) ser- ver [7] for a particular implementation. The behavior of the system can be briefly described as follows. Incoming cells are examined by Check to determine whether they are faulty. Fault-free cells arrive through the UTOPIA_Rx inter- face and are eventually stored in the Shared Buffer. If the in- coming cell is faulty, it goes through the module Faulty and then is sent out using the UTOPIA_Tx interface without pro- cessing. The module Address Lookup checks the Lookup Memory and, for each non-defective input cell, a com- pressed form of the Virtual Channel (VC) identifier in the cell header is computed. With this compressed form of the VC identifier, the module Traffic checks its internal tables and decides whether to accept the incoming cell or discard it in order to avoid congestion. If the cell is accepted, Traffic gives instructions to Queue Manager indicating where to store the incoming cell in the buffer. Traffic also indicates to Queue Manager the cell (stored in Shared Buffer) to be output. Supervisor is the module in charge of updating in- ternal tables of Traffic and the Lookup Memory. The select- ed outgoing cell is emitted through the module UTOPIA_Tx. The specification of the system includes a time constraint given by the rate (155 Mbit/s) of the appli- cation: one input cell and one output cell must be processed every 2.7 µs. Figure 4. PRES+ model of an A-VPN server To verify the correctness of the A-VPN server, we must prove that for all possible conditions the system will even- tually complete its functionality, and that such a functional- ity will eventually fit within a cell time-slot. The completion of the task of the A-VPN server, modeled by the net in Fi- gure 4, is represented by the state (marking) in which the place is marked. Then we must prove that for all com- dis0 dis1,a dis1,b ent 3 t 3 t 1 t 2 t 2 t 1 t 4 t4 ~ dis0 en t4 ~ dis1 t 1 t 2 t 1t 2 t 4 (b) (a) pe EF pe EF pe a 5≥ p f EF<8.4 p f Shared Buffer Queue ManagerUTOPIA_Rx Address Lookup Lookup Memory Traffic Supervisor p 2 p 5 p 6 p 8 p 9 p 11 p 12 p 10 p 7 p 4Fa ul ty C he ck p 3 p 1 U T O PI A _T x p 13 VC Setup [0.1,0.25] [0.3,0.5] [fault] [0.15,0.2] [0.53,0.86] [0.1,0.22][0.45,0.58] [0.14,0.25] [f au lt ] [0 .1 ,0 .2 5] ATM Cell (In) ATM Cell (Out) [0 .1 ,0 .3 ] 0. 05 p1 putation paths, will eventually get a token and its time stamp will be less than 2.7 µs. These conditions might be straightforwardly specified using CTL and TCTL formulas, namely and . Notice that the first formula is a necessary condition for the second one. Using the trans- lation procedure described above and the HyTech tool [11], we found out that the CTL formula holds while the TCTL formula does not. Moreover, we have checked the formula that turned out to be true, which means that it is possible to get a token in with a time stamp less than 2.7 µs. However, recall that does not hold and therefore this implementation does not fulfill the system specification because it is not guaranteed that the time constraint will be satisfied. We must consider an alternative solution. To do so, sup- pose we want to modify Traffic, keeping its functional be- havior but seeking superior performance: we want to explore the allowed interval of delays for Traffic in order to fulfill the constraints. We can define the minimum and max- imum transition delays of Traffic as parameters and , and then perform parametric analysis to find out the values for which is satisfied. We get that if and, by definition, then the property holds. This indicates that the worst case execution time of the function associated to Traffic must be less than 0.57 µs to fulfill the system specification. Running the HyTech tool on a Sun Ultra 10 workstation, both the verification of the TCTL formula for the model given in Figure 4, and the parametric analysis de- scribed in the paragraph above take roughly 1 second. The example of the ATM server described above has shown that our approach is not only suitable to verify the correctness of embedded systems but also that this tech- nique can be a useful tool during design space exploration. Information, like the one obtained through parametric anal- ysis, can guide the designer when exploring design alterna- tives. Thus, at the same time that we check the correctness of designs, we get valuable information that serves as guide- line along the design process. 6. Conclusions We have formally defined PRES+, a Petri net based model aimed to represent embedded systems. The model is simple, intuitive, and can be easily handled by the designer. It is a computational model with extensions to capture im- portant characteristics of embedded systems. We presented a practical approach to verification of em- bedded systems represented by PRES+. We use symbolic model checking to prove the correctness of such systems in respect to reachability and time, specifying design proper- ties as CTL and TCTL formulas. Thus verification with tim- ing properties is possible. In order to use existing verification tools, we introduced a systematic procedure to translate PRES+ models into lin- ear hybrid automata. This method can be automated in a rel- atively simple manner. An ATM server has been studied to illustrate the applicability of our verification approach to practical systems. The approach presented in this work is not only appropri- ate to verify the correctness of embedded systems, but may also be a useful tool for design space exploration. References [1] R. Alur, C. Courcoubetis and D. L. Dill, “Model Checking for Real-Time Systems,” in Proc. Symposium on Logic in Computer Science, 1990, pp. 414-425. [2] R. Alur, C. Courcoubetis, N. Halbwachs, T. A. Henzinger, P.- H. Ho, X. Nicollin, A. Olivero, J. Sifakis, and S. Yovine, “The Al- gorithmic Analysis of Hybrid Systems,” in Theoretical Computer Science, vol. 138, pp. 3-34, February 1995. [3] R. Alur, T. A. Henzinger, and P.-H. Ho, “Automatic Symbol- ic Verification of Embedded Systems,” in IEEE Trans. Software Engineering, vol. 22, pp. 181-201, March 1996. [4] F. Balarin, H. Hsieh, A. Jurecska, L. Lavagno, and A. Sangio- vanni-Vincentelli, “Formal Verification of Embedded Systems based on CFSM Networks,” in Proc. DAC, 1996, pp. 568-571. [5] E. M. Clarke, E. A. Emerson, and A. P. Sistla, “Automatic Verification of Finite-State Concurrent Systems Using Temporal Logic Specifications,” in ACM Trans. on Programming Languag- es and Systems, vol. 8, pp. 244-263, April 1986. [6] L. A. Cortés, P. Eles, and Z. Peng, “A Petri Net based Model for Heterogeneous Embedded Systems,” in Proc. NORCHIP Con- ference, 1999, pp. 248-255. [7] E. Filippi, L. Lavagno, L. Licciardi, A. Montanaro, M. Paoli- ni, R. Passerone, M. Sgroi, and A. Sangiovanni-Vincentelli, “Intel- lectual Property Re-use in Embedded System Co-design: an Industrial Case Study,” in Proc. ISSS, 1998, pp. 37-42. [8] J. D. Gannon, J. M. Purtilo, and M. V. Zelkowitz, Software Specification: A Comparison of Formal Methods. Norwood, NJ: Ablex Publishing, 1994. [9] E. H. A. Garcez and W. Rosenstiel, “CVF - Coverification Framework,” in Proc. Brazilian Symposium on Integrated Circuit Design, 1998, pp. 103-106. [10] P.-A. Hsiung, “Hardware-Software Coverification of Concur- rent Embedded Real-Time Systems,” in Proc. Euromicro RTS, 1999, pp. 216-223. [11] HyTech: The HYbrid TECHnology Tool, http://www- cad.eecs.berkeley.edu/~tah/HyTech/ [12] C. Kern and M. R. Greenstreet, “Formal Verification in Hard- ware Design: A Survey,” in ACM Trans. on Design Automation of Electronic Systems, vol. 4, pp. 123-193, April 1999. [13] P. Maciel, E. Barros, and W. Rosenstiel, “A Petri Net Model for Hardware/Software Codesign,” in Design Automation for Em- bedded Systems, vol. 4, pp. 243-310, Oct. 1999. [14] E. Pastor, O. Roig, J. Cortadella, and R. M. Badia, “Petri Net Analysis Using Boolean Manipulation,” in Application and Theo- ry of Petri Nets 1994, R. Valette, Ed. LNCS 815, Berlin: Springer- Verlag, 1994, pp. 416-435. [15] E. Stoy and Z. Peng, “An Integrated Modelling Technique for Hardware/Software Systems,” in Proc. ISCAS, 1994, pp. 399-402. [16] K. Strehl and L. Thiele, “Symbolic Model Checking of Pro- cess Networks Using Interval Diagrams Techniques,” in Proc. IC- CAD, 1998, pp. 686-692. [17] G. Wimmel, “A BDD-based Model Checker for the PEP Tool,” Major Individual Project Report, Dept. of Computing Sci- ence, University of Newcastle, May 1997. p1 AF p1 AF<2.7 p1 AF p1 AF<2.7 p1 EF<2.7 p1 p1 AF<2.7 p1 d- d+ AF<2.7 p1 d + 0.57< d- d+≤ AF<2.7 p1 AF<2.7 p1