IEEE Real-Time Embedded System Workshop, Dec. 3, 2001
1
Preparing SDL code generation for real-time embedded systems modeling Ahmad ALKHODRE, Jean-Philippe BABAU, Jean-Jacques SCHWARZ* Abstract-- SDL is used increasingly for the development of Real time embedded systems. Nevertheless, the associated code generators do not integrate the management of temporal constraints. In this paper, we propose a real-time semantics to SDL for the modeling of real-time systems in order to prepare the code generation. Index Terms --Embedded systems, SDL, Real time systems, Event/Action model, and Architecture.
1
E
INTRODUCTION
mbedded systems interact strongly with a physical process and they are subject to strong reliability constraints, in particular at the temporal level. “A real-time embedded system is defined as a system whose correctness of the system depends not only on the logical results of computation, but also on the time at which results are produced” [4]. Due to their necessary correctness, the development of such systems implies the use of formal languages. Although SDL (Specification and Design Language) is such a formal language, increasingly used for the development of embedded system, it however does not give a clear translation of time and does not provide a complete description in which the model must be executed over the time. In order to use the existing edition and verification tools of SDL (without any modification of SDL or formalisms multiplication), we propose a temporal semantics associated to a standardized architecture supporting the temporal constraints. To prepare the further code generation, a semantic configuration of time allowing a flexible specification of the temporal constraints and temporal knowledge of the system is proposed. In the next part of the paper, we briefly present SDL and its time management possibilities. The third part is devoted to the model of the standardized architecture that will support the temporal constraints. The fourth part emphasizes the real-time semantics. Finally, the work as a whole is briefly illustrated with a short example.
2
SDL: BASIC PRINCIPLE AND REAL TIME:
SDL is a ITU-T standardized language and, because it is supported by an integrated development environment (objectGEODE, Tau)[3], it is widely used in industry. The code generated by the tools is usually based on the services of a real-time multitasking executive. The soformed application is then a set of communicating tasks. SDL can model concurrency and distributed systems; it also owns some specific instructions for temporal data. The language is based on communicating finite state machines (FSM) and abstract data types. It includes the concepts of type and genericity. At the first level, the application is a system made up of blocks (subsystems) related to one another and to the border of the system by channels. Blocks are composed of "substructures " (subblock) and processes. A process in SDL is a communicating FSM with, maybe, several instances being executed in parallel. Communication is made via signals (data) conveyed between blocks by the means of channels. The communicating mechanism is mono-sender/multireceiver, yet, at the time of a transmission of a given signal, only one receiver among those waiting consumes it. Time in SDL can only be defined and manipulated using the NOW instruction and the "timer"[15]. NOW gives access to a global clock and returns the current time. The actions related to the timer are the activation SET (delay) (expiry at NOW+delay) and the termination RESET. When a timer expires, it sends a signal to the waiting processes. At implementation, each action takes a certain amount of time for execution. As SDL does not specify how global time flows, the assumption, during the simulation of a SDL model, is to consider that the duration of an action can be neglected. SDL does not give a clear translation of time and does not provide a complete description in which the model must be executed over time. This raises a problem for the development and the validation of the real-time systems. On the one hand, temporal validation (schedulability analysis) is really on a model of tasks in which each task is characterized by a priority level carried out from the temporal constraints and on the other hand, the SDL code generators do not integrate temporal constraints (not specified in SDL). It is thus
* Ahmad ALKHODRE, Jean-Philippe BABAU and Jean-Jacques SCHWARZ are with the Laboratory of L3i, departement of informatic, INSA-Lyon, 69621 Villeurbanne, France. Email:{ahmad.alkhodre, jpbabau}if.insa-lyon.fr ;
[email protected].
IEEE Real-Time Embedded System Workshop, Dec. 3, 2001 necessary to add real time semantics to SDL in order to build a real time code generator. The research in this field has taken three main directions. The first one focuses on enhancing SDL by adding new structures to describe the real-time features ( QSDL [5] and SDL* [9]). The second one uses SDL to model the behaviour. The model is then translated into another formalism to introduce the temporal requirement (as timed automata IF [6][7]). The third direction proposes to provide SDL with a temporal semantics [8]. That is our case, and we base our approach for the implementation level (within the aim of further code generation) on an architecture model. ARCHITECTURE MODEL
The real time system must react to stimuli (input events) coming from the interfaces with the environment and produce answers (data or output events) within a given deadline. In the case of mono-processor system, the stimuli are distributed according to four categories: interrupts and Data (IT_niv, Update_A_n) sent by the process, periodic clock signals (TOP_p) and messages (local MSG_loc and remote MSG_net). Input data is associated with the stimuli or directly read on the process. Output data (data or events) is associated with the messages (ANS, COM, REP) or becomes output information. The proposed architecture is based on the pattern shown in figure 1. At the implementation, each category of exchange corresponds to a dedicated mode of communication between the application and its environment. For example, A polling server is dedicated to each interrupt and a periodic alarm is associated with each periodic clock signal. A mailbox, or some other queuing mechanism, is linked with the software communication and the exchanged data become shared resources. In order to generate the corresponding code, it is necessary to classify the I/O exchanges between the
application and its environment according to the type of communication used in the exchange. We propose typed naming rules for these signals (cf. table 1). These signals can also convey data not represented here, because it may be specific to a given application. 4
REAL TIME SEMANTICS
The proposed semantics integrates the "Event-Action" model of Jahanian and Mok [1] into the former architecture model. A real-time application is composed of a group of actions that operate on data by taking into account the time flow, and events rising from the computer system or its environment [14]. The temporal constraints expressed on the events are the frequency of their arrivals (minimum elapsed time between two successive events) and the response times (deadline). The temporal constraints expressed on the data are related to the life span and validity, and those relating to the actions are the execution and communication duration. At the implementation stage, the temporal constraints relating to the events and the data are derived on the launched actions by these events and on the actions which processes the data. They can be translated into activation dates of the actions (periodic, sporadic and aperiodic), waiting delays, deadlines, data ages, dates production of data, and delay of take into account the data. First of all, we consider descriptively the stimuli (TOP, IT, MSG) and afterwards, we approach particular case of data. 4.1
Activation models
Based on the three categories of stimuli defined in the architecture model, three activation modes, regarding to the type of signal, are defined. 4.1.1
Periodic activation
The periodic activation must launch an action with the periodicity p according to: @(e1,i+1) - @(e1,i) = p (where
Clock
Environment EXTERN
TOP_p MSG_loc
IT_niv
Application Data Processing
COM Update_A_n
REP
MSG_net Net
Figure 1: architecture model
ANS
messages
Software
3
2
IEEE Real-Time Embedded System Workshop, Dec. 3, 2001 e1 is the launching event of the action and @evt represents the arrival date of the event evt). 4.1.2
3 time-out, it sends a signal to the process, which realizes the corresponding action. Once the temporal constraints and their associated
Activation on interruption
The named signal IT_niv is dedicated to an interrupt which is characterized by its priority level (niv) and by dmin, the minimum interval separating two successive instances of the interrupt. Dmin is defined by: @(IT, i+1) - @(IT, i) > dmin. 4.1.3
Activation by message (locals and/or remote)
The messages exchanged between the processes can be either synchronous RQST_S (waiting for a response synchronization in the transmitting process, figure 2-a) or asynchronous RQST_A (no waiting for the answer figure 2-b). A process can launch or finish when it awaits a message. Moreover, temporal constraints on the minimal time between two sent messages can also be expressed. Sender
Figure 4: periodic activation
Receiver
Figure 2-a: synchronous message exchange. Sender
Figure 3: deadline propagation
Receiver Wait_IT IT_lev(d1,d2) activation_time :=now now-activation_time >d2
Figure 2-b: asynchronous message exchange 4.2
( True
Deadline model.
When an event e1 occurs, a set of actions is to be executed according to a specific deadline. This constraint is expressed by the following law: @(s1,i) - (e1,i) =deadline. (s1: the end of the action). A deadline is therefore associated with each input signal to the system. The constraint is then propagated in an implicit manner, in accordance with the propagation mode [2], to all the signals sent consequently to the input signal. The actions launched by these signals therefore inherit the constraint transferred by the signal. The periodic activation is simple to model in SDL by using the timer with a timeout equal to the period (figure 4): when the timer expires its
)
(
False
)
Processing series
now-activation_time
