Seminar Report- Embedded OS for Real Time Applications

A Seminar Report

ON

EMBEDDED OPERATING SYSTEM FOR REAL TIME APPLICATIONS

Bachelor of Technology

IN

Electronics & Communication Engineering

Submitted By

ANKIT MAKOL EC 3rd YEAR

0802831016

DEPARTMENT OF ELECTRONICS & COMM. ENGG. IDEAL INSTITUTE OF TECHNOLOGY

GHAZIABAD (INDIA) (2010-2011)

ABSTRACT

Embedded systems are the computing devices hidden inside a vast array of everyday products and appliances such as cell phones, toys, handheld PDAs, cameras, etc. An embedded system is various type of computer system or computing device that performs a dedicated function and/or is designed for use with a specific embedded software application. Embedded systems may use a combination of ‘Read-only’ as well as with ‘Read-Write’ based operating system. But an embedded system is not usable as a commercially viable substitute for general-purpose computers or devices. As applications grow increasingly complex, so do the complexities of the embedded computing devices. An embedded real-time operating system is the software program that manages all the programs in an embedded device after initial load of programs by a boot loader. It normally guarantees a certain capability within a specified storage size and time constraint as well as with application programs. It also normally has small foot print including initial boot loader, OS kernel, required device drivers, file systems for the user data and so forth. It has very-likely structure of a normal operating system however mainly differentiated by some factors such as type of pre-installed device, functional limits, taking designed job only. This paper attempts to throw some light on the technologies behind the embedded systems design and concludes by the survey of some of the available real-time operating systems.

CONTENTS

1. Introduction.................................................................................................. 1

2. Embedded Systems...................................................................................... 1 2.1. What are embedded Systems?.............................................................. 1 2.2. What is inside an embedded system?................................................... 2 2.3. Features of embedded systems............................................................ 3

3. Operating Systems....................................................................................... 4

4. Real time embedded systems...................................................................... 6 4.1. Real time systems................................................................................ 7 4.2. Characteristics of real time systems.................................................... 8 4.3. Hard and soft real time systems.......................................................... 9

5. Features of a good operating systems......................................................... 12 5.1. Operating system architectures............................................................ 12

5.1.1. Monolithic operating system..................................................... 12 5.1.2. Layered operating system.......................................................... 12 5.1.3. Client-Server operating system.................................................. 13

5.2. Process-Thread-task model.................................................................. 14 5.3. Scheduling, Priorities and Interrupts.................................................... 15

5.3.1. Scheduler................................................................................... 16 5.3.2. Interrupts................................................................................... 17

5.4. Tasks and Task states.......................................................................... 17 5.5. Tasks and data...................................................................................... 18 5.6. Task Synchronisation & Inter task Communication........................... 18 5.7. Memory Management......................................................................... 20

6. Case Studies............................................................................................... 20 6.1. RQS RTOS v6.1................................................................................ 20 6.2. VRTX................................................................................................ 20 6.3. Windows CE 3.0............................................................................... 21 6.4. pSOSystem/x86 2.2.6....................................................................... 21 6.5. VxWorks (Wind River System)........................................................ 21 6.6. Windows NT..................................................................................... 22

7. Conclusions................................................................................................ 22

8. References................................................................................................. 24

I. INTRODUCTION

Last few decades have seen the rise of computers to a position of prevalence in human affairs. It has made its mark in every field ranging personal home affairs, business, process automation in industries, communications, entertainment, defence etc... An embedded system is a combination of hardware and software and perhaps other mechanical parts designed to perform a specific function. Microwave oven is a good example of one such system. This is in direct contrast to a personal computer. Though it is also comprised of hardware and software and mechanical components it is not designed for a specific purpose. Personal computer is general purpose and is able to do many different things.

An embedded system is generally a system within a larger system. Modern cars

and trucks contain many embedded systems. One embedded system controls anti-lock brakes, another monitors and controls vehicle’s emission and a third displays information on the dashboard. Even the general-purpose personal computer itself is made up of numerous embedded systems. Keyboard, mouse, video card, modem, hard drive, floppy drive and sound card are each an embedded system. Tracing back the history, the birth of microprocessor in 1971 marked the booming of digital era. Early embedded applications included unmanned space probes, computerized traffic lights and aircraft flight control systems. In the 1980s, embedded systems brought microprocessors into every part of our personal and professional lives. Presently there are numerous gadgets coming out to make our life easier and comfortable because of advances in embedded systems. Mobile phones, personal digital assistants and digital cameras are only a small segment of this emerging field.

One major subclass of embedded systems is real-time embedded systems. A

real time system is one that has timing constraints. Real-time system’s performance is specified in terms of ability to make calculations or decisions in a timely manner. These important calculations have deadlines for completion. A missed deadline is just as bad as a wrong answer. The damage caused by this miss will depend on the application. For example if the real-time system is a part of an airplane’s flight control system, single missed deadline is sufficient to endanger the lives of the passengers and crew.

2. EMBEDDED SYSTEMS

2.1. WHAT ARE EMBEDDED SYSTEMS?

An embedded system is generally a system within a larger system. Modern cars and trucks contain many embedded systems. One embedded system controls anti-lock brakes, another monitors and controls vehicle’s emission and a third displays information on the dashboard. Even the general-purpose personal computer itself is made up of numerous embedded systems. Keyboard, mouse, video card, modem, hard drive, floppy drive and sound card are each an embedded system.

Tracing back the history, the birth of microprocessor in 1971 marked the booming of digital era. Early embedded applications included unmanned space probes, computerized traffic lights and aircraft flight control systems.

In the 1980s, embedded systems brought microprocessors into every part of our

personal and professional lives. Presently there are numerous gadgets coming out to make our life easier and comfortable because of advances in embedded systems. Mobile phones, personal digital assistants and digital cameras are only a small segment of this emerging field.

Embedded systems do not provide standard computing services and normally

exist as part of a bigger system. Embedded systems are usually constructed with the least powerful computers that can meet the functional and performance requirements. This is essential to lower the manufacturing cost of the equipment.

Other components of the embedded system are similarly chosen, so as to lower

the manufacturing cost. In conventional operating systems, a programmer needing to store a large data structure can allocate big chunks of memory without having to think of the consequences. These systems have enough main memory and a large pool of virtual memory (in the form of disk space) to support such allocations. The embedded systems’ developers do not enjoy such luxuries and have to manage with complex algorithms to manage resources in the most optimized manner.

One major subclass of embedded systems is real-time embedded systems. A

real-time system is one that has timing constraints. Real-time system’s performance is specified in terms of ability to make calculations or decisions in a timely manner. These important calculations have deadlines for completion. A missed deadline is just as bad as a wrong answer. The damage caused by this miss will depend on the application. For example if the real-time system is a part of an airplane’s flight control system, single missed deadline is sufficient to endanger the lives of the passengers and crew.

In most of the real-life applications, real-time systems often work in an

embedded scenario and most of the embedded systems have real-time processing needs. Such software is called Real-time Embedded Software systems.

2.2. WHAT IS INSIDE AN EMBEDDED SYSTEM?

All embedded systems contain a processor and software. The processor may be 8051 micro-controller or a Pentium-IV processor (having a clock speed of 2.4 GHz). Certainly, in order to have software there must be a place to store the executable code and temporary storage for run-time data manipulations. These take the form of ROM and RAM respectively. If memory requirement is small, it may be contained in the same chip as the processor. Otherwise one or both types of memory will reside in external memory chips. All embedded systems also contain some type of inputs and outputs (Fig. 2.2.a). For example in a microwave oven the inputs are the buttons on the front panel and a temperature probe and the outputs are the human readable display and the microwave radiation. Inputs to the system generally take the form of

sensors and probes, communication signals, or control knobs and buttons. Outputs are generally displays, communication signals, or changes to the physical world.

Fig. 2.2.a Generic Embedded System

2.3. FEATURES OF AN EMBEDDED SYSTEM

Within the exception of these few common features, rest of the embedded hardware is usually unique and varies from application to application. Each system must meet a completely different set of requirements. The common critical features and design requirements of an embedded hardware include:

• Processing power: Selection of the processor is based on the amount of

processing power to get the job done and also on the basis of register width required.

• Throughput: The system may need to handle a lot of data in a short period of time.

• Response: The system has to react to events quickly.

• Memory: Hardware designer must make his best estimate of the memory

requirement and must make provision for expansion.

• Power consumption: Systems generally work on battery and design of

both software and hardware must take care of power saving techniques.

• Number of units: The no. of units expected to be produced and sold will dictate the Trade-off between production cost and development cost.

• Expected lifetime: Design decisions like selection of components to

system development cost will depend on how long the system is expected to run.

• Program Installation: Installation of the software on to the embedded system needs special tools.

• Testability & Debug ability: Setting up test conditions and equipment

will be difficult and finding out what is wrong with the software will become a difficult task without a keyboard and the usual display screen.

• Reliability: Reliability is critical if it is a space shuttle or a car but in

case of a toy it doesn’t always have to work right.

Besides these few important and critical features of an embedded system, it must also obey some more features which play an important role in achieving the goal of a system. They are as follows:

• Limited resources: They are often strong limitations regarding

available resources. Mainly due to cost and size constraints related to mass production and strong industrial competition, the system resources as CPU, memory, devices have been designed to meet these requirements. As a result of these limitations, the system has to deal with an efficient use of the computational resources.

• Real-time application requirements: Some of the applications to be run in these devices have temporal requirements. These applications are related with process control, multimedia processing, instrumentation, and so on, where the system has to act within a specified interval.

• Embedded control systems: Most of the embedded systems perform control activities involving input data acquisition (sensing) and output delivery (actuation). Deterministic communications are also another important issue.

• Quality of service: An efficient use of the system resources is a must in embedded systems. Feedback based approaches are being used to adjust the performance or quality of service of the applications as a function of the available resources.

The challenge is how to implement applications that can execute efficiently on limited resource and that meet non-functional requirements such as timeliness, robustness, dependability, performance, and so on.

3. OPERATING SYSTEMS

The operating system organizes and controls the hardware and it is that piece of software that turns the collection of hardware blocks into a powerful computing tool. Broadly the tasks of the Operating system are:

a. Processor Management: The main tasks in processor management are ensuring that each process and application receives enough of the processor's

time to function properly, using maximum processor cycles for real work as is possible and switch between processes in a multi-tasking environment.

b. Memory and Storage Management: The tasks include allotting enough memory required for each process to execute and efficiently use the different types of memory in the system

c. Device Management: The operating system manages all hardware not on the computer's motherboard through driver programs. Drivers provide a way for applications to make use of hardware subsystems without having to know every detail of the hardware's operation. The driver's function is to be the translator between the electrical signals of the hardware subsystems and the high-level programming languages of the operating system and application programs. One reason that drivers are separate from the operating system is for upgradability of devices.

d. Providing Common Application Interface: Application program interfaces (APIs) let application programmers use functions of the computer and operating system without having to directly keep track of all the details in the CPU's operation. Once the programme uses the APIs, the operating system, connected to drivers for the various hardware subsystems, deals with the changing details of the hardware.

e. Providing Common User Interface: A user interface (UI) brings a formal structure to the interaction between a user and the computer. Recently all developments in user interfaces have been in the area of the graphical user interface (GUI). Apple's Macintosh and Microsoft's Windows are the popular GUIs.

Four types of Operating systems, based on the kind of applications they support are:

a. Single-user, single task - This operating system is designed to manage the computer so that one user can effectively do one thing at a time. The Palm OS for Palm hand-held computers is a good example.

b. Single-user, multi-tasking - This is the type of operating system most of us use on our desktop and laptop computers today. Windows 98 and the MacOS are examples of OS that let a single user have several programs in operation at the same time.

c. Multi-user - A multi-user operating system allows many different users to take advantage of the computer's resources simultaneously. The operating system must make sure that the requirements of the various users are balanced, and that each of the programs they are using has sufficient and separate resources so that a problem with one user doesn't affect the other users. Unix is an example of multi-user operating system.

d. Real-time operating system (RTOS) – The main task of a RTOS is to manage the resources of the computer such that a particular operation executes in precisely the same amount of time every time it occur. “In a complex machine, having a part move more quickly just because system resources are available may be just as catastrophic as having it not to move at all because the system is busy.”

4. REAL TIME EMBEDDED SYSTEM

In the simplest form, real-time systems can be defined as those systems that respond to external events in a timely fashion, as shown in Figure 4.a. The response time is guaranteed. We revisit this definition after presenting some examples of real-time systems.

Fig. 4.a. A simple view of real-time systems.

External events can have synchronous or asynchronous characteristics. Responding to external events includes recognizing when an event occurs, performing the required processing as a result of the event, and outputting the necessary results within a given time constraint. Timing constraints include finish time, or both start time and finish time.

A good way to understand the relationship between real-time systems and

embedded systems is to view them as two intersecting circles, as shown in Figure 4.b. It can be seen that not all embedded systems exhibit real-time behaviours nor are all real-time systems embedded.

However, the two systems are not mutually exclusive, and the area in which

they overlap creates the combination of systems known as real-time embedded systems.

Fig. 4.b Real-time embedded systems

Knowing this fact and because we have covered the various aspects of embedded systems in the previous sections, we can now focus our attention on real-time systems. 4.1 REAL TIME SYSTEMS

The environment of the real-time system creates the external events. These events are received by one or more components of the real-time system. The response of the real-time system is then injected into its environment through one or more of its components. Decomposition of the real-time system, as shown in Figure 4.a, leads to the general structure of real-time systems.

Fig. 4.c Structure of real-time systems

The structure of a real-time system, as shown in Figure 4.c, is a controlling system and at least one controlled system. The controlling system interacts with the controlled system in various ways. First, the interaction can be periodic, in which communication is initiated from the controlling system to the controlled system. In this case, the communication is predictable and occurs at predefined intervals. Second, the interaction can be aperiodic, in which communication is initiated from the controlled system to the controlling system. In this case, the communication is unpredictable and is determined by the random occurrences of external events in the environment of the controlled system. Finally, the communication can be a combination of both types. The controlling system must process and respond to the events and information generated by the controlled system in a guaranteed time frame.

Imagine a real-time weapons defence system whose role is to protect a naval

destroyer by shooting down incoming missiles. The idea is to shred an incoming missile into pieces with bullets before it reaches the ship. The weapons system is comprised of a radar system, a commandant-decision (C&D) system, and weapons firing control system. The controlling system is the C&D system, whereas the controlled systems are the radar system and the weapons firing control system.

• The radar system scans and searches for potential targets. Coordinates of a

potential target are sent to the C&D system periodically with high frequency after the target is acquired.

• The C&D system must first determine the threat level by threat classification and evaluation, based on the target information provided by the radar system. If a threat is imminent, the C&D system must, at a minimum, calculate the speed and flight path or trajectory, as well as estimate the impact location. Because a missile tends to drift off its flight path with the degree of drift dependent on the precision of its guidance system, the C&D system calculates an area (a box) around the flight path.

• The C&D system then activates the weapons firing control system closest to the anticipated impact location and guides the weapons system to fire continuously within the moving area or box until the target is destroyed. The weapons firing control system is comprised of large-calibre, multi-barrel, high-muzzle velocity, high-power machine guns.

In this weapons defence system example, the communication between the radar

system and the C&D system is aperiodic, because the occurrence of a potential target is unpredictable and the potential target can appear at any time. The communication between the C&D system and the weapons firing control system is, however, periodic because the C&D system feeds the firing coordinates into the weapons control system periodically (with an extremely high frequency).Initial firing coordinates are based on a pre-computed flight path but are updated in real-time according to the actual location of the incoming missile.

Consider another example of a real-time system-the cruise missile guidance

system. A cruise missile flies at subsonic speed. It can travel at about 10 meters above water, 30 meters above flat ground, and 100 meters above mountain terrains. A modern cruise missile can hit a target within a 50-meter range. All these capabilities are due to the high-precision, real-time guidance system built into the nose of a cruise missile. In a simplified view, the guidance system is comprised of the radar system (both forward-looking and look-down radars), the navigation system, and the divert-and-altitude-control system. The navigation system contains digital maps covering the missile flight path. The forward-looking radar scans and maps out the approaching terrains. This information is fed to the navigation system in real time. The navigation system must then recalculate flight coordinates to avoid terrain obstacles. The new coordinates are immediately fed to the divert-and-altitude-control system to adjust the flight path. The look-down radar periodically scans the ground terrain along its flight path. The scanned data is compared with the estimated section of the pre-recorded maps. Corrective adjustments are made to the flight coordinates and sent to the divert-and-altitude-control system if data comparison indicates that the missile has drifted off the intended flight path.

In this example, the controlling system is the navigation system. The controlled

systems are the radar system and the divert-and-altitude-control system. We can observe both periodic and aperiodic communications in this example. The communication between the radars and the navigation system is aperiodic. The communication between the navigation system and the diver and-altitude-control system is periodic. 4.2. CHARACTERISTICS OF REAL-TIME SYSTEMS

The C&D system in the weapons defence system must calculate the anticipated flight path of the incoming missile quickly and guide the firing system to shoot the missile down before it reaches the destroyer. Assume T1 is the time the missile takes to reach the ship and is a function of the missile's distance and velocity. Assume T2 is the time the C&D system takes to activate the weapons firing control system and includes transmitting the firing coordinates plus the firing delay. The difference between T1 and T2 is how long the computation may take. The missile would reach its intended target if the C&D system took too long in computing the flight path. The missile would still reach its target if the computation produced by the C&D system was inaccurate. The navigation system in the cruise missile must respond to the changing terrain fast enough so that it can re-compute coordinates and guide the altitude control system to a new flight path. The missile might collide with a mountain if the navigation system cannot compute new flight coordinates fast enough, or if the new coordinates do not steer the missile out of the collision course.

Therefore, we can extract two essential characteristics of real-time systems

from the examples given earlier. These characteristics are that real-time systems must produce correct computational results, called logical or functional correctness, and that these computations must conclude within a predefined period, called timing correctness.

Real-time systems are defined as those systems in which the overall correctness

of the system depends on both the functional correctness and the timing correctness. The timing correctness is at least as important as the functional correctness.

It is important to note that we said the timing correctness is at least as important

as the functional correctness. In some real-time systems, functional correctness is sometimes sacrificed for timing correctness. We address this point shortly after we introduce the classifications of real-time systems.

Similar to embedded systems, real-time systems also have substantial

knowledge of the environment of the controlled system and the applications running on it. This reason is one why many real-time systems are said to be deterministic, because in those real-time systems, the response time to a detected event is bounded. The action (or actions) taken in response to an event is known a priori. A deterministic real-time system implies that each component of the system must have a deterministic behaviour that contributes to the overall determinism of the system. As can be seen, a deterministic real-time system can be less adaptable to the changing environment. The lack of adaptability can result in a less robust system. The levels of determinism and of robustness must be balanced. The method of balancing between the two is system- and application-specific. 4.3 HARD AND SOFT REAL-TIME SYSTEMS

In the previous section, we said computation must complete before reaching a given deadline. In other words, real-time systems have timing constraints and are deadline-driven. Real-time systems can be classified, therefore, as either hard real-time systems or soft real-time systems.

What differentiates hard real-time systems and soft real-time systems are the degree of tolerance of missed deadlines, usefulness of computed results after missed deadlines, and severity of the penalty incurred for failing to meet deadlines.

For hard real-time systems, the level of tolerance for a missed deadline is

extremely small or zero tolerance. The computed results after the missed deadline are likely useless for many of these systems. The penalty incurred for a missed deadline is catastrophe. For soft real-time systems, however, the level of tolerance is non-zero. The computed results after the missed deadline have a rate of depreciation. The usefulness of the results does not reach zero immediately passing the deadline, as in the case of many hard real-time systems. The physical impact of a missed deadline is non-catastrophic.

A hard real-time system is a real-time system that must meet its deadlines with

a near-zero degree of flexibility. The deadlines must be met, or catastrophes occur. The cost of such catastrophe is extremely high and can involve human lives. The computation results obtained after the deadline have either a zero-level of usefulness or have a high rate of depreciation as time moves further from the missed deadline before the system produces a response.

A soft real-time system is a real-time system that must meet its deadlines but

with a degree of flexibility. The deadlines can contain varying levels of tolerance, average timing deadlines, and even statistical distribution of response times with different degrees of acceptability. In a soft real-time system, a missed deadline does not result in system failure, but costs can rise in proportion to the delay, depending on the application.

Penalty is an important aspect of hard real-time systems for several reasons. What is meant by 'must meet the deadline'? It means something catastrophic occurs if the deadline is not met. It is the

penalty that sets the requirement. Missing the deadline means a system failure, and no recovery is possible other

than a reset, so the deadline must be met. Is this a hard real-time system? That depends. If a system failure means the system must be reset but no cost is

associated with the failure, the deadline is not a hard deadline, and the system is not a hard real-time system. On the other hand, if a cost is associated, either in human lives or financial penalty such as a $50 million lawsuit, the deadline is a hard deadline, and it is a hard real-time system. It is the penalty that makes this determination.

What defines the deadline for a hard real-time system? It is the penalty. For a hard real-time system, the deadline is a deterministic

value, and, for a soft real-time system, the value can be estimation. One thing worth noting is that the length of the deadline does not make a real-

time system hard or soft, but it is the requirement for meeting it within that time. The weapons defence and the missile guidance systems are hard real-time

systems. Using the missile guidance system for an example, if the navigation system cannot compute the new coordinates in response to approaching mountain terrain before or at the deadline, not enough distance is left for the missile to change altitude. This system has zero tolerance for a missed deadline. The new coordinates obtained

after the deadline are no longer useful because at subsonic speed the distance is too short for the altitude control system to navigate the missile into the new flight path in time. The penalty is a catastrophic event in which the missile collides with the mountain. Similarly, the weapons defence system is also a zero-tolerance system. The missed deadline results in the missile sinking the destroyer, and human lives potentially being lost. Again, the penalty incurred is catastrophic.

On the other hand, the DVD player is a soft real-time system. The DVD player

decodes the video and the audio streams while responding to user commands in real time. The user might send a series of commands to the DVD player rapidly causing the decoder to miss its deadline or deadlines. The result or penalty is momentary but visible video distortion or audible audio distortion. The DVD player has a high level of tolerance because it continues to function. The decoded data obtained after the deadline is still useful.

Timing correctness is critical to most hard real-time systems. Therefore, hard

real-time systems make every effort possible in predicting if a pending deadline might be missed. Returning to the weapons defence system, let us discuss how a hard real-time system takes corrective actions when it anticipates a deadline might be missed. In the weapons defence system example, the C&D system calculates a firing box around the projected missile flight path. The missile must be destroyed a certain distance away from the ship or the shrapnel can still cause damage. If the C&D system anticipates a missed deadline (for example, if by the time the precise firing coordinates are computed, the missile would have flown past the safe zone), the C&D system must take corrective action immediately. The C&D system enlarges the firing box and computes imprecise firing coordinates by methods of estimation instead of computing for precise values.

The C&D system then activates additional weapons firing systems to

compensate for this imprecision. The result is that additional guns are brought online to cover the larger firing box. The idea is that it is better to waste bullets than sink a destroyer.

This example shows why sometimes functional correctness might be sacrificed

for timing correctness for many real-time systems. Because one or a few missed deadlines do not have a detrimental impact on the

operations of soft real-time systems, a soft real-time system might not need to predict if a pending deadline might be missed. Instead, the soft real-time system can begin a recovery process after a missed deadline is detected.

For example, using the real-time DVD player, after a missed deadline is

detected, the decoders in the DVD player use the computed results obtained after the deadline and use the data to make a decision on what future video frames and audio data must be discarded to re-synchronize the two streams. In other words, the decoders find ways to catch up.

So far, we have focused on meeting the deadline or the finish time of some

work or job, e.g., a computation. At times, meeting the start time of the job is just as important. The lack of required resources for the job, such as CPU or memory, can

prevent a job from starting and can lead to missing the job completion deadline. Ultimately this problem becomes a resource-scheduling problem. The scheduling algorithms of a real-time system must schedule system resources so that jobs created in response to both periodic and aperiodic events can obtain the resources at the appropriate time. This process affords each job the ability to meet its specific timing constraints.

5. FEATURES OF A GOOD EMBEDDED OPERATING SYSTEM

5.1. OPERATING SYSTEM ARCHITECTURE

5.1.1. MONOLITHIC OPERATING SYSTEM

The OS is a piece of software that can be designed in different

ways. 20 years ago, the OS was just one piece of code composed of different modules. One module calls another in one or more ways. This is called a monolithic OS. This type of OS has the problem of being difficult to debug. If one module has to be changed, then the impact on other modules may be substantial. If one module is fixed, other bugs in other modules may show up.

Fig. 5.1.1a Monolithic operating system

The more modules there are, and the more interconnections there

are between modules, the more chaotic the software becomes due to the multiple interconnections. This is sometimes referred to as “spaghetti software”. With this design, it is almost impossible to distribute the OS in one or other way on multiple processors.

5.1.2. LAYERED OPERATING SYSTEM

A better approach is to use a “layered structure” inside the OS, such as the well-known OSI layers. However OS technology, for performance reasons, is not as orthogonal with its layers as OSI technology is. In OSI you CANNOT skip a layer. You can therefore easily replace one layer without affecting the others. This is not the case in OS technology. A system call goes directly to each individual layer. In RTOS even going directly to the hardware is desirable. In most cases the OS software is as chaotic as in the previous “monolithic” approach. To clarify this statement the next figures show the MS-DOS approach. Figure 5.1.2a gives a representation of a well-organized OS. However by redrawing it like Figure 5.1.2b it can be seen how things are really organized. It is indeed a layered structure, but several shortcuts exist: an application can directly access the BIOS or even the hardware.

Fig 5.1.2a Layered Operating System 1

Fig 5.1.2b Layered Operating System 2 RTOSs have basically been designed this way for a long time.

5.1.3. Client-server operating system

A new approach has been observed in the last 5 years: Client-Server technology in OS. As demonstrated in Figure 5.1.3a, the

fundamental idea is to limit the basics of the OS to a strict minimum (a scheduler and synchronization primitive). The other functionality is on another level, implemented as system threads or tasks. A lot of these “server” tasks are responsible for different functions or “system calls”. The applications are clients requesting services from the server via system calls.

This way of doing things makes it a lot easier for the OS vendor

to sell a scalable OS (with a greater or lesser number of functions). It is easier to debug (each “object” remains small). Distribution over multiple processors is simple. Replacing one module does not have a “bug snowball effect”. One module crash does not necessarily crash the whole system, meaning it is an investment in a more robust environment. Using this method to implement redundancy in the OS is also more conceivable. Dynamic loading and unloading of modules becomes a possibility.

Fig. 5.1.3a Client-Server operating system

The major problem with this model is the overhead due to

memory protection. The server processes have to be protected. Every time a service is requested, the system has to switch from the application’s memory space to the server’s memory space. The time it takes to switch from one process to another will increase when the processes are protected from each other. On the other hand, if no protection is offered, a bug in the application might affect the system processes, which could compromise system stability.

5.2 PROCESS – THREAD – TASK MODEL

The first RTOS was produced more than 20 years ago by DEC for the PDP family of machines. A multitasking concept is essential if you want to develop a good real-time application. Indeed, an application has to be capable of responding in a predictable way (definition of real-time) to multiple simultaneous external events (arriving in an uncontrolled way). If you only use one processor to do so, you have to introduce a sort of pseudo parallelism, called multitasking. Nowadays Rate

Monotonic Scheduling (RMS) theories are helping to compute in advance the processor power you need to deal with all these simultaneous events in time.

We have one application running on a system. This application is subdivided

into multiple tasks. In the UNIX (or POSIX) world, from the outset people have talked about the

different processes in the system. In these complex systems, the context or environment for each process is very heavy, (Processor, I/O, MMU, FPP, etc.) and therefore switching from one process to another is time-consuming. Two reasons changed this approach. Firstly, producing complex, distributed software requires a multitasking approach which is too heavy to implement with the process concept. Secondly, there was the POSIX effort, aimed at bringing the RT and non RT world together. The concept of a “thread” was therefore invented. It is a “sub process” or a “light-weight process”. It inherits the context of a process but uses only a subset of it so that switching between threads can be done more rapidly. Also between threads, there are no security aspects because they really belong to the same environment or process.

The net result today is that it can be said that in an RT environment, a process is

an application subdivided into tasks or threads. 5.3 SCHEDULING, PRIORITIES & INTERRUPTS

In a multitasking environment, you have to “schedule” from one task (or thread) to another. If more than one thread wants to use the processor simultaneously, an algorithm is needed to decide which thread will run first. A deadline-driven scheduling mechanism would be ideal. However, the current state of technology does not allow this. Pre-emptive priority scheduling offers a substitute, taking into account the existence of theories like RMS to give you a decision rule concerning which priority level to assign to each thread. Pre-emption should be used all the time to ensure that a high priority event can be dealt with before any other lower priority event. For this we not only need a pre-emptive priority scheduling mechanism: but in addition interrupt handling following different simultaneous interrupts should be handled in a pre-emptive way.

Furthermore, we have to recognise that each OS needs to disable the interrupts

from time to time to execute critical code that should not be interrupted. The number of lines of code executed should be limited to a minimum to have minimum interrupt latency, but more essentially, should be bound under all circumstances.

There are different reasons to have a lot of priority levels provided in the

RTOS. The first one stems from what was discussed in sections 5.1 and 5.2. In a client-server OS environment, the system itself can be viewed as one or more server applications subdivided into threads. Therefore a number of high priority levels have to be dedicated to system processes and threads.

The second reason is due to RMS scheduling theory. In a complex application

with a large number of threads, it is essential to be able to place all the real-time

threads on a different priority level. The non real-time threads can be placed on one level (lower than the real-time ones) and may run in a round-robin fashion. A level 0 priority or lowest level is necessary to implement the idle monitor required to measure the available processor power.

5.3.1. SCHEDULER

The heart and soul of any operating system is its scheduler. This piece of the operating system decides which of the ready tasks has the right to use the processor (go into running state) at a given time. Some of the common scheduling algorithms used in mainstream operating systems are first-in-first-out (FIFO), shortest job first and round robin. First-in-first-out [FIFO] scheduling is used in DOS, which is not a multitasking operating system. Here each task runs until it is finished and only after that next task is started. In shortest job first scheduler each time a running task completes or blocks itself, next task selected is one that will require the least amount of processor time to complete. Round robin is the only scheduling algorithm of the three in which the running task can be pre-empted, that is, interrupted while it is running. In this case, each task runs for some predetermined amount of time. After that interval has elapsed, the running task is pre-empted by the operating system and the next task in line gets its chance to run.

Unfortunately embedded operating systems cannot use any of these

simple scheduling algorithms. Embedded systems, particularly real-time systems, almost always require a way to share the processor that allows the most important tasks to grab the control of processor as soon as they need it. A deadline driven scheduling mechanism is the ideal one. However, the current state of technology does not allow this. Therefore most embedded operating systems utilize a priority based scheduling algorithm that supports pre-emption. We also need that interrupt handling in case of different simultaneous interrupts should be handled in a pre-emptive way.

A good embedded RTOS should have provision for lot of priority levels.

A number of high priority levels have to be dedicated to the system processes and threads. And in a complex application with large number of threads, it is essential to be able to place all the real-time threads on a different priority level above the non real-time threads.

There is also necessary to have a backup scheduling policy. This is the

scheduling algorithm to be used in the event that several ready tasks have same priority. The most common backup algorithm used is the round robin. If there are no tasks in ‘ready state’ when a scheduler is called, the idle task will be executed which is basically an infinite loop that does nothing. Idle task will have the lowest priority and will always be in ready state. The actual process of changing from one task to another is called a context switch. Since the contexts are processor-specific, the code that implements this is also processor-specific.

So it is always written in assembly language. For real-time systems the context switch should take only the bare minimum of time because this determines the response.

5.3.2 INTERRUPTS

“An interrupt is a hardware mechanism used to inform the CPU that an asynchronous event has occurred”. When CPU recognizes an interrupt, it saves its context and jumps to a subroutine known as Interrupt Service routine (ISR).Upon completion of the ISR the program returns to:

a) The background in the case of foreground/background system b) Interrupted task in case of a non-pre-emptive kernel c) The highest priority task that is ready to run in case of a pre-emptive

kernel.

Each OS needs to disable interrupts from time to time to execute critical code that should not be interrupted. The number of lines of this code should be minimum and bound under all circumstances. ISR must not call any RTOS function that might get blocked. An ISR must not call any RTOS function that might cause RTOS to switch task states unless RTOS knows that an ISR and not a task are running.

A good RTOS should have shortest Interrupt latencies, interrupt responses and interrupt recovery times. The ISR processing time also must be kept to the minimum for the best real-time response.

5.4. TASK & TASK STATES

Task is the basic building block of software written under an RTOS. Each task in RTOS is in one of the following three states Fig 5.4a.

a. Running: The microprocessor is executing the instruction that

make up this task. In single processor systems only one task is running at a time.

b. Ready: means that some other task is running but this task has things that it could do if processor becomes available.

c. Blocked: this task has nothing to do right now even if microprocessor becomes available. Tasks get into this state because they are waiting for some external event.

For example a task that handles data coming from a network will have nothing to do when there is no data.

The non real-time part of a complex system should therefore be capable of

using an RRS. Most RTOSs implement this when you put more than one task on the same priority level. Other RTOSs have an RRS explicitly defined for certain priority ranges.

Fig 5.4a Process States and Transitions Conclusion: an RTOS should always support pre-emptive priority scheduling.

For complex applications, where for some parts of the system a more GPOS-oriented philosophy is needed, RRS or some other mechanisms might be useful.

5.5. TASKS AND DATA Each task has its own private data [includes register values, Program Counter and stack]. All other data like global, static, initialized, un-initialised…etc is shared among the tasks. A situation like this can lead to many of shared data problems. If task1 calls a function Read X for reading a shared data that is being modified by task2, there is a chance that data read by task1 is erroneous (Fig. 5.5a).

Fig 5.5a Tasks and data- adapted

5.6. TASK SYNCHRONISATION & INTER TASK COMMUNICATION

There are several tools available in RTOS to enable inter task communication and task synchronisation:

Semaphores: Semaphores are inter task communication tools used to protect shared data resources. Tasks can call Take-Semaphore and Release-Semaphore functions. If one task has called Take-Semaphore and has not called the Release-Semaphore to release it, then any other task that calls Take-Semaphore will block until first task calls Release-Semaphore. Here, in the function where task2 is modifying shared data X (Fig. 5.5a), we can protect the shared data by taking the semaphore before modifying and releasing it only after that. Whenever task takes a semaphore it is potentially slowing the response of any other task that needs the same semaphore. Two types of semaphore namely binary semaphore and counting semaphore exist. A counting semaphore is used when more than one task uses the same resource like in the case of a buffer pool management. Using a different semaphore for highest priority tasks ensures better response. Multiple semaphores can be used to protect different shared resources. Semaphore can also act as a signalling device for synchronisation. For example, a task that formats printed reports builds those reports into a fixed memory buffer. After formatting one report into the buffer the task must wait until interrupt routine has finished printing. Here the task can wait for a semaphore after it has formatted a report. The interrupt routine on feeding the report to printer can release the semaphore. The task on receiving the semaphore formats the next report. When using Semaphores, one should ensure that it does not lead to Priority inversion or deadly embrace. Some RTOS have a method called priority inheritance to tackle this problem. Message Mailboxes: Messages are sent to a task using kernel services called message mailbox. Mailbox is basically a pointer size variable. Tasks or ISRs can deposit and receive messages (the pointer) through the mailbox. A task looking for a message from an empty mailbox is blocked and placed on waiting list for a time(time out specified by the task) or until a message is received. When a message is sent to the mail box, the highest priority task waiting for the message is given the message in priority-based mailbox or the first task to request the message is given the message in FIFO based mailbox. Message Queues: is used to send one or more messages to a task. Basically Queue is an array of mailboxes. Tasks and ISRs can send and receive messages to the Queue through services provided by the kernel. Extraction of messages from a queue may follow FIFO or LIFO fashion. When a message is delivered to the queue either the highest priority task (Priority based) or the first task that requested the message (FIFO based) is given the message. Event Flags: basically these are Boolean flags which tasks can set or reset that other tasks can wait for. Event flags are used in cases where a task has to synchronise with occurrence of multiple events. A task can be synchronized when any of the events have occurred as in disjunctive synchronisation (logical OR) or may be synchronized when all the events have occurred as in conjunctive synchronisation (logical AND) [3]. More than one task can wait for

same event. RTOS can form groups of events and tasks can wait for any subset of events in a group.

5.7. MEMORY MANAGEMENT

Each programs need to held in a memory generally in a ROM to be executed. The task data (stack and registers) and all variables must be stored in RAM. In a real-time system the main requirement is that the access time should be bound or predictable. The use of demand paging is not allowed since the systems providing virtual memory mechanisms use memory swapping which is not predictable. RTOS have fast and predictable functions to allocate and free fixed size buffers. RTOS allows to setup pools each of which consist of same number of memory buffers. In any given pool all buffers are of same size. In many circumstances it is not acceptable for hardware failure to corrupt data in memory. In such instance hardware protection mechanism should be used. In Hard Real-time systems static memory allocation is used. In a Soft Real-time system of dynamic memory allocation is preferred.

6. CASE STUDIES

Some of the popular RTOSs are reviewed here to identify their salient features which make them suitable for different embedded real-time applications. One of the General Purpose Operating Systems is also discussed here to highlight why a General Purpose Operating System is not suitable for real-time applications. 6.1. QNX RTOS v6.1

The QNX RTOS v6.1 has a client-server based architecture. QNX adopts the approach of implementing an OS with a 10 Kbytes micro-kernel surrounded by a team of optional processes that provide higher-level OS services .Every process including the device driver has its own virtual memory space. The system can be distributed over several nodes, and is network transparent. The system performance is fast and predictable and is robust. It supports Intel x86family of processors, MIPS, PowerPC, and Strong ARM. Documentation is extensive except for the details on the APIs. QNX has successfully been used in tiny ROM-based embedded systems and in several-hundred node distributed systems 6.2. VRTX

VRTX has multitasking facility to solve the real-time performance requirements found in embedded systems. Pre-emptive scheduling is followed ensuring the best response for critical applications. Inter-task communication is by use of mailboxes and queues. Mailbox is equivalent to an event signal and events can pass data along with the event. Queues can hold multiple messages and this buffering facility is useful when sending task produces messages faster than the receiving task can handle them. Dynamic memory allocation is supported and allocation and release is in fixed

size blocs to ensure predictable response times. VRTX has been designed for development and target system independence as well as real-time clock independence. VRTX provides core services which every microprocessor can use to its advantage. 6.3. Windows CE 3.0

Windows CE 3.0 is an Operating system rich in features and is available for a variety of hardware platforms. It exhibits true real-time behaviour most of the times. But the thread creation and deletion has periodic delays of more than 1 millisecond occurring every second. The system is complex and highly configurable. The configuration of CE 3.0 is a complicated process. The documentation does not give in depth knowledge about inner workings of the system though the APIs are well documented. The system is robust and no memory leak occurs even under stressed conditions. CE 3.0 uses virtual memory protection to protect itself against faulty applications. 6.4. pSOSystem/x86 2.2.6

pSOS+ is a small kernel suitable for embedded applications. This uses the software bus to communicate between different modules. The choice of module to be used can be done at compile time making it suitable for embedded applications. System has a flat memory space. All threads share the same memory space and also share all objects such as semaphores. So it has more chances of crashing. Around 239 usable thread priority levels available making it suitable for Rate monotonic scheduling.

pSOS has a multiprocessor version pSOS+m which can have one node as

master and a number of nodes as slaves. Failure in master will however lead to system crash. The Integrated Development Environment is comprehensive and is available for both Windows and UNIX systems. The drawback of this RTOS is that it is available only for selected processors and that lack of mutexes in some versions leads to priority inversion. 6.5. VxWorks (Wind River Systems)

VxWorks is the premier development and execution environment for complex real-time and embedded applications on a wide variety of target processors. Three highly integrated components are included with VxWorks: a high performance scalable real-time operating system which executes on a target processor; a set of powerful cross-development tools; and a full range of communications software options such as Ethernet or serial line for the target connection to the host. The heart of the OS is the Wind microkernel which supports multitasking, scheduling; inter task management and memory management. All other functionalities are through processes. There is no privilege protection between system and application and also the support for communication between processes on different processors is poor.

6.6. Windows NT

The overall architecture is good and may be a suitable RTOS for control systems that need a good user interface and can tolerate the heavy recourse requirements demanded for installation. It needs hard disk and a powerful processor. Configuration and user interaction requires a dedicated screen and keyboard. The choice of selecting components for installation is limited and it is not possible to load and unload major components dynamically. Because of all these limitations Windows NT not suitable for embedded applications. It is neither suitable for other real time applications because of the following factors:

a) There are only 7 priority levels & there is no mechanism to avoid priority inversion

b) The Queue of threads waiting on a semaphore is held in a FIFO order. Here there is no regard for priority, hampering the response times of highest priority tasks.

c) Though ISR responses are fast, the Deferred Procedure Calls (DPC) handling is a problem since they are managed in a FIFO order.

d) The thread switch latency is high (~ 1.2 ms), which is not acceptable in many real-time applications.

7. CONCLUSIONS

Real time Operating systems play a major role in the field of embedded systems especially for mission critical applications are involved. Selection of a particular RTOS for an application can be made only after a thorough study of the features provided by the RTOS. Since IC memories are getting denser scaled down versions of general operating systems are able to compete with traditional Real Time Operating Systems for the embedded product market. The choice of Operating System generally comes after the selection of the processor and development tools. Every RTOS is associated with a finite set of microprocessors and a suite of development tools. Hence the first step in choosing an RTOS must be to make the processor, real-time performance and the budget requirements clear. Then look at the available RTOS to identify the one which suits our application. Generally an RTOS for embedded application should have the following features:

I. Open Source II. Portable

III. ROM able IV. Scalable V. Pre-emptive

VI. Multi-tasking VII. Deterministic

VIII. Efficient Memory Management IX. Rich in Services X. Good Interrupt Management

XI. Robust and Reliable

Within the class of real-time embedded systems, the general feature is that system and its application are fixed for the life of a product or the system. Thus there is a real need for a general purpose architecture which would be flexible enough to meet the varied requirements of these systems( wide range of sensors, threats, and scenarios ), but which would still be dedicated and matched to an application through the use of special configurations of general modules. Even though most of the current kernels (RTOS) are successfully used in today real-time embedded systems, but they increase the cost and reduce flexibility. Next generation real-time operating systems would demand new operating systems and task designs to support predictability, and high degree of adaptability.

8. References

1. Operating System Support for Embedded Real-Time Applications, Alfons

Crespo, Ismael Ripoll, Michael Gonzalez Harbour, and Giuseppe Lipari, 2008

2. Dedicated Systems Experts, “What makes a good RTOS.” Brussels, Belgium: Dedicated Systems Experts, 2001.

3. S. Baskiyar ad N. Meghanathan, “A survey of contemporary Real-Time

Operating Systems,” Informatica 29(2005), pp. 233-240.

4. K. Ramamritham and J. A. Stancovic, “Scheduling Algorithms and Operating Systems Support for Real-time Systems,” Proceedings of the IEEE, pp. 55-67, Jan 1994.

5. C. Walls, “RTOS for Microcontroller Applications,” Electronic Engineering, vol. 68, no. 831, pp. 57-61, 1996.

Seminar Report- Embedded OS for Real Time Applications

Documents

Transcript of Seminar Report- Embedded OS for Real Time Applications