THE REPRESENTATION OF PEARL TASKS AS TIMED STATE TRANSITION DIAGRAMS. Roman Gumzej, Matjaž Colnari

Transcription

1 THE REPRESENTATION OF PEARL TASKS AS TIMED STATE TRANSITION DIAGRAMS Roman Gumzej, Matjaž Colnari University of Maribor Faculty of Electrical Eng. and Comp. Sci. Smetanova 17, 2000 Maribor, Slovenia tel.: (+386-2) fax: (+386-2) Abstract: In the article a part of the Specification PEARL HW / SW co-design methodology is presented. As a part of the software architecture design Timed State Transition Diagrams (TSTD) have been introduced for program / task modelling, supporting the PEARL process model. The resulting task models can be translated to PEARL task prototypes in a systematic manner. In the article TSTD semantics is explained, followed by an example of the TSTD to task prototype translation. Copyright 2002 IFAC Keywords: automata theory, computer programs, control systems, real-time tasks. 1. INTRODUCTION Real-time systems are expected to conform to additional safety restrictions beside the real-time imposed limitations. Therefore, it is necessary to design them in a way, which will enable effective verification of their correctness. Different approaches have been used to provide this feature. Usually a single formalism is not enough to express all aspects of real-time systems design. To enable verification, often formal languages and / or mathematical notations are used, for which subsequently a proof can be worked out, e.g.: differential equations' supported formalisms, which describe the system's operation in time and space (Eriksen et al. 1996); formal languages and timed automata (Agha 1991, Chaochen et al. 1996); dedicated state transition automata like CRSM (Shaw 1992) are often used as the basic internal computation model (e.g.: POLIS (Balarin et al. 1997); combinations of conventional CASE methods and state charts as well as graphical techniques with the same expressing power as their formal language counterparts (Dietz 1997) have also been devised to ease the introduction of formal methods into the design process. While enabling formal verification, many of these methods lack the versatility of basic constructs and user friendliness. Therefore graphical formalisms with a larger set of basic constructs have been defined (e.g.: CSR/CCSR (Lee et al. 1991), TTM/RTTL (Ostroff 1997), LACATRE (Schwarz et al. 1993)), while keeping enough "strictness'' to enable verification. As said in the beginning, all these methods have been derived with the goal of ensuring the coherence, consistence and support for the verifiability of the designed models and systems. For pragmatic reasons simulation is often used to check the correctness of the designed systems or parts thereof. Co-designing systems with time limitations also led to the introduction of real-time scheduling algorithms into their co-design and simulation (e.g. Mooney 1998).

2 In this article a part of the Specification PEARL design methodology is presented, which is meant to represent the dynamic part of real-time system s software (program tasks - processes). Task State Transition Diagrams (TSTD) are hierarchical state charts with timing restrictions to the states. They are meant to express the control and in part the data flow components of programs in a real-time system. They are translated to task prototypes. Together with the simulator shell, parameterised by the SW/HW architecture description, they form an executive model of the designed system that is used for feasibility checking by co-simulation. 2. SPECIFICATION PEARL METHODOLOGY The Specification PEARL co-design methodology is based on the Multiprocessor PEARL standard (DIN 66253: Part 3; 1989). It enables the construction of a conceptual system model, whereby its hardware and software architectures may be designed in parallel. For each hardware and software component of the designed system, its relevant timing information is specified. For more information on the constructs and notation of the Specification PEARL language, please refer to (Gumzej 1999). The benefits of using the Specification PEARL methodology are: early reasoning on the system integration, the ability to apply timing parameters to HW / SW constructs, and the ability to check the feasibility of the design before implementation. 2.1 Modelling the tasks. According to (Mok 1991) for most applications, running in real-time their computational model can be written in the form of the following equation : Real-time program model = Data flow model + State automaton + Timing limitations The tasks of the system represent the processes of the running system. Their main properties are: trigger conditions and timing limitations as well as being part of a certain COLLECTION. This information is sufficient to build a rough program model, but it is not enough to determine its feasibility. Therefore, timed state transition diagrams have been introduced, representing their control and data flow as well as their synchronisation and inter-communication through calls to the configuration manager / RTOS of the station, executing the task. A Timed STD represents a single task and has the semantics of a timed finite state automaton, consisting of: start states (task trigger conditions and initialisation actions), working states, super states (for hierarchical decomposition of working states) and final states (finalisation actions). Every state contains the following data: state type (start, working / super and final state), precondition for the states' execution (trigger condition for a start state), time frame (shortest and maximum execution times), timeout action (the action, which is executed, in case a state exceeds its time frame), connection(s) to the next state in case the execution continues successfully, activities, which are carried out within the execution of this state (PEARL-comments and / or system calls). The connections between states represent the applications' progress in time. All connections are local (i.e.: bound to the states of one task). Inter-task co-operation is modelled by the state actions - system calls to the RTOS, being part of a configuration management module. These also trigger the continuation preconditions of the states. The operating system and configuration manager are visible to the user only through their system calls (API) and system configuration, which is set-up by setting the parameters of the STATION. Trigger conditions differ slightly depending on the state type. Only start states have the possibility of explicit (on-demand) triggering. Other state types rely on the following types of preconditions: 1. events (ev), representing interrupts and internal signals. 2. timers (tm), representing timer signals. 3. general conditions (cd) IF-conditions. 4. expressions (ex) returning boolean results from evaluation of internal system states or (RTOS) data structures, which can be used in conditional statements. Only final states may progress automatically (without a precondition - upon successful completion of the previous state). Upon fulfilment of the precondition of a super state the control is automatically transferred to the start state of its sub-chart. If the condition to proceed to the next state is fulfilled by the maximum time frame (maxt) of the current state, the corresponding successful continuation connection is followed. If the minimum time frame is foreseen (mint) it is not checked, whether the continuation conditions are fulfilled, before the specified time has elapsed. The time-out condition is set to the maximum time frame by the beginning of each states execution. In case the timeout occurs before the requested

3 resources are available (the precondition of the a next state is fulfilled), the appropriate on-timeout action is executed. If it is not specified, an error occurs and it is logged. The activities within a state are a set of actions, which are carried out while the task is in this state. It is foreseen that the actions form a single block of PEARL statements including system service calls to the RTOS and/or configuration manager, around which the control structure is formed by the transformation of the chart to program code. Their execution time frames are estimated by the designer and used while setting the time frames for the state. 2.2 Task forming guidelines The role of a task is the same in the Specification PEARL methodology as it is in the corresponding programming language PEARL (DIN 66253: Parts 1, 2; 1981, 1982). Every procedure, which needs to be carried out within a given time frame, is a task. The problem when trying to break the tasks' operations down into states is that simple tasks only have three states: start, working and final. New states are introduced only: (a) if a time-limited logical suboperation is identified or (b) if synchronisation or communication among tasks is necessary. Good decomposition requires only one logical operation, which changes the systems' state, to be executed within a single state. The following task state forming criteria have been selected: a state represents a single logical activity whose execution time can be determined, every task must have at least one start state, one or more working/super states and one final state. 2.3 Modelling the RTOS part Most co-design and verification methodologies don't consider any RTOS. Those who do, and produce executable code, use off-the-shelf operating systems, in which case, the tool is strictly bound to the target RTOS and it becomes harder to adapt for use with other RTOS-es. From this point of view, it seemed meaningful to use a RTOS with a rich set of system calls, supporting the real-time operation like the PEARL RTOS, which can be constrained and adapted for use with other RTOS-es more easily. The executive role of the operating system in the model has been retained, although the communication and reconfiguration parts have been moved to a separate module within the communication manager module (CMM) to support RTOS-less stations. Based on the experience, gained by building a kernel for an asymmetrical multiprocessor real-time system (HaRTOS (Colnari et al. 1998)), a small RTOS kernel was developed which is also used here. The time, which is required to execute the operating system, is assumed constant. Schedule and dispatch cycle requires no handling by the rest of the system and is assumed to require no time at all. This time is considered as being part of the system call service time and is not modelled separately. 2.4 Translation from TSTD to task prototypes TSTD task models are translated to PEARL Task prototypes in two forms: 1. Execution form (as it can be compiled by the PEARL compiler and executed under the supervision of the configuration management program) and 2. Simulation form (as it is used for feasibility estimation by the simulator shell and interpreted). The main difference between the two forms is the way the events are handled in the first case they are handled by the configuration manager (RTOS), whereas in the second case they are generated and handled in the co-simulation environment. Its concepts have been discussed in (Gumzej et. al. 2001). MODULE module_name; SYSTEM;! interrupts, signals and system variables definitions PROBLEM; task_name : TASK MAIN;! initialisation of all global structures state_id = 0;! for start state(s) WHILE '1'B REPEAT CASE state_id ALT (0)! START state:! RESUME task after fulfilment of! the trigger conditions;! perform the appropriate start state's! statements;! wait until next working / super / end states'! preconditions are fulfilled;! set the state_id variable accordingly;! relinquish timeout schedules; ALT (1)! for a WORKING state: AFTER mint RESUME;! perform statements;! wait until next working / super / end states'! preconditions are fulfilled;! set the state_id variable accordingly;! relinquish timeout schedules; ALT (2)! for a SUPER state:! call the procedure, representing the sub-chart; CALL State2;

4 ! check next working / super / end states'! preconditions and set the state_id variable! accordingly;! wait until next working / super / end states'! preconditions are fulfilled;! set the state_id variable accordingly; ALT (n)! END state: AFTER mint RESUME;! perform statements; state_id = 0;! reset task! relinquish timeout schedules; MOD Table 1: PEARL TSTD representation The form of chart data storage of as well as the mechanism for the translation of TSTD charts to PEARL task prototypes are discussed and illustrated throughout the following example. The general PEARL task prototype form, obtained from the TSTD, is shown in Table TSTD TO TASK TRANSLATION EXAMPLE S S1 S3 S3.S S2 S3.Step 2 S3.Step 3 pedestrian crossing. The traffic light is controlled by a simple logic with the output to control the lights and a relay switch for pedestrian crossing. The execution is cyclic and can be represented with the series of steps, depicted in Fig. 2. While starting at Step 1 initially, the series starts upon pressing the button for pedestrian crossing or after 3 minutes after the last cycle. Demands and restrictions: Step 1 is delayed 180 seconds (unless the pedestrian relay switch is pressed beforehand), Step 2 is delayed 10 seconds, Step 3 is delayed 30 seconds, Step 4 is delayed 20 seconds and the execution continues at Step 1. Initial conditions: the red light is turned on for the pedestrians and green light is turned on for cars (Step 1), the relay switch is reset. Traffic light pedestrians Traffic light cars Step Red Green Red Yellow Green Fig. 2. Logical execution table for the traffic light problem The TSTD textual representation (Table 2) consists of fragments of initialisation code for each of the TSTD states. The Precondition represents the trigger condition for the state. As described in Section 2.1, there are four types of preconditions, which can be used here. The maxt and mint parameters have the purpose to determine the time frame for the state's execution. The Action and OnTimeout parts are represented by PEARL statements and comments, which are limited by the "" keyword. While the TSTD graphical representation (Fig. 1) is mainly meant to be used in the CASE design tool, the textual representation is meant for storage (Table 2) and automatic translation to PEARL code prototypes (Table 1) as in the example (Table 3). S3.E S3.Step 4 [State types] START=0 TRANSIENT=1 SUPER=2 END=3 Fig. 1. TSTD representation This example should illustrate the use of TSTDs on a simple task model for controlling a traffic light at a [States] S=START S1=WORK S2=WORK S3=SUPER E=END

5 [S] MinT=0 MaxT=0 Next=S1; S2;! Step1 lights setting [S1] tm(180 SEC) Next=S3; OnTimeout= [S2] ev(button : INT) Next=S3; OnTimeout=! reset button [S3] Next=S; OnTimeout= S3; [State types] START=0 TRANSIENT=1 SUPER=2 END=3 [States] S3.S=START S3.Step2=WORK S3.Step3=WORK S3.Step4=WORK S3.E=END [S3.S] Next= S3.Step2; OnTimeout= DISABLE button; [S3.Step2] mint=10 SEC Next= S2.Step3; OnTimeout=! Step 2 lights setting [S3.Step3] mint=30 SEC Next= S2.Step4; OnTimeout=! Step3 lights setting [S3.Step4] mint=20 SEC Next= S3.E; OnTimeout=! Step4 lights setting [S3.E] mint= Next= OnTimeout= ENABLE button; Table 2: TSTD textual representations for main and sub-tstd diagrams for the example MODULE TL_SUPERVISOR; SYSTEM; button : INT; PROBLEM; Start : TASK MAIN; DCL state_id : FIXED; state_id = 0; WHILE '1'B REPEAT CASE state_id ALT (0)! Step1 traffic lights setting ENABLE button; WHEN button AFTER 180 SEC RESUME; IF button EQ pressed THEN state_id = 1 ; ELSE state_id = 2 ; ALT (1) state_id = 3 ; ALT (2)! reset button state_id = 3 ; ALT (3) CALL S3; state_id = 0; S3 : PROCEDURE; DCL sid FIXED; sid:=0; WHILE '1'B REPEAT CASE sid ALT (0)

6 DISABLE button; sid:=1; ALT (1)! Step 2 lights setting AFTER 10 SEC RESUME; sid:=2; ALT (2)! Step 3 lights setting AFTER 30 SEC RESUME; sid:=3; ALT (3)! Step 4 lights setting AFTER 20 SEC RESUME; sid:=4; ALT (4) ENABLE button; sid:=0; RETURN; MOD Table 3: TSTD PEARL representations for the example 4. CONCLUSION In the article some (co-) design methodologies and formalisms, used in real-time systems design and verification, are discussed. The Specification PEARL embedded control systems co-design methodology is presented - in particular the program task modelling part. The hierarchical timed state chart formalism has been adapted for their use in conjunction with the architectural modelling in the form of Timed State Transition Diagrams (TSTD). The notation and semantics, used in designing the charts and their translation to program tasks, have been defined. In the article also the representation, which is used for storing the diagrams in a CASE environment, is presented. TSTD translation to PEARL task prototypes for (1) compilation and execution on the target architecture and (2) co-simulation with feasibility checking has been worked out. The TSTD formalism is primarily meant to model the dynamical behaviour; hence, for static program design it shall be combined with other appropriate well-established formalisms. ACKNOWLEDGEMENTS This article presents a part of the research project Holistic Embedded Control Systems Design ( ), being financed by the Slovenian Ministry of Education, Science and Sport. REFERENCES G. Agha (1991). The Structure and Semantics of Actor Languages. J.W. de Bakker, W.P. de Roever, and G. Rozenberg, editors, Foundations of Object-Oriented Languages, pp. 1-59, Springer Verlag,. F. Balarin, M. Chiodo, P. Giusto, H. Hsieh, A. Jurecska, L. Lavagno, C. Passerone, A. Sangiovanni-Vincentelli, E. Sentovich, K. Suzuki and B. Tabarra (1997). Hardware- Software Co-Design of Embedded Systems: The POLIS Approach. Kluwer Academic Publishers. Z. Chaochen, Ji Wang and A. P. Rawn (1996). A Formal Description of Hybrid Systems. Hybrid Systems III, eds. R Alur and T. Henzinger and E. Sontag, LNCS 1066, Springer-Verlag. M. Colnari, D. Verber, R. Gumzej and W. A. Halang (1998). Implementation of Real-Time Embedded Control systems. Real-Time Systems, Kluwer Academic Publishers. C. Dietz (1997). Action Diagrams. Proceedings of 22nd IFAC/IFIP Workshop on Real-Time Programming (WRTP'97), September 15-17, Lyon, France. T. J. Eriksen, S. T. Heilmann, M. Holdgaard and A. P. Ravn (1996). Hybrid Systems: A Real-Time Interface to Control Engineering. Proceedings of 8th Euromicro Workshop on Real-Time Systems, IEEE, pp R. Gumzej. Embedded System Architecture Co- Design and its Validation, Doctoral thesis, University of Maribor, Slovenia, R. Gumzej and M. Colnari (2001). An Approach to Modeling and Verification of Real-Time Systems. Proceedings of 4 th IEEE Interntional Symposium on Object-Oriented Real-Time Distributed Computing (ISORC'2001), 2-4 May 2001, Magdeburg, Germany. J. Rumbaugh et al. (1991), Object-Oriented Modeling and Design. Englewood Cliffs, NJ: Prentice Hall. I. Lee, S. Davidson, and R. Gerber (1991). Communicating Shared Resources: A Paradigm for Integrating Real-Time Specification and Implementation. Foundations of Real-Time Computing: Formal Specifications and Methods. Kluwer Academic Publishers. A. K. Mok (1991). Towards Mechanization of Real- Time System Design. Foundations of Real-Time Computing: Formal Specifications and Methods. Kluwer Academic Publishers. V. J. Mooney III (1998). Hardware/Software Co- Design of Run-Time Sytems. PhD thesis. J. S. Ostroff (1997). A Visual Toolset for the Design Of Real-Time Discrete Event Systems. IEEE Transactions On Control Systems Technology. J.-J. Schwarz and J.-J. Skubich (1993). Graphical programming for Real-Time Systems. Control Engineering Practice, Vol. 1, No. 1, pp A. C. Shaw (1992). Communicating real-time state machines. IEEE Trans. Software Engineering, Vol. 18, No. 9, pp