esign issues in real-time

Getting control of the parameters and the terminology involved

Most of us are familiar with systems in which data needs to be processed at some regular and timely rate. For example, an aircraft uses a sequence or stream of accelerometer pulses to determine its current position. In addition, other systems require fastresponse 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 thats leaving in 30 minutes. 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 information 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. a false position or velocity indication and cause the aircraft to go off-course at best or crash at worst. For a nuclear reactor over-temperature problem, failure to respond swiftly could result in a melt-down. Finally an airline reservation system must be able to handle a peak rate of passenger requests within the passengers perception of a reasonable time (or as fast as the competitors 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.

A simple program

Fig. 1
system operating criteria, including timing constraints, is so important. Real-time systems are often reactive or embedded systems. Reactive systems are those which have some ongoing interaction with their environment, for example 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 devices for general user interface. For example the microprocessor system residing in many automobiles used to control the fuel/air mixture in the carburetor is clearly embedded. Similarly, the software used to control the Inertial Measurement Unit of the Space Shuttle is highly embedded. Incidentally. systems that are not embedded are sometimes called orgcrizic. sytetns if they are not designed for a specialized hardware application. and loosely coupled or semidetuched if they can be made easily organic with the rewrite of a few modules. Of course our three previous examples satisfy the criteria for a real-time system precisely. An aircraft must process accelerometer data within a certain period that depends on the specifications of the aircraft. for example every I O milliseconds ( I O thousandths of a second). Failure to do so could result in

When is a system real-time?

It can be argued that, in a sense, all 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 insurance certificate). it must respond within a certain amount of time or your insurance will lapse-a disaster. Even a word-processing program should respond to your commands within a reasonable amount of time (e.g.. 1 second) or it will become torture to use. Most literature refers to such systems as sqft red-time s ~ s t e m sthat is systems , where performance is degraded but not destroyed by failure to meet response time constraints. However, systems where failure to meet response time constraints leads to system failure are called hard real-time sjsterns. For the remainder of this article. we will use the term real-time system to mean hard realtime system U ithout loss of generality.

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 constraints or it is assumed that it will fail. What is considered a failed system?In the case of the Space Shuttle or a nuclear plant it is painfully obvious when a failure has occurred. For other systems, such as an automatic bank teller machine, the notion of failure is less clear. For our purposes, we will define failure as the inability of the system to perform according to system specification. It is because of this definition of failure that precise specification of the

Events and determinism

In software systems, achange in state results in a change in the flow-of-control of the computer program. What is

24

IEEE POTENTIALS

fl ow - of - c o n t ro 1'? Consider the flow Example chart in Figure 1. The decision block represented by the triangle suggests that the stream of prognm instructions, like water flowing through a pipe into a Yshaped joint. can take one of two paths depending on the response to the question. IF-THEN, G O T 0 and CASE statements in any language represent possible changes in flow-of-control. Statements such as subroutine calls in FORTRAN and invocation of procedures in C, Pascal or Ada represent changes in flow-ofcontrol. In general. any occurrence that causes the program counter to change Interrupt Driven System non-sequentially is considered a change of flow-of-control and thus an event. We will see momentarily that hardware signals can cause a change in flow-of-control and thus are events. Events can be divided into two categorie s : s ~ r i c r o n o ~ ~ s a s y ch r o ~ ~ o i ~ s . h and Synchronous events are those that occur at predictable times in the tlow-of-control-such as at the decision box in the Fig. 3 flow chart. You can anticipate this change of tlow-of-control (although it may not always happen). Asynchronous events occur at unpredictable points in tines) or through the use of interrupts. In interrupt-drirwl systems, a set of interrupt the flow-of-control and are usually handlers are installed during initialization, while the main program consists of a simple caused by eternal sources. jump-to-self loop. Interrupts cause the interrupt handler to be invoked in order to react A clock that pulses "regularly" at 5 to the associated event (see Figure 3). Foregroiirio'/BackSrr,llrld systems are an improvement over purely interrupt driven milliseconds is not a synchronous event. systems and are the most common solution for embedded real-time applications. In these Even if the clock could tick at a perfect systems. the simple jump-to-self loop is replaced by non-time-critical code called the 5 milliseconds without drift (which it hrickgroiind. The interrupt driven processes are called theji,reground. The background cannot for physical reasons). where the task is fully preemptable by any foreground task and in a sense. represents the lowest tick occurs within the flow-of-control is priority task in the system. The aircraft navigation system can be set up using the foregroundhackground scheme. essentially random. You can never count The five main process cycles, asynchronous 30ms. 5ms, loins. 40ms, and one second, on a clock ticking exactly at the rate are set up as foreground processes. The background process is used for slow built in test specified and must design any system software such as a CPU check and other non-time-critical processing such as data logging with that in mind. or screen update. It is common to increment acounter in background to provide a measure I n an! +! stem, but especially a realof time-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 time system. maintaining control is exby its respective process. If the background detects that one of the counters is not being tremely important. For any physical reset. the corresponding task is assumed to be locked and a failure can be indicated. system there are certain states under Foreground/background systems are the best kernel choice when the number of real-time which the system is considered to be"out tasks i s fixed. Unfortunately, these systemb are vulnerable to timing variations, unanticiof control." The software controlling pated race conditions and hardware failures. For this reason some companies avoid designs based on interrupts altogether. -PAL such a system must avoid these states. For example. in certain guidance systems for robots o r aircraft, rapid rotation the program and not the data area of dict the next state of the system given through a 180' pitch angle can cause a memory. The latter case can occur in the current state and a set of inputs. In physical loss of gyro control. The softpoorly tested systems and is a catastroother words, one wishes to predict how ware must be able to foresee and prepare phe from which there is almost no hope r ~ ~ : ~ t.!.illi - r l-i-hx.i- i n 211 pcvihlc cirfor this situation or risk losing control. Another characteristic of a controlled software system is that the computer is fetching ancl executing instructions from

FEBRUARY 1993

25

One final concept needs to be introduced because i t is Problem Solution(s) Possible often used as a measurement of Drawback real-time system performance. Time-lotrdirig, or the u t i l i w System model- dataflow cannot depict ing and design diagrams control flow tioii,fuctoi: is a measure of the percentage of useful procSuitable Ada poor and essing the computer is doing. programming unpredictable languages performance A system is said to be tirnrovc~rloudeclif it is 100% or Kernel selection commercial poor and tnore time-loaded. Time-loadproducts unpredictable performance ing differs from CPU throughput. which is a measure of the Inter-task mailboxes, degrade number of macro instructions communication queues performance per second that can be procInter-task semaphores deadlock essed based on some pre-detersvnchronization mined instruction mix. Memory dynamic fragmentation, This type of measurement management allocation degraded is typically used to compare performance CPU horsepower for some Testing test not feasible particular application. Recall everything that a CPU is constantly busy with the fetch-execute cycle even when idling (its executcumstances. A system is said to be deing a dummy instruction called a 1 1 0 terministic if for each possible state. and op).lfthe computer is never idling, that each set of inputs, a unique set of outputs is it executes no no-ops. then it is 100% and next state of the system can be detertime-loaded. mined. Systems which are too highly timeIn particular, a certain kind of deterloaded. say 98%. are undesirable beminism called event deternzirzisiii means cause changes or additions cannot be that the next states and outputs of sysmade to the system without risk of tem are known for each set of inputs t i me - o v er I o ad i n g . S y s te m s which which trigger events. Thus, a system have low time-loading factors, say which is deterministic is event determi10%. are not necessarily good because nistic. While it would be difficult for a this may imply that the processor and system to be deterministic only for those related hardware may be too powerful inputs which trigger events. this is plaufor the application. This means that sible and so event determinism may not perhaps costs can be reduced by proimply determinism. We are, however. curing a less powerful processor. only interested in pure deterministic There is no magic number for timesystems. Finally, if in a deterministic loading. While 50% is common for system the response time for each set of new products and 80% is acceptable outputs is known. then the system also for systems which do not expect exhibits tempor-ul deternziriisni. growth. 70% as a desired time-loading Each of these previous definitions of figure is well grounded in theory. determinism imply that the system must have a finite number of states. This is a Real-time design issues reasonable assumption to make in a Why study real-time systems? The digital computer system where all indesign and implementation ofreal-time puts are digitized to within a finite systems requires the careful considerarange. One side benefit of designing tion of a variety of issues. Among the deterministic systems is that one can tasks facing the real-time system deguarantee that the system can respond at \igner are: any time, and in the case of temporally I . The helection of hardware and deterministic systems, when they will software and the appropriate mix respond. This reinforces the association needed for a cost-effective solution. of control with real-time systems.

Table 1

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 appropriate software language for system development. 5. The maximizing of system faulttolerance and reliability through careful design and rigorous testing. 6. The design and administration of tests and the selection of test and development equipment. Addressing these issues for large or even modest projects can present a staggering task. Table 1 lists some other problem issues in real-time system design. possible solutions and their potential drawbacks. Finally, the techniques you learn by building real-time systems enable you to develop non-real-time systems that are more efficient, reliable, and maintainable.

Read more about it

Furht, Borko, et al., Real-Time UNIX Systems Design arid Applicatiorz Guide, Kluwer Academic Publishers, Boston. 199 1 . Laplante. Phillip A., Red-Time Sjsteiris Desigri arid Analysis: Ai1 Engirieer iHarzdDook, IEEE Press, Piscataway. NJ, 1993 The JmiriitiI qfReul-Time Sjstems is the archival journal for real-time systems research. In addsition, two IEEE societies and their archival journals, T r a iz s a ct i o 11 s or1 Conzp u t e r s and Trunsuctioris or1 Sqftnare Engineering, regularly publishes articles on real-time systems.

About the author

Phillip Laplante is an Assistant Professor of Computer Science at Fairleigh Dickinson University, 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 \ e r two dozen scholarly papers and three books including one on real-time systems design and analysis and another on the UNIX operating sJsteni. 1

26

IEEE POTENTIALS