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)
1

(2010-2011)
Page
 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.

2
Page
 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
3

8. References................................................................................................. 24
Page
 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.
4
Page
 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
5

display and the microwave radiation. Inputs to the system generally take the form of
Page
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.
6
Page
 • 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:
7

a. Processor Management: The main tasks in processor management are

Page

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.
8
Page
 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

9
Page
 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.

•
10

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
Page

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.
11

4.2. CHARACTERISTICS OF REAL-TIME SYSTEMS

Page
 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
12

deadline-driven. Real-time systems can be classified, therefore, as either hard real-

time systems or soft real-time systems.
Page
 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
13

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.
Page

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.
14

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
Page

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.
15

5.1.2. LAYERED OPERATING SYSTEM

Page
 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

16

A new approach has been observed in the last 5 years: Client-

Page

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
17

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
Page

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.
18

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

Page

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.
19
Page
 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

20

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
Page

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

21
Page
 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
22

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
Page

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
23

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
Page

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
24

processes. There is no privilege protection between system and application and also
the support for communication between processes on different processors is poor.
Page
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
25

X. Good Interrupt Management

XI. Robust and Reliable
Page
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.

26
Page
 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.

27
Page