Download - Design Issues in RTS
8/2/2019 Design Issues in RTS
http://slidepdf.com/reader/full/design-issues-in-rts 1/3
esign issues in real-time
Getting control of the parameters and the terminology involved
Most of us are familiar with sys-tems in which data needs to be proc-
essed at some regular and timely rate.
For example, an aircraft uses a sequence
or stream of accelerometer pulses to de-
termine its current position. In addition,
other systems require ‘‘fast’’ esponse to
events that are occurring at non-regular
rates such as an over-temperature failure
in a nuclear plant. In some sense it is
understood that these events require
“real-time” processing.
Now consider a situation in which
you approach an airline reservation
counter and request Flight 432 from
New York to Boston that’s leaving in 30minutes. The reservation clerk enters
your request in the computer and a few
seconds later produces a boarding pass.
Is this a real-time system?
Indeed, all the above systems are
real-time because they must process in-
formation within a specified interval or
risk system failure. Thus, in some way,
one wishes to define clearly when a
system is real-time and when it is not.
What is a real-time system?A real-time system is a system whose
correctness depends on timeliness as well
as logical correctness. Another way of
saying this is that the system must satisfy
explicit (bounded) response time con-
straints or it is assumed that it will fail.
What is considered a “failed’ system’? n
the case of the Space Shuttle or a nuclear
plant it ispainfully obvious when a failure
has occurred. For other systems, such as
an automatic bank teller machine, the no-
tion of failure is less clear.
For our purposes, we will define fail-
ure as the “inability of the system to
perform according to system specifica-
tion.” It is because of this definition of
failure that precise specification of the
A simple program
Fig. 1system operating criteria, including tim-
ing constraints, is so important.
Real-time systems are often reactive
or embedded systems. Reactive systems
are those which have some ongoing in-
teraction with their environment, for ex-
ample a fire-control system which
constantly reacts to buttons pressed by a
pilot. Embedded systems are those used
to control specialized hardware and lack
an operating system and associated de-
vices for general user interface. For ex-
ample the microprocessor system
residing in many automobiles used to
control the fuel/air mixture in the carbu-
retor is clearly embedded. Similarly, the
software used to control the Inertial
Measurement Unit of the Space Shuttle
is highly embedded. Incidentally. sys-
tems that are not embedded are some-
times called orgcrizic. sytetns if they are
not designed for a specialized hardware
application. and loosely coupled or semi-
detuched if they can be made easily or-
ganic with the rewrite of a few modules.
Of course ou r three previous exam-
ples satisfy the criteria fo r a real-time
system precisely. An aircraft must proc-
ess accelerometer data within a certainperiod that depends on the specifica-
tions of the aircraft. fo r example every
I O milliseconds ( I O thousandths of a
second) . Failure to do so could result in
24
a false position or velocity indicationand cause the aircraft to go off-course at
best or crash at worst. For a nuclear
reactor over-temperature problem, fail-
ure to respond swiftly could result in a
melt-down. Finally an airline reserva-
tion system must be able to handle a
peak rate of passenger requests within
the passenger‘s perception of a reason-
able time (o r as fast as the competitor’s
system). In short. a system does not
have to process data in microseconds to
be considered real-time; it simply must
have response times that are constrained
and thus predictable.
When isa system real-time?It can be argued that, in a sense, al l
systems are real-time systems. Even a
batch-oriented system, like the kind
many insurance companies now use to
process automobile insurance punch
cards, is real-time. Although the system
may have response time of days or
weeks (the time between when you mail
your card and are returned your insur-
ance certificate). it must respond within
a certain amount of time or your insur-
ance will lapse-a disaster. Even a
word-processing program should re-
spond to your commands within a rea-
sonable amount of time (e.g.. 1 second)
or it will become torture to use.
Most literature refers to such systems
as sqft red - t im e s ~ s t e m s ,hat is systems
where performance is degraded but not
destroyed by failure to meet response
time constraints. However, systems
where failure to meet response time con-
straints leads to system failure are called
hard real-time sjsterns. For the remain-
der of this article. we will use the term
“real-time system’’ to mean hard real-
time system U ithout loss of generality.
Events and determinismI n software systems, achange in state
results in a change in the flow-of-con-
trol of the computer program. What is
IEEE POTENTIALS
8/2/2019 Design Issues in RTS
http://slidepdf.com/reader/full/design-issues-in-rts 2/3
f l ow of -con t ro ? Consider the flow
chart i n Figure 1. The decision block
represented by the triangle suggests that
the stream of prognm instructions, like
water flowing through a pipe into a Y-shaped joint. can take one of two paths
depending on the response to the ques-
tion. IF-THEN, GO T0 and CASE state-
ments in any language represent possiblechanges in flow-of-control. Statements
such as subroutine calls in FORTRAN
and invocation of procedures in C, Pas-
cal or Ada represent changes in flow-of-
control. In general. any occurrence that
causes the program counter to change
non-sequentially is considered a change
of flow-of-control and thus an event. We
will see momentarily that hardware sig-
nals can cause a change in flow-of-con-
trol and thus are events.
Events can be divided into two cate-
gories: ~ r i c ho n o ~ ~ snd a s y h r o ~ ~ o i ~ s .
Synchronous events are those that occurat predictable times in the tlow-of-con-
trol-such as at the decision box in the
flow chart. You can anticipate this
change of tlow-of-control (although it
may not always happen). Asynchronous
events occur at unpredictable points in
the flow-of-control and are usually
caused by eternal sources.
A clock that pulses "regularly" at 5
milliseconds is not a synchronous event.
Even if the clock could tick at a perfect
5 milliseconds without drift (which i t
cannot for physical reasons). where the
tick occurs within the flow-of-control is
essentially random. You can never count
on a clock ticking exactly at the rate
specified and must design any system
with that in mind.
I n an! + stem, but especially a real-
time system. maintaining control is ex -
tremely important. For any physical
system there are certain states under
which the system is considered to be"out
of control." The software controlling
such a system must avoid these states.
Fo r example. in certain guidance sys-
tems fo r robots o r aircraft, rapid rotation
through a 180' pitch angle can cause a
physical loss of gyro control. The soft-ware must be able to foresee and prepare
for this situation or risk losing control.
Another characteristic of a controlled
software system is that the computer is
fetching anc l executing instructions from
Example
Interrupt Driven System
Fig. 3
tines) or through the use of interrupts. In interrupt-drirwl systems, a set of interrupt
handlers are installed during initialization, while the main program consists of a simple
jump-to-self loop. Interrupts cause the interrupt handler to be invoked in order to react
to the associated event (see Figure 3) .Foregroiirio'/BackSrr,llrld systems are an improvement over purely interrupt driven
systems and are the most com mon solution for embedded real-time applications. In these
systems. the simple jump-to-self loop is replaced by non-time-critical code called the
hrickgroiind. The interrupt driven processes are called theji ,reground. The background
task is fully preemptable by any foreground task and i n a sense. represents the lowest
priority task in the system.
The aircraft navigation system can be set up using the foregroundhack ground scheme.
The five main process cycles, asynchronous 30ms. 5 ms , loins. 40ms, and on e second,
ar e set up as foreground processes. The background process is used for slow built in test
software such as a CPU check and other non-time-critical pro cessing such as data logging
or screen update. It is comm on to increment acount er n background to provide a measure
of t ime-loading or to detect if any foreground proces+ has locked up.
For example. a counter is provided for each of the foreground processes, and is reset
by its respective process. If the background detects that one of the counters is not being
reset. the corresponding task is assumed to be locked and a failure can be indicated.
Foreground/background systems are the best kernel choice when the number of real-time
tasks i s fixed. Unfortunately, these systemb are vulnerable to timing variations, unantici-
pated race conditions and hardware failures. For this reason some companies avoid
designs based on interrupts altogether. -PAL
the program and not the data area of
memory. The latter case can occur inpoorly tested systems and is a catastro-
phe from which there is almost no hope
dict the next state of the system given
the current state and a set of inputs. Inother words, one wishes to predict how
r ~ ~ : ~ t r i - -!.ill l-i-hx.i- i n 211 p c v i h l c cir-
FEBRUARY 1993 25
8/2/2019 Design Issues in RTS
http://slidepdf.com/reader/full/design-issues-in-rts 3/3
Problem
System model-
ing and design
Suitable
programming
languages
Kernel selection
Inter-task
communication
Inter-task
svnchronization
Memory
management
Testing
Table 1
Solution(s)
dataflow
diagrams
Ada
commercial
products
mailboxes,queues
semaphores
dynamic
allocation
test
everything
Possible
Drawback
cannot depictcontrol low
poor and
unpredictableperformance
poor and
unpredictable
performance
degrade
performance
deadlock
fragmentation,
degraded
performance
not feasible
cumstances. A system is said to bede-
terministic if for each possible state. and
each set of inputs, a unique set of outputs
and next state of the system can be deter-
mined.
In particular, a certain kind of deter-
minism called event deternzirzisiiimeans
that the next states and outputs of sys-
tem are known for each set of inputs
which trigger events. Thus, a system
which is deterministic is event determi-
nistic. While it would be difficult for a
system to be deterministic only for those
inputs which trigger events. this is plau-
sible and so event determinism may not
imply determinism. We are, however.only interested in pure deterministic
systems. Finally, if in a deterministic
system the response time for each set of
outputs is known. then the system also
exhibits tempor-ul deternziriisni
Each of these previous definitions of
determinism imply that the system must
have a finite number of states. This is a
reasonable assumption to make in a
digital computer system where all in-
puts are digitized to within a finite
range. One side benefit of designing
deterministic systems is that one can
guarantee that the system can respond at
any time, and in the case of temporally
deterministic systems, when they will
respond. This reinforces the association
of control with real-time systems.
One final concept needs to
be introduced because i t is
often used as a measurement of
real-time system performance.
Time-lotrdirig, or the u t i l i w
tioii,fuctoi: is a measure of the
percentage of “useful” proc-
essing the computer is doing.
A system is said to be tirnr-
ovc~rloudecl f it is 100% ortnore time-loaded. Time-load-
ing differs from CPU through-
put. which is a measure of the
number of macro instructions
per second that can be proc-
essed based on some pre-deter-
mined instruction mix.
This type of measurement
is typically used to compare
CPU horsepower for some
particular application. Recall
that a CPU is constantly busy
with the fetch-execute cycle
even when idling (it’s execut-
ing a dummy instruction called a 1 1 0 -
op). fth e computer is never idling, that
is it executes no no-ops. then it is 100%
time-loaded.
Systems which are too highly time-
loaded. say 98%. are undesirable be-
cause changes or additions cannot be
made to the system without risk of
t i me -ov er oad i n g . Sy s te ms which
have low time-loading factors, say
10%.are not necessarily good because
this may imply that the processor and
related hardware may be too powerful
for the application. This means that
perhaps costs can be reduced by pro-curing a less powerful processor.
There is no magic number for time-
loading. While 50% is common for
new products and 80% is acceptable
for systems which do not expect
growth. 70% as a desired time-loading
figure is well grounded in theory.
Real-time design issuesWhy study real-time syst ems? The
design and implementation ofreal-time
systems requires the careful considera-
tion of a variety of issues. Among the
tasks facing the real-time system de-
\igner are:I . The helection of hardware and
software and the appropriate mix
needed for a cost-effective solution.
2. The decision to take advantage of a
commercial real-time operating system or
to design a special operating system.
3. The prediction and measurement
of time-loading and its reduction.
4. The selection ofan appropriatesoft-
ware language for system development.
5. The maximizing of system fault-
tolerance and reliability through careful
design and rigorous testing.6. The design and administration of
tests and the selection of test and devel-
opment equipment.
Addressing these issues for large or
even modest projects can present a stag-
gering task. Table 1 lists some other
problem issues in real-time system de-
sign. possible solutions and their poten-
tial drawbacks. Finally, the techniques
you learn by building real-time systems
enable you to develop “non-real-time
systems” that are more efficient, reli-
able, and maintainable.
Read more about itFurht, Borko, et al., Real-Time
UNIX Systems Design arid Applicatiorz
Guide, Kluwer Academic Publishers,
Boston. 199 1 .
Laplante. Phillip A., Red-T ime
Sjsteiris Desigri arid Analysis: Ai1 Engi-
rieeri arzdDook, IEEE Press, Piscat-
away. NJ, 1993
Th e JmiriitiI qf‘Reul-TimeS j s t e m s is
the archival journal for real-time sys-
tems research. In addsition, two IEEE
societies and their archival journals,
T r a z s a c‘t io 11 s or1 Conzpu t e s and
Trunsuctiorisor1
Sqftnare Engineer-i n g , regularly publishes articles on
real-time systems.
About the authorPhillip Laplante is an Assistant
Professor of Computer Science at
Fair leigh Dickinson Universi ty ,
Madison ( N J ) . He obtained his Ph.D.
degree i n Computer Science and
Electrical Engineering from Stevens
Institute of Technology i n 1990 and
is a Licensed Professional Engineer
i n the state of New Jersey. He has
published o\er two dozen scholarly
papers and three books includingone on real-time systems design and
analysis and another on the UNIX
operating sJ’steni. 1
26 IEEE POTENTIALS