Development of embedded systems from RTCP-net model to Ada code

Transcription

1 Part 2: Specificati Development of embedded systems from RTCP-net model to Ada code Marcin Szpyrka 1 Institute of Automatics, AGH University of Science and Technology, Al. Mickiewicza 30, Kraków, Poland mszpyrka@agh.edu.pl Abstract. The paper describes some aspects of the development of ctrol embedded systems ccerned with the transformati from a formal RTCP-net model into Ada 2005 source code. RTCP-nets have been defined, amg other things, to equip coloured Petri nets with capability of direct modelling of elements typical for ccurrent programming in Ada, such as task priorities, timeouts, etc. Hence, it is possible to define an algorithm for a semi-automatic transformati from a model into an implementati. Especially, the possibility is ccerned with systems implemented in accordance with Ada Ravenscar Profile that limits the set of acceptable language cstructis. 1 Introducti Using of formal methods in the embedded systems development process may reduce the amount of testing and ensure more dependable software ([6]). Formal methods can be used at different stages in the development process ([4]). Especially, it is possible to design a system model at any abstract level. This paper focuses the transformati from a detailed system model into an Ada 2005 implementati. The presented approach is based a subclass of coloured Petri nets (CP-nets), the so-called RTCP-nets ([7], [8], [9]). RTCP-nets are an adaptati of CP-nets to make modelling and verificati of embedded systems easier and more efficient. To enable semi-automatic design of models a special hierarchical form of the nets (canical form) has been defined. An RTCP-net in canical form represents the structure of a modelled system, its dynamic and also functial relatiships. Each part (object) of the modelled system and each system activity is represented by a distinguished part of the correspding RTCP-net. Hence, it is possible to identify parts of Ada source code that should be defined e.g.: tasks, protected objects, suspending objects, etc. This paper presents methods of the transformati of an RTCP-net in canical form into a framework of Ada 2005 source code. It is organized as follows. A short descripti of RTCP-nets is presented in secti 2. The Ravenscar Profile is shortly described in secti 3. The transformati algorithm is presented in secti 4. An example of a driver for an air cditier is used to demstrate the approach. The paper is shortly ccluded in the final secti. Research supported from a KBN Research Project No.: 4 T11C

2 Proc. CS&P '06 2 RTCP-nets Definiti of the RTCP-nets is based the experience with the applicati of CPnets ([5]) for real-time systems modelling and verificati. The definiti of RTCPnets is based the definiti of n-hierarchical timed CP-nets presented in [5], but a few differences between timed CP-nets and RTCP-nets can be pointed out. First of all, a priority value is attached to each transiti. Moreover, a new time model is used. Time stamps are attached to places instead of tokens. Any positive value of a time stamp describes how lg a token in the correspding place will be inaccessible for any transiti. A token is accessible for a transiti, if the correspding time stamp is equal to or less than zero. The negative values denotes the age of tokens the place ctains (e.g. the stamp is equal to 3 means that tokens are 3 time-units old). It is possible to specify how old a token should be so that a transiti may csume it. For any variable v, T (v) will be used to denote the type of the variable i.e. the set of all admissible values, the variable can be associated with. Let x be an expressi. V(x) will denote the set of all variables in the expressi x, and T (x) will denote the type of the expressi, i.e. the set of all possible values, which can be obtained by evaluating the expressi. For any given set of variables V, the type of the set of variables is defined as follows: T (V ) = {T (v): v V }. Let Bool denote the boolean type (ctaining the elements {false, true}, and having the standard operatis from propositial logic). For an arc a, P (a) and T (a) will be used to denote the place node and the transiti node of the arc, respectively. Definiti 1. An RTCP-net is a tuple N = (Σ, P, T, A, C, G, I, E M, E S, M 0, S 0 ) satisfying the following requirements. (1) Σ is a n-empty finite set of n-empty types (colour sets). (2) P is a n-empty finite set of places. (3) T is a n-empty finite set of transitis such that P T =. (4) A (P T ) (T P ) is a flow relati (set of arcs). (5) C: P Σ is a type functi, which maps each place to its type. (6) G is a guard functi, which maps each transiti to an expressi such that: t T : T (G(t)) Bool T (V(G(t))) Σ. (7) I: T N {0} is a priority functi, which maps each transiti to a n-negative integer called transiti priority. (8) E M is an arc expressi functi, which maps each arc to a weight expressi such that: a A: T (E M (a)) C(P (a)) T (V(E M (a))) Σ. (9) E S is an arc time expressi functi, which maps each arc to a time expressi such that: a A: T (E S (a)) Q + {0} T (V(E S (a))) Σ, (10) M 0 is an initial marking, which maps each place to a multi-set M 0 (p) 2 C(p), where 2 C(p) denotes the set of all multi-sets over the set C(p). (11) S 0 : P Q is an initial time stamp functi, which maps each place to a ratial value called initial time stamp. A marking of an RTCP-net N is a functi M defined the set of places P, such that: p P : M(p) 2 C(p), while a time stamp functi is a functi S such that: p P : S(p) Q. If the set P is ordered, then both a marking M and a time stamp 232

3 Part 2: Specificati functi S can be represented by vectors with P entries. A state of an RTCP-net is a pair (M, S), where M is a marking and S is a time stamp functi. Let X = P T denote the set of all nodes of an RTCP-net and x X. In(x) and Out(x) denote the set of input and output nodes of the node x, i.e. In(x) = {y X: (y, x) A} and Out(x) = {y X: (x, y) A}. Let V(t) be the set of variables that occur in the expressis of arcs surrounding the transiti t and in the guard of the transiti. A binding of a transiti t is a substituti that replaces each variable of V(t) with a value of the correspding type, such that the guard evaluates to true. G(t) b denotes the evaluati of the guard expressi in the binding b. Similarly, E M (p, t) b and E S (p, t) b denote the evaluati of the weight and the time expressi in the binding b, respectively. Definiti 2. A transiti t T is enabled in a state (M, S) in a binding b iff the following cditis hold: p In(t): E M (p, t) b M(p) E S (p, t) b S(p), p Out(t): S(p) 0 and for any transiti t t that satisfies the above cditis, I(t ) I(t) or In(t) In(t ) = Out(t) Out(t ) =. If a transiti t T is enabled in a state (M 1, S 1 ) in a binding b it may fire, changing the state (M 1, S 1 ) to another state (M 2, S 2 ), such that: M 2 (p) = M 1 (p) {E M (p, t) b } {E M (t, p) b }, ({E M (x, y) b } = if (x, y) / A), and E S (t, p) b for p Out(t), S 2 (p) = 0 for p In(t) Out(t), (1) S 1 (p) otherwise. A global clock is used to measure time. Every time the clock goes forward, all time stamps are decreased by the same value. If a transiti t T is enabled in a state (M 1, S 1 ) in a binding b and a state (M 2, S 2 ) is derived from firing of the transiti t, then we write (M 1, S 1 ) (t,b) (M 2, S 2 ). Definiti 3. Let (M, S) be a state and e = (1, 1,..., 1) a vector with P entries. The state (M, S) is changed into a state (M, S ) by a passage of time τ Q +, denoted by (M, S) τ (M, S ), iff M = M and the passage of time τ is possible, i.e., no transiti is enabled in any state (M, S ), such that: S = S τ e, for 0 τ < τ. A firing sequence of an RTCP-net N is a sequence of pairs α = (t 1, b 1 ), (t 2, b 2 ),..., such that b i is a binding of the transiti t i, for i = 1, 2,... The firing sequence is feasible from a state (M 1, S 1 ) iff there exists a sequence of states such that: (M 1, S 1 ) τ1 (M 1, S 1) (t1,b1) (M 2, S 2 ) τ2... (tn,bn) (M n+1, S n+1 ) τn+1... (2) For the sake of simplicity, we will assume that there is at most e passage of time (sometimes equal to 0) between firings of two csecutive transitis. Formal verificati of RTCP-nets is based coverability graphs. Two states are csidered to cover each other, if both have the same markings and the same level of tokens accessibility, i.e. in both states, for each place the tokens are already accessible or we have to wait the same number of time units to remove them. A coverability relati 233

4 Proc. CS&P '06 is defined the set of all states and the coverability graph ctains ly e node for each equivalence class of the relati. Each node correspds to a unique state (representative of an equivalence class), csisting of a net marking and a time vector, such that the state is a result of firing of a transiti. Each arc represents a change from e state to another resulting from a passage of time and a firing of a transiti. Not ly can e use such a graph for the analysis of typical Petri nets properties such as boundedness, liveness or fairness, but also it may be used for verificati of timing properties, which are very important for most real-time embedded systems. Moreover, it has been shown that for strgly bounded RTCP-nets (i.e. nets with finite multiset bound for each place) e can cstruct a finite coverability graph ([8]). Hierarchical RTCP-nets are based the cstruct used for hierarchical CP-nets. Substituti transitis and fusi places ([5]) are used to combine pages but they are a mere designing cvenience. In comparis with CP-nets general ports are not allowed in RTCP-nets. Each socket node must have ly e port node assigned and vice versa. Moreover, global fusi sets ly are allowed in RTCP-nets. A special form of hierarchical RTCP-nets called canical form ([7]) has been defined to speed up and facilitate drawing of models. Nets in canical form are composed of 4 types of subnets with precisely defined structures: Primary place pages are used to represent active objects (i.e. objects performing actis) and their activities. They are oriented towards objects presentati and are top level pages. Primary transiti pages are oriented towards activities presentati and are secd level pages. Any such page ctains all the places, the values of which are necessary to execute the activity. Linking pages belg to the functial level of a model. They are used (if necessary) to represent an algorithm that describes an activity in detail. Moreover, a linking page is used as an interface for gluing the correspding D-net into a model. Such a page is used to gather all necessary informati for the D-net and to distribute the results of the D-net activity. D-nets are used to represent rule-based systems in the Petri net form. 3 Ada Ravenscar Profile The Ada Ravenscar Profile ([1], [2], [3]) describes a subset of the Ada task model defined for the producing of analysable and deterministic code for safety-critical applicatis. The requirement to analyse both the functial and temporal behaviours of such systems imposes a number of restrictis the ccurrency model that can be employed. The most important features of Ravenscar Profile are as follows: An applicati ctains a fixed set of Ada tasks, with the use of fixed priority scheduling. All tasks have to be declared at the library level and they never terminate. The tasks may be cyclic or aperiodic. The synchrisati or/and exchange of data between tasks is de by means of protected objects. Only e entry for a protected object is allowed, and the guard of this entry has to be a simple boolean variable. The maximum length of the entry queue is e. Implementati of periodic processes is possible using delay until operatis. Protected procedures are used as interrupt handlers. 234

5 Part 2: Specificati The dynamic allocati, requeue statement, asynchrous transfer of ctrol, abort statement, task entries, dynamic priorities, Calendar package, relative delays, requeue and select statement are not allowed. In most cases, a small number of the language templates is enough to develop embedded systems software. The most popular es are ([3]): cyclic tasks, event-triggered tasks, protected objects and suspensi objects. 4 Transformati of a model into an Ada source code Formal models of an embedded system are typically used to verify selected properties of the system. Such models can be designed at any abstract level, but they usually do not represents all implementati details. Hence, it is hardly possible to generate a complete source code automatically. However, using of RTCP-nets in canical form enables generating of the source code framework with all tasks, protected objects, etc. RTCP-nets in canical form are composed of four types of subnets, but it is enough to focus primary places and transitis pages to present the main aspects of the transformati from an RTCP-net model into an Ada source code. Hence, a simple RTCP-net without linking pages and D-nets will be presented in this secti. 4.1 RTCP-net model Let s csider a system for keeping a required temperature in an office. The system csists of: a driver, a temperature sensor and an air cditier. The system enables users to set the required temperature and it turns the air cditier /off to keep the office temperature equal to the required e. The system works in the following way. The driver reads the sensor state every 30 secds. If the current temperature is greater than the required temperature the air cditier is turned. Moreover, the system should detect a failure of the temperature sensor and in such a situati turn off the air cditier and driver. An RTCP-net model represents not ly an embedded system but also its envirment and it simulates changes in the envirment. In the csidered example an extra object (place) Office is used to represent the system envirment. Definitis of types and declaratis of variables used in the model are as follows: color Temperature = int with 5..35; color = bool with (off, ); color Driver = product Temperature * Temperature * ; color Sensor = product Temperature * ; color Hazard = int with 1..2; var t, t1, t2 : Temperature; var s : ; var x : Hazard; Primary place pages for the csidered system are presented in Fig. 1. Each such page is composed of e place representing an object and e transiti for each object activity. It should be mentied, that some simplificatis are applied in presented figures. Weight and time expressis are separated by sign. Initial markings are 235

6 Proc. CS&P '06 a) 1 TurnOn TurnOff Driver Driver (20,20,) SetReqTemp Reading DetectFailure 2 b) Sensor (20,) Sensor Measurement 1 c) (off) AirCditi Cooling d) Temperature (20) Office CoolHeat 1 Fig. 1. Primary place pages placed into parenthesis, initial time stamps, transitis priorities and time expressis equal to 0 are omitted. If a transiti is substituted, then expressis of its surrounding arcs may be omitted. It is sufficient to specify them in the subpage. Primary transiti pages are shown in Fig. 2. Such a page ctains all the places, the values of which are necessary to execute the correspding activity, i.e. the page is composed from e transiti representing the activity and a few places. Designing of a primary transiti page is similar to declaring a procedure in Ada programming language. It is necessary to describe input, output and input/output parameters. Suppose the set of places of the csidered net is ordered as follows: P = { Driver, Sensor, AirCditi, Office, SetReqTemp.Timer, Reading.Timer, Measurement.Timer, Cooling.Timer, CoolHeat.Timer}. The initial state is the pair (M 0, S 0 ), where: M 0 = ((20, 20, ), (20, ), off, 20,,, (1) + (2),, ), S 0 = (0, 0, 0, 0, 0, 0, 0, 0, 0). (3) Let s focus selected primary transiti pages. The Driver is described by three attributes. The first and secd attribute denote the required and current temperature respectively. The transiti SetReqTemp represents setting the required temperature by a user. To model the possibility of changing the temperature from time to time, the transiti is fired every 100 s, but some occurrences may not change the temperature. The transiti can fire if the Driver state is (regardless of the temperatures values), Timer is and time stamps of both places are equal to or less than 0. If it is fired, the time stamp of the place Timer is set to 100 and the transiti must be suspend until the time stamp again decreases to 0. For the Measurement activity, the extra place Timer is used not ly to fire the transiti every 30 s, but also to model the possibility of the sensor failure. The transiti Cooling represents the changes of the current temperature being result of the air cditier work, while CoolHeat represents some random changes of the temperature. 236

7 Part 2: Specificati a) Driver (20,20,) Driver TurnOn [t1 < t2] off AirCditi (off) AirCditi Driver (20,20,) Driver b) TurnOff [t1 >= t2] 1 off AirCditi (off) AirCditi (20,20,) Driver SetReqTemp c) (t,t2,) Timer () d) Driver (20,20,) Driver (t1,t,) (t,) (t,) Sensor Sensor (20,) Sensor Timer () e) Driver (20,20,) Driver (t1,t2,off) DetectFailure s off 2 (t,off) (t,off) Sensor Sensor Sensor (20,) (off) AirCditi AirCditi f) Sensor (t1,) t2 t2 Temperature (20,) Sensor Measurement Office (20) if(x = 1) x 1 Office then (t2,) else (t1,off) x@30 Hazard Timer (1)+(2) g) (off) AirCditi [t2 = 0 or t2 = 1] Cooling Timer () t1+t2 Temperature Office (20) Office Temperature (20) Office h) t1+t2 t1 [t2 = 1 or t2 = 1] CoolHeat Timer () Fig. 2. Primary transiti pages Page hierarchy graph for the csidered RTCP-net is presented in Fig. 3. Each node in such graph represents a single page, and each arc represents a cnecti between a subpage and its substituti transiti. 237

8 Proc. CS&P '06 Driver#1 TurnOn TurnOff SetReqTemp Reading DetectFailure TurnOn#2 TurnOff#3 SetReqTemp#4 Reading#5 DetectFailure#6 Sensor#7 Measurement Measurement#8 AirCditi#9 Cooling Cooling#10 Office#11 CoolHeat CoolHeat#12 Fig. 3. Page hierarchy graph 4.2 Ada implementati This subsecti presents an algorithm of the transformati of an RTCP-net into a framework of Ada 2005 source code. The algorithm does not guarantee that the generated code will be optimal in each case but it should be useful in most cases for embedded ctrol systems. It csists of the following steps: (1) Determining the system boundary: (a) Check the primary places and transitis pages and prepare a list of all places and a list of all transitis the pages ctain. To avoid ambiguity, a place (transiti) name may have attached its page name or/and number if necessary. (b) Divide objects from the first list into two subsets, objects belging to the developed system and objects belging to its envirment. (c) Divide activities from the secd list into three subsets: activities belging to the system, to its envirment, and es that cstitute the interface between the system and the envirment. (d) Elements from the envirment are omitted from csiderati. (2) Determining the system tasks: (a) Take all activities belging to the system as the initial list of tasks. (b) Divide the activities into two subsets, the cyclic and aperiodic es. (c) Eradicate redundant aperiodic tasks, i.e. tasks, which body can be included as a part of a cyclic task. (d) Check primary transiti pages for transiti representing cyclic tasks. If such a page ctains a place that ly remembers the task period, remove the place from the list of system objects. (3) Determining and implementati of the system protected objects: 238

9 Part 2: Specificati (a) For each object belging to the system define a protected object with data representing the object attributes. The correspding types (attributes domains) should be defined if necessary. (b) Eradicate redundant protected objects. If a protected data is used by ly e task and the protected object is not cnected with any outer device, it may be moved from the protected object to the task. (c) For each protected object define procedures and functis for managing the protected data if necessary. (4) Determining and implementati of the system interface: (a) For each activity belging to the system interface determine interrups needed to implement the cnecti between the system and its envirment. (b) Define procedures to handle interrups in the correspding protected objects. (5) System implementati and optimalizati: (a) For each determined task define its body. (b) Determine priorities values for tasks and protected objects. (c) Parametrize the tasks and protected objects. (d) Using the functial level of the model define bodies of all functis and procedures. Table 1. System boundary Objects Activities system Driver TurnOn Sensor TurnOff AirCditi Reading Reading.Timer DetectFailure interface SetReqTemperature Measurement envirment Office CoolHeat Measurement.Timer Cooling CoolHeat.Timer Cooling.Timer Let s csider the RTCP-net presented in secti 4.1. The lists of objects and activities are presented in table 1. The initial list of tasks ctains the following elements: TurnOn, TurnOff, Reading and DetectFailure. Only the task Reading is a cyclic e. The tasks TurnOn, TurnOff can be eradicated (their bodies can be included into the Reading task body). Hence, the implementati will ctain ly two tasks Reading and DetectFailure. Moreover, the object Reading.Timer should be deleted from the list of the system objects. Therefore, it is necessary to define three protected objects: Driver, Sensor and AirCditi. A part of the definiti of the protected object AirCditi is presented below. The Boolean type stands for the color. 239

10 Proc. CS&P '06 protected AirCditi is procedure TurnOn; procedure TurnOff; functi Get return Boolean; private state : Boolean := false; protected body AirCditi is procedure TurnOn is begin state := true; Due to the SetReqTemperature transiti, the protected object Driver will ctain two procedures to handle two interrups (a keyboard with arrow up and down keys used to set the required temperature). type Temperature is new Integer range 5..35; protected Driver is procedure SetTemperature(newTemp : in Temperature); procedure Set(new : in Boolean); functi GetTemperature return Temperature; functi GetRequiredTemperature return Temperature; functi Get return Boolean; procedure RequiredTemperatureDecrease; procedure RequiredTemperatureIncrease; pragma Attach_Handler(RequiredTemperatureDecrease, 10); pragma Attach_Handler(RequiredTemperatureIncrease, 12); private temp : Temperature := 20; reqtemp : Temperature := 20; state : Boolean := true; protected body Driver is procedure RequiredTemperatureDecrease is begin if (state = true) then reqtemp := reqtemp - 1; end if; The Sensor protected object is defined in the similar way. The object ctains e procedure to handle the interrupt that is request if the sensor fails. Moreover, it ctains an entry used to trigger the aperiodic task DetectFailure. protected Sensor is entry Failure; functi GetTemperature return Temperature; 240

11 Part 2: Specificati functi Get return Boolean; procedure SensorFailure; pragma Attach_Handler(SensorFailure, 24); private temp : Temperature := 20; state : Boolean := true; failed : Boolean := false; protected body Sensor is entry Failure when failed is begin failed := false; The cyclic task Reading is the main part of the system. Within the loop the task reads the state of the Driver and Sensor and turn the AirCditi /off if necessary. task body Reading is nextperiod : Time; period : cstant Time_Span := Millisecds(30000); temp : Temperature; begin nextperiod := Clock + period; loop delay until nextperiod; if (Driver.Get = true) and (Sensor.Get = true) then temp := Sensor.GetTemperature; Driver.SetTemperature(temp); if (temp > Driver.GetRequiredTemperature) and (AirCditi.Get = false) then AirCditi.TurnOn; end if; if (temp <= Driver.GetRequiredTemperature) and (AirCditi.Get = true) then AirCditi.TurnOff; end if; end if; nextperiod := nextperiod + period; end loop; The secd task (DetectFailure) is an aperiodic e. The task infinite loop ctains as the first statement a call to the protected entry Failure. If a failed of the Sensor is detected the task turns the Driver and AirCditi off. task body DetectFailure is begin loop 241

12 Proc. CS&P '06 Sensor.Failure; AirCditi.TurnOff; Driver.Set(false); end loop; The main parts of the driver source code have been presented above. Some improvements in the source code should be made next. To satisfy the Ada Ravenscar Profile limits, priorities for the tasks and protected objects must be defined. Declarati of the parametrized task type Reading is presented below: task type Reading (taskpriority : System.Priority, taskperiod : Positive) is pragma Priority(TaskPriority); Moreover, some code optimalizati is possible. For example, the variable temp can be moved from the protected object Driver to the task Reading and the procedure SetTemperature and functi GetTemperature of the object can be removed. 5 Summary Some aspects of the transformati from a formal RTCP-net model into an implementati in Ada 2005 programming language have been presented in the paper. RTCP-nets have been defined to equip coloured Petri nets with capability of direct modelling of elements typical for ccurrent programming. Thus, it is possible to formulate some general rules that should be obeyed during the transformati and such rules have been described in the paper. The presented results are a first step toward working out tools for automatic transformati of an RTCP-net into Ada source code framework. References 1. Ada Reference Manual ISO/IEC 8652:200y(E) Ed. 3 (2006) 2. Burns, A., Dobbing, B.: The Ravenscar Profile for Real-Time and High Integrity Systems. CrossTalk 16(11) (2003) Burns, A., Dobbing, B., Vardanega, T.: Guide for the Use of the Ada Ravenscar Profile in High Integrity Systems. University of York Technical Report YCS (2003) 4. Cheng, A. M. K.: Real-Time Systems. Scheduling, Analysis, and Verificati. New Yersey, Wiley Interscience (2002) 5. Jensen, K.: Coloured Petri Nets. Basic Ccepts, Analysis Methods and Practical Use. Vol. 1-3 Springer-Verlag ( ) 6. Sommerville, I.: Software Engineering. Pears Educati Limited (2004) 7. Szpyrka, M.: Fast and Flexible Modelling of Real-Time Systems with RTCP-nets. Computer Science 6 (2004) Szpyrka, M.: Analysis of RTCP-nets with Reachability Graphs. Fundamenta Informaticae (to appear) (2006) 9. Szpyrka, M., Szmuc, T., Matyasik, P., Szmuc, W.: A Formal Approach to Modelling of Realtime Systems Using RTCP-nets. Foundatis of Computing and Decisi Sciences 30(1) (2005)