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



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



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

Design Issues in RTS

Documents

Transcript of Design Issues in RTS