1

Introduction to Real-Time Systems (by Damir Isovic)

Summary: This chapter provides an introduction to real-time systems. First, it presents some typical real-time applications and discusses how they differ from traditional, non-real-time computer systems. Then, it highlights some typical properties of real-time systems, such as timely execution and safety-critical behavior, as well as some of the major challenges with the development of real-time applications. Furthermore, the chapter discusses basic knowledge, methods and techniques for construction of real-time systems. Finally, it presents some of our own experiences within the subject.

1.1

Learning objectives of this chapter

After reading this chapter you should be able to Understand the difference between real-time systems and traditional computer systems Have knowledge and understanding of fundamental real-time systems design paradigms, architectures and possibilities. Obtain knowledge about different classes of real-time systems. Obtain knowledge about major challenges when constructing real-time applications, as well as common misconceptions about real-time systems.

1.2

Introduction

Over the past years, it has become more and more common to use computers to control processes that are traditionally controlled with proven conventional techniques such as mechanics and electro-mechanics. For example, nowadays we can find computers in modern cars, airplanes, and medical equipment, but also in small embedded devices such as cell phones, game consoles, digital cameras, home appliances, etc. One reason for using computer systems is to improve already existing systems. For example, Antilock Braking System (ABS) in a car allows the driver to steer during hard braking, which means that the car can be controlled much better. Before this, drivers had to know how to "pump" the brakes or sense the lockup and release foot pressure in order to prevent skidding. Another example in cars is Electronic Stability Program (ESP), which assist drivers in critical driving situations by monitoring the vehicle's response to the driver's steering and braking. This way, over steer or under steer situations can be avoided. Another reason for replacing mechanical systems with software-based systems is cost reduction. Let's take a car example again. In the past, wiring was the standard means of connecting one element to another. Adding new functionality to the vehicle means also adding new wires, which weakens performance, and makes adherence to reliability standards difficult. Besides, complex wiring harnesses took up large amount of vehicle volume, making

it heavier, and consequently increased fuel consumption. Today, physical point-to-point connections between car components have been replaced by a communication network, where different parts of the vehicle communicate through a common communication network. For example, in a 1998 press release, Motorola reported that replacing wiring harnesses with a common bus network in the four doors of a BMW reduced the weight by 15 kilograms while enhancing functionality. However, replacing hardware solution with software is not a trivial task. Computer systems in safety-critical applications, such as vehicle control systems and medical equipment, must be at least as reliable and safe as the mechanical systems they are replacing. At the same time, computer solutions make it possible to implement more advanced functionality, making the whole system more complex. Also, compared to a mechanical system (e.g., a bridge that will sustain a load up to a certain maximum if it is tested to hold for the maximum load), a computer with its software is potentially discontinuous across its whole range of operation, e.g., correct handling of input values 1 and 27 cannot be used as an indication for correct handling of all intermediate (or other) input values. In software systems, there are no physical limitations, such as mass, energy, density etc, which can be found and measured in other types of systems. The only physical property that we can measure is time, and for the systems mentioned above, it is crucial that the system operates well both in the functional and the temporal domain. The correct behavior of the system does not only depend on the correctness of the result, but also on the time when the result is delivered. These types of systems are called real-time systems. We will provide a more exact definition of real-time systems later in this chapter, but lets first have a look at the history of process control.

1.3

Historical perspective

Through the history, people were always trying to control external processes. One example is controlling the water level on the rice fields via floodgates in ancient China. The control system in this case is a human, i.e., the eyes are sensors that get input from the environment, the brain is a computer, and the muscles are used for actuation. The first mechanical control systems were developed in the 18th century. One example is Spinning Jenny, a mechanical spinning machine with multiple spindles. By turning a single wheel, the operator could now spin eight threads at once. The spinning machine developed further, so that it could be driven by water sources and, later, by a combustion engine. The next step in the development was relays. A relay is a simple electromechanical switch made up of an electromagnet and a set of contacts. Relays are found hidden in all sorts of devices. In fact, some of the first computers ever built used relays to implement Boolean gates. Another application area is telephone switches there are still electromechanical switches in use. Once we entered the computer era, the transition from relays to programmable systems, called Programmable Logic Controller (PLC) was not far away. In a PLC system, the relays are

connected to each other by software that executes on a primitive computer. These systems are built as a loop with a set of instructions that can handle the input data and produce an output. Note that every instruction has to be executed in each cycle, i.e., there is no selection. Figure1 Fel! Hittar inte referensklla.illustrates the principle behind a simple PLC.

Read digital values as input 1 2 3

. . .

I/O-copy

Write digital values as output

x = y AND x

Figure1:PrinciplebehindasimplePLC.

PLC systems are still very common in industry because the systems that are built of PLCs are simple and easy to implement and maintain. The next step in the development was control systems based on microprocessors. It started with single-processor systems with cyclic programs similar to the PLC loop. The main difference was the possibility to include more logics by storing the internal application states, and the possibility to implement iteration and selection. I/O (input/output) was typically polled, i.e., checked periodically. The system usually had a clock that got initiated at the start of the system, and it was used to provide a certain periodicity in the execution. At the beginning of each periodic cycle, new I/O values were loaded from sensors, followed by calculations of new values which were then used to control the process. Then, the system waited for the next cycle by checking the current clock value. The whole idea is illustrated by the program in Figure 2. Later, interrupt handling was added. Interrupt routines made it possible to handle even nonperiodic functions, i.e., functions for which we cannot define a period. One example of such non-periodic function is a pulse counter that counts the number of cars that pass a certain street we do not know how often the cars are passing. Microprocessor systems work well if the controlled environment is not too complex. They are still very common in resource constrained systems (e.g., memory- or CPU limited systems)

that have simple functionality. One example are small control system nodes, e.g., a node that controls electrical power windows in a car.

void main (void){ initializeClock(); while(1){ readSensors(...); actuateProcess(...); else error(); waitForNextCycle(...); } } Figure2:Exampleofasimplecyclicmicroprocessorprogram. /* wait some time and redo everything */ /* system initialization */ /* do repeatedly */ /* read input values from sensors */ /* produce output */ /* do some action based on new values */

if (calculateNewSetValues(...))

It is quite difficult to describe what is the "state-of-the-art" today, since there are many different types of controlled system, but in general we can say that in resource constrained systems we can use microprocessor systems with an instruction loop and interrupt routines. Those are usually system-on-chip computers, i.e., computers that have a CPU, memory and I/O integrated on a single chip. When the application complexity is low, PLC-systems can be used. However, in more complex systems real-time systems can be used. Real-time systems can be executed on a stand-alone single processor, but could also be executed on a distributed computer system consisting of several processing nodes connected through a communication network. The choice of computer system architecture depends on the physical distribution and complexity of the application.

1.4

What is a real-time system?

We mentioned above that many applications require that the system delivers correct data within a specific time interval. One example is the airbag control system in a car, which is designed to protect the driver and passenger against injury in case of collision. Upon a car collision, the system must inflate the airbag within a fraction of a second. If the system waits too long to inflate, the driver and passengers will be both dangerously close to the explosion used to inflate the airbag and/or hit the steering wheel and the dashboard. At the same time, the airbag must not be inflated too early either, since the airbag then will deflate before catching the driver/passenger, resulting in a hard blow to the head or chest that can cause serious injury or death. Hence, there is certain time interval in which the inflation of the airbag must occur not too early neither too late.

Another, less safety-critical example of a system that requires timely delivery is video processing. A video stream consists of a series of still pictures that are displayed in sequence with a certain rate. If the display rate is high enough, e.g., 30 pictures per second, the eye will not detect the void between consecutive pictures and a motion will be perceived. This puts some challenges on the system that is playing the video. With a rate of 30 pictures per second, the system will have 33 milliseconds to process each picture, i.e., to read the picture from disk, decode it and display it on the screen. Delays in processing a picture will result in visible artifacts, i.e., the user will perceive the video as having low quality. Hence, we need to ensure that each picture will be processed in time before the next one arrives. Both examples above show that in some systems it is not enough to produce a correct computational result, this result must also be produced and delivered on time. These systems are called real-time systems and we define them as follows (Stankovic & Ramamritham, 1988): Definition: A real-time system is a system that reacts upon outside events and performs a function based on these and gives a response within a certain time. Correctness of the function does not only depend on correctness of the result, but also on the time when these are produced. Note that the definition above says nothing about the time scale that is to be used. That is because the controlled process dictates the time scale some processes have demand on response at second level, others at milli- or even microsecond level. The most common misconception associated with real-time systems is that their main mechanism and purpose is to increases the execution speed of the application. While this is true in some cases, they actually enhance the application by providing more precise and predictable timing characteristics. With these enhancements, it is possible to determine the exact time when certain events will occur. We can say that the main objective of real-time systems is not to achieve fast computing, it is to achieve timely computing. Fast computing tries to minimize average computation time for the entire system, i.e., all programs that execute all together, while real-time computing fulfils individual timing constraints for each separate program that runs on processor, so called real-time tasks: A real-time task is a sequential program that performs certain computation and possibly communicates with other tasks in the system. A typical timing constraint on a real-time task is the deadline, i.e., the latest point in time at which the task must complete its execution. One such real-time task is the one that controls the airbag in a car, and its individual timing constraints are the earliest and the latest time (deadline) the airbag must be inflated. Sometimes, the word thread is used instead of task. Although they are usually considered as synonyms, there is a distinction that we can make; the term task is used when discussing the design and analysis of real-time systems, while thread is used when talking of the implementation of a real-time task in an operating systems. We can say that thread is an implementation of a task in a real-time operating system.

1.5

Close interaction with the environment

Many applications are inherently of real-time nature; examples include aircraft and car control systems, chemical plants, automated factories, medical intensive care devices and numerous others. Most of these systems interact directly or indirectly with electronic and mechanical devices through sensors and actuators. Sensors provide information to the system about the state of its environment. For example, medical monitoring devices, such as ECG, use sensors to monitor patient status. Air speed, attitude and altitude sensors provide aircraft information for proper execution of flight control plans etc. The process of collecting the data from the environment through sensors is called sampling. Actuators work the other way around, they transform digital data, e.g., result from a computation, into physical format, e.g., brake force in a car. Examples include motors, pumps, machines etc. The process of performing some action on the environment is called actuation. We can make a parallel with the human body. Our sensors are our eyes, ears, nose, skin, everything that we use to collect information from the environment. Our actuators are our arms and legs; we perform some action with them. For example, if somebody throws a ball toward us, we detect it (sampling) with our eyes (sensors) and pass the information about incoming ball (signals) to our brain (computer). The brain makes decision what to do, e.g., to catch the ball (processing) and sends the order (actuation) to our hand (actuator) to catch it. An example of a real-time system that uses sensors and actuators is a computer system that regulates the rotation speed of an electrical engine. It uses a sensor to read the current rotation speed of the engine, another sensor to read the desired rotation speed that a user can set, and an actuator to change the rotation speed. The computer system executes a control algorithm that calculates the new control values based on the input from the sensors, and sends them out to the engine via the actuator, as depicted in Figure 3.

Speed sensor

Electrical motor

Speed actuator

Sensor values (current rotation speed)

New control values (increase/decrease speed)

Computer system

User input

Figure3:Rotationspeedregulationinanelectricalmotor.

1.6

Timing constraints

We mentioned before that fulfilling timing constraints of individual tasks is crucial for correct functioning of real-time systems. One such constraint was the deadline of a task, discussed above in the airbag example. If we continue with our electrical motor example from the previous subsection, we can identify a couple of new timing constraints the latency and the period time of a task; see the timing diagram in Figure 4:

sampling

actuation

sampling

actuation

computation

computation

time
latency period time
Figure4:Asimplecontrolmodelforelectricalmotor.

The latency requirement specifies how fast we need to process the input data and produce an output, and the period-time requirement specifies how often we need to sample in order to get an accurate view of the environment. So, where do the timing constraints come from? One answer is: from close analysis of the controlled process, performed by control engineers. The analysis needs to consider the laws of nature, e.g., bodies in motion arm movement of a robot system has to follow some physical laws. Furthermore, it needs to consider mathematical theory, e.g., recommended sampling rate is equal to half the rate of the sampled signal, artificial deduction, i.e., some constraints are given but some others has to be deduced, etc. In the electrical motor example above, we have probably got the values for allowed latency and period time from a control engineer that has analyzed the process, i.e., the timing requirements of the system. What we need to do now is to construct a real-time system that fulfills those requirements. If we, for example, construct a system where the period time varies too much, it might result in a severely reduced control performance. If the period time is too short, the control algorithm will run too often, taking CPU time from other tasks in the system. If the period, however, is too long, the system could be perceived as slow, i.e., the time between sending a user request to change the speed and actually enforcing the new speed will be too long. This leads us to the problem definition for real-time systems: to construct a computer system so that all individual timing constraints of the tasks are really fulfilled, at the same time as the system resources are shared properly between tasks. Let's have a look at another example with

the terrain collision feature in an airplane that displays a warning in a cockpit when the path of flying intersects the terrain. For example, if there is a mountain in front of the airplane, the system must detect it and issue a warning on time so that the pilot can increase the altitude, see Figure 5.

A warning must be issued latest here

a) Too frequent monitoring b) Sufficient monitoring c) Too infrequnt monitirering Late warning

Figure5:Exampleperiodinanautopilot.

The question here is how often the system shall check the terrain. Sampling too often (scenario a in the figure) means waste of resources if too much time is spent in checking the terrain, some other function in the airplane, e.g., cabin pressure controller, might not get time to execute. If the system, on the other hand, waits too long between two samples, it might detect the change in terrain too late, leading to unavoidable crash (scenario c). Hence, the time between two samples should not be too short or too long, as in scenario b of the figure. Assigning right periods, and other timing constraints in general, is not trivial, since we need to take into consideration both a tasks own individual timing requirements and the other tasks in the system that compete for the same resources, e.g., CPU time. We will see in later chapters both how we can assign appropriate timing constraints to tasks, and how the system should schedule tasks so that they meet their requirements.

1.7

Characteristics of real-time systems

Beside the most obvious properties that weve discussed several times so far the timeliness and close interaction with the environment real-time systems have the following other important characteristics: Predictable execution To guarantee a minimum level of performance, the system must be able to predict the consequence of any scheduling decision. If some task cannot be guaranteed to execute within its time constraints, the system must notify this fact in advance, so that alternative actions can be planned in time to cope with the event. Remember, real-time computing is not about fast computing, but about predictable computing. If we recall the airbag example, this means that it must be known in advance, i.e., before the collision occurs, how long time does it take in the worst case to react upon a collision and activate the airbag. Multitasking In a real-time system, several tasks are competing for the system resources. For example, a control system in an airplane needs to perform several activities at the same time, such as to check the altitude, check the cabin pressure, process radar signals, etc. Obviously, if we have only one processor, we need to share it among different tasks by running the tasks in parallel, which is called multitasking. Note that this is simulated parallelism tasks are not really executed in parallel but the system switches the execution of tasks very often and fast. This is different from real parallelism where several processing units are used simultaneously. Prioritization Some tasks are more important than others, e.g., the task that inflates an airbag has the highest priority among all other tasks running in the car. Hence, if we get into a situation where several tasks want to execute at the same time, the real-time system must be able to chose (and run) tasks in the order importance, i.e., execute the most important one first. Event-triggered or time-triggered execution There are two fundamental principles of how to control the activity of a real-time system, event-triggered and time-triggered. The first one reacts upon external events as they happen, e.g., a sensor generates an interrupt which triggers a certain task to start its execution. In the second one all activities are carried out at certain points in time known in advance, e.g., the task itself periodically checks if the sensor value has changed. States Each task can be in several different states during its execution. For example, when a task is competing for the CPU time with other tasks, it is in ready state, and when it starts to run on a processor, we say that the task state is executing. We will learn more about task states and state transition in the next chapter. Design for peak load and fault tolerance - Real-time systems must not collapse when they are subjects to peak load conditions, so they must de designed to manage all anticipated scenarios. Also, single hardware and software failures should not cause the system to crash.

1.8

Classifications of real-time systems

There are several different classifications of real-time systems, based on different criteria, such as activation of tasks, resource dimensioning, service level, application domain, and so on. Here, we will present some of the most common classifications. Event-triggered vs. time-triggered real-time systems In event-triggered systems, all activities are carried out in response to relevant events external to the system. When a significant event in the outside world happens, it is detected by some sensor, which then causes the attached device (CPU) to get an interrupt. Event-triggered systems are often simple, work well in applications with sufficient computing power, and they are flexible, i.e., it is easier to add new tasks to the system. However, the temporal control is enforced from the environment onto the system in an unpredictable manner (interrupts), hence they can fail under conditions of a heavy load, i.e., when many events are happening at once. In time-triggered systems, all events are handled at predefined points in time, which are known in advance. Real-time systems of this kind are time triggered in the sense that their overall behavior is globally controlled by a recurring clock tick. They are most often cyclic systems which repeat a certain scenario: clock interrupt occurs at regular intervals and at that time selected sensors are sampled, e.g., a task that reads a sensor each 50 milliseconds (regardless if there is a new value available or not). Time-triggered systems are less flexible than event-triggered systems, but they are more predictable, which eases system validation and verification considerably. We will talk much more about these two types of real-time systems in consecutive chapters. Hard vs soft real-time systems Depending on the consequences that may occur due to a missed deadline, real-time systems can be divided into two classes, hard and soft. In hard realtime systems, all task deadlines must be met. Missing a deadline may lead to catastrophic consequences on the environment being controlled. In extreme cases, e.g., control system of an airplane, it can lead to loss of live or an environmental disaster. In less extreme situations, failing to meet hard real-time constraints results in computations being useless. For example, missing a deadline to recognize a moving object on a factory conveyor belt means that the object cannot be properly processed. In a hard real-time system, the peak-load performance must be predictable and should not violate the predefined deadlines. Hard real-time systems are often safety critical, e.g., nuclear power plants, airbags, air traffic control systems, etc. In soft real-time systems, it is acceptable to occasionally miss a deadline. Meeting deadlines is desirable for performance reasons. Missing a deadline does not cause serious damage but it leads to reduced usefulness of the computation (reduced service). For example, a telephone switch may be permitted to lose or misroute one call in 100,000, or multimedia system may miss delivering some video frames giving lower video quality. Some other examples are ticket reservation systems, ATM machines, temperature monitoring, etc. Typically, real-world applications include both hard and soft activities, and therefore a hard real-time system should be designed to handle both hard and soft tasks using two different

strategies. The objective is to guarantee individual timing constraints of hard activities while minimizing the average response time of soft activities. Resource sufficient vs. resource limited real-time systems depending on how many resources are reserved for the system, we can divide real-time systems into resource sufficient and resource limited systems. A real-time system with enough resources is a system in which we always can guarantee that all functions in the system can be performed in time, i.e., before their deadlines. In these systems, the CPU will never get overloaded, since those systems are designed for the worst-case scenario (peak load). Examples include ABS brake systems, flight control systems, etc., i.e., most safety-critical applications. On the other hand, in resource limited systems, there will be occasions when we cannot guarantee that all computations will complete in time. One example is telephone switch system which is designed for the average case load. In most of the cases the telephone switch system works well: when we call somebody, we usually get the dial tone right away, but when we try to dial on the New Year's Eve, when all other people try to call at the same time, the system might not be able to connect our call (or we need to wait for some time). This case happens so rarely that it is not worth the cost for the telephone company to dimension its systems for this peak load. Instead, the system is dimensioned for more likely average load scenarios. Embedded vs. non-embedded systems An embedded system is a special-purpose computer that performs a few dedicated functions, usually with very specific requirements. Examples include portable devices such as cell phones or MP3 players, flight control systems, car engine controllers, home appliances, medical equipment, TV sets, video game consolers, and many more. Actually, more than 99% of all computers today are embedded in different kinds of electronic equipment and machines. Since those systems are usually integrated in a product it is hard to re-program, e.g., a heart pacemaker in a human body, therefore they should be very robust and reliable. Non-embedded, open systems, on the other hand, are based on generally accessible computers, such as operator terminals, surveillance systems, etc, that are possible to reprogram on site.

1.9

Example applications

In order to distinguish more clearly between different types of real-time systems, we will have a look some examples. Vehicle control system The control system of Volvo S80 (architecture from late 90s, see Figure 6), is built of two connected Controller Area Network (CAN) communication busses: one high-speed bus for safety-critical applications in a car, such as ABS or ESP, and a lowspeed bus, which is used by other nodes, e.g., electric windows, air condition and infotainment system. A number of processing nodes are placed on different strategic places in the car, i.e., close to the sensors and actuators they interact with. Typically, a node is single-

chip computer, i.e., a microprocessor with some functionality for communication, analog-todigital and digital-to-analog conversion.
High-speed network for safety-critical functions PDM ECM TCM ETM SAS ABS DIM SWM CCM AUM PHM UEM SRS PSM RTI REM Low-speed network

CEM

DDM

Figure6:CommunicationNetworkinVolvoS80.

All sensors, actuators and contacts are connected to the closest processing node, regardless if the corresponding software is physically located on the node. If a specific task that uses produced sensor data is scheduled to run on another node, the sensor values are sent over the common communication bus. Since the CAN bus is of broadcast type, all information that is sent on the bus will be available for all attached nodes. Industrial control system Such systems are built of several different subsystems, see Figure 7. PLC-programming is used for simple processing operations. PLC nodes are often connected through a field bus, i.e., a communication bus that supports simple connection of sensors and actuators, making larger processing units. Those are then connected to a factory network, which is usually based on Ethernet or Token Ring (more on this will come later when we discuss real-time communication).

Operator station Factory network

Processing station Fieldbus PLC

Processing station

Processing station

Environment PLC PLC

Figure7:Exampleindustrialsystem.

Consumer electronics Real-time systems are even used in consumer electronic (CE) devices, such as TVs, Blue Ray players, HiFi products, computer game consoles etc. Today, most of the existing analog home entertainment devices are being replaced by corresponding digital products. Analog television broadcasting has been replaced by digital signals that better utilize the communication media and provide for a greater variety of TV channels and interactive services that are not possible in the analog domain. Compared to the analog domain, digital media introduces additional and different requirements on the environment. At the same time, there are restrictions on the communication and storage media, display devices and users. In their original form, digital multimedia streams are very big in size, while the storage and the communication media have limited resources. Thus, media files must be compressed before being stored on e.g., a DVD, or transmitted through a network, e.g., the Internet. Display devices are also restricted, e.g., with respect to processing power, memory, and battery life. For instance, the processing power of hand held devices, such as pocket PCs or video mobile phones, is not sufficient to play out a full-size video stream without impairing video quality. Real-time admission control and resource reservation mechanisms can be used to ensure that video processing applications perform satisfactory, even under limited system resources. If there is not enough resources to fully process the incoming video, it can be adjusted based on the current resource availability. When real-time systems are used, we have a better control over available system resources and we can reserve them in order to meet task deadlines, and hence, improve performance. In fact, producers of such consumer electronic devices have argued to mandate the use of hard real-time methods for audio/video processing.

1.10

Some misconceptions about real-time systems

There are several misconceptions about real-time systems and we need to mention some of them before proceeding any further, for a more extensive list see (Stankovic J. A., 1988). One of the most common misconceptions is that real-time computing is equal to fast computing. The objective of fast computing is to minimize the average response time of a give set of tasks, while the objective of real-time computing is to meet the individual timing requirements of each task. Rather than being fast, the most important property of a real-time system is predictability, i.e., its functional and timing behavior should be sufficiently deterministic to satisfy the system specifications. Another misconception is that the advances in hardware will automatically take care of realtime requirements. These advances will likely exploit parallel processors to improve system throughput, but this does not mean that the timing constraints will be met automatically. In fact, the faster the hardware gets, the more complex do real-time systems become. Furthermore, it is also a misconception that real-time programming implies low level, assembly programming. Handcrafted assembly and device driver programming are major source of bugs. One of the primary objectives in real-time research is, in fact, to automate, by

exploiting optimizing transforms and scheduling theory, the synthesis of highly efficient code and customized resource schedulers from timing constraint specification. The state-of-thepractice today when programming real-time systems is not to write assembler code, but to use high level languages such as C, Ada or Java, with a heavy tool support. While assembly language programming, device driver writing and interrupt programming are aspects of realtime computing, they do not constitute open scientific problems, except in their automation.

1.11

Challenges with real-time systems

As we could see so far, it is possible to implement very advanced real-time systems. However, it can be pretty challenging, lets see why. One problem is lack of physical limitations. Time is the only physical thing we can measure in real-time systems. If we compare it to some other, traditional disciplines, such as building and construction engineering, the latter has a number of physical limitations that we can rely on when designing and verifying the system, e.g., material properties, physical laws etc. Besides, mankind has been building houses for centuries, and has gained valuable experience through the years; computer engineering has been around only for decades. Another challenge is that in real-time systems, we must solve the same problems as in traditional computer systems, and in addition we need to take the timing requirements into account. Furthermore, efficiency is important but predictability is essential. We must be able to predict with confidence the worst case response times for systems. Devices operate in parallel in the real-world. Several tasks are competing for the CPU time pre-empting each other, which conflicts with sequential execution on controller. This makes it hard to maintain deterministic, reproducible behavior. Some other challenges are interaction with special purpose hardware, i.e., we must program devices in a reliable and abstract way. Interfaces, device drivers are often large development time sink. Since most of the real-time systems are embedded into products, maintenance is usually difficult. Embedded real-time systems usually operate in harsh environment (high temperature, EMI, radiation, etc). Finally, real-time systems often have to be extremely reliable and safe. Embedded systems typically control the environment in which they operate. Failure to control can result in loss of life, damage to environment or economic loss.

1.12

Summary

Real-time technology ensures that the results of computations are not only correct, but also delivered at the correct times, which is essential in applications ranging from airplanes, cars to mobile phones and multimedia devices, such as DVD players, TVs, etc. In real-time computing systems, the correctness of results depends not only functional values, but also the time of availability: a correct value delivered too late is wrong. The predominate approach of standard computer systems which focus on minimizing average delays are inappropriate for such systems, since they may result in crashed planes and cars, lost phone calls, or disturbed movies. The real-time system has to react to events as they occur, at their speed; the environment dictates the speed and cannot be slowed down. Fast or timely on average behavior is not acceptable; rather the worst case situation has to be handled. Compare to crossing a river: not the average depth determines safe passage, but the deepest one. With real-time systems, the prime goal is not to achieve fast computing, it is to achieve timely computing. In some cases, the system must wait until it responds, as in the airbag application in a car, where there is an exact time interval in which the airbag must be inflated not too early, nor too late. This is an example of a hard real-time system, i.e., no deadlines must be missed. In soft systems, deadlines can me missed occasionally, but the system performance gets degraded. Execution of real-time systems is achieved in real-time tasks, which are sequential programs that perform certain actions in the systems. Tasks are executed in a multitasking manner, i.e., the system switches task execution according to some scheduling policy such that all tasks get to execute, and at the same time, all tasks meet their individual timing constraints. Task activation and execution can be either event-triggered or time-triggered. In the first case, the system reacts to external events as they happened and activates corresponding tasks. In timetriggered systems, all system actions are dictated by a system clock, i.e., all task executions is predefined in advance. Event-triggered systems are more flexible, but less predictable than time-triggered systems. A number of areas in computing are affected by real-time demands, including hardware and operating systems, CPU and communication network scheduling, reliability, programming languages and specification. In this book, we will cover numerous aspects of real-time systems, such as support by operating system to implement real-time applications, real-time scheduling mechanisms, temporal analysis, verification and validation of real-time applications, design or real-time systems, as well as some complex real-time architecture that involve several separate processing nodes connected through some real-time communication network. After reading this book, you should be prepared to develop real-world real-time applications.

1.13

Exercises

1.1. Explain in your own words what a real-time system is. Why do we need this type of systems? 1.2. One of the largest misconceptions about real-time systems is: a real-time system is equivalent to a fast system. Explain why this is a misconception. 1.3. Real-time systems interact with the environment via sensors and actuators. Explain what sensors and an actuators do, i.e., in which way they interact with the environment. Give one example of real-time systems that uses sensors and actuators. 1.4. One classification of real-time systems is into hard and soft real-time systems. Explain the difference between those two types of RT systems and give one example for each of the types. 1.5. One classification of real-time systems is into event-triggered and time-triggered realtime systems. Explain the difference between those two types of RT systems and give one example of each type (examples from the book are not allowed). 1.6. Building real-time systems introduce some additional challenges compared to traditional computer systems. Discuss at least three difficulties when developing real-time systems.

Bibliography

Stankovic, J. A. (1988). Misconceptions About Real-Time Computing: A Serious Problem for Next-Generation Systems. Computer , 10-19. Stankovic, J., & Ramamritham, K. (1988). Tutorial on Hard Real-Time Systems. IEEE Transactions on Computing.