Scheduler 1-2-3: an interactive schedulability analyzer for real-time systems

Scheduler 1-2-3 is an interactive analysis tool that can perform schedulability analysis for the development of real-time computing systems. The schedulability analysis can verify whether all hard real-time tasks in a target system will be completed by their deadlines at the system design phase. Scheduler 1-2-3 is a window-based stand-alone tool that can also be used as a synthetic workload generator in an integrated tool set that consists of a timing tool, a schedulability analyzer, and a real-time monitor/debugger.<<ETX>>

consists of a timing tool, a schedulability analyzer and a real-time monitor/debugger. In this paper, we will focus on our interactive schedulability analyzer, Schedulerl-2-3 2 . First, we present the overview of the real-time computational model we use. Then, we present the objectives of Scheduler 1-2-3 and its internal structure. We also describe both techniques adopted for the schedulability analysis and its interactive operations, and we compare our approach with other related approaches. We then summarize our works and mention future extensions. First of all, let us review software tools which focus on the prediction, detection, and elimination of the timing errors in real-time systems, before stepping into the detail discussion of Schedulerl-2-3.

Timing tools
Unfortunately, most high-level programming languages do not treat "time" as a first class object, then any timing constraint on a real-time activity must be imposed implicitly. This type of "implicit binding" between a code segment and time causes many common timing errors. One way of avoiding the error is to use "time" in the real-time program explicitly. Then, a timing tool which can estimate or measure the average, the worst, and the best case of the timing characteristics of a given program module would be very handy. The timing tool should be available at the design phase as well as the debugging phase. 1 Ada is a registered trademark of the U.S. Government, Ada Joint Program Office.
which is a registered trade mark of Lotus Development An example of such timing tools has been developed for the SARTOR Environment [15], and it can estimate the timing information (i.e., cpu execution time) for a given code segment using a microprocessor simulator. There is also a real-time programming language, called Real-Time Euclid [7] which was designed with a set of schedulability analysis provisions built-in for the sake of schedulability analysis.

Schedulability Analysis Tools
A schedulability analysis tool can verify whether a given real-time task set can meet their timing constraints or not. The benefits of this tool is that it is possible to foresee the schedulability of the target system in prior to the implementation phase. In general, the predictability of the analyzer heavily depends on the scheduling policies the target system use. It is desirable that the analyzer can be applied to various scheduling policies. Moreover, the analyzer should be able to take into account various types of practical system overheads.
There are well-known schedulability analysis algorithms [10,11,14], however, practical interactive analysis tools have not been demonstrated yet.

Real-Time Computational Model
The biggest difference between real-time systems and non real-time systems is time-critical nature.
Real-time systems must respond on external activities. Response must be done in time. Among various types of real-time systems, we first classify the real-time computing tasks as hard real-time or soft real-time. By the hard real-time task we mean that the task must complete its activities by its "hard" deadline time, otherwise it will cause undesirable damage or a fatal error to the system. The soft real-time task, on the other hand, does not have such "hard" deadline and it still make sense to the system to complete the task even if it passed its "critical" (i.e. soft deadline) time. Suppose we use a "value function" [12,20] which represents the task's contribution (i.e., semantic value) to the system as a function of time, we can illustrate the difference. The hard real-time task indicates a step function where the discontinuity occurs at its deadline while the soft real-time has a continuous (linear or non-linear) decreasing function after its critical time.
In both types, a task can be either periodic or aperiodic, A periodic task P t is defined by the total computation time C t , period r, while an aperiodic task AP i is defined by the total computation time C, its distribution mean arrival time Af ( , and standard deviation S r In particular, when a hard real-time task is an aperiodic, we call it a sporadictask where consecutive requests of the task initiation are kept at least Q unit of time apart [14]. It should be noted that it is not our intention to

Objectives
The main objective is to provide an interactive design tool that makes it easy to design a complex real-time system. For the existing systems, the Schedulerl-2-3 can be used to predict the timing effects due to software and hardware modification. Another objective is to utilize Schedulerl-2-3 as a synthetic workload generator, which can be integrated with the other test tools, the timing tool and the real-time monitor/debugger. The objectives are summarized as following.

• Schedulability Analysis
The schedulability is verified for the given hard deadline task sets under the given scheduling algorithm. Currently, we are interested in analysis on the the rate monotonic [11], the first-in first-out (FIFO), the closest deadline first and the round robin scheduling. If a given task set is not schedulable, the following information is reported, namely, when a deadline will be missed first time and which task misses its deadline. Furthermore, Scheduler1-2-3 gives some intelligent suggestions based on the period transformation method [18].

Structure
Schedulerl-2-3 consists of three major modules. They are the Analysis module, the File interface module and the User interface module, as depicted in Figure 3-2. It is easy to port Schedulerl-2-3 to other hosts or to apply the analysis module to another purpose. Those major modules are structured independently of each other.

Analysis Module
The analysis module performs schedulability analysis, response time analysis for aperiodic tasks and monitorability analysis. The rate monotonic algorithm [11] is currently available for schedulability analysis of hard deadline tasks. The scheduling algorithm for aperiodic tasks is currently based on the deferrable server algorithm [9]. Analysis steps are explained in the following section.

Schedulability Analysis Module
In case of schedulable Step-1 Step-2 Step-3

Task Analysis
We will describe the task analysis techniques based on the rate monotonic scheduling algorithm in this section. Although schedulability of real-time tasks is very difficult to predict, the rate monotonic scheduling makes it possible to analyze the schedulability with the closed formula described in this section. Even if the activities of the task set include interprocess communication or mutual exclusion among the task set, the closed form analysis is still possible by using the priority inheritance algorithm [18]. Simulation part will be added to deal with the other scheduling policies.

Schedulability Analysis
The rate monotonic scheduling gives higher priority in execution to more frequently executed periodic tasks. The schedulability analysis is carried out along with the following three steps as shown in Figure   3-3. Suppose there are n periodic tasks whose periods and execution times are represented as T i and Crespectively, where 1 < i <n and T x <T 2 < <T n .

Stepl -Utilization Bound Check:
Under the rate monotonic scheduling, if processor (CPU) utilization is less than n (2 ,/,l -l) with n periodic tasks in the given task set, which is approximately equal to In 2 « 0.693 5 , it has been proved to be schedulable [11]. Therefore, a task set with CPU utilization which is not higher than this limitation is reported to be schedulable, and the subsequent steps are omitted.

Step2 -Harmonic Task Check:
Further research on the rate monotonic algorithm leads to a more sophisticated verification technique, called the Task-Lumping Technique [17]. This technique is used to predict the schedulability if CPU utilization by a given task set exceeds In 2. This Lumping technique tries to lump tasks together so that schedulability test becomes easier and simpler. The Lumping technique is applied iteratively from the most frequency task up to the least frequency task. If all tasks are successfully lumped together, the given task set is proved to be schedulable. One lumping is described as below.
1. The first step tried to lump task,, and task i+p where 1 <i < n-l. If T M is a multiple of T v those two tasks are called harmonic and lumped together into one task, x ; whose period is 2. CPU utilization of task x, is verified, if task, and task <+l are harmonic. CPU utilization of t;, C-/T i + c M IT i+V is below 100 percent, schedulability is guaranteed up to task l+| .

If those two tasks are not harmonic, namely T M is not a multiple of T it schedulability has to
be checked explicitly. In period of r i+l , if both tasks get allocated CPU time that are longer than or equal to their execution times, those tasks turned out to be schedulable and those two are lumped into x : whose period is set to the least common multiple of T-and T M .
4. If task, and task +1 are schedulable, x { would be regarded as task, in the next lumping.
Step3 -Critical Zone Check: Because the Lumping technique is slightly pessimistic, all schedulable task set cannot be found by the lumping technique. In this case, the decision is made by the third stage test, which is a kind of numerical 5 ln average case, the rate monotonic algorithm can schedule task sets with 0.88 or more CPU utilization [8J.
simulation of the critical zone as illustrated below.

Schedulability of task,, the highest frequent periodic task, is verified by confirming its
execution time is less than or equal to its period (C, <T { ). otherwise, there is at least 1 way to schedule / tasks so that all of them will meet their deadlines.

If this simulation finishes successfully for all n periodic tasks, the task set is schedulable.
An amendment -Context switching overhead:

Overhead caused by the context switching must be taken into account, because task creation and elimination consume considerable processor time, and this overhead is not avoidable when periodic tasks which repeat creation and elimination are handled. Schedulerl-2-3 can take context switching overhead into its schedulability analysis by adding those overhead twice into the execution time of every periodic
tasks before an analysis begins.

Integrated Schedulability Analysis with Aperiodic Tasks
It

Scheduler1-2-3 sets the deferrable server's period to the highest period in the task set, when an
analysis includes aperiodic tasks. Then maximum slack time that may be allocated to the deferrable server is found by means of a binary search. Nonetheless, it is possible to set the period arbitrarily by hand and to see the schedulability.

Monitorabllity analysis
The analysis that verifies whether or not the runtime system behavior can be monitored is done by the worst case analysis. First, if the monitoring task (Reporter) is not included in the task set, it reports that the task set cannot be monitored. The Reporter task is in charge of sending event information over the network to the "Visualizer", where event information is analyzed and visualized. If there is the Reporter, 9 the maximum number of events that can occur in one Reporter's period is estimated. If the number of events taking place in one Reporter's period overwhelms the Reporter's capability of sending event information over the network, event information will be lost eventually. In that case, this task set is not "monitorable". The precise analysis steps are described in [21].

User Interface
Schedulerl-2-3 is characterized by its interactive user interface based on a window system of bitmap display. As illustrated in Figure 3

Context switching overhead
Context overhead was taken through the editing window. The effect context overhead has on schedulability is typically illustrated in Figure 3-6, which first shows the task set that used to be schedulable in Figure 3-5 becomes non-schedulable when context overhead is added. Then, as a result  of the analysis, Schedulerl-2-3 reports that the Velocity Updater task will miss its deadline at its 4 th arrival.

Integrated analysis
Creation of the deferrable server and the result of analysis with the deferrable server task is depicted by Figure 3-7 in case of the INS task set. Clicking the Acyclic button creates the deferrable server task automatically and goes into the analysis steps. This example indicates that the schedulability is maintained with 0.96 CPU utilization.

Monitorabllity analysis
Monitorability is analyzed simultaneously along with other analyses as shown in Figure 3-8, where the INS task set can be monitored with maximum number of events coming up in a period of the monitoring task being about 51.6.

This facility makes Schedulerl-2-3
an efficient integrated tool, which can work in the practical world.

For the purpose of testing on the ART Real-Time Testbed, Schedulerl-2-3 generates a workload table after the schedulability analysis. The workload table would be included into a testing program that generates synthetic workload, then the schedulability is practically tested on the ART Real-Time Testbed.
A workload table is shown in Figure 3-9, which would be an include file of a C program.

Related Work
We introduced our approach to schedulability analysis based on an interactive analysis tool Our approach can be classified as the "tool oriented" approach introducing an integrated toolset. Similar approaches has scarcely attempted. On the other hand, some theoretical approaches and language oriented approaches has been proposed. An strong point of the theoretical approach is its generality.
Theoretical approach is not limited to a specific scheduling algorithm, the host machine's architecture or the language used to describe the target system. Meanwhile fewer constraints sometimes leads to a pessimistic or oversimplified analysis. The language oriented approach uses real-time programming languages. This approach takes advantage of precise analysis based on the language specification. By a real-time programming language, we mean a high-level language which explicitly binds the timing

Leinbaugh's Algorithm
A formula well known for analyzing the schedulability of periodic tasks with hard deadline has been given by Leinbaugh. The schedulability analysis technique introduced in this approach consists of the following items.

rate t = TOTN i I (GT i -TOTR i -TOTD i -B-)
• rate;. The ratio of processor time allocated to perform non-critical sections of task. The following constraint must be kept. rate i < 1 • TOTN;. Total processor time for performing non-critical sections, which implies task, can be interrupted and taken over by task that begins non-interruptable execution.
• GTf. The Guaranteed response time of task ; , representing the period of task..

• TOTRr. Total execution time for critical sections included task/s execution. Critical sections
are non-preemptable. TOTR i may be called non-interruptable execution time.
• TOTD;'. Total time spent by task, on handling devices; the worst case should be known precisely.

Real-Time Euclid and Schedalyzer
Stoyenko introduced Real-Time Euclid [19], which is designed with a set of schedulability analysis Two important extensions are also planned in more sophisticated capabilities for the analysis. One is an extension for intelligent diagnostics which include intelligent suggestions (e.g. a result from a period transformation method) to improve the schedulability. Another extension is related with the response time analysis for aperiodic tasks. The current analysis for the aperiodic task set is to estimate their response time under a given scheduling policy. However, a reversed analysis is also important. That is, for a given response time requirement of the aperiodic task set, Scheduler)-2-3 should be able to estimate the necessary specifications of the deferrable server or anything that can produce the given response time.
The goal of this reversed analysis would be to exploit a scheduling scheme for a mixture of periodic and sporadic tasks. Finally, we are also planning to extend the domain of the real-time computational model to a distributed environment, a stochastic execution model, as well as a cooperating task set using shared variables or message passing by using the priority inheritance algorithm.

Summary
Despite advances in Software Engineering, a good programming tools for real-time systems are missing. In particular, we need to develop a better tool set which can easily detect or eliminate nasty "timing error" from a real-time program. In this paper, we described an interactive schedulability analyzer,