Abstract:

Real-Time systems are becoming pervasive. Typical examples of real-time systems

include Air Traffic Control Systems, Networked Multimedia Systems, command Control
Systems etc. In a Real-Time System the correctness of the system behavior depends not
only on the logical results of the computations, but also on the physical instant at which
these results are produced. Real-Time systems are classified from a number of viewpoints
i.e. on factors outside the computer system and factors inside the computer system.
Special emphasis is placed on hard and soft real-time systems. A missed deadline in hard
real-time systems is catastrophic and in soft real-time systems it can lead to a significant
loss. Hence predictability of the system behavior is the most important concern in these
systems. Predictability is often achieved by either static or dynamic scheduling of real-
time tasks to meet their deadlines. Static scheduling makes scheduling decisions at
compile time and is off-line. Dynamic scheduling is online and uses schedulabilty test to
determine whether a set of tasks can meet their deadlines. The present paper talks about
static and dynamic scheduling algorithms and operating systems support for these
mechanisms.

Contents:

• Introduction
• Key Concepts
• Available tools, techniques, and metrics
• Relationship to other topics
• Conclusions
• Annotated Reference List
• Loose Ends

1.Introduction
Real-Time systems span several domains of computer science. They are defense and
space systems, networked multimedia systems, embedded automotive electronics etc. In a
real-time system the correctness of the system behavior depend not only the logical
results of the computations, but also on the physical instant at which these results are
produced. A real-time system changes its state as a function of physical time, e.g., a
chemical reaction continues to change its state even after its controlling computer system
has stopped. Based on this a real-time system can be decomposed into a set of subsystems
i.e., the controlled object, the real-time computer system and the human operator. A real-
time computer system must react to stimuli from the controlled object (or the operator)
within time intervals dictated by its environment. The instant at which a result is
produced is called a deadline. If the result has utility even after the deadline has passed,
the deadline is classified as soft, otherwise it is firm. If a catastrophe could result if a firm
deadline is missed, the deadline is hard. Commands and Control systems, Air traffic
control systems are examples for hard real-time systems. On-line transaction systems,
airline reservation systems are soft real-time systems.

2.Key Concepts

Classification Of Real-Time Systems

Real-Time systems can be classified from different perspectives. The first two
classifications, hard real-time versus soft real-time, and fail-safe versus fail-operational,
depend on the characteristics of the application, i.e., on factors outside the computer
system. The second three classifications, guaranteed-timeliness versus best-effort,
resource-adequate versus resource-inadequate, and event-triggered versus time-triggered,
depend on the design and implementation, i.e., on factors inside the computer system.

Hard Real-Time versus Soft Real-Time

Table shows the major differences between hard and soft real-time systems. The response
time requirements of hard real-time systems are in the order of milliseconds or less and
can result in a catastrophe if not met. In contrast, the response time requirements of soft
real-time systems are higher and not very stringent. In a hard real-time system, the peak-
load performance must be predictable and should not violate the predefined deadlines. In
a soft real-time system, a degraded operation in a rarely occurring peak load can be
tolerated. A hard real-time system must remain synchronous with the state of the
environment in all cases. On the other hand soft real-time systems will slow down their
response time if the load is very high. Hard real-time systems are often safety critical.
Hard real-time systems have small data files and real-time databases. Temporal accuracy
is often the concern here. Soft real-time systems for example, on-line reservation systems
have larger databases and require long-term integrity of real-time systems. If an error
occurs in a soft real-time system, the computation is rolled back to a previously
established checkpoint to initiate a recovery action. In hard real-time systems, roll-
back/recovery is of limited use.

3.The Nature of Real-Time Systems

An important common feature of the systems presented above is the fact that
they may be divided into 2 separate parts, the process and the controller. Such
terms may lead us to believe that real time systems only exist within the world of control
engineering. The terms process and controller are in this context only meant to separate
the objects in the world existing independently to our efforts and, on the other hand, the
fruits of our efforts to interact with this world automatically, i.e.

! Process: The physical world existing prior and independently

to our technological efforts: car wheels, diesel cylinder, telephone user, e.t.c.

! Controller: The device we construct to interact automatically with the

physical world: main computer in car, uP with SW in mobile phone, e.t.c.

The real world (process) thus determines the proper real-time behavior of the
system.

! Train departure as well as AAU schedule determines the daily live of yours
sincerely.

! Control theory determines that ABS breaker systems have to be submitted

to control 1000 times every second.

! The user determines that at normal writing speed the processing and
echoing of characters in his word processor should not be behind more than 5
characters. Users ! demand that the mean service time at
http://www.altavista.com should be below 1min for 20000 hits.

Implementation Issues
In some real-time systems the interaction with the environment is
spread across ar large area so that distribution of functionality is
feasible - such systems are called distributed real-time systems as
opposed to localized real-time systems.

Distributed systems are naturally a collection of localized systems

connected by loose couplings (computer networks) .

Both distribution and the fact that the real-world interactions are numerous
lead us to recognize that parallel computing (multitasking) is well suited for
real-time systems.

For distributed systems true parallelism is obviously required

whereas both true- and pseudo- parallelism is found to be feasible
paradigms for localized systems due to the multilateral nature of the
interaction with the environment. True parallelism is implemented by a
number of physical processors running simultaneously
facilitating independent design of subsystems each handling the
interaction with their specific part of the environment. Independent
systems may communicate but only across very thin and well
defined communication interfaces.

Pseudo parallelism is implemented in SW by so called scheduler,

located in the interior of an operating system or kernel, to imitate the
multiprocessor situation in order to maintain the independent development of
subsystems. Subsystems do not run simultaneously but the designer should
assume and rely on that in every relevant respect it seems like they do.
Every apparently parallel executing subsystem is called a process as opposed
to the physical processor.

Real time operating platforms

! realtime operating systems: MARS, RT-Linux, Solaris, Windows NT

! realtime kernels: RTOS, Kernel

! realtime languages: Realtime PASCAL, Concurrent PASCAL, JAVA

All offer means for Inter Process Communication (IPC) in the form of
message queues, semaphores or monitors. Likewise tools for timing like
HW/SW timers or timer semaphores are supported. True and pseudo
paralellism are not mutual exclusive. Operating systems like Solaris are fully
equipped to handle a number of physical processors supporting an even
larger number of processes.

Development models

Following the OOA scheme we would initiate analysis by structuring the

problem area, i.e. the part of the world relevant to our system.

Following the CODARTS approach we do the same but now with a slight
change of focus. Now the relevant part of the world would not be complex
object structures but instead the physics interfacing directly to our system.

CODARTS is for concurrent object oriented design and analysis of real time
systems. Its emphasis is on the interfaces to the physical world and the
intrinsincly parallel nature of real time systems.

Therefore it is specially focused on task structuring according to timing

issues, as well as Inter Process Communication (IPC), that may influence
the timing characteristics of the final design.

Subsystems
CODARTS proceeds with considering dividing the entire system into
subsystems. Subsystems are recognized as groups of similar functionality
or localization.

When a localization criterion is applied the resulting system is likely to

be distributed whereas functionality may belong to one of the groups
presented below:

! Realtime control: Implementing one or more real-time control loops

(wait,input,compute,output)

! Real-time coordination: Overall elevator control. Balance control of

car. (speeder, steering wheel, wheel tacho, accelerometer, dampers)
 ! Data collection: Typically non-time-critical logging of history.
! Data analysis: Typically complex and non-time-critical, but time
critical examples exist: Geiger counter.

! Server: Database services.

! User services: User interface.

! System services: File system, network system e.t.c.

Behavioral specification
The behavioral specification of every objects is done by means of:

! Control transformations: Finite state machines capable of initiating and

ending data transformation.

! Data transformation: Either described by a minispec. (textual) or

collection of a control transformation and a number of data transformations.

Control transformations may only implement a State Transition Diagram

where state transition is performed upon receiving a message.

Message transmission is done during state transition. Arbitrary control

messages may be transmitted but 3 main categories are identified:

! Trigging: Commands to data transformations to perform some action which

could be completed before reaching the target state. (blocking call)

! Enabling: Commands to data transformation to perform actions with

duration beyond reaching the target state. (unblocking call)

! Disabling: Stop execution of action previously enabled.

A rule of thumb may be that trigging is equivalent to procedure calls where

as enabling is a kick off signal to an independent process, that may or may
not report back when it has finished its work. Enabling may be done by
signaling a semaphore of a task queued up in the associated semaphore
queue.

Task structuring
 At this point we are left with a number of control transformations and
data transformations described by MiniSpecs. or STD’s. As we from the
beginning assumed our platform to be of multitasking type so that all our
transformations are to grouped into a preferably lower number of parallel
processes.

There are 2 main considerations to be taken:

! Enough parallel processes to facilitate the optimal processor utilization and

parallel design.

! Not to many parallel processes in order to keep overhead by context

switching down.

First we consider I/O and user role objects. We need to categorize objects
according to the timely nature of the device they are interfacing. We
categorize external devices into

! Active: The device spontaneously activates its associated I/O object

(interrupt)

! Passive: Device is polled by its I/O object. as well as

! Periodic

! A periodic devices.

Most devices will either by Active/aperiodic or Passive/periodic.

! Aperiodic/Active I/O objects are each associated to a process.(task).

! Periodic I/O objects with similar periods may be grouped into 1 process.

! Periodic I/O objects where periods divide may be grouped into 1 task

If periods are very different in magnitude introduce unnecessary overhead.

When objects are grouped by period like above we say that tasks are
structured according to temporal cohesion. For internal objects we may use
the criteria above. Likewise a few other criteria are introduced.

! Functional cohesion where tasks performs nearly identical functions.

! Sequential cohesion: Is when a number of objects stimulate each other in

a fixed sequence to execute. Then they may be collected into one task.
! Control cohesion: This type of cohesion has to do with the grouping of
control transformations and data transformations that interact.

1. When data transformations are triggered by control transformations the

2 may be grouped into one task.

2. When data transformations are enabled by a control transformation the

2 should be in separate tasks. (Both should be active when the disable
stimulus is arriving.)

3 One may overrule the above criterion when the enabled data
transformation is the one receiving the disabling stimulus.

Time characterization of tasks

After task structuring we will proceed by defining some important
concepts and the appropriate notation to deal with the .

! Ready time: r is the instant in time so that the job can begin
executing after r and not before.

! Computation time: c is the duration of the job assuming it

occupies the processor totally.

! Starting time: S is the instant where the first instruction

associated to J is executed.

! Completion time: C is the instant where the last instuction

associated to J has just ended.

! Deadline: d is the instant before which the job has to finish in

order to meet realtime requirements.

Comparison of development models

From OO* viewpoint:

OO* CODARTS
Analysis of Problem domain: Model component is embedded in
Information modelling which ends dataabstraction objects.
up in the model component.
 Analysis of application domain: List Demands and user types are
of demands, user types, user preanalytic (specification phase).
interfaces and use patterns. User types is low numbered.

Use patterns is embedded in

Achitectural design: Components,
Model, Functional and Interface
component.
scenarios developed for designing
the functionality.
Subsystems, taskstructuring.

Real-Time Scheduling

A hard real-time system must execute a set of concurrent real-time tasks in such a way
that all time-critical tasks meet their specified deadlines. Every task needs computational
and data resources to complete the job. The scheduling problem is concerned with the
allocation of the resources to satisfy the timing constraints. Figure given below represents
a taxonomy of real-time scheduling algorithms.

Real-Time scheduling can be categorized into hard vs soft. Hard real-time scheduling can
be used for soft real-time scheduling.
Hard real-time scheduling can be broadly classifies into two types: static and dynamic. In
static scheduling, the scheduling decisions are made at compile time. A run-time schedule
is generated off-line based on the prior knowledge of task-set parameters, e.g., maximum
execution times, precedence constraints, mutual exclusion constraints, and deadlines. On
the other hand, dynamic scheduling makes its scheduling decisions at run time, selecting
one out of the current set of ready tasks. Dynamic schedulers are flexible and adaptive.
But they can incur significant overheads because of run-time processing. Preemptive or
non preemptive scheduling of tasks is possible with static and dynamic scheduling. In
preemptive scheduling, the currently executing task will be preempted upon arrival of a
higher priority task. In non preemptive scheduling, the currently executing task will not
be preempted until completion.

Examples of real-time systems.

! Animation graphics in an mpeg viewer on a PC.

! Sound effects in your windows theme.

! Yours sincerely. As a response to alarm clock wake up call at 7.00 AM he

should: enter train (Hjørring/Aalborg) at 7.47, reach AAU at 8.50, perform a
reasonable amount of work, reach bus (AAU, Railway station) at 4.13 PM,
reach train (Aalborg/Hjørring) at 4.46 PM.

! GSM telephone system.

Key people

• SAIEEP J (PESIT)
• David Dill
• Rajeev Alur
• Costas Courcourbetis
• Alan Burns
• Nicolas Halbwachs

Conclusions
Real-Time systems span a large part of computer industry. So far most of the real-time
systems research has been mostly confined to single node systems and mainly for
processor scheduling. This needs to be extended for multiple resources and distributed
nodes. Real-time systems are expanding to several other domains such as automotive
industry and embedded real-time systems. Especially the marriage of the Internet with
multimedia applications has opened several new volume applications.