A Tool for Modeling and Simulation of Real-Time Systems Behaviour

Doina Zmaranda & Gianina Gabor Department of Computer Science, University of Oradea

1 Universitatii Street, 410087 Oradea, Romania Phone: (+40) 259-408204, e-mail: zdoina@uoradea.ro; gianina@rdsor.ro

Abstract - In several real-time applications, tasks are not only subjected to complete their deadlines, but more control of the scheduling process is required [11]. In such situations, quality of service is interpreted in many ways (jitters, response times, etc.). In other real-time environments the objective is to optimize a performance measure while respecting release times and deadlines; other environments permit modifications of release times, but not of the deadline times, in a controlled manner. This paper focus on additional issues related on precedence constrains and variable execution times that could be considered during scheduling. In this idea, the paper presents a way of possible integration of such issues into a tool used for modelling and simulation of real-time systems behaviour.

I. INTRODUCTION

Most existing scheduling algorithms only cope with satisfaction of deadline constraints. But, there are several other issues that must be taken into consideration, such as precedence relationships between tasks or variable execution times [3] [16]. Another issue that could be also considered is the scheduling assessment from different point of views, for example taking into consideration both periodic and aperiodic tasks, most existing scheduling algorithms for hard real-time systems being either periodic or aperiodic, but not both [1].

Consequently, a general task specification model that can be used for describing for each task Ti the timing characteristics uses the following parameters [5]:

- task identifier IDi and/or name (unique) Ni – defines a task uniquely

- task i execution or computing time Ci– the execution time of a task can vary within an interval [CBi, Cwi] where CBi and Cwi are the best respectively the worst case execution times for the task i (in most of the cases Worst Case Execution Time is denoted by WCETi); generally, only the best and the worst execution time of each task are known. When modeling the timing behavior of tasks, this is a natural approach, because exact computation time of a task cannot be establish. Consequently, both times have to be considered when creating a task behavior model, and results must be compared; another approach could analyze the timingbehavior starting from the idea of variable execution times [6].

- task deadline Di – deadline is a typical task constraint in real-time systems: the time before which the task must complete its execution. Usually, the deadline of the task is relative, meaning that, from the moment when a task Ti arrives, it should finish within Di time units [7].

- task period Tiper – for periodic tasks, task period Tiper is considered to be equal to task deadline Di

- task ready (arrival) time Ri – represents the moment of time when the task Ti is ready for execution.

- precedence constrains - generally, in a real-time system, tasks are not running independently: several relations exist between the implied tasks. One important relation between tasks is the precedence relation: task j precedes task i, if task i could not be executed until task j finishes its execution.

The paper is organized as follows: chapter II presents theoretical issues regarding scheduling: integrating periodic with aperiodic tasks, including precedence constraints and variable execution times.

Chapter III presents an implementation of a tool that tries to integrate some of the additional issues presented in chapter II into scheduling process, in order to make an attempt to create models and simulations more suitable for real-time systems.

II.ADDITIONAL ISSUES REGARDING SCHEDULING

A. Integrating Periodic with Aperiodic Tasks Periodic tasks typically arise from sensor data or control

loops, while aperiodic tasks generally arise from operator actions or aperiodic events. However, in practice, most real-time systems requires an integrated and consistent approach, suitable for scheduling periodic tasks that have hard deadlines along with aperiodic tasks (generally represented by alerts, that require guaranteed response time). The problem of jointing during scheduling both types of tasks has several implications, and, consequently, needs a specific approach [2]: generally, the simples approach is to construct a special periodic task, a so called polling task PT, with a relatively high priority TPT that is used to provide service to aperiodic tasks arrivals [15]. This special polling task is ready to run at the start of its period and services pending or arriving aperiodic tasks over the interval from the start of its period until CPT units later (where CPT

represents task’s computation time). The PT is subject to preemption by higher priority tasks,

until either it exhausts its execution time or there is no aperiodic work left to be executed. In the latter case, it loses any unused execution time and is unavailable to service aperiodic tasks until the start of the next period TPT.

Using this approach, the PT is scheduled as if it is a periodic task with period TPT. The chosen priority for the PT is given relative to the other tasks priorities: the PT can execute at any priority level, but, assigning to the PT the highest priority allows one to guarantee that deadline for aperiodic alerts are met.

B. Scheduling with Variable Execution Times When using fixed priority schedulers, and computation time

for each task is known, it is possible to compute directly a set

211978-1-4244-1608-0/07/$25.00 ©2007 IEEE.

of priorities for each task that, associated with an on-line scheduler leads to good performances. Such tools are needed at the design step, in order to build up a schedule with expected performances. But the complexity of the scheduling increases if computation time of tasks cannot precisely estimated because it may vary in a known interval.

The offline dispatching with variable execution times scheduling model investigates the schedulability of a set of tasks, when execution times for these tasks are not given in a fixed way, instead, an interval is given that defines the lower and upper bound for execution time of a task [9]. Time specifications establish minimum and maximum constrained relationship between occurrences of events.

When specification of a program is generated, event-driven constraints are generally translated into equivalent relationships between start and finish times of a task. This helps and eases the process of scheduling and dispatching them to guarantee that those constraints will hold [4].

When considering variable execution times for a set of sequentially tasks, the following assumption are made:

- the tasks are denoted by 1, 2, ….n, and the set of tasks with Tset = {1, 2, 3,…..n}

- the order of tasks in predetermined (this assumption relies from real-time control system’s specifications, when a task should start only after another task is finished)

- the tasks cannot be preempted (we have a non-preemptive system)

- each task is characterized by its start time, the start time for task I is denoted by si

- each task is characterized by its actual execution time, ei ; this value could vary from an execution to another, generally being defined using an interval [minei, maxei] where minei corresponds to the minimum execution time of task i and maxei corresponds to the maximum execution time of task i , so the actual execution time ei

∈ [minei, maxei]. Several constraints are define further for the task set,

generally in the form of Cx ≤ V, where C is an [m x 2n] matrix – the constraints matrix (m is the number of constraints and 2n is the dimension of the vector formed by the start and execution times for all n tasks, i.e. [s1, e1, s2, e2, …..sn, en] ) and V is an m-dimension column vector of constant values.

In the set of constraints, the one that denotes the predefined ordering of the tasks is also included.

In the example from Fig.1, time is considered in terms of milliseconds, and the following constrains are defined:

- the constraints for the upper and lower bounds for execution times: 3 ≤ e1 ≤ 9 5 ≤ e2 ≤ 12 (1) 8 ≤ e3 ≤ 15 2≤ e4 ≤ 10

- constraints on the tasks that results from system’s specifications:

s4 +e4 ≤ 88 - task 4 finishes before or at time 88 (2) s4 +e4 ≤ s3 +e3 + 15 - task 4 finishes within 15 ms of task 3 finishing (3)

s2 +e2 + 20 ≤ s4 - task 4 starts no earlier than 20 ms of task 2 finishing (4) s3 +e3 ≤ s1 +e1 + 50 - task 3 finishes within 50 ms of task 1 finishing (5)

- constraints representing the sequential ordering of the tasks:

0 ≤ s1 s1 +e1 ≤ s2 (6) s2 +e2 ≤ s3 s3 +e3 ≤ s4

An example of a constrained sequential task set is depicted in Fig. 1.

Fig.1. A set of tasks with constraints

Solving the above set of equations, given by Cx ≤ V inequality, is the main challenge in this approach. The solving process implies determining the upper and lower bounds for starting times for each task from the constrained task set. It is obvious that, if it is possible to know all execution times in advance (that means that minei = maxei for all i tasks), solving the above equations is trivial.

As it was stated before, in reality task execution time is not so predictable: generally, two different runs is likely to produce different measured execution times. For a given task i, the upper and lower start time limits can be defined using functions, that are dependent from the previously 1…i-1 constraints on tasks.

If such limits could be determined for each task i, for that all constraints are satisfied, then the dispatcher could start the task i whenever it considers within those upper and lower limits. Such an approach benefit of the advantage of a great flexibility, especially when is applied for systems that include a mix of real-time and non-real time tasks.

A method to solve the above equations and determine start times lower and upper limits, is variable elimination technique, that is eliminating one by one the e4 and s4, e3 and s3, e2 and s2

and e1 and s1 variable. Generally, elimination process started to the innermost variable sn determining another set of constraints in which only sn-1, en-1, sn-2….. e1 and s1 variables are presented, that defines the upper and lower limits for s4. So, generally, si

upper and lower limits are defined using only starting and execution times for i-1, i-2, … 1 tasks.

If resulting conditions are every time consistent, then results that task set is schedulable for the given constrains. Using these calculated intervals, evaluation of these functions is done and

SOFA 2007 • 2nd IEEE International Workshop on Soft Computing Applications • 21–23 August, 2007 • Gyula, Hungary – Oradea, Romania

212

lower and upper bounds for the start time of the next task is calculated, using the actual measured execution times and actual start times for all predecessors.

Any point of time between calculated upper and lower limits the task could be released.

Generalizing, based on the above presented case study and using similar notations we will obtain the starting times si for each task as an interval:

s1 ∈ [mins1, maxs1] (7) s2 ∈ [mins2, maxs2] . . . . sn ∈ [minsn, maxsn]

where minsn and maxsn are functions of f (s1, e1, s2, e2, . . . , sn-1, en-1) type.

The algorithm used for the considered case study uses the successively elimination variables (s1, e1, s2, e2, … , si, ei, . . . , sn, en) from the set of constraints. It first removes the innermost evariable, producing a new and refined set of constraints in which en does not appear. Next the algorithm removes the innermost s variable producing a new set of constraints in which sn is eliminated.

The algorithm continues working using an inside out method, and progressively eliminates variables of s and e type, remaining at the end only constraints on s1. If at any stage of the algorithm an inconsistency between constrains is detected, this result in a non-schedulable set of tasks. If no inconsistencies are detected, the algorithm determines minimum and maximum intervals for s1, s2, …, si,…, sn , as shown in relations (7). A proposed schematic form of the algorithm is presented below (C represents the initial set of constraints):

Cn+1=C for (i=n;1;i--) {

Ci=Ci+1 with “∀ei ∈[minei, maxei]” eliminated if inconsistent Ci

minsi= max{f(s1, e1,…, sn-1, en-1) | existing constraints si

≥ f(s1, e1,…, sn-1, en-1) in Ci}maxsi=min{f(s1, e1,…, sn-1, en-1) | exists constraints si ≤

f(s1, e1,…, sn-1, en-1) in Ci}Ci=Ci with “exists si” eliminated

}

C. Scheduling with Precedence Relations Integration of precedence relations into the support tool a

major problem that arises is to check consistency between the release times of the tasks and the deadlines, within a given partial order. Generally, the problem could be formulated in the following way: given a partial order < on the two tasks Ti and Tj, the release times for these tasks (denoted by Ri and Rj), and the deadlines (denoted by Di and Dj) are consistent with the partial order if:

Ti < Tj => Ri ≤ Rj and Di ≤ Dj (8) where generally we use Ri and Di to denote release time and

deadline respectively for the task Ti.

According to the current practice, a task Ti is ready at time t and may be processed if Ri ≤ t. Also, the release time and deadline are satisfied (the schedule being thus feasible) if the start time of the task is greater or equal to its release time and its completion time is less than or equal to its deadline. Consequently, task Ti is eligible to execution only if the current time is greater than or equal to its release time [13].

A consequence of the above relation is the idea that behind the consistency of a partial order stay an enforcement of precedent constrains by modifying release times and deadline in order to obey relation (8). If such enforcement is possible, this gives the initial premises that a scheduling algorithm will also obey to the precedence constrains imposed initially. When considering also a variable execution time for the task set, it is important that precedent constraint conditions to be added to the rest of the constraints and verified prior to start the elimination process.

Based on these precedence relations, a relative order between tasks should be established, if necessary by modifying releases times for tasks in accordance with the given partial order. These modifications add additional constraints to si

variables from the Cx ≤ V equation. Implementation of the above concepts requires several

steps: - given a set of processes, characterized by deadlines,

period, computation time and release time and precedence relations between them, a directed acyclic graph should be constructed to model partial order among tasks: there is an arc from node i to node j if and only if Ti < Tj

- sort the tasks in topological order using topologic sorting algorithm; if algorithm has no solution then the given precedence relations are not consistent and initial data about tasks must be changed

- if the algorithm have several solutions, then all possibilities will be retained and further analyzed

- verify the consistency between the release times and deadlines with the previously determined partial order, according to the assertion formulated in (1)

- if situations where relation (1) is not accomplished are identified, modify releases times and deadlines for tasks in accordance with the given partial order

- analyze the impact of the modifications through the schedulability analysis by simulation using the developed tool from paragraph III.

The characteristic modifications should be made without affecting tasks initial timing constraints; in our approach, thus implying modification of release times with a late value, if this leads to consistency with the imposed precedence order. So, the new release time for a task Ti can be calculated by the following steps:

- if all tasks have been processed, stop; otherwise, processing the tasks should be made in direct topological order

- for the following task Ti is the release time is calculated based on the release time of the previous task Ti-1 in the

D. Zmaranda, G. Gábor • Tool for Modeling and Simulation of Real-Time Systems Behaviour

213

above determine topological order, according to the following relation:

Ri = max (Ri , Ri-1 + Ci-1 ) (9) where Ci-1 is the worse computation time for predecessor task Ti-1, and Ri and Ri-1 are the release times for tasks Ti and Ti-1 respectively.

- go to the first step.

III.TOOL STRUCTURE AND IMPLEMENTATION

The developed analysis tool permits modeling, simulation and schedulability analysis for real-time systems, and was implemented in Visual C++. It is divided into two parts: a specification part and an analysis part (Fig.2).

In the specification part, user models the analyzed real-time system, by given all initial data about the set of tasks. The framework provides a graphical user interface for specifying system’s (tasks) initial characteristics and a simulator for simulation of tasks execution.

In the analysis part, the given real-time system is analyzed from the schedulability point of view. Also, system’s dynamic behavior could be observed and several optimizations could be done based on these observations. The framework implements the most used scheduling algorithms, grouped into two categories: periodic and aperiodic.

Between of periodic tasks, one is usually a polling task for processing aperiodic events, as it was stated in chapter II.A; system’s designer should decide about its priority according to system’s initial specifications. From the tool’s point of view, this task is viewed in a similar way as the other tasks. This approach permits to mix periodic and aperiodic tasks during scheduling, a common requirement in real-time systems [11].

Fig.2. Tool general structure

The main features of the analysis tool are the following: - a graphical user interface for introducing tasks

parameters, such as: deadline, execution time, priority, etc; these parameters are saved in a (text) file for each given task, in a specific format

- several scheduling algorithms are implemented, and the user could choose from a list of implemented algorithms. These algorithms are grouped into two

categories: for periodic (Rate Monotonic, Earliest Deadline First, Least Slack Time First, First In First Out ) and non-periodic tasks (Round Robin, Shortest Job First, First Come First Served, Highest Response Ratio Next, Shortest Remaining Time Next).

- a simulator, that shows a graphical representation of the generated trace of execution for the set of tasks, according to the chosen scheduling algorithm. Using this simulation, the points when tasks arrive, when they are suspended or completed could be easily observed. Also, when a tasks miss its deadline (for a non-schedulable set of tasks), this situation is marked in the simulation view using a red cross. By simulation user can validate the dynamic behavior of the system and see how tasks are executing according to their given parameters and scheduling policy

- schedulability analysis implies checking if all tasks meet their deadlines; a message to the user is displayed, that indicates is system is schedulable or not. For the time being, it is assumed that all the tasks released times are given through the interface, together with other tasks parameters. In the future, the framework could be extended by introducing the possibility of creating several arrival patterns for the set of tasks, and the framework will analyze schedulability for all possible resulting states.

Each task is presented as a sequence of components, each with a different execution time and deadline.

TABLE I INITIAL PERIODIC TASK REQUIREMENTS

For example, by adding some precedence constraints for the task set presented in Table I, we have to enforce scheduling algorithm to take this constraints into consideration and provide a feasible scheduling, if it is possible.

Fig.3. Earliest Deadline First scheduling with precedence constraints after release time modifications

According to the relation (8), we have the following:

ID Name R C Tper D Precedence constraints

1 Proces1 (T1) 0 10 80 80 2 Proces2 (T2) 20 20 80 80 after Proces1 3 Proces3 (T3) 10 10 80 80 after Proces4 4 Proces4 (T4) 0 20 80 80 after Proces2

Scheduling algorithms

Task files

Task parameters

Scheduling analysis

Simulator

execution trace

NO

SPECIFICATION ANALYSIS

YES

SOFA 2007 • 2nd IEEE International Workshop on Soft Computing Applications • 21–23 August, 2007 • Gyula, Hungary – Oradea, Romania

214

- (R1 =0) ≤ (R2 =20) => true - (R4 =0) ≤ (R3 =10) => true - (R2 =20) ≤ (R4 =0) => false, so there is an

inconsistency between the imposed release times and precedence requirements

So, after establishing the topological order that satisfies the imposed precedence relations (in this case, this is: T1 , T2 , T4 , T3 ), modification of release times should be done according to (9).

The result is illustrated in Fig.3, showing that, for this example, there is a feasible schedule that takes into consideration also the precedence constraints.

Such analysis should be done also for other scheduling algorithms; also the above discussion could be extended also for deadline modifications too. But, for this situations several additional problems arises for periodic algorithms, where task period is assumed to be equal to task period.

For the time being, the tool computes and verifies if there is a solution for the topological order problem and, if yes, signals the existing inconsistencies for releases times. Then the release times could be modified by user manually, through the application interface.

Further implementation and development of the tool is intended to automatically modify releases times for processes; this could be done by implementing the algorithm that calculates release times based on variable execution times that are given initially. Also, analysis of several scheduling possibilities, and, if possible, choosing the optimal one is intended to be implemented in the future.

IV. CONCLUSIONS

When modeling real-time systems behavior, simplifying assumption should often be made, in order to reduce model complexity.

Therefore, many models that are currently used were limited to situations without precedence constraints. By including precedence constrains into a real-time system’s model, several additional problems arises, thus resulting the necessity to evaluate if a scheduling algorithm is feasible to be used in certain situations.

In this paper we present an approach for integrating precedence constrains into a tool for modeling and analyzing real-time systems. The framework should be further developed and improved; in this idea, possibilities of extending the application with analysis of impact of using variable execution times into the developed tool are currently investigated.

REFERENCES

[1] T.Amnell, E.Fersman, L.Mokrusin, P. Pettersson and W.Yi, “A tool for modeling and implementation of embedded systems”, Proceedings of TACAS’02, vol. 2280 of LNCS, pp. 460-464, 2002

[2] I.Bate, and A.Burns, “A Framework for Scheduling in Safety-Critical Embedded Control Systems”, Proceedings of the 6th International Conference on Real-Time Computing Systems and Applications, pp.467-475. 1999

[3] S.V.A. Campos and E.Clarke, “Analysis and Verification of Real-Time Systems Using Quantitative Symbolic Algorithms”, Journal of Software Tools for Technology Transfer, pp. 260-269, 1999

[4] C.Chejuri, S.Khanna, and A.Zhu, “Algorithms for minimizing weighted flow time”, Proceedings of ACM Symposium on Theory and Computing, 2001

[5] J.Du, J. and J.Leung, “Minimizing mean flow time with release time and deadline constrains”, Proceedings of Real Time Systems Symposium, pp.24-32, 1998

[6] B. Korousic-Seljac, “Task Scheduling Policies for Real Time Systems”, Microprocessors and Microsystems, vol 18, nr. 9, pp. 501-511, 1994

[7] C.Kirch,”Principles of Real-Time Programming”, EMSOFT02, LNCS 2491, Springer-Verlag Berlin, 2002

[8] W.Svrcek, D.Mahoney and B.Young, “A Real-Time Approach to Process Control”, John Wiley & Sons, 2000

[9] Ph.A. Laplante, “Real-Time Systems Design and Analysis – An Engineer’s Handbook” – Second Edition, IEEE Computer Society Press, 2000

[10] J. P. Lehoczy, “Fixed priority scheduling of periodic task sets with arbitrary deadlines”, Proceedings 11th IEEE real-Time Systems Symposium, pp. 201-209, 1990

[11] J.Liu, “Real-Time Systems”, Prentice Hall, 2000 [12] P. Richard, “A Tool for Controlling Response Time in Real-Time

Systems”, TOOLS 2002, LNCS 2324, pp. 339-348, 2000 [13] M. Spuri, J.A.Stankovic, “How to Integrate Precedence Constrains and

Shared Resources in real-Time Scheduling”, IEEE Transactions on Computers, vol 43, no. 12, pp. 1407-1412, 1994

[14] J.Stankovic and K. Ramamritham, “Deadline Scheduling for Real-time systems: EDF and Related Algorithm”, Kluwer Academic Publishers, 1998

[15] J.K. Strosnider, J.P.Lehoczky, and L.Sha, “The Deferrable Server Algorithm for Enhanced Aperiodic Responsiveness in Hard real-Time Environments”, IEEE Transactions on Computers, vol. 44, no. 1, 1995

[16] J. Xu,“On Inspection and Verification of Software with Timing Requirements”, IEEE Transactions on Software Engineering, vol. 29, no. 8, 2003

D. Zmaranda, G. Gábor • Tool for Modeling and Simulation of Real-Time Systems Behaviour

215