Embedded Operating Systems

Dinuka Wijesinghe
B00538290

University of Ulster, Jordanstown

Systems Software
COM 332
Assignment 2

Abstract installations like traffic lights, factory controllers, or the

This paper presents a comprehensive in-depth study of
Embedded Operating Systems. This includes
discussing typical requirements, constraints, and
applications of embedded systems. Typical characteristics ,
issues and design requirements for an embedded
operating systems and the relative advantages and
disadvantages of developing an embedded operating
system based on modifications to an existing operating
system compared to the development of a purpose-built
embedded operating system. This section should make
reference to commercially available embedded operating
systems.
Keywords: Requirements engineering, specification,
Embedded Operating Systems
1. Introduction
Like the familiar Microwave Oven, an Embedded System is
designed to perform some dedicated function. A
combination of hardware and software, it forms an
embedded part of a complete device. Since an Embedded
system has a limited range of applications, design
engineers face no problem to optimize both size and cost
or enhance reliability and quality of performance.
systems controlling nuclear power plants. Complexity
varies from low, with a single microcontroller chip, to very
high with multiple units, peripherals and networks
mounted inside a large chassis or enclosure.
Typically, embedded systems are Reactive and Real time
systems. A Reactive system is one, which is in continual
interaction with its environment and executes at a pace
determined by that environment.
Embedded system is application-oriented special
computer system which is scalable on both software and
hardware. It can satisfy the strict requirement of
functionality, reliability, cost, volume, and power
consumption of the particular application.
With rapid development of IC design and manufacture,
CPUs became cheap. Lots of consumer electronics have
embedded CPU and thus became embedded systems. For
example, PDAs, cell phones, point-of-sale devices, VCRs,
industrial robot control, or even your toasters can be
embedded system. There is more and more demand on the
embedded system market. Some report expects that the
demand on embedded CPUs is 10 times as large as general
purpose PC CPUs.
As applications of the embedded systems become more
complex, the operating system support and development
environment became crucial.

Embedded systems range from portable devices such as

digital watches and MP3 players, to large stationary

Figure 1: Generic embedded system.

 2. Uses of Embedded
Systems
There are endless uses for embedded systems in consumer
products, with new methods of exploiting them presented
every year at such industry events as the MEDC and the
Embedded Systems Conference. The most obvious
beneficiaries are those enterprises concerned with the
manufacture and sale of electrical devices, as the inclusion
of microcontrollers to replace general purpose
microprocessors can drive down unit manufacturing costs
and end user prices dramatically, resulting in increased
sales and an improved profit margin.
The use of embedded systems in electrical products can
also solve many problems of complexity and product size.
For example, a modern automobile may contain dozens of
embedded systems to control a wide range of processes
within the car, ranging from brake balance control to air
conditioning to the ignition system. Without embedded
systems it would be impossible to computerise all of these
features without the inclusion of a mass of complicated,
fault prone electronics.
The only realistic alternative to using embedded systems
in a modern automobile would be to install a fully
functional PC within the car to control all of the functions
currently managed by microcontrollers.
Examples:
• Audio like mp3 players and telephone switches
for interactive voice response systems
• Avionics, such as inertial guidance systems,
flight control hardware/software and other
integrated systems in aircraft and missiles
• Cellular telephones and telephone switches
• Electric or Electronic Motor controller for
Brushless DC motors, Induction motors and DC
Motors
• Engine controllers and antilock brake
controllers for automobiles
• Home automation products, such as
thermostats, air conditioners, sprinklers, and
security monitoring systems
• Handheld calculators
• Household appliances, including microwave
ovens, washing machines, television sets, DVD
players and recorders
• Medical equipment
• Personal digital assistant
• Videogame consoles
• Computer peripherals such as routers and
printers
• Industrial controllers for remote machine
operation
• Digital musical instruments (digital synthesizers
and digital pianos).
• Security applications such as DVR and video
server
Growing importance of embedded systems
• Worldwide mobile phone sales surpassed 156.4
rnillion units In Q2 2004, a 35% increase from
Q2 2003,
Characteristics
• Embedded Systems are designed to do some
specific task, rather than be a general-purpose
computer for multiple tasks. Some also have
real-time performance constraints that must be
met, for reason such as safety and usability;
others may have low or no performance
requirements, allowing the system hardware to
be simplified to reduce costs.
• Embedded Systems are not always separate
devices. Most often they are physically built-in
to the devices they control.
• The software written for embedded systems is
often called firmware, and is stored in read-only
memory or Flash memory chips rather than a
disk drive. It often runs with limited computer
hardware resources: small or no keyboard,
screen, and little memory.
• Must be dependable. Reliability R (t) =
Probability of system working correctly provided
that it was working at t=O. Making the system
dependable must not be an afterthought, it must
be considered from the very beginning
• Maintainability M (d) = Probability of system
working correctly d time units after error
occurred
• Availability A (t): Probability of system working
at time t.
• Safety: No harm to be caused.
• Security: Confidential and authentic
communication. Even perfectly designed
systems can fail if the assumptions about the
workload and possible errors turn out to be
wrong.
• Must be efficient
Energy efficient
Code-size efficient (especially for systems on a
chip)
Run-time efficient
Weight efficient
Cost efficient
• Dedicated towards a certain application.
Knowledge about behaviour at design time can
be used to minimize resources and to maximize
robustness.
• Dedicated user interface. (No mouse, keyboard
and screen)
• Many Embedded System must meet real-time
constraints
• Frequently connected to physical environment
through sensors and actuators, Dortmund
• The worldwide portable flash player market
exploded in 2003 and is expected to grow from
12.5 rnillion units in 2003 to over 50 rnillion
units in 2008
• Global 3G subscribers will grow from an
estimated 45 rnillion at the end of 2004 to 85
rnillion in 2005,according to Wireless World
Forum
 • The number of broadband lines worldwide should behaviour in a variety of circumstances. For
increased by almost 55% to over 123 rnillion in example,
the 12months to the end of June 2004,
according to Point-Topic. · The system shall adjust the angle of the telescope under
• Today's DVR (digital video recorders) users - 5% user control
of households will grow to 41% within five years · The system shall deliver anaesthetic agent in gaseous
• Embedded chips form the backbone of the form to a desired concentration.
electronics driven world in which we live they · Locking clamps shall engage when the elevator cable
are part of breaks.
• almost everything that runs on electricity · The device shall alarm if the heart rate falls to less than
• 79% of all high-end processors are used in 30 beats per minute.
· The pacemaker shall pace in AAI mode (pace the atrium,
embedded systems
sense in the atrium, inhibit on an intrinsic heart beat
detection).
Application areas · The spacecraft shall downlink captured information
periodically to the deep space network.
• Automotive
• Electronics Quality of Service (QoS) requirements specify how well a
• Avionics functional requirement shall be accomplished. In real-time
• Trains and embedded systems, QoS requirements may specify
• Telecommunication properties of the system, e.g. range, speed, throughput,
• Medical systems capacity, reliability, maintainability, evolvability, time to
• Authentication market, safety, predictability, schedulability; or properties
• Military applications of the process. As a rule of thumb, if it’s something that
can be quantified, or optimized, then it is a QoS
• Robotics
requirement. For example (QoS requirements italicized),
• Sensor technology
• Mobile phones · The angle of the telescope shall be set in units of 0.1
• Mobile base station degrees with a maximum error of 0.01 degrees.
• Telecom switch · The anaesthetic agent shall be controllable from 0.00%
• Optical O copper connections to 5.00% by volume in units of 0.01% with an accuracy of
• Smart welding machine 0.005%.
• Sewing machine · Locking clamps shall engage in the event of an elevator
support cable breakage within less than 0.5 seconds.
· The device shall alarm within 10 seconds if the heart rate
falls to less than 30 beats per minute.
· The pacemaker pacing rate shall be settable from 30 to
3. Requirements 120 paces per minute (inclusive) and during operation
accuracy of pacing shall be ±100 ms.
· The reliability of communications from the spacecraft to
the deep space network shall be better than 0.9994%, with
There are two kinds of requirements: functional and
a single bit error detection/correction rate of 0.9999%
quality of service. Functional requirements are
and a multiple bit detection/correction rate of 0.99%.
requirements about what the system should do and how it

Industrial Requirements Industrial requirements depend on applications; special

requirements typically include:
 • Availability and reliability
Availability (from Wikipedia): The degree to which a
system, subsystem, or equipment is operable and in a
committable state at the start of a mission, when the
mission is called for at an unknown, i.e., a random, time.
Simply put, availability is the proportion of time a system
is in a functioning condition.
Reliability: The IEEE defines it as ". . . the ability of a
system or component to perform its required functions
under stated conditions for a specified period of time." In
general, in automation, availability and reliability are
required to be very high, to minimize the cost of operation
(for instance to minimize scheduled and unplanned
maintenance)
• Safety
Safety: Absence of catastrophic consequences of a system
failure for property, humans, and environment
The (embedded) automation systems and plants have to be
safe operational over extended periods of time, even if they
continue operation in a degraded mode in the presence of
a fault.
• Survivability
Survivability: Need for restricted modes of operation that
preserve essential services in adverse operational
environments
• Security
Operational IT security requirements:
Confidentiality: Protecting data from unauthorized
entities
Integrity: Protecting against unauthorized data
manipulation
Availability: Data available when needed
• Real-time, deterministic response
Typically, (networked) embedded systems are required to
operate in a reactive way (for instance, systems used for
control purposes) requiring to respond within a predefined
period of time, mandated by the dynamics of the process
under control.
A response, in general, may be:
•Periodic - to control a specific physical quantity by
regulating dedicated end-effectors
•Aperiodic - arising from unscheduled events such as out-
of-bounds state of a physical parameter or any other kind
of abnormal conditions.
• Power consumption
Low-power design: extending life time of electronic
components (lifecycle). Wireless sensor networks need for
self-sustained energy source.
Sources of wireless power:
•Batteries, fuel cells, etc.
•From local environment: light, heat, vibration,
•Transmitted by optical and radio frequencies, sound
• Lifetime issues
Typical lifetime of a device in an industrial environment is
around 10 - 20 (plus) years
Need for:
•Increased reliability
•Robustness
•Re-configurability
•Maintainability
•Scalability
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: 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.
4. System Limitations
Most embedded systems place severe constraints on the
processor in the terms of requirements for size, weight,
power, cooling, performance, reliability, and cost.
This is because the processor is just a component of a
larger system, which has its own operating requirements
and manufacturing constraints.
Size and Weight
Size and weight restrictions can greatly limit the
complexity of the hardware which can be brought to bear
on solving a particular embedded control problem.
Platforms such as aircraft, spacecraft, and portable
equipment may have strict weight limitations. Most other
applications also have size limitations of some sort. A
typical embedded controller may have a size budget of a few
cubic inches, and a weight budget of a few pounds (including
the power supply requirements).
The problem with size and weight restrictions is that
high performance processing systems tend to be larger and
heavier than slower systems. At the CPU level, a processor
that has a large number of pins takes up a large printed
circuit board area. At the system level, a design that needs
cache memory controller chips and large amounts of
memory takes even more printed circuit board area.
The key to the size and weight issue is keeping
component count small. This is best accomplished by using
the highest integration level possible. But, even with
custom VLSI chips and surface- mount technology the
fact remains that in embedded system, high complexity
means problems with size and weight budgets. The
smallest systems are those which have on-chip memory for
some or all of the system requirements, do not require
external support chips (especially cache memory support),
and which allow small, efficient encodings of programs.
Power and Cooling
The processor complexity can affect the power
consumption of the system. High power consumption
increases the size and weight requirements of the power
supply. Since essentially all power consumed by a
computer is eventually given off as heat, increased power
consumption results in increased cooling requirements.
The amount of power used by the processor is related
to the number of transistors and pins on the processor
chip. Processors that rely on exotic process technology for
speed usually consume too much power to be useful.
Processors that need huge numbers of power consuming
high speed memory devices likewise can exceed a power
budget.
Consequently, CMOS components are usually used
whenever possible. Newer CMOS technology runs at high
speed, yet dissipates little power in comparison to other
technologies. Static CMOS is often selected because it can
operate with a slow or stopped clock to save power when the
system is idle.
Computing Performance
Computing performance in a real time embedded control
environment is not simply an instructions per-second
rating. While raw computational performance is
important, other factors which are vital to system
performance include interrupt response characteristics,
context switching overhead and I/O performances. Since
real time tasks are characterized by frequent, often
unpredictable events, the performance of a processor at
handling interrupts is crucial to its suitability for real time
processing. Since a control application usually involves a
reasonable amount of communication with the outside
world (such as reading sensors and activating control
circuits), good IJO performance is also important.
Two key considerations for more difficult real time
control applications are predictability and determinacy.
Predictable systems have behavior at run-time that is
easily understandable from examination of the original
source code program;
In other words, there are no surprises to a user of average
sophistication. Deterministic systems hove instructions
whose behavior does not vary; in other words, the
execution speed of an instruction does not depend on
execution history of the program. For real time control
with hard deadlines, a designer must be able to predict
with absolute certainty the running time of the piece of
code responding to an external event. If a system has
variable performance elements, such as cache memory, the
designer must be extremely pessimistic about the
performance of these features, and plan on the worst case.
In some systems, it is important to exactly determine the
time for a sequence of instructions to execute, with no
possibility for variation allowed. Processors with
extremely consistent execution speeds can use software to
reduce system complexity by replacing hardware such as
UART chips, disk controller chips, or video memory se-
quencers with programmed transfers using carefully timed
code.
Since program memory space may be extremely limited,
programs may be highly compacted by using subroutine
calls to reuse common code sequences. In fact, many
embedded applications use threaded languages such as
Forth because they produce exceedingly compact code.
This suggests that an embedded processor should have
efficient support for subroutine calls as a means of
conserving program memory.
Embedded processing applications are notorious for
extreme operating conditions, especially in automotive
and military equipment. The processing system must deal
with vibration, shock, extreme heat and cold, and perhaps
radiation. In remotely installed applications, such as
spacecraft and undersea applications, the system must be
able to survive without field service technicians to
make repairs.
The general techniques used for avoiding problems caused
by operating environments are to keep the component
count and number of pins as low as possible. It is also
helpful to keep the systems cool as possible to inhibit aging
of the system's components.
Cost
The cost of the processor itself may be very important to
low- and medium-performance systems, especially
consumer electronics products. Since the cost of a chip is
related to the number of transistors and to the number of
pins on the chip, low complexity processors have an
inherent cost advantage.
In high-performance systems, the cost of the processor
may be overwhelmed by the cost of the multi-layered
printed circuit boards, support chips, and high-
speed memory chips. In these cases, overall system
complexity must be reduced to keep system costs down.
Architectural Features
Many of the computer architect's techniques to improve
system performance, such as cache, branch target
buffers, and pre-fetch queues, work on statistical
principles. They assume things such as temporal and
spatial locality, which tend to be true on large workstation
programs when run for long periods of time. They give
relatively uniform performance when used in a CAD or
office automation environment.
However, the constraints of hard real time control
applications have requirements which make standard,
statistically good speedup techniques inappropriate. Real
time control of periodic events requires absolute
predictability, often down to a single clock cycle. Deadlines
must be guaranteed to be met 100% of the time. Having a
situation where an unfortunate interaction between
two different routines contending for cache
memory causes an increase in cache misses is simply
unacceptable. In a tightly scheduled environment, even the
time taken by a single cache miss can cause a missed
deadline.
Inappropriate Architectural Features
There are many reasons that an architectural feature is
included in a processor. Today, usually the feature is
added in order to support "general purpose" computing,
which usually means engineeri n g w o r k s t a t i o n
a p p l i c a t i o n p r o g r a m s . T h e problem is that this
definition of "general purpose" is often at odds with
requirements for the systems we have just described. The
list of architectural features that are inappropriate
for hard real time embedded control systems seems
similar to a catalogue of modern processor design
techniques. They are listed here along with a brief
explanation of the problems they can cause. The focus here
is on determinism and predictability, although the reader
should not forget that most of these features also
contribute substantially to system complexity as well.
Cache memory: Data and instruction cache m e m o r i e s
a r e t h e b i g g e s t s o u r c e s o f u n p r e dictability and
indeterminacy. Modern compiler technology is just
beginning to address the issue of scheduling
instruction cache misses. Furthermore, it is
impossible to characterize data cache misses for programs
of interesting complexity. Because the time required to
process a cache miss is approximately an order of
magnitude slower than the time required for a cache hit,
significant execution speed degradation takes place
with even a small percentage of cache misses. Figure 1
shows relative execution time variations that may take
place with varying numbers of cache misses. In this
five-instruction example, assuming that a cache
miss costs five clock cycles, execution time may vary
between 5 and 25 clock cycles for the same code. In hard
real-time systems, often the worst case of all cache misses
must be assumed for time-critical sections, resulting
in designing hardware with only fast static memory
chips that render the cache management hardware super-
fluous. On-chip caches add to system debugging concerns
because they are often not visible outside the chip.
Low semantic content of instructions: Low semantic
content of instructions greatly increases the number of
instructions that must be executed to accomplish a given
task. This, in turn, increases demands for high-speed
memory. A requirement for large amounts of high speed
If no spare bus cycles are forthcoming, the processor
must be stalled when the write buffer overflows.
Additional stalls can be caused if a memory read could
possibly correspond to a memory location that has yet
to be updated by the write buffer. Interaction between
the write buffer and cache misses for instruction and
data fetches can cause indeterminacy in program
execution.
Branch target buffers: This is a special case of an
instruction cache, in which past program execution
history is used to cache instructions at branch targets for
quick access. This type of instruction cache operates
in a manner dependent on input data, and so is
beyond the ability of compilers to manage effectively.
Branch target buffers are sometimes used in
conjunction with branch prediction strategies, in which
the compiler encodes a guess as to whether a
particular branch is likely to be taken into the
instruction itself, causing either the branch target or
the next consecutive instruction to be fetched before
the outcome of the branch is resolved. The actual time
to perform a branch then depends on whether the
compiler guessed the branch outcome correctly, and
whether the branch target buffer value corresponds to
the guess made by the compiler.
Pre-fetch queues: Pre-fetch queues greatly affect the
predictability of execution because the execution time
for an instruction depends on whether or not the
preceding instructions were slow enough to allow the
pre-fetch queue to accumulate new instructions. Thus,
determining whether a particular instruction will
execute quickly from the pre-fetch queue or slowly from
program memory requires cycle counting of several
preceding instructions to see if spare memory cycles would
have been available for the pre-fetch queue to fill. This
cycle counting is subtly affected by data-dependent
execution paths through the program as well as the
memory in turn either requires the use of cache memory
or a significant expense in making all program memory
out of cache-grade memory chips for high guaranteed
system performance.
Variable length execution times of instructions: Many
instructions can take a variable number of clock cycles to
execute, often depending on the data input to the
instruction. An example of such an instruction is a
multiply routine that has an "early-out" feature.
Write buffers: Write buffers allow the CPU to perform a
write to memory without pausing for an actual memory
cycle to take place. The problem is that this write must then
wait for spare bus cycles.
number of wait states or cache misses in program
memory. For example, if there is latency for filling an
empty pre-fetch queue, adding a one- cycle wait state
that causes the pre-fetch queue to be emptied may add
more than one clock cycle to program execution time.
Pipelines: Deep instruction pipeline increases interrupt
response latency. Even if the first instruction of an
interrupt service routine can be inserted into the
pipeline within one clock of the interrupt being asserted, it
still takes several clock cycles for the instruction to
pass through the pipeline and actually do its job. A
pipeline also requires some sort of handling of
data dependencies and delays for memory access, which
results either in compiler-generated flops, instruction
rearrangement, or hardware-generated pipeline
stalls. All of these dependency-resolution techniques
decrease predictability, determinacy, or both.
Pure load/store architectures: Load/store RISC
architectures can by their very nature makes no
provision for atomic read/modify/write instructions. This
generally required the addition of external hardware
for implementing semaphores, locks, and other
inter-process communication devices, increasing
system complexity.
Scoreboards: Scoreboards attempt to speed up program
execution by allowing several instructions to be in
execution concurrently. Score boarding usually implies
out-of-order execution, which may make it impossible to
correctly determine the correct system state in the event of
an exception or interrupt (the term usually used here
is that the system has imprecise interrupts).
Furthermore, the execution time of an instruction
depends on the resources being used by the previous
several instructions, and can vary considerably.
Supers cater instruction issue: Newer-generation
microprocessors are beginning to implement
"superscalar" instruction execution, in which multiple
instructions may be issued in a single clock cycle.
Unfortunately, the number of instructions that may be
issued depends on the types of the instructions, the
available hardware resources, and the execution
history of the program. All these factors make it
very difficult to determine any single instruction's
execution time.
Dependence on sophisticated compiler technology: Most
RISC designs depend implicitly on complex and
ambitious optimizing compilers for fast op erating
speeds. This t radeoff between hardware and
software complexity is a part of the RISC design
philosophy. The problem is that the optimizing compilers
make it difficult to establish a correspondence between
source code and the code that actually is executed
because of the large number of program transformations
performed. This c o m p l i ca t es p r o g ra m d eb u g g i n g ,
a s w el l a s decouples the programmer's source code
changes f ro m eff ect s on f in a l p ro g ra m
p erf o rm a n ce, decreasing predictability. A surprising
side-effect of the complexity of these compilers is that
they add a level of indeterminacy in the mapping of
source to object code. The use of heuristics for
block-level and global optimization techniques can
actually cause the same exact sequence of source code
statements to generate significantly different object code
in two places of the same program module (Razouk
etal. 1986).
Large register file: The use of a large number of
registers allows programs to execute quickly, hut
greatly increases the amount of information (the
machine state) that must be saved on context switches and
interrupts. This adversely affects responsiveness to
external events.
Virtual memory: The use of virtual memory
5. Embedded OS vs. General
Purpose OS
The key difference between general-computing operating
systems and real-time operating systems is the need for
“deterministic " timing behaviour in the real-time
operating systems. Formally, "deterministic" timing means
that operating system services consume only known and
expected amounts of time. In theory, these service times
could be expressed as mathematical formulas. These
formulas must be strictly algebraic and not include any
random timing components. Random elements in service
times could cause random delays in application software
and could then make the application randomly miss real-
time deadlines – a scenario clearly unacceptable for a real-
time embedded system. Many non-real-time operating
systems also provide similar kernel services.
General-computing non-real-time operating systems are
often quite non-deterministic. Their services can inject
random delays into application software and thus cause
slow responsiveness of an application at unexpected times.
If you ask the developer of a non-real-time operating
system for the algebraic formula describing the timing
behaviour of one of its services (such as sending a message
from task to task), you will invariably not get an algebraic
implies the use of a cache memory to perform
address translation (a Translation Look aside Buffer),
which has the same problems as other caches. If a
disk-paging system is used, the problem of speed
degradation can become much worse than for simple
cache misses.
Use of DRAM access technology: Some processor
implementations exploit special access techniques to
DRAM chips in order to achieve high average
throughput with a low system coat. The use of static-
column, paged, and video DRAMs creates real
problems in predictability because access to these
DRAMs becomes much slower whenever page boundaries
must be crossed. The use of DRAM memory chips also
requires performing memory refresh, which can
interact with other accesses to cause performance
degradations that are worse than expected.
Autonomous I/O processors: The use of
autonomous I/O processors and DMA hardware that
steal bus cycles can cause non-determinism as the
processor is stalled for bus accesses. Consequently, it is
sometimes desirable to perform I/O directly from the
CPU.
The Challenge to Processor Designers
The above list of architectural characteristics contains
elements of design found in virtually every RISC or
CISC processor made today. These architectural
characteristics are truly valuable for speeding up average
system performance, especially in workstation
environments. The problem is that hard embedded
real time control applications do not have the same
characteristics and requirements as workstation-based
engineering design applications, and so these
characteristics actually hurt s ystem p erformance.
Therefo re, what is needed are new CPU design's that
make tradeoffs in favor of the requirements of real time
embedded control, even at the expense of performance of
workstation-type applications.
formula. Instead the developer of the non-real-time
operating system (such as Windows, UNIX or Linux) will
just give you a puzzled look. Deterministic timing
behaviour was simply not a design goal for these general-
computing operating systems.
On the other hand, real-time operating systems often go a
step beyond basic determinism. For most kernel services,
these operating systems offer constant load-independent
timing: In other words, the algebraic formula is as simple
as: T(message send) = constant , irrespective of the length
of the message to be sent, or other factors such as the
numbers of tasks and queues and messages being
managed by the RTOS.
Many RTOS proponents argue that a real-time operating
system must not use virtual memory concepts, because
paging mechanics prevent a deterministic response. While
this is a frequently supported argument, it should be noted
that the term "real-time operating system" and
determinism in this context covers a very wide meaning,
and vendors of many different operating systems apply
these terms with varied meaning. When selecting an
operating system for a specific task, the real-time attribute
alone is an insufficient criterion, therefore. Deterministic
behaviour and deterministic latencies have value only if
the response lies within the boundaries of the physics of
the process that is to be controlled. For example,
controlling a combustion engine in a racing car has
different real-time requirements to the problem of filling a
1,000,000 litre water tank through a 2" pipe.
Real-time operating systems are often uses in embedded
solutions, that is, computing platforms that are within
another device. Examples for embedded systems include
combustion engine controllers or washing machine
controllers and many others. Desktop PC and other
general-purpose computers are not embedded systems.
The most common operating system for
personal computer include Windows from Microsoft, OS X
from Apple, and the wide variety of Linux variants that can
be obtained from their respective developers. What most
people do not know are Real-time Operating Systems or
generally referred to by the acronym RTOS. These are
operating systems that are used for more specialized
applications that demand response that is as close to real
time as possible. The most significant difference between
the two is in how they approach each task. Standard
operating systems focus on doing as much computation in
the shortest span of time while RTOS’s emphasize on
having a predictable response time.
Standard operating systems are widely used nowadays,
partly due to the rapid spread of personal computers.
Devices that use standard operating systems, aside from
computers and laptops, are also beginning to appear.
RTOS’s are used in more specialized fields where the
response time is much more important than the ability to
An RTOS is not required for an embedded system but it
can offer powerful advantages to the system developer.
Without an RTOS the developer must write his own code
to handle all of these functions.
• Enables real-time, deterministic scheduling and task
prioritization
• Abstracts away the complexities of the processor
• Provides a solid infrastructure constructed of rules
and policies
• Simplifies development and improves developer
productivity
• Integrates and manages resources needed by
communications stacks and middleware
• Optimizes use of system resources
• Improves product reliability, maintainability and
quality
• Promotes product evolution and scaling
While real-time operating systems are typically designed
for and used with embedded systems, the two aspects are
essentially distinct, and have different requirements. A
real-time operating system for embedded system
addresses both sets of requirements.
process a huge number of instructions within a given time
span. Examples of which are computer that scan levels and
states in a facility. It is important that the monitors see
changes occur at the instant that they do.
Most operating systems use a time sharing architecture
where each task is assigned a small slice of time to execute
its instructions before switching to another task. The
switching process is too fast that it often appears as real
time to users. Some RTOS’s also use this design but with
much lower density of tasks to ensure that the processor
never gets to loaded, which can increase the response time.
Another design that is used for an RTOS is an event-driven
architecture. In this design, the system only switches tasks
once an event or interrupt occurs.
Coding practices for an RTOS is much stricter compared to
a standard OS as the code needs to perform consistently all
the time. Standard OS’s are not that concerned since
response time is not of great importance in its application.
A well-architected RTOS will handle these functions much
more efficiently that a programmer could write the code.
RTOS developers are expert in how to handle operations
with a minimum of processor cycles.
There are many questions when adapting a GPOS (General
Purpose Operating System) RTOS:
• What does an RTOS have that a GPOS does not?
• How useful are the real-time extensions now
available for some GPOSs?
• Can such extensions provide a reasonable
facsimile of RTOS performance?
Task scheduling
Let’s begin with task scheduling. In a GPOS, the scheduler
typically uses a fairness policy to dispatch threads and
processes onto the CPU. Such a policy enables the high
overall throughput required by desktop and server
applications, but offers no guarantees that high-priority,
time critical threads will execute in preference to lower-
priority threads. For instance, a GPOS may decay the
priority assigned to a high-priority thread, or otherwise
dynamically adjust the priority in the interest of fairness to
other threads in the system. A high-priority thread can, as
a consequence, be pre-empted by threads of lower priority.
In addition, most GPOSs have unbounded dispatch
latencies: the more threads in the system, the longer it
takes for the GPOS to schedule a thread for execution. Any
one of these factors can cause a high-priority thread to
miss its deadlines – even on a fast CPU.
In an RTOS, on the other hand, threads execute in order
of their priority. If a high-priority thread becomes ready to
run, it will, within a small and bounded time interval, take
over the CPU from any lower-priority thread that may be
executing. Moreover, the high-priority thread can run
uninterrupted until it has finished what it needs to do –
unless, of course, it is pre-empted by an even higher
priority thread. This approach, known as priority-based
pre-emptive scheduling, allows high-priority threads to
meet their deadlines consistently, no matter how many
other threads are competing for CPU time.
Pre-emptily kernel
For most GPOSs, the OS kernel is not pre-emptily.
Consequently, a high-priority user thread can never pre-
empty a kernel call, but must instead wait for the entire
call to complete – even if the call was invoked by the
lowest-priority process in the system. Moreover, all
priority information is usually lost when a driver or other
system service, usually performed in a kernel call, executes
on behalf of a client thread. Such behaviour causes
unpredictable delays and prevents critical activities from
completing on time. In an RTOS, on the other hand, kernel
operations are pre-emptily. There are still windows of time
in which pre-emption may not occur, but in a well-
designed RTOS, those intervals are extremely brief, often
on the order of hundreds of nanoseconds. Moreover, the
RTOS will impose an upper bound on how long pre-
emption is held off and interrupts disabled; this allows
developers to ascertain worst-case latencies.
To achieve this goal, the RTOS kernel must be simple and
as elegant as possible.
Only services with a short execution path should be
included in the kernel itself. Any operations that require
significant work
(For instance, process loading) must be assigned to
external processes or threads. Such an approach helps
ensure that there is an upper bound on the longest non-
pre-emptily code path through the kernel. In a few GPOSs,
such as Linux 2.6, some degree of pre-emptibility has been
added to the kernel. However, the intervals during which
pre-emption may not occur are still much longer than
those in a typical RTOS; the length of any such pre-
emption interval will depend on the longest critical section
of any modules incorporated into the kernel (for example,
networking and file systems). Moreover, a pre-empt kernel
does not address other conditions that can impose
unbounded latencies, such as the loss of priority
information that occurs when a client invokes a driver or
other system service.
Avoiding priority inversion
Even in an RTOS, a lower-priority thread can
inadvertently prevent a higher priority thread from
accessing the CPU – a condition known as priority
inversion. Generally speaking, priority inversion occurs
when two tasks of differing priority share a resource, and
the higher priority task cannot obtain the resource from
the lower-priority task. To prevent this condition from
exceeding a fixed and bounded interval of time, an RTOS
may provide a choice of mechanisms including priority
inheritance and priority ceiling emulation. We could not
possibly do justice to both mechanisms here, so let us
focus on a simple example of priority inheritance. To
begin, we first must look at the blocking that occurs from
synchronization in systems, and how priority inversion
can occur as a result. Let us say two jobs are running, and
that Job 1 has the higher priority. If Job 1 is ready to
execute, but must wait for Job 2 to complete an activity,
we have blocking. This blocking may occur as a result of
synchronization – waiting for a shared resource controlled
by a lock or a semaphore – or as a result of requesting a
service.
The blocking allows Job 2 to run until the condition that
Job 1 is waiting for occurs (for instance, Job 2 unlocks the
resource that both jobs share). At that point, Job 1 gets to
execute. The total time that Job 1 must wait may vary, with
a minimum, average, and maximum time. This interval is
known as the blocking factor. If Job 1 is to meet any of its
timeliness constraints, this factor cannot vary according to
any parameter, such as the number of threads or an input
into the system. In other words, the blocking factor must
be bounded. Now let us introduce a third job that has a
higher priority than Job 2 but a lower priority than Job 1
(Figure 1). If Job 3 becomes ready to run while Job 2 is
executing, it will pre-empty Job 2, and Job 2 will not be
able to run again until Job 3 blocks or completes. This will,
of course, increase the blocking factor of Job 1; that is, it
will further delay Job 1 from executing. The total delay
introduced by the pre-emption is a priority inversion. In
fact, multiple jobs can pre-empt Job 2 in this way,
resulting in an effect known as chain blocking. Under
these circumstances, Job 2 might be pre-empted for an
indefinite period of time, yielding an unbounded priority
inversion, causing Job 1 to fail to meet any of its timeliness
constraints. This is where priority inheritance comes in. If
we return to our scenario and make Job 2 run at the
priority of Job 1 during the synchronization period, then
Job 3 will not be able to pre-empty Job 2, and the resulting
priority inversion is avoided (Figure 2).
Duelling kernels
GPOSs – Linux, Windows, and various flavors of UNIX –
typically lack the Mechanisms we have just discussed.
Nonetheless, vendors have developed a number of real-
time extensions and patches in an attempt to fill the gap.
There is, for example, the dual-kernel approach, in which
the GPOS runs as a task on top of a dedicated real-time
kernel (Figure 3). Any tasks that require deterministic
scheduling run in this kernel, but at a higher priority than
the GPOS kernel. These tasks can thus pre-empt the GPOS
whenever they need to execute and will yield the CPU to
the GPOS only when their work is done.
Unfortunately, tasks running in the real-time kernel can
make only limited use of existing system services in the
GPOS – file systems, networking, and so on. In fact, if a
real-time task calls out to the GPOS for any service, it will
be subject to the same pre-emption problems that prohibit
GPOS processes from behaving deterministically. As a
result, new drivers and system services must be created
specifically for the real-time kernel – even when
equivalent services already exist for the GPOS.
Also, tasks running in the real-time kernel do not benefit
from the robust Memory Management Unit (MMU)
protected environment that most GPOSs provide for
regular, non-real-time processes. Instead, they run
unprotected in kernel space.
Consequently a real-time task that contains a common
coding error, such as a corrupt C pointer, can easily cause
a fatal kernel fault. To complicate matters, different
implementations of the dual kernel approach use different
APIs. In most cases, services written for the GPOS cannot
be easily ported to the real-time kernel, and tasks written
for one vendor’s real-time extensions may not run on
another’s real-time extensions.
Modified GPOSs
Rather than use a second kernel, other approaches modify
the GPOS itself, such as by adding high-resolution timers
or a modified process scheduler. Such approaches have
merit, since they allow developers to use a standard kernel
(albeit with proprietary patches) and programming model.
Moreover, they help address the requirements of reactive,
event-driven systems.
Unfortunately, such low-latency patches do not address
the complexity of most real-time environments, where
real-time tasks span larger time intervals and have more
dependencies on system services and other processes than
do tasks in a simple event-driven system. For instance, in
systems where real-time tasks depend on services such as
device drivers or file systems, the problem of priority
inversion would have to be addressed. In Linux, for
example, the driver and Virtual File System (VFS)
frameworks would effectively have to be rewritten along
with any device drivers and file systems employing them.
Without such modifications, real-time tasks could
experience unpredictable delays when blocked on a
service. As a further problem, most existing Linux drivers
are not pre-empting. To ensure predictability,
programmers would also have to insert pre-emption
points into every driver in the system. All this points to
the real difficulty and immense scope of modifying a GPOS
so it is capable of supporting real-time behaviour.
However, this is not a matter of RTOS good, GPOS bad.
GPOSs such as Linux, Windows XP, and UNIX all serve
their intended purposes extremely well. They only fall
short when they are forced into deterministic
environments they were not designed for, such as those
found in automotive telemetric systems, medical
instruments, and continuous media applications.
What about an RTOS?
Still, there are undoubted benefits to using a GPOS, such
as support for widely used APIs, and in the case of Linux,
the open source model. With open source, a developer can
customize OS components for application-specific
demands and save considerable time troubleshooting. The
RTOS vendor cannot afford to ignore these benefits.
Extensive support for POSIX APIs – the same APIs used
Along with diagnostic information such as the contents of
data items and a history of function calls. This architecture
also provides superior fault isolation. If a driver, protocol
stack, or other system service fails, it can do so without
corrupting other services or the OS kernel. In fact,
software watchdogs can continuously monitor for such
events and restart the offending service dynamically,
without resetting the entire system or involving the user in
any way. Likewise, drivers and other services can be
stopped, started, or upgraded dynamically, again without a
system shutdown.
A strategic decision
An RTOS can help make complex applications both
predictable and reliable. In fact, the predictability made
possible by an RTOS adds a form of reliability that cannot
be achieved with a GPOS (if a system based on a GPOS
does not behave correctly due to incorrect timing
behaviour, then we can justifiably say that the system is
unreliable). Still, choosing the right RTOS can itself be a
complex task. The underlying architecture of an RTOS is
an important criterion, but so are other factors. Consider
Internet support. Does the RTOS support an up-to-date
suite of protocol stacks such as IPv4, IPv6, IPSec, SCTP,
and IP filtering with NAT? What about scalability? Does
the RTOS support a limited number of processes, or does
it allow hundreds or even thousands of processes to run
concurrently? And does it provide support for distributed
or symmetric multiprocessing?
GUI considerations
Graphical User Interfaces (GUIs) are becoming
increasingly common in embedded systems, and those
interfaces are becoming increasingly sophisticated.
by Linux and UNIX – is an important first step. So is
providing well-documented source and customization kits
that address the specific needs and design challenges of
embedded developers. The architecture of the RTOS also
comes into play. An RTOS based on a microkernel design,
for instance, can make the job of OS customization
fundamentally easier to achieve. In a microkernel RTOS,
only a small core of fundamental OS services (such as
signals, timers, and scheduling) reside in the kernel itself.
All other components (such as drivers, file systems,
protocol stacks, and applications) run outside the kernel as
separate, memory protected processes (Figure 4). As a
result, developing custom drivers and other application-
specific OS extensions does not require specialized kernel
debuggers or kernel gurus. In fact, as user space programs,
such extensions become as easy to develop as regular
applications, since they can be debugged with standard
source level tools and techniques. For instance, if a device
driver attempts to access memory outside its process
container, the OS can identify the process responsible,
indicate the location of the fault, and create a process
dump file viewable with source-level debugging tools. The
dump file can include all the information the debugger
needs to identify the source line that caused the problem,
Consequently, does the RTOS support primitive graphics
libraries, or does it provide an embeddable windowing
system that supports 3D rendering, multi-layer interfaces,
and other advanced graphics? Can you customize the
GUI’s look-and feel? Can the GUI display and input
multiple languages simultaneously? And does the GUI
support an embeddable web browser? The browser should
have a scalable footprint, and be capable of rendering web
pages on very small screens. It should also support current
standards such as HTML 4.01, XHTML 1.1, SSL 3.0, and
WML 1.3.
Tool considerations
On the tools side, does the RTOS vendor offer diagnostic
tools for tasks such as trace analysis, memory analysis,
application profiling, and code coverage? What of the
development environment? Is it based on an open
platform like Eclipse, which lets you readily plug in third-
party tools for modelling, version control, and so on? Or is
it based on proprietary technology? On one point, there is
no question. The RTOS can play a key role in determining
how reliable your system will be, how well it will perform,
and how easily it will support new or enhanced
functionality. And it can support many of the rich services
traditionally associated with GPOSs, but implemented in a
way to address the severe processing and memory
restraints of embedded systems.
6. Embedded GPOS Examples
Windows XP
Benefits: Windows® XP Embedded is built on upon the
proven code base of Windows XP, which features a 32-bit
computing architecture and a fully protected memory
model. Key reliability, security, and performance features
include Device Driver Rollback, a pre-emptive Multi-
tasking Architecture, and Encrypting File System (EFS)
with Multi-user Support.
By componentizing Windows® XP Professional, Windows
XP Embedded enables developers to use the latest
technologies the Windows platform has to offer, while at
the same time achieving a reduced footprint. Embedded
developers can take advantage of all the great features
available in Windows XP such as multimedia capabilities.
Features include Universal Serial Bus (USB) and Internet
Explorer 6.0.
Windows XP Embedded also includes embedded-enabling
features, such as Flexible Boot and Storage Options, and
Enhanced Write Filter. Rich networking capabilities and
management features provide Windows® XP Embedded
devices seamless integration with PCs, servers, Web
services, and other devices. Comprehensive networking
protocol support includes Infrared Data Association
(IrDA) Support, 802.11 and 802.1x, and Universal Plug
and Play.
Windows® XP Embedded includes a completely
redesigned tool set that enables devices based on Windows
XP Embedded to be brought to market faster. The new
Windows Embedded Studio streamlines the end-to-end
development process enabling developers to rapidly
configure, build, and deploy smart designs with rich
applications.
Features:
Device Driver Rollback If issues occur when new
device drivers are added, a copy of the previously installed
driver is saved, enabling a user to roll back to the original
device.
Universal Serial Bus (USB) Supports a wide array of
USB peripherals such as scanners, mice, keyboards, and so
on.
Universal Plug and Play (UPnP) Universal Plug and
Play (UPnP) is architecture for pervasive peer-to-peer
network connectivity of devices of all form factors,
including intelligent appliances and wireless devices.
UPnP is a distributed, open networking architecture that
leverages TCP/IP and the Web to enable seamless-
proximity networking in addition to control and data
transfer among networked devices in the home, office, and
everywhere in between.
Pre-emptive Multi-tasking Architecture Designed
to allow multiple applications to run simultaneously.
Includes enhancements to ensure great system response
and stability.
Encrypting File System (EFS) with Multi-user
Support Encrypts each file with a randomly generated
key. The encryption and decryption processes are
transparent to the user. In Windows XP Embedded, EFS
can allow multiple authorized users access to an encrypted
document.
Flexible Boot and Storage Options In addition to
magnetic disk, boot capability is offered for alternative
nonvolatile (persistent) read/write storage devices such as
Flash ROM and battery-backed RAM. Boot from CDROM
is possible when the El Torito bootable CD-ROM driver is
used in combination with the Enhanced Write Filter and
ROM. Windows XP Embedded also provides support for
DiskOnChip Flash, PCMCIA-ATA, Compact Flash,
MultiMediaCard, and MemoryStick.
Enhanced Write Filter Enhanced Write Filter (EWF)
re-routes selected disk I/O to memory or another storage
medium, thus providing the appearance to the operating
system that your read-only storage is writable.
Internet Explorer 6 Provides the latest Web browsing
technologies including visual refresh, playback support for
Flash and Shockwave files, and privacy enhancements.
802.11 Windows XP Embedded supports 802.11 wireless
LAN technologies that provide high bandwidth
connectivity without wires.
802.1X 802.1X provides secure access to the network to
support wireless LANs and Ethernet. It enables
interoperable user identification, centralized
authentication, and dynamic key management and can
secure both wired and wireless LAN access.
Infrared Data Association (IrDA) Support Windows
XP Embedded fully supports standards for this low-cost,
low-power, cable replacement technology that enables any
device to communicate from point-to-point when two
devices are in line sight of each other.
Embedded-Specific Features Windows XP Embedded
with Service Pack 1 incorporates the latest embedded-
enabling capabilities, focusing on remote deployment and
maintenance scenarios.
Remote Boot The Remote Boot service for Windows XP
Embedded with Service Pack 1 enables a Windows XP
Embedded-based client device to boot using an image
downloaded from a server. It also enables Windows XP
Embedded-based devices to operate without requiring
persistent storage, such as a hard drive or Flash RAM.
Device Update Agent Windows XP Embedded with
Service Pack 1 enhances support for in-field servicing with
Device Update Agent (DUA). DUA is designed to address
scenarios where it is necessary to incrementally update or
service a Windows XP Embedded device that has been
previously deployed to the field.
Footprint Estimator Using Footprint Estimator,
embedded developers can now estimate the footprint size
of individual components and their dependencies, as well
as macro components, prior to adding them to a
configuration. This enables developers to proactively know
what the impact of a given component will have on the
image size, thereby avoiding guesswork and saving
development time.
System Deployment Image (SDI) Manager: The
System Deployment Image (SDI) service enables you to
quickly deploy run-time images to your Windows XP
Embedded-based devices. The SDI feature enables easier
staging of runtime images on your development
workstation and preparation of images for fast
deployment. It also provides an easier method for
transferring the runtime image from the development
system to the device.
Multilingual User Interface (MUI) Language
Packs Windows XP Embedded with Service Pack 1 has
support for over 20 languages. Windows XP Embedded
MUI Language Packs enable you to save time and effort in
localizing your solution for multiple markets by enabling
you to develop your customized operating system image
only once rather than requiring you to localize each
version from the ground up. By simply adding the desired
language pack to your base English configuration, the user
interface will be localized into your chosen language.
Hardware Requirements
CPU: Computer with 300 megahertz or higher processor
clock speed recommended; Pentium II 233 MHz minimum
required (single or dual processor system);* Intel
Pentium/Celeron family, or AMD K6/Athlon/Duron
family, or compatible processor recommended. Some
slower CPU's are supported but will cause limitations of
the build particularly in multimedia applications.
RAM: 256 Megabytes (MB) of RAM or higher (256
megabytes recommended) (128 MB minimum supported;
but will limit performance and some features)
Flash: 200 megabytes or more of available storage space
Video: Super VGA (800 × 600) or higher-resolution
video adapter and monitor
User Interface: Keyboard and Microsoft Mouse or
compatible pointing device
Typical requirements for a Full standard
workstation XPE build: A system with a Pentium III
or better processor 256MB of memory and at least 2GB of
flash for a Full Standard build with SP3 and .Net 3.0
frameworks. Builds running multimedia will require a
faster processor and more memory, typically at least
512MB, to run smoothly.
Minimum recommended system for a Full
standard workstation XPE build: LX800 500MHz
CPU, 512MB of memory 4GB of High-speed DMA Flash
Minimum recommended system for a partial
workstation XPE build: VDX 800MHz CPU, 256MB
of memory 1GB Embed disk Flash
Windows NT
FEATURES & BENEFITS
Scalable Functionality; Supports Both Workstation and
Server Features — Windows NT Embedded can be scaled
from a workstation with no GUI to a full-server, based on
the requirements of the application. There are four
licensing configurations: Headless Workstation, Full
Workstation, Headless Server, and Full Server.
Authoring Tool Set — Windows NT offers a broad
spectrum of functionality with many opportunities for
"componentization". To take advantage of this, Windows
NT Embedded includes an authoring tool set that is
currently composed of two tools, the Target Designer and
the Component Designer. The Target Designer is the
primary authoring tool, allowing you to define the target
configuration of the OS and build the run-time
environment for the device. While the Target Designer
defines the set of files and configuration information to be
included on the target system, the Component Designer
allows you to define elements of the OS into components.
One or more components comprise a capability and
capabilities are grouped together to form overall system
configurations. It is the inclusion or exclusion of
components that ultimately determines the feature-set of
the embedded target. Using the familiar Windows NT user
interface, the tool set guides you through the process of
profiling, defining, and generating customized software
system.
Headless support — this enables Windows NT to be used
in devices that boot and run without a mouse, keyboard or
display device. Many embedded systems do not expose
either a traditional user interface (e.g. Windows-based or
DOS-based PC) or, in many instances, any local user
interface whatsoever. Windows NT requires a display
driver to interface between the graphics sub-system and
the video hardware. All currently available video display
drivers assume and rely on the existence of underlying
video hardware. Windows NT Embedded does not require
this.
Read-Only Boot Support — many embedded devices
utilize ROM to support stateless operation, lower the unit
cost and improve reliability. Windows NT Embedded
supports a variety of read-only media for boot-strapping
itself in a manner that is transparent to the applications
and system binaries that access the media.
Solid-State Media Support — Due to environmental
factors such as shock or vibration, many embedded
devices use bootable non-volatile storage media with no
moving parts to increase mean time between failure
(MTBF) ratings and to improve overall device robustness.
NT Embedded supports solid state disks and flash
memory.
Remote Management — in an embedded system, access to
the operating system and/or application is often through a
remote system of some type, since a user interface on the
device itself does not exist or is not practical to access.
Windows NT Embedded provides both character-mode
and graphical management solutions using serial, dial-up,
and network connections.
Error Recovery — Robustness and fault-resilience have
always been design criteria of Windows NT. For example,
Windows NT possesses characteristics such as protected
virtual memory and object-based security. Many
embedded applications have more extensive error recovery
requirements since they are often used in 7/24 an
application in which operator intervention and assistance
is not practical. Windows NT Embedded solves the issues
associated with "blue screens", the communication of error
conditions normally displayed on the console that require
user interaction. These errors can not only be logged, but
can be used to trigger application software events.
TECHNICAL OVERVIEW
A developer configures a device-specific NTE image by
using Target Designer to select the Windows NT binaries
needed by the application, the binaries associated with the
special NTE features required by the application, and the
application itself. In some cases, Component Designer is
needed to recreate reusable components not found in NTE
(e.g. device drivers). Once created, new components are
imported into Target Designer, dependencies are checked,
and an OS image is built that can be downloaded onto the
device.
Windows NT Embedded does not compete with Windows
CE but rather provides a complementary choice for
embedded developers. There are a number of design
considerations that will help to select the best version of
Windows for your device:
§ Platform
Windows NT Embedded is currently only available for
Intel Pentium and compatible microprocessors. Windows
CE supports X86 microprocessors as well as RISC
processors such as MIPS, ARM and StrongARM, SHx, and
PPC.
§ Footprint
If a device needs a small footprint, Windows CE
is the best choice, requiring as little as 4MB of
RAM. Windows NT Embedded requires a device
with the specifications listed below:
Class 1 — Headless Workstation
Standard Install
Memory: 32 to 256 MB of RAM
Storage (min.): 128 MB
(Build size is about 92 MB.)
Specialized Install
Memory: 16 to 256 MB of RAM
Storage (min.): 32 MB
(Build size is about 32 MB.)
Class 2 — Standard Workstation
Standard Install
Memory: 32 to 256 MB
Storage (min.): 128 MB
(Build size is about 90 MB.)
Specialized Install
Memory: 16 to 256 MB
Storage (min.): 32 MB
(Build size is about 30 MB.)
Windows NT Embedded supports up to 256 MB
of RAM Maximum.
§ Feature Set
Windows CE is the best choice if the device
requires semi-real-time capabilities, instant on,
and the ability to operate in a disconnected
state. Windows NT Embedded would be the
better choice if the device requires the full
Win32 API, built-in networking, Windows NT
security, remote administration and
management, POSIX support, and extensive
device driver support. Real-time capabilities for
NT and NT Embedded can be added using third
party solutions. There is no USB support for
Windows NT Embedded, all drivers for USB
support must be custom written.
Windows CE
The Windows CE operating system is a 32-bit,
multitasking, multithreaded operating system that has a
scalable, open architecture design, providing support for a
variety of devices. Windows CE is compact, providing high
performance in limited memory configurations,
supporting a range of embedded, mobile or multimedia
product lines. Windows CE also has integrated power
management, enabling long battery life on mobile devices.
Standard communications support is built into Windows
CE, enabling access to the Internet to send and receive e-
mail or browse the World Wide Web. A graphical user
interface incorporating many elements of the familiar the
Desk-Top Windows user interface is also available,
facilitating ease-of-use for end users.
KEY FEATURES & BENEFITS
Sub-set of Win32 API – Windows CE supports more than
700 of the most-frequently-used Win32 APIs, enabling
developers to take advantage of vast amounts of third-
party programming resources, tools, software examples,
and documentation for their Windows CE-based
development. With more than 500,000 developers
worldwide using Win32, there are many experienced
programmers who already know how to develop for the
Microsoft Windows CE platform, which lowers training
costs and shortens your time to market.
Low-cost, familiar development tools – Windows CE
requires two inexpensive, basic development tools. The
first development tool is for the operating system itself:
Platform Builder which is required if you are generating
your own build. If you have EMAC generate your build you
will not require this relatively expensive and difficult to
use tool. Platform Builder contains all of the cross-
compilers, assemblers, remote debugger tools, boot
loaders, sample device drivers (keyboard, LCD, serial,
IrDA, touch screen, etc.), sample platforms, and operating
system components. The second development tool
Windows Visual Studio is used for developing
applications.
Scalable, full-featured operating system – Windows CE
can be customized for a product by selecting from a set of
available software modules. In addition, some of the
modules are componentizable, which means that you can
further customize the modules by selecting from a set of
available components for that module. Because the
Windows CE operating system is componentized, you can
design embedded system platforms using the minimum
set of software modules and components needed to
support the platform's system requirements. This
minimizes the memory footprint and maximizes
performance of the operating system. Windows CE scales
from a kernel to a full-featured OS with networking and
GUI.
Extensive and Extensible Device Support – Windows CE
directly supports many kinds of hardware peripherals and
devices, such as keyboards, mouse devices, touch panels,
serial ports, Ethernet, modems, USB devices, audio
devices, parallel ports, printer devices, and storage devices
(ATA or flash media). At the same time, as Windows CE
extends to new industries and device categories, there is
tremendous potential for embedded developers to easily
add new device types and peripherals. This is made
possible through the simple and well-defined Windows CE
Device Driver model, which provides a well-documented
set of device driver interfaces (DDIs) and sample code that
demonstrates implementation. This model enables
embedded developers (both OEMs and IHVs) to easily
implement their own driver software for a variety of
devices that run on the Microsoft Windows CE platform.
Wide microprocessor support – Currently supported
processor architectures include: NEC, Philips, Toshiba
MIPS 39xx and 4xxx, Motorola PowerPC 821, 823, 850,
860, Hitachi SH3 and SH4, Intel 486 and Pentium (and
compatibles: AMD, Cyrix, SGS Thomson), ARM, and Intel
X-Scale. The wide choice enables OEMs to select
architecture with the best price/performance for their
specific application. New processors are being added
regularly. For the complete list of supported processors,
including specific model numbers, visit the Microsoft
Windows CE website.
TECHNICAL OVERVIEW
OEM Adaptation Layer (OAL)
Windows CE is adapted for a specific hardware platform
by creating a thin layer of code that resides between the
kernel and the hardware platform. This layer is known as
the OEM Adaptation Layer (OAL). The OAL isolates
device-specific hardware features from the kernel. The
Windows CE kernel, in turn, contains processor-specific
code to handle processor core functions. The OAL is
specific for a particular CPU and hardware platform.
The primary purpose of the OAL is to expose the target
platform's hardware to the kernel. This includes managing
the hardware's timers and device interrupts, and
implementing power management across the device's
peripherals. Windows CE handles interrupts by
associating each hardware interrupt request line (IRQ)
with one interrupt service routine (ISR). When interrupts
are enabled and an interrupt occurs, the kernel calls the
registered ISR for that interrupt. The ISR, the kernel-
mode-portion of interrupt processing, is kept as short as
possible. Its responsibility is primarily to direct the kernel
to schedule and launch the appropriate interrupt service
thread (IST). The IST, implemented in the device driver
software module, gets or sends data and control codes
from or to the hardware and acknowledges the device
interrupt.
Device Drivers
§ Built-in support for the keyboard, touch panel,
notification LED, display, audio (including
Sound Blaster™), battery drivers, and a rapid
development model that allows these devices to
be ported quickly to your platform.
§ Support for wireless and wireline Ethernet LAN
connectivity
§ Statically replaceable keyboard layout
§ Extended interrupt processing interface or
device drivers based on the Win32 event model
§ Network printing
§ Support for serial and parallel devices
§ Host support for Universal Serial Bus (USB)
devices
§ PCMCIA Card and Socket Services for
removable or built-in storage cards
Kernel
§ Multi-threaded; preemptive multitasking
§ Preemptive priority-based thread scheduling
based on the Win32 process and thread model;
supports eight levels of thread priority
§ Support for priority inheritance to correct
priority inversion
§ Demand paging supported by ROM, RAM, and
FAT file systems
§ Execute in place from ROM
§ Support for synchronization objects
(WaitForSingleObject, WaitForMultipleObjects)
§ Low ISR and threat latency
§ Portable across microprocessors
§ Heap size that is limited only by available
memory
Object Store
§ Available object stores include file systems,
registry, and database
§ Database provides storage and retrieval of
database records, with up to four sort keys and
support for transaction logging and rollback
§ File System
§ Access is through Win32 API
§ Supports FATFS, including multiple FAT
volumes (up to 99 volumes)
§ Installable block Device Drivers (ATA Flash and
SRAM drivers included)
§ True Flash File System support
§ Installable file systems
§ Databases on mounted file systems
Registry
§ Win32-like registry
§ Access is through Win32 Registry API
GDI and USER
§ Configurable from nothing to full-blown GDI &
User, with intermediate points:
§ display-less, message passing
(mininput)
§ graphics but no windowing (mingdi)
§ minimalist window manager
(minwmgr)
§ GDI - resolution-independent graphics
§ Raster and TrueType Font support o1 to 32 BPP
Color Pixel depths w/ palettes
§ Printing (device-side rendering)
§ User - windowing, dialogs, messaging
§ Additional: Controls, clipboard, cursors, caret,
idle time out, hot keys, etc.
§ GDI and user export a subset of the Win32 API
Communications Support
§ Windows Sockets APIs
§ WinInet with FTP, HTTP and HTTPS support
§ Secure Sockets Layer (SSL) with Server Gated
Cryptography support
§ TCP/IP, PPP, SLIP, and IrDA, including Fast IR
§ TAPI modem support
§ Serial APIs
§ Direct connection, dial-up and device-to-device
connectivity
§ LAN connectivity using NDIS and Microsoft
Network client software (to access remote file
and print servers)
§ Remote access services (RAS) to support remove
connectivity
§ Remote debugging over LAN, serial or parallel
connections
§ Built-in support for communication hardware
(built-in modems, Ethernet chips, etc.)
§ Windows NT® LAN Manager-based
authentication
Remote Connectivity
§ Remote networking
§ Direct connection to PC
§ Dial-up access to Internet, PCs, and Servers
Shell
 § Includes a minimum shell that supports
application launching and switching
§ The shell can be included to serve as the basis of
an embedded application
§ Key UI components included to allow rapid
development of custom embedded shells
Internationalization/Localization
§ Support for localization of the operating system,
including built-in support for French, German,
Italian, Portuguese (Brazilian), Spanish, Dutch,
Swedish, Japanese and Chinese (Beta)
§ Far East text support
§ Input Method Manager, Input Method Editor,
and Soft Input Panel
§ UNICODE support
§ Support for the national language support (NLS)
API, which allows system and user locales
Additional Component Features
§ ActiveX® and COM/OLE
§ Microsoft Virtual Machine for Java for Windows
CE
§ Microsoft Foundation Classes for Windows CE
Tied for second place are the Microsoft twins, Windows XP
for Embedded and Windows CE (there were separated by
one vote). In a predictable reversal, WinXP and WinCE
were most popular where VxWorks was weakest:
industrial and computer-related applications. XPe was
especially strong in manufacturing industries, where
VxWorks also made a good showing.
In the number four spot we have Texas Instruments'
DSP/BIOS, a product with obvious hardware ties. That's
followed by Red Hat's Linux, the first of the many Linux
variants to make the list.
After that, the numbers all drop to below 8%. QNX, RTX,
C/OS, and Mentor Graphics' Nucleus RTOS head the list of
WINDOWS CE - Based HARDWARE
REQUIREMENTS
At a minimum, a Windows CE-based device must have a
supported processor, memory and an internal timer for
scheduling. No other hardware is specifically referenced by
the operating system, but most devices will have a number
of peripherals.
Windows CE is a small-footprint, flexible operating
system. The memory needed by a Windows CE-based
system is totally dependent on which components the
designer of the system selects. A Typical CE build may
require 32 Meg of Flash and 32 Meg of RAM.
7. Commercial RTOS brands
Among commercial embedded operating systems, Wind
River's VxWorks was the undisputed leader, as shown in
Figure 6. With more than 25% of all the votes, it scored
particularly well in avionics applications (where it ranked
well above average) but somewhat poorer in automotive,
computer-related, and industrial segments (where it
scored well below average). Its popularity was insensitive
to age but was strongly correlated to company size, with
larger development firms using VxWorks much more
frequently than small companies.
several popular embedded OSes with single-digit market
shares. ThreadX is deliberately listed twice: once for the
Green Hills distribution and once for Express Logic's
product. Oddly, Green Hills appears to sell more copies of
ThreadX than the company that developed it.
Looking ahead, we asked those same survey takers what
OS they'd consider using in their next project. Would they
stay with their current OS or switch to another? We also
asked non-OS users the same question to see if they were
considering a commercial OS for the first time. The results
are summarized in Figure 7.
The chart shows the delta between the "would consider"
responses and the "using now" responses from the
previous graph. In brief, the winners lose and the losers
win. How is that possible and what does it all mean?
First, the responses don't necessarily mean that VxWorks
users are unhappy with their current RTOS and are ready
to jump to (for example) LynxOS or Wind
River's Platform NE Linux. We can't correlate the
responses from the first question to the second; the person
who said he's using VxWorks now may not be the same
person who said he'd consider EPOC in the future. What
we can say with certainty is that about 8% fewer people
said they'd consider VxWorks compared with the number
using it now. Whether or not those are the same people is
impossible to tell.
Microsoft's two embedded OSes didn't fare well, either. In
fact, the eight top choices all lost ground in the game of
"guess tomorrow's operating system."
Reflecting a kind of Zen balance, almost all of the middle About two-thirds of the OS defections are what we might
and low scorers gained share of mind in roughly equal call voluntary changes. Twenty-seven percent said they'd
proportion to the share lost by the big players. Whether switched operating systems because the new one "had
accidentally or by design, the numbers reflect a zero-sum better features," with 21% opting for "a better roadmap for
game. This gives us a hint as to the true nature of the data. growth" and 20% jumping ship for "better development
Recall that more than 28% of embedded projects use no tools." Another 15% said they bailed because the new OS
OS at all, and that this proportion has been shrinking was cheaper. Very few (8%) said their old OS was no
steadily for years. Those developers have to go somewhere; longer available and even fewer (6%) switched because
what OS will they choose as their first? Logically they're they were unhappy with their previous OS supplier. Fewer
going to choose a smaller, more inexpensive OS over a than 5% switched because the old system was too slow.
large and fully featured one. If you're upgrading your The overall picture is therefore good for commercial OS
system from no OS at all it makes sense to start small. suppliers. As the number and type of embedded systems
Thus, we see that the smaller RTOS vendors gain share of increase, so will the total available market. As in-house
mind among potential next-generation projects. and proprietary OS’s slowly ride into the sunset,
Will the current commercial vendors lose some development teams will be filling the gap mostly with
customers? Sure, just as every supplier occasionally loses commercial alternatives. And although open-source
customers to a competitor. But they'll probably gain even operating systems are well and truly established, with one-
more new customers. Nothing sinister lurks in the data fifth of developers using one now, their growth seems to
here; nothing to trouble the sleep of the friendly have flattened. Only about 17% of embedded systems
neighbourhood RTOS marketing staff. OS loyalty is fairly developers would consider Linux who aren't already using
low anyway. As the chart in Figure 8 shows, more than it. What's certain is that the variety of embedded systems—
one-third (36%) of developers are using a different OS and the operating systems that serve them—will continue
than they did in their previous project. Usually that's just to flourish.
because of a change in hardware (44%) or, more
ominously, that the new OS was not the developers' choice
and was forced upon them.

Conclusion:
Embedded Systems will play a key role to drive the
technological evolution in the next decades. In this respect
they stand on the same level as Nano technologies,
bioelectronics, and photonics. The central role of
embedded systems in the economy grows stronger and
stronger. The starting point is the convergence between
storage, security, video, audio, mobility and connectivity.
Systems are converging and ICs are more and more
converging with systems. This poses a number of
challenges for designers and technologists. A key issue is
the definition of the right methodologies to translate
system knowledge and competences into complex
embedded systems, taking into account many system
requirements and constraints. The key factor to win this
challenge is to build the right culture. This means to be
able to build the right environment to exploit existing
design, architectural and technological solutions, and to
favour the transfer of knowledge from one application field
into another.

Reference:

Requirements Engineering for Embedded Systems1) Manfred Broy Technische Universität München, Institut für
Informatik

Capturing Requirements for Real-Time and Embedded Systems- Bruce Powel Douglass, Chief Evangelist, I-Logix

Razouk, It., Stewart, T. & Wilson, M. (1986) Measuring Operating System Performance on Modern Micro-Processors,
In: Perfor-mance 86, ACM, NY, pp. 193-202.

DESIGN CONSTRAINTS ON EMBEDDED REAL TIME CONTROL SYSTEMS

Philip J. Koopman Jr. Senior Scientist Harris Semiconductor 2525A Wexford Run Rd. Wexford, PA 15090

VHDL vs. Bluespec System Verilog: A Case Study on a Java Embedded Architecture
Flavius Gruian, Lund University, Sweden
Mark Westmijze, University of Twente, The Netherlands

The Minimization of Hardware Size in Reconfigurable Embedded Platforms

Nei-Chiung Perng, Genesys Logic, Taiwan
Jian-Jia Chen, Swiss Federal Institute of Technology, Switzerland
Tei-Wei Kuo, National Taiwan University, Taiwan
Chi-Sheng Shih, National Taiwan University, Taiwan

Embedded Systems Handbook, ed. R. Zurawski, CRC

Press/Taylor & Francis, 2005.

Proceedings of the IEEE, Special Issue on Industrial

Communication Systems, guest editor R. Zurawski, vol. 93,
no.6, June 2005.

The Ubiquitious Embedded System-SCMS School of Technology and Management

http://wiki.answers.com/Q/What_is_the_difference_between_RTOS_and_OS#ixzz1HLKhzdCP

http://wiki.answers.com/Q/Advantages_disadvantages_of_embedded_operating_system#ixzz1HLkFchT6

http://www.control.com/thread/1026205354

Difference Between RTOS and OS | Difference Between | RTOS vs OS

http://www.differencebetween.net/technology/difference-between-rtos-and-os/#ixzz1HLm3zaC5

http://belhob.wordpress.com/2007/10/12/rtos-vs-general-purpose-os/

http://www.emdebian.org/about/why.html

http://www.microsoft.com/windowsembedded/en-us/develop/windows-embedded-products-for-developers.aspx

http://www.answers.com/topic/embedded-system

http://www.netrino.com/Embedded-Systems/Glossary

http://embedsoftdev.com/

http://www.microcontroller.com/

http://www.flexerasoftware.com/promolanding/embedded-software-
licensing.htm?gclid=CJf6wuz24qcCFUdP4QodFngV-A

http://www.ni.com/academic/embedded.htm

http://www.esacademy.com/
Assessment of Technical Report

Student’s name Mark overall

Dinuka Wijesinghe

Criterion Weight

Demonstration of knowledge
25
and understanding

Critical evaluation 30

Breadth and appropriateness of

references (properly 30
referenced) and bibliography

Presentation (in terms of

structure) Grammar and 15
Spelling

TOTAL

Comments.