Embedded operating systems

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

• Embedded Systems are designed to do some
specific task, rather than be a general-purpose
There are endless uses for embedded systems in consumer computer for multiple tasks. Some also have
real-time performance constraints that must be
products, with new methods of exploiting them presented
met, for reason such as safety and usability;
every year at such industry events as the MEDC and the others may have low or no performance
Embedded Systems Conference. The most obvious requirements, allowing the system hardware to
beneficiaries are those enterprises concerned with the be simplified to reduce costs.
manufacture and sale of electrical devices, as the inclusion
of microcontrollers to replace general purpose • Embedded Systems are not always separate
microprocessors can drive down unit manufacturing costs devices. Most often they are physically built-in
to the devices they control.
and end user prices dramatically, resulting in increased
sales and an improved profit margin.
• The software written for embedded systems is
The use of embedded systems in electrical products can often called firmware, and is stored in read-only
also solve many problems of complexity and product size. memory or Flash memory chips rather than a
For example, a modern automobile may contain dozens of disk drive. It often runs with limited computer
embedded systems to control a wide range of processes hardware resources: small or no keyboard,
within the car, ranging from brake balance control to air screen, and little memory.
conditioning to the ignition system. Without embedded
• Must be dependable. Reliability R (t) =
systems it would be impossible to computerise all of these
Probability of system working correctly provided
features without the inclusion of a mass of complicated, that it was working at t=O. Making the system
fault prone electronics. dependable must not be an afterthought, it must
be considered from the very beginning
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 • Maintainability M (d) = Probability of system
currently managed by microcontrollers. working correctly d time units after error
occurred
Examples:
• Availability A (t): Probability of system working
• Audio like mp3 players and telephone switches at time t.
for interactive voice response systems
• Avionics, such as inertial guidance systems,
flight control hardware/software and other • Safety: No harm to be caused.
integrated systems in aircraft and missiles
• Cellular telephones and telephone switches • Security: Confidential and authentic
communication. Even perfectly designed
• Electric or Electronic Motor controller for systems can fail if the assumptions about the
Brushless DC motors, Induction motors and DC workload and possible errors turn out to be
Motors wrong.
• Engine controllers and antilock brake
controllers for automobiles
• Home automation products, such as • Must be efficient
thermostats, air conditioners, sprinklers, and Energy efficient
Code-size efficient (especially for systems on a
security monitoring systems
chip)
• Handheld calculators Run-time efficient
• Household appliances, including microwave Weight efficient
ovens, washing machines, television sets, DVD Cost efficient
players and recorders
• Dedicated towards a certain application.
• Medical equipment
Knowledge about behaviour at design time can
• Personal digital assistant be used to minimize resources and to maximize
• Videogame consoles robustness.
• Computer peripherals such as routers and
printers • Dedicated user interface. (No mouse, keyboard
• Industrial controllers for remote machine and screen)
operation
• Many Embedded System must meet real-time
• Digital musical instruments (digital synthesizers constraints
and digital pianos).
• Security applications such as DVR and video • Frequently connected to physical environment
server through sensors and actuators, Dortmund
• The worldwide portable flash player market
exploded in 2003 and is expected to grow from
Growing importance of embedded systems 12.5 rnillion units in 2003 to over 50 rnillion
units in 2008
• Worldwide mobile phone sales surpassed 156.4 • Global 3G subscribers will grow from an
rnillion units In Q2 2004, a 35% increase from estimated 45 rnillion at the end of 2004 to 85
Q2 2003, 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 Need for:
•Increased reliability
Availability (from Wikipedia): The degree to which a •Robustness
•Re-configurability
system, subsystem, or equipment is operable and in a
•Maintainability
committable state at the start of a mission, when the •Scalability
mission is called for at an unknown, i.e., a random, time.
Simply put, availability is the proportion of time a system Within the exception of these few common features, rest of
is in a functioning condition. the embedded hardware is usually unique and varies from
application to application. Each system must meet a
Reliability: The IEEE defines it as ". . . the ability of a completely different set of requirements. The common
system or component to perform its required functions critical features and design requirements of an embedded
under stated conditions for a specified period of time." In hardware include:
general, in automation, availability and reliability are
• Processing power: Selection of the processor is
required to be very high, to minimize the cost of operation based on the amount of processing power to get
(for instance to minimize scheduled and unplanned the job done and also on the basis of register
maintenance) width required.
• Throughput: The system may need to handle a
• Safety lot of data in a short period of time.
• Response: the system has to react to events
Safety: Absence of catastrophic consequences of a system quickly
failure for property, humans, and environment • Memory: Hardware designer must make his best
estimate of the memory requirement and must
make provision for expansion.
The (embedded) automation systems and plants have to be • Power consumption: Systems generally work on
safe operational over extended periods of time, even if they battery and design of both software and
continue operation in a degraded mode in the presence of hardware must take care of power saving
a fault. techniques.
• Number of units: the no. of units expected to be
• Survivability produced and sold will dictate the Trade-off
between production cost and development cost
• Expected lifetime: Design decisions like
Survivability: Need for restricted modes of operation that
selection of components to system development
preserve essential services in adverse operational cost will depend on how long the system is
environments expected to run.
• Program Installation: Installation of the
• Security software on to the embedded system needs
special tools.
Operational IT security requirements: • Testability & Debug ability: setting up test
Confidentiality: Protecting data from unauthorized conditions and equipment will be difficult and
finding out what is wrong with the software will
entities
become a difficult task without a keyboard and
Integrity: Protecting against unauthorized data the usual display screen.
manipulation • Reliability: is critical if it is a space shuttle or a
Availability: Data available when needed car but in case of a toy it doesn’t always have to
work right.
• 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 4. System Limitations
under control.
Most embedded systems place severe constraints on the
A response, in general, may be: processor in the terms of requirements for size, weight,
power, cooling, performance, reliability, and cost.
•Periodic - to control a specific physical quantity by This is because the processor is just a component of a
regulating dedicated end-effectors larger system, which has its own operating requirements
and manufacturing constraints.
•Aperiodic - arising from unscheduled events such as out-
of-bounds state of a physical parameter or any other kind Size and Weight
of abnormal conditions.
Size and weight restrictions can greatly limit the
complexity of the hardware which can be brought to bear
• Power consumption on solving a particular embedded control problem.
Platforms such as aircraft, spacecraft, and portable
Low-power design: extending life time of electronic equipment may have strict weight limitations. Most other
components (lifecycle). Wireless sensor networks need for applications also have size limitations of some sort. A
self-sustained energy source. typical embedded controller may have a size budget of a few
cubic inches, and a weight budget of a few pounds (including
Sources of wireless power: the power supply requirements).
•Batteries, fuel cells, etc. The problem with size and weight restrictions is that
•From local environment: light, heat, vibration, high performance processing systems tend to be larger and
•Transmitted by optical and radio frequencies, sound heavier than slower systems. At the CPU level, a processor
that has a large number of pins takes up a large printed
• Lifetime issues 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.
Typical lifetime of a device in an industrial environment is
The key to the size and weight issue is keeping
around 10 - 20 (plus) years
component count small. This is best accomplished by using

the highest integration level possible. But, even with Embedded processing applications are notorious for
custom VLSI chips and surface- mount technology the extreme operating conditions, especially in automotive
fact remains that in embedded system, high complexity and military equipment. The processing system must deal
means problems with size and weight budgets. The with vibration, shock, extreme heat and cold, and perhaps
smallest systems are those which have on-chip memory for radiation. In remotely installed applications, such as
some or all of the system requirements, do not require spacecraft and undersea applications, the system must be
external support chips (especially cache memory support), able to survive without field service technicians to
and which allow small, efficient encodings of programs. make repairs.

The general techniques used for avoiding problems caused
Power and Cooling by operating environments are to keep the component
count and number of pins as low as possible. It is also
The processor complexity can affect the power helpful to keep the systems cool as possible to inhibit aging
consumption of the system. High power consumption of the system's components.
increases the size and weight requirements of the power
supply. Since essentially all power consumed by a Cost
computer is eventually given off as heat, increased power
consumption results in increased cooling requirements. The cost of the processor itself may be very important to
The amount of power used by the processor is related low- and medium-performance systems, especially
to the number of transistors and pins on the processor consumer electronics products. Since the cost of a chip is
chip. Processors that rely on exotic process technology for related to the number of transistors and to the number of
speed usually consume too much power to be useful. pins on the chip, low complexity processors have an
Processors that need huge numbers of power consuming inherent cost advantage.
high speed memory devices likewise can exceed a power In high-performance systems, the cost of the processor
budget. may be overwhelmed by the cost of the multi-layered
Consequently, CMOS components are usually used printed circuit boards, support chips, and high-
whenever possible. Newer CMOS technology runs at high speed memory chips. In these cases, overall system
speed, yet dissipates little power in comparison to other complexity must be reduced to keep system costs down.
technologies. Static CMOS is often selected because it can
operate with a slow or stopped clock to save power when the
system is idle.
Architectural Features
Computing Performance Many of the computer architect's techniques to improve
system performance, such as cache, branch target
Computing performance in a real time embedded control buffers, and pre-fetch queues, work on statistical
environment is not simply an instructions per-second principles. They assume things such as temporal and
rating. While raw computational performance is spatial locality, which tend to be true on large workstation
important, other factors which are vital to system programs when run for long periods of time. They give
performance include interrupt response characteristics, relatively uniform performance when used in a CAD or
context switching overhead and I/O performances. Since office automation environment.
real time tasks are characterized by frequent, often However, the constraints of hard real time control
unpredictable events, the performance of a processor at applications have requirements which make standard,
handling interrupts is crucial to its suitability for real time statistically good speedup techniques inappropriate. Real
processing. Since a control application usually involves a time control of periodic events requires absolute
reasonable amount of communication with the outside predictability, often down to a single clock cycle. Deadlines
world (such as reading sensors and activating control must be guaranteed to be met 100% of the time. Having a
circuits), good IJO performance is also important. situation where an unfortunate interaction between
Two key considerations for more difficult real time two different routines contending for cache
control applications are predictability and determinacy. memory causes an increase in cache misses is simply
Predictable systems have behavior at run-time that is unacceptable. In a tightly scheduled environment, even the
easily understandable from examination of the original time taken by a single cache miss can cause a missed
source code program; deadline.

In other words, there are no surprises to a user of average Inappropriate Architectural Features
sophistication. Deterministic systems hove instructions
whose behavior does not vary; in other words, the There are many reasons that an architectural feature is
execution speed of an instruction does not depend on included in a processor. Today, usually the feature is
execution history of the program. For real time control added in order to support "general purpose" computing,
with hard deadlines, a designer must be able to predict which usually means engineeri n g w o r k s t a t i o n
with absolute certainty the running time of the piece of 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
code responding to an external event. If a system has requirements for the systems we have just described. The
variable performance elements, such as cache memory, the list of architectural features that are inappropriate
designer must be extremely pessimistic about the for hard real time embedded control systems seems
performance of these features, and plan on the worst case. similar to a catalogue of modern processor design
techniques. They are listed here along with a brief
In some systems, it is important to exactly determine the explanation of the problems they can cause. The focus here
time for a sequence of instructions to execute, with no is on determinism and predictability, although the reader
possibility for variation allowed. Processors with should not forget that most of these features also
contribute substantially to system complexity as well.
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- Cache memory: Data and instruction cache m e m o r i e s
quencers with programmed transfers using carefully timed 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
code. indeterminacy. Modern compiler technology is just
beginning to address the issue of scheduling
Since program memory space may be extremely limited, instruction cache misses. Furthermore, it is
programs may be highly compacted by using subroutine impossible to characterize data cache misses for programs
calls to reuse common code sequences. In fact, many of interesting complexity. Because the time required to
embedded applications use threaded languages such as process a cache miss is approximately an order of
Forth because they produce exceedingly compact code. magnitude slower than the time required for a cache hit,
This suggests that an embedded processor should have significant execution speed degradation takes place
efficient support for subroutine calls as a means of with even a small percentage of cache misses. Figure 1
conserving program memory. shows relative execution time variations that may take

place with varying numbers of cache misses. In this memory in turn either requires the use of cache memory
five-instruction example, assuming that a cache or a significant expense in making all program memory
miss costs five clock cycles, execution time may vary out of cache-grade memory chips for high guaranteed
between 5 and 25 clock cycles for the same code. In hard system performance.
real-time systems, often the worst case of all cache misses
must be assumed for time-critical sections, resulting Variable length execution times of instructions: Many
in designing hardware with only fast static memory instructions can take a variable number of clock cycles to
chips that render the cache management hardware super- execute, often depending on the data input to the
fluous. On-chip caches add to system debugging concerns instruction. An example of such an instruction is a
because they are often not visible outside the chip. multiply routine that has an "early-out" feature.

Low semantic content of instructions: Low semantic
content of instructions greatly increases the number of Write buffers: Write buffers allow the CPU to perform a
instructions that must be executed to accomplish a given write to memory without pausing for an actual memory
task. This, in turn, increases demands for high-speed cycle to take place. The problem is that this write must then
memory. A requirement for large amounts of high speed wait for spare bus cycles.

If no spare bus cycles are forthcoming, the processor number of wait states or cache misses in program
must be stalled when the write buffer overflows. memory. For example, if there is latency for filling an
Additional stalls can be caused if a memory read could empty pre-fetch queue, adding a one- cycle wait state
possibly correspond to a memory location that has yet that causes the pre-fetch queue to be emptied may add
to be updated by the write buffer. Interaction between more than one clock cycle to program execution time.
the write buffer and cache misses for instruction and
data fetches can cause indeterminacy in program
execution. Pipelines: Deep instruction pipeline increases interrupt
response latency. Even if the first instruction of an
Branch target buffers: This is a special case of an interrupt service routine can be inserted into the
instruction cache, in which past program execution pipeline within one clock of the interrupt being asserted, it
history is used to cache instructions at branch targets for still takes several clock cycles for the instruction to
quick access. This type of instruction cache operates pass through the pipeline and actually do its job. A
in a manner dependent on input data, and so is pipeline also requires some sort of handling of
beyond the ability of compilers to manage effectively. data dependencies and delays for memory access, which
Branch target buffers are sometimes used in results either in compiler-generated flops, instruction
conjunction with branch prediction strategies, in which rearrangement, or hardware-generated pipeline
the compiler encodes a guess as to whether a stalls. All of these dependency-resolution techniques
particular branch is likely to be taken into the decrease predictability, determinacy, or both.
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 Pure load/store architectures: Load/store RISC
to perform a branch then depends on whether the architectures can by their very nature makes no
compiler guessed the branch outcome correctly, and provision for atomic read/modify/write instructions. This
whether the branch target buffer value corresponds to generally required the addition of external hardware
the guess made by the compiler. for implementing semaphores, locks, and other
inter-process communication devices, increasing
Pre-fetch queues: Pre-fetch queues greatly affect the system complexity.
predictability of execution because the execution time
for an instruction depends on whether or not the Scoreboards: Scoreboards attempt to speed up program
preceding instructions were slow enough to allow the execution by allowing several instructions to be in
pre-fetch queue to accumulate new instructions. Thus, execution concurrently. Score boarding usually implies
determining whether a particular instruction will out-of-order execution, which may make it impossible to
execute quickly from the pre-fetch queue or slowly from correctly determine the correct system state in the event of
program memory requires cycle counting of several an exception or interrupt (the term usually used here
preceding instructions to see if spare memory cycles would is that the system has imprecise interrupts).
have been available for the pre-fetch queue to fill. This Furthermore, the execution time of an instruction
cycle counting is subtly affected by data-dependent depends on the resources being used by the previous
execution paths through the program as well as the several instructions, and can vary considerably.

Supers cater instruction issue: Newer-generation implies the use of a cache memory to perform
microprocessors are beginning to implement address translation (a Translation Look aside Buffer),
"superscalar" instruction execution, in which multiple which has the same problems as other caches. If a
instructions may be issued in a single clock cycle. disk-paging system is used, the problem of speed
Unfortunately, the number of instructions that may be degradation can become much worse than for simple
issued depends on the types of the instructions, the cache misses.
available hardware resources, and the execution
history of the program. All these factors make it Use of DRAM access technology: Some processor
very difficult to determine any single instruction's implementations exploit special access techniques to
execution time. 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
Dependence on sophisticated compiler technology: Most problems in predictability because access to these
RISC designs depend implicitly on complex and DRAMs becomes much slower whenever page boundaries
ambitious optimizing compilers for fast op erating must be crossed. The use of DRAM memory chips also
speeds. This t radeoff between hardware and requires performing memory refresh, which can
software complexity is a part of the RISC design interact with other accesses to cause performance
philosophy. The problem is that the optimizing compilers degradations that are worse than expected.
make it difficult to establish a correspondence between
source code and the code that actually is executed Autonomous I/O processors: The use of
because of the large number of program transformations autonomous I/O processors and DMA hardware that
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 , steal bus cycles can cause non-determinism as the
a s w el l a s decouples the programmer's source code processor is stalled for bus accesses. Consequently, it is
changes f ro m eff ect s on f in a l p ro g ra m sometimes desirable to perform I/O directly from the
p erf o rm a n ce, decreasing predictability. A surprising CPU.
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 The Challenge to Processor Designers
block-level and global optimization techniques can
actually cause the same exact sequence of source code The above list of architectural characteristics contains
statements to generate significantly different object code elements of design found in virtually every RISC or
in two places of the same program module (Razouk CISC processor made today. These architectural
etal. 1986). characteristics are truly valuable for speeding up average
system performance, especially in workstation
Large register file: The use of a large number of environments. The problem is that hard embedded
registers allows programs to execute quickly, hut real time control applications do not have the same
greatly increases the amount of information (the characteristics and requirements as workstation-based
machine state) that must be saved on context switches and engineering design applications, and so these
interrupts. This adversely affects responsiveness to characteristics actually hurt s ystem p erformance.
external events. 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
Virtual memory: The use of virtual memory 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
5. Embedded OS vs. General behaviour was simply not a design goal for these general-
computing operating systems.
Purpose OS
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
The key difference between general-computing operating
systems and real-time operating systems is the need for timing: In other words, the algebraic formula is as simple
“deterministic " timing behaviour in the real-time as: T(message send) = constant , irrespective of the length
operating systems. Formally, "deterministic" timing means of the message to be sent, or other factors such as the
that operating system services consume only known and numbers of tasks and queues and messages being
expected amounts of time. In theory, these service times managed by the RTOS.
could be expressed as mathematical formulas. These
Many RTOS proponents argue that a real-time operating
formulas must be strictly algebraic and not include any
system must not use virtual memory concepts, because
random timing components. Random elements in service
paging mechanics prevent a deterministic response. While
times could cause random delays in application software
this is a frequently supported argument, it should be noted
and could then make the application randomly miss real-
that the term "real-time operating system" and
time deadlines – a scenario clearly unacceptable for a real-
determinism in this context covers a very wide meaning,
time embedded system. Many non-real-time operating
and vendors of many different operating systems apply
systems also provide similar kernel services.
these terms with varied meaning. When selecting an
operating system for a specific task, the real-time attribute
General-computing non-real-time operating systems are
alone is an insufficient criterion, therefore. Deterministic
often quite non-deterministic. Their services can inject
random delays into application software and thus cause behaviour and deterministic latencies have value only if
slow responsiveness of an application at unexpected times. the response lies within the boundaries of the physics of
If you ask the developer of a non-real-time operating the process that is to be controlled. For example,
system for the algebraic formula describing the timing controlling a combustion engine in a racing car has
behaviour of one of its services (such as sending a message different real-time requirements to the problem of filling a
1,000,000 litre water tank through a 2" pipe.
from task to task), you will invariably not get an algebraic

Real-time operating systems are often uses in embedded While real-time operating systems are typically designed
solutions, that is, computing platforms that are within for and used with embedded systems, the two aspects are
another device. Examples for embedded systems include essentially distinct, and have different requirements. A
combustion engine controllers or washing machine real-time operating system for embedded system
controllers and many others. Desktop PC and other addresses both sets of requirements.
general-purpose computers are not embedded systems.

The most common operating system for process a huge number of instructions within a given time
personal computer include Windows from Microsoft, OS X span. Examples of which are computer that scan levels and
from Apple, and the wide variety of Linux variants that can states in a facility. It is important that the monitors see
be obtained from their respective developers. What most changes occur at the instant that they do.
people do not know are Real-time Operating Systems or
generally referred to by the acronym RTOS. These are Most operating systems use a time sharing architecture
operating systems that are used for more specialized where each task is assigned a small slice of time to execute
applications that demand response that is as close to real its instructions before switching to another task. The
time as possible. The most significant difference between switching process is too fast that it often appears as real
the two is in how they approach each task. Standard time to users. Some RTOS’s also use this design but with
operating systems focus on doing as much computation in much lower density of tasks to ensure that the processor
the shortest span of time while RTOS’s emphasize on never gets to loaded, which can increase the response time.
having a predictable response time. Another design that is used for an RTOS is an event-driven
architecture. In this design, the system only switches tasks
Standard operating systems are widely used nowadays, once an event or interrupt occurs.
partly due to the rapid spread of personal computers.
Devices that use standard operating systems, aside from Coding practices for an RTOS is much stricter compared to
computers and laptops, are also beginning to appear. a standard OS as the code needs to perform consistently all
RTOS’s are used in more specialized fields where the the time. Standard OS’s are not that concerned since
response time is much more important than the ability to response time is not of great importance in its application.
An RTOS is not required for an embedded system but it A well-architected RTOS will handle these functions much
can offer powerful advantages to the system developer. more efficiently that a programmer could write the code.
Without an RTOS the developer must write his own code RTOS developers are expert in how to handle operations
with a minimum of processor cycles.
to handle all of these functions.
There are many questions when adapting a GPOS (General
Purpose Operating System) RTOS:
• Enables real-time, deterministic scheduling and task
prioritization
• What does an RTOS have that a GPOS does not?
• Abstracts away the complexities of the processor • How useful are the real-time extensions now
• Provides a solid infrastructure constructed of rules available for some GPOSs?
and policies • Can such extensions provide a reasonable
• Simplifies development and improves developer facsimile of RTOS performance?
productivity
• Integrates and manages resources needed by Task scheduling
communications stacks and middleware
Let’s begin with task scheduling. In a GPOS, the scheduler
• Optimizes use of system resources typically uses a fairness policy to dispatch threads and
• Improves product reliability, maintainability and processes onto the CPU. Such a policy enables the high
quality overall throughput required by desktop and server
• Promotes product evolution and scaling 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 Avoiding priority inversion
priority assigned to a high-priority thread, or otherwise
dynamically adjust the priority in the interest of fairness to Even in an RTOS, a lower-priority thread can
other threads in the system. A high-priority thread can, as inadvertently prevent a higher priority thread from
a consequence, be pre-empted by threads of lower priority. accessing the CPU – a condition known as priority
In addition, most GPOSs have unbounded dispatch inversion. Generally speaking, priority inversion occurs
latencies: the more threads in the system, the longer it when two tasks of differing priority share a resource, and
takes for the GPOS to schedule a thread for execution. Any the higher priority task cannot obtain the resource from
one of these factors can cause a high-priority thread to the lower-priority task. To prevent this condition from
miss its deadlines – even on a fast CPU. exceeding a fixed and bounded interval of time, an RTOS
In an RTOS, on the other hand, threads execute in order may provide a choice of mechanisms including priority
of their priority. If a high-priority thread becomes ready to inheritance and priority ceiling emulation. We could not
run, it will, within a small and bounded time interval, take possibly do justice to both mechanisms here, so let us
over the CPU from any lower-priority thread that may be focus on a simple example of priority inheritance. To
executing. Moreover, the high-priority thread can run begin, we first must look at the blocking that occurs from
uninterrupted until it has finished what it needs to do – synchronization in systems, and how priority inversion
unless, of course, it is pre-empted by an even higher can occur as a result. Let us say two jobs are running, and
priority thread. This approach, known as priority-based that Job 1 has the higher priority. If Job 1 is ready to
pre-emptive scheduling, allows high-priority threads to execute, but must wait for Job 2 to complete an activity,
meet their deadlines consistently, no matter how many we have blocking. This blocking may occur as a result of
other threads are competing for CPU time. synchronization – waiting for a shared resource controlled
by a lock or a semaphore – or as a result of requesting a
Pre-emptily kernel service.
The blocking allows Job 2 to run until the condition that
For most GPOSs, the OS kernel is not pre-emptily. Job 1 is waiting for occurs (for instance, Job 2 unlocks the
Consequently, a high-priority user thread can never pre- resource that both jobs share). At that point, Job 1 gets to
empty a kernel call, but must instead wait for the entire execute. The total time that Job 1 must wait may vary, with
call to complete – even if the call was invoked by the a minimum, average, and maximum time. This interval is
lowest-priority process in the system. Moreover, all known as the blocking factor. If Job 1 is to meet any of its
priority information is usually lost when a driver or other timeliness constraints, this factor cannot vary according to
system service, usually performed in a kernel call, executes any parameter, such as the number of threads or an input
on behalf of a client thread. Such behaviour causes into the system. In other words, the blocking factor must
unpredictable delays and prevents critical activities from be bounded. Now let us introduce a third job that has a
completing on time. In an RTOS, on the other hand, kernel higher priority than Job 2 but a lower priority than Job 1
operations are pre-emptily. There are still windows of time (Figure 1). If Job 3 becomes ready to run while Job 2 is
in which pre-emption may not occur, but in a well- executing, it will pre-empty Job 2, and Job 2 will not be
designed RTOS, those intervals are extremely brief, often able to run again until Job 3 blocks or completes. This will,
on the order of hundreds of nanoseconds. Moreover, the of course, increase the blocking factor of Job 1; that is, it
RTOS will impose an upper bound on how long pre- will further delay Job 1 from executing. The total delay
emption is held off and interrupts disabled; this allows introduced by the pre-emption is a priority inversion. In
developers to ascertain worst-case latencies. fact, multiple jobs can pre-empt Job 2 in this way,
resulting in an effect known as chain blocking. Under
To achieve this goal, the RTOS kernel must be simple and these circumstances, Job 2 might be pre-empted for an
as elegant as possible. indefinite period of time, yielding an unbounded priority
Only services with a short execution path should be inversion, causing Job 1 to fail to meet any of its timeliness
included in the kernel itself. Any operations that require constraints. This is where priority inheritance comes in. If
significant work we return to our scenario and make Job 2 run at the
(For instance, process loading) must be assigned to priority of Job 1 during the synchronization period, then
external processes or threads. Such an approach helps Job 3 will not be able to pre-empty Job 2, and the resulting
ensure that there is an upper bound on the longest non- priority inversion is avoided (Figure 2).
pre-emptily code path through the kernel. In a few GPOSs,
such as Linux 2.6, some degree of pre-emptibility has been Duelling kernels
added to the kernel. However, the intervals during which
pre-emption may not occur are still much longer than GPOSs – Linux, Windows, and various flavors of UNIX –
those in a typical RTOS; the length of any such pre- typically lack the Mechanisms we have just discussed.
emption interval will depend on the longest critical section Nonetheless, vendors have developed a number of real-
of any modules incorporated into the kernel (for example, time extensions and patches in an attempt to fill the gap.
networking and file systems). Moreover, a pre-empt kernel There is, for example, the dual-kernel approach, in which
does not address other conditions that can impose the GPOS runs as a task on top of a dedicated real-time
unbounded latencies, such as the loss of priority kernel (Figure 3). Any tasks that require deterministic
information that occurs when a client invokes a driver or scheduling run in this kernel, but at a higher priority than
other system service. 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 Modified GPOSs
GPOS – file systems, networking, and so on. In fact, if a
real-time task calls out to the GPOS for any service, it will Rather than use a second kernel, other approaches modify
be subject to the same pre-emption problems that prohibit the GPOS itself, such as by adding high-resolution timers
GPOS processes from behaving deterministically. As a or a modified process scheduler. Such approaches have
result, new drivers and system services must be created merit, since they allow developers to use a standard kernel
specifically for the real-time kernel – even when (albeit with proprietary patches) and programming model.
equivalent services already exist for the GPOS. Moreover, they help address the requirements of reactive,
Also, tasks running in the real-time kernel do not benefit event-driven systems.
from the robust Memory Management Unit (MMU) Unfortunately, such low-latency patches do not address
protected environment that most GPOSs provide for the complexity of most real-time environments, where
regular, non-real-time processes. Instead, they run real-time tasks span larger time intervals and have more
unprotected in kernel space. dependencies on system services and other processes than
Consequently a real-time task that contains a common do tasks in a simple event-driven system. For instance, in
coding error, such as a corrupt C pointer, can easily cause systems where real-time tasks depend on services such as
a fatal kernel fault. To complicate matters, different device drivers or file systems, the problem of priority
implementations of the dual kernel approach use different inversion would have to be addressed. In Linux, for
APIs. In most cases, services written for the GPOS cannot example, the driver and Virtual File System (VFS)
be easily ported to the real-time kernel, and tasks written frameworks would effectively have to be rewritten along
for one vendor’s real-time extensions may not run on with any device drivers and file systems employing them.
another’s real-time extensions. Without such modifications, real-time tasks could

experience unpredictable delays when blocked on a by Linux and UNIX – is an important first step. So is
service. As a further problem, most existing Linux drivers providing well-documented source and customization kits
are not pre-empting. To ensure predictability, that address the specific needs and design challenges of
programmers would also have to insert pre-emption embedded developers. The architecture of the RTOS also
points into every driver in the system. All this points to comes into play. An RTOS based on a microkernel design,
the real difficulty and immense scope of modifying a GPOS for instance, can make the job of OS customization
so it is capable of supporting real-time behaviour. fundamentally easier to achieve. In a microkernel RTOS,
However, this is not a matter of RTOS good, GPOS bad. only a small core of fundamental OS services (such as
GPOSs such as Linux, Windows XP, and UNIX all serve signals, timers, and scheduling) reside in the kernel itself.
their intended purposes extremely well. They only fall All other components (such as drivers, file systems,
short when they are forced into deterministic protocol stacks, and applications) run outside the kernel as
environments they were not designed for, such as those separate, memory protected processes (Figure 4). As a
found in automotive telemetric systems, medical result, developing custom drivers and other application-
instruments, and continuous media applications. specific OS extensions does not require specialized kernel
debuggers or kernel gurus. In fact, as user space programs,
What about an RTOS? such extensions become as easy to develop as regular
applications, since they can be debugged with standard
Still, there are undoubted benefits to using a GPOS, such source level tools and techniques. For instance, if a device
as support for widely used APIs, and in the case of Linux, driver attempts to access memory outside its process
the open source model. With open source, a developer can container, the OS can identify the process responsible,
customize OS components for application-specific indicate the location of the fault, and create a process
demands and save considerable time troubleshooting. The dump file viewable with source-level debugging tools. The
RTOS vendor cannot afford to ignore these benefits. dump file can include all the information the debugger
Extensive support for POSIX APIs – the same APIs used needs to identify the source line that caused the problem,

Along with diagnostic information such as the contents of Consequently, does the RTOS support primitive graphics
data items and a history of function calls. This architecture libraries, or does it provide an embeddable windowing
also provides superior fault isolation. If a driver, protocol system that supports 3D rendering, multi-layer interfaces,
stack, or other system service fails, it can do so without and other advanced graphics? Can you customize the
corrupting other services or the OS kernel. In fact, GUI’s look-and feel? Can the GUI display and input
software watchdogs can continuously monitor for such multiple languages simultaneously? And does the GUI
events and restart the offending service dynamically, support an embeddable web browser? The browser should
without resetting the entire system or involving the user in have a scalable footprint, and be capable of rendering web
any way. Likewise, drivers and other services can be pages on very small screens. It should also support current
stopped, started, or upgraded dynamically, again without a standards such as HTML 4.01, XHTML 1.1, SSL 3.0, and
system shutdown. WML 1.3.

A strategic decision Tool considerations

An RTOS can help make complex applications both On the tools side, does the RTOS vendor offer diagnostic
predictable and reliable. In fact, the predictability made tools for tasks such as trace analysis, memory analysis,
possible by an RTOS adds a form of reliability that cannot application profiling, and code coverage? What of the
be achieved with a GPOS (if a system based on a GPOS development environment? Is it based on an open
does not behave correctly due to incorrect timing platform like Eclipse, which lets you readily plug in third-
behaviour, then we can justifiably say that the system is party tools for modelling, version control, and so on? Or is
unreliable). Still, choosing the right RTOS can itself be a it based on proprietary technology? On one point, there is
complex task. The underlying architecture of an RTOS is no question. The RTOS can play a key role in determining
an important criterion, but so are other factors. Consider how reliable your system will be, how well it will perform,
Internet support. Does the RTOS support an up-to-date and how easily it will support new or enhanced
suite of protocol stacks such as IPv4, IPv6, IPSec, SCTP, functionality. And it can support many of the rich services
and IP filtering with NAT? What about scalability? Does traditionally associated with GPOSs, but implemented in a
the RTOS support a limited number of processes, or does way to address the severe processing and memory
it allow hundreds or even thousands of processes to run restraints of embedded systems.
concurrently? And does it provide support for distributed
or symmetric multiprocessing?

GUI considerations

Graphical User Interfaces (GUIs) are becoming
6. Embedded GPOS Examples
increasingly common in embedded systems, and those
interfaces are becoming increasingly sophisticated.

Windows XP 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
Benefits: Windows® XP Embedded is built on upon the ROM. Windows XP Embedded also provides support for
proven code base of Windows XP, which features a 32-bit DiskOnChip Flash, PCMCIA-ATA, Compact Flash,
computing architecture and a fully protected memory MultiMediaCard, and MemoryStick.
model. Key reliability, security, and performance features
include Device Driver Rollback, a pre-emptive Multi- Enhanced Write Filter Enhanced Write Filter (EWF)
tasking Architecture, and Encrypting File System (EFS) re-routes selected disk I/O to memory or another storage
with Multi-user Support. medium, thus providing the appearance to the operating
system that your read-only storage is writable.
By componentizing Windows® XP Professional, Windows
XP Embedded enables developers to use the latest Internet Explorer 6 Provides the latest Web browsing
technologies the Windows platform has to offer, while at technologies including visual refresh, playback support for
the same time achieving a reduced footprint. Embedded Flash and Shockwave files, and privacy enhancements.
developers can take advantage of all the great features
available in Windows XP such as multimedia capabilities. 802.11 Windows XP Embedded supports 802.11 wireless
Features include Universal Serial Bus (USB) and Internet LAN technologies that provide high bandwidth
Explorer 6.0. connectivity without wires.

Windows XP Embedded also includes embedded-enabling 802.1X 802.1X provides secure access to the network to
features, such as Flexible Boot and Storage Options, and support wireless LANs and Ethernet. It enables
Enhanced Write Filter. Rich networking capabilities and interoperable user identification, centralized
management features provide Windows® XP Embedded authentication, and dynamic key management and can
devices seamless integration with PCs, servers, Web secure both wired and wireless LAN access.
services, and other devices. Comprehensive networking
protocol support includes Infrared Data Association
(IrDA) Support, 802.11 and 802.1x, and Universal Plug Infrared Data Association (IrDA) Support Windows
and Play. 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
Windows® XP Embedded includes a completely devices are in line sight of each other.
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 Embedded-Specific Features Windows XP Embedded
development process enabling developers to rapidly with Service Pack 1 incorporates the latest embedded-
configure, build, and deploy smart designs with rich enabling capabilities, focusing on remote deployment and
applications. maintenance scenarios.

Features: 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
Device Driver Rollback If issues occur when new downloaded from a server. It also enables Windows XP
device drivers are added, a copy of the previously installed Embedded-based devices to operate without requiring
driver is saved, enabling a user to roll back to the original persistent storage, such as a hard drive or Flash RAM.
device.

Device Update Agent Windows XP Embedded with
Universal Serial Bus (USB) Supports a wide array of Service Pack 1 enhances support for in-field servicing with
USB peripherals such as scanners, mice, keyboards, and so Device Update Agent (DUA). DUA is designed to address
on. scenarios where it is necessary to incrementally update or
service a Windows XP Embedded device that has been
Universal Plug and Play (UPnP) Universal Plug and previously deployed to the field.
Play (UPnP) is architecture for pervasive peer-to-peer
network connectivity of devices of all form factors, Footprint Estimator Using Footprint Estimator,
including intelligent appliances and wireless devices. embedded developers can now estimate the footprint size
UPnP is a distributed, open networking architecture that of individual components and their dependencies, as well
leverages TCP/IP and the Web to enable seamless- as macro components, prior to adding them to a
proximity networking in addition to control and data configuration. This enables developers to proactively know
transfer among networked devices in the home, office, and what the impact of a given component will have on the
everywhere in between. image size, thereby avoiding guesswork and saving
development time.
Pre-emptive Multi-tasking Architecture Designed
to allow multiple applications to run simultaneously. System Deployment Image (SDI) Manager: The
Includes enhancements to ensure great system response System Deployment Image (SDI) service enables you to
and stability. quickly deploy run-time images to your Windows XP
Embedded-based devices. The SDI feature enables easier
Encrypting File System (EFS) with Multi-user staging of runtime images on your development
Support Encrypts each file with a randomly generated workstation and preparation of images for fast
key. The encryption and decryption processes are deployment. It also provides an easier method for
transparent to the user. In Windows XP Embedded, EFS transferring the runtime image from the development
can allow multiple authorized users access to an encrypted system to the device.
document.
Multilingual User Interface (MUI) Language
Flexible Boot and Storage Options In addition to Packs Windows XP Embedded with Service Pack 1 has
magnetic disk, boot capability is offered for alternative support for over 20 languages. Windows XP Embedded
nonvolatile (persistent) read/write storage devices such as MUI Language Packs enable you to save time and effort in

localizing your solution for multiple markets by enabling configurations. It is the inclusion or exclusion of
you to develop your customized operating system image components that ultimately determines the feature-set of
only once rather than requiring you to localize each the embedded target. Using the familiar Windows NT user
version from the ground up. By simply adding the desired interface, the tool set guides you through the process of
language pack to your base English configuration, the user profiling, defining, and generating customized software
interface will be localized into your chosen language. system.

Hardware Requirements 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
CPU: Computer with 300 megahertz or higher processor either a traditional user interface (e.g. Windows-based or
clock speed recommended; Pentium II 233 MHz minimum DOS-based PC) or, in many instances, any local user
required (single or dual processor system);* Intel interface whatsoever. Windows NT requires a display
Pentium/Celeron family, or AMD K6/Athlon/Duron driver to interface between the graphics sub-system and
family, or compatible processor recommended. Some the video hardware. All currently available video display
slower CPU's are supported but will cause limitations of drivers assume and rely on the existence of underlying
the build particularly in multimedia applications. video hardware. Windows NT Embedded does not require
this.
RAM: 256 Megabytes (MB) of RAM or higher (256
megabytes recommended) (128 MB minimum supported; Read-Only Boot Support — many embedded devices
but will limit performance and some features) utilize ROM to support stateless operation, lower the unit
cost and improve reliability. Windows NT Embedded
Flash: 200 megabytes or more of available storage space 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.
Video: Super VGA (800 × 600) or higher-resolution
video adapter and monitor
Solid-State Media Support — Due to environmental
factors such as shock or vibration, many embedded
User Interface: Keyboard and Microsoft Mouse or devices use bootable non-volatile storage media with no
compatible pointing device moving parts to increase mean time between failure
(MTBF) ratings and to improve overall device robustness.
Typical requirements for a Full standard NT Embedded supports solid state disks and flash
workstation XPE build: A system with a Pentium III memory.
or better processor 256MB of memory and at least 2GB of
flash for a Full Standard build with SP3 and .Net 3.0 Remote Management — in an embedded system, access to
frameworks. Builds running multimedia will require a the operating system and/or application is often through a
faster processor and more memory, typically at least remote system of some type, since a user interface on the
512MB, to run smoothly. device itself does not exist or is not practical to access.
Windows NT Embedded provides both character-mode
Minimum recommended system for a Full and graphical management solutions using serial, dial-up,
standard workstation XPE build: LX800 500MHz and network connections.
CPU, 512MB of memory 4GB of High-speed DMA Flash
Error Recovery — Robustness and fault-resilience have
Minimum recommended system for a partial always been design criteria of Windows NT. For example,
workstation XPE build: VDX 800MHz CPU, 256MB Windows NT possesses characteristics such as protected
of memory 1GB Embed disk Flash 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
Windows NT conditions normally displayed on the console that require
user interaction. These errors can not only be logged, but
FEATURES & BENEFITS can be used to trigger application software events.

Scalable Functionality; Supports Both Workstation and TECHNICAL OVERVIEW
Server Features — Windows NT Embedded can be scaled
from a workstation with no GUI to a full-server, based on A developer configures a device-specific NTE image by
the requirements of the application. There are four using Target Designer to select the Windows NT binaries
licensing configurations: Headless Workstation, Full needed by the application, the binaries associated with the
Workstation, Headless Server, and Full Server. special NTE features required by the application, and the
application itself. In some cases, Component Designer is
Authoring Tool Set — Windows NT offers a broad needed to recreate reusable components not found in NTE
spectrum of functionality with many opportunities for (e.g. device drivers). Once created, new components are
"componentization". To take advantage of this, Windows imported into Target Designer, dependencies are checked,
NT Embedded includes an authoring tool set that is and an OS image is built that can be downloaded onto the
currently composed of two tools, the Target Designer and device.
the Component Designer. The Target Designer is the
primary authoring tool, allowing you to define the target Windows NT Embedded does not compete with Windows
configuration of the OS and build the run-time CE but rather provides a complementary choice for
environment for the device. While the Target Designer embedded developers. There are a number of design
defines the set of files and configuration information to be considerations that will help to select the best version of
included on the target system, the Component Designer Windows for your device:
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 Platform

Windows NT Embedded is currently only available for supporting a range of embedded, mobile or multimedia
Intel Pentium and compatible microprocessors. Windows product lines. Windows CE also has integrated power
CE supports X86 microprocessors as well as RISC management, enabling long battery life on mobile devices.
processors such as MIPS, ARM and StrongARM, SHx, and Standard communications support is built into Windows
PPC. 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
Footprint Desk-Top Windows user interface is also available,
facilitating ease-of-use for end users.
If a device needs a small footprint, Windows CE
is the best choice, requiring as little as 4MB of KEY FEATURES & BENEFITS
RAM. Windows NT Embedded requires a device
with the specifications listed below:
Sub-set of Win32 API – Windows CE supports more than
700 of the most-frequently-used Win32 APIs, enabling
Class 1 — Headless Workstation developers to take advantage of vast amounts of third-
party programming resources, tools, software examples,
Standard Install and documentation for their Windows CE-based
development. With more than 500,000 developers
worldwide using Win32, there are many experienced
Memory: 32 to 256 MB of RAM programmers who already know how to develop for the
Storage (min.): 128 MB Microsoft Windows CE platform, which lowers training
(Build size is about 92 MB.) costs and shortens your time to market.

Specialized Install Low-cost, familiar development tools – Windows CE
requires two inexpensive, basic development tools. The
Memory: 16 to 256 MB of RAM first development tool is for the operating system itself:
Storage (min.): 32 MB Platform Builder which is required if you are generating
(Build size is about 32 MB.) 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-
Class 2 — Standard Workstation compilers, assemblers, remote debugger tools, boot
loaders, sample device drivers (keyboard, LCD, serial,
Standard Install IrDA, touch screen, etc.), sample platforms, and operating
system components. The second development tool
Windows Visual Studio is used for developing
Memory: 32 to 256 MB applications.
Storage (min.): 128 MB
(Build size is about 90 MB.)
Scalable, full-featured operating system – Windows CE
can be customized for a product by selecting from a set of
Specialized Install available software modules. In addition, some of the
modules are componentizable, which means that you can
Memory: 16 to 256 MB further customize the modules by selecting from a set of
Storage (min.): 32 MB available components for that module. Because the
(Build size is about 30 MB.) Windows CE operating system is componentized, you can
design embedded system platforms using the minimum
set of software modules and components needed to
Windows NT Embedded supports up to 256 MB support the platform's system requirements. This
of RAM Maximum. 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
Feature Set GUI.

Windows CE is the best choice if the device Extensive and Extensible Device Support – Windows CE
requires semi-real-time capabilities, instant on, directly supports many kinds of hardware peripherals and
and the ability to operate in a disconnected devices, such as keyboards, mouse devices, touch panels,
state. Windows NT Embedded would be the serial ports, Ethernet, modems, USB devices, audio
better choice if the device requires the full devices, parallel ports, printer devices, and storage devices
Win32 API, built-in networking, Windows NT (ATA or flash media). At the same time, as Windows CE
security, remote administration and extends to new industries and device categories, there is
management, POSIX support, and extensive tremendous potential for embedded developers to easily
device driver support. Real-time capabilities for add new device types and peripherals. This is made
NT and NT Embedded can be added using third possible through the simple and well-defined Windows CE
party solutions. There is no USB support for Device Driver model, which provides a well-documented
Windows NT Embedded, all drivers for USB set of device driver interfaces (DDIs) and sample code that
support must be custom written. 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
Windows CE processor architectures include: NEC, Philips, Toshiba
MIPS 39xx and 4xxx, Motorola PowerPC 821, 823, 850,
The Windows CE operating system is a 32-bit, 860, Hitachi SH3 and SH4, Intel 486 and Pentium (and
multitasking, multithreaded operating system that has a compatibles: AMD, Cyrix, SGS Thomson), ARM, and Intel
scalable, open architecture design, providing support for a X-Scale. The wide choice enables OEMs to select
variety of devices. Windows CE is compact, providing high architecture with the best price/performance for their
performance in limited memory configurations, specific application. New processors are being added

regularly. For the complete list of supported processors, Available object stores include file systems,
including specific model numbers, visit the Microsoft registry, and database
Windows CE website. Database provides storage and retrieval of
database records, with up to four sort keys and
TECHNICAL OVERVIEW support for transaction logging and rollback
File System
Access is through Win32 API
OEM Adaptation Layer (OAL)
Supports FATFS, including multiple FAT
volumes (up to 99 volumes)
Windows CE is adapted for a specific hardware platform Installable block Device Drivers (ATA Flash and
by creating a thin layer of code that resides between the SRAM drivers included)
kernel and the hardware platform. This layer is known as
True Flash File System support
the OEM Adaptation Layer (OAL). The OAL isolates
device-specific hardware features from the kernel. The Installable file systems
Windows CE kernel, in turn, contains processor-specific Databases on mounted file systems
code to handle processor core functions. The OAL is
specific for a particular CPU and hardware platform. Registry

The primary purpose of the OAL is to expose the target
platform's hardware to the kernel. This includes managing Win32-like registry
the hardware's timers and device interrupts, and Access is through Win32 Registry API
implementing power management across the device's
peripherals. Windows CE handles interrupts by GDI and USER
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 Configurable from nothing to full-blown GDI &
registered ISR for that interrupt. The ISR, the kernel- User, with intermediate points:
mode-portion of interrupt processing, is kept as short as display-less, message passing
possible. Its responsibility is primarily to direct the kernel (mininput)
to schedule and launch the appropriate interrupt service graphics but no windowing (mingdi)
thread (IST). The IST, implemented in the device driver
software module, gets or sends data and control codes minimalist window manager
from or to the hardware and acknowledges the device (minwmgr)
interrupt. GDI - resolution-independent graphics
Raster and TrueType Font support o1 to 32 BPP
Color Pixel depths w/ palettes
Device Drivers
Printing (device-side rendering)
User - windowing, dialogs, messaging
Built-in support for the keyboard, touch panel, Additional: Controls, clipboard, cursors, caret,
notification LED, display, audio (including idle time out, hot keys, etc.
Sound Blaster™), battery drivers, and a rapid GDI and user export a subset of the Win32 API
development model that allows these devices to
be ported quickly to your platform.
Support for wireless and wireline Ethernet LAN Communications Support
connectivity
Statically replaceable keyboard layout Windows Sockets APIs
Extended interrupt processing interface or WinInet with FTP, HTTP and HTTPS support
device drivers based on the Win32 event model
Secure Sockets Layer (SSL) with Server Gated
Network printing Cryptography support
Support for serial and parallel devices TCP/IP, PPP, SLIP, and IrDA, including Fast IR
Host support for Universal Serial Bus (USB) TAPI modem support
devices
Serial APIs
PCMCIA Card and Socket Services for
Direct connection, dial-up and device-to-device
removable or built-in storage cards
connectivity
LAN connectivity using NDIS and Microsoft
Kernel Network client software (to access remote file
and print servers)
Multi-threaded; preemptive multitasking Remote access services (RAS) to support remove
connectivity
Preemptive priority-based thread scheduling
based on the Win32 process and thread model; Remote debugging over LAN, serial or parallel
supports eight levels of thread priority connections
Support for priority inheritance to correct Built-in support for communication hardware
priority inversion (built-in modems, Ethernet chips, etc.)
Demand paging supported by ROM, RAM, and Windows NT® LAN Manager-based
FAT file systems authentication
Execute in place from ROM
Support for synchronization objects Remote Connectivity
(WaitForSingleObject, WaitForMultipleObjects)
Low ISR and threat latency Remote networking
Portable across microprocessors Direct connection to PC
Heap size that is limited only by available Dial-up access to Internet, PCs, and Servers
memory

Shell
Object Store

Includes a minimum shell that supports WINDOWS CE - Based HARDWARE
application launching and switching REQUIREMENTS
The shell can be included to serve as the basis of
an embedded application At a minimum, a Windows CE-based device must have a
Key UI components included to allow rapid supported processor, memory and an internal timer for
development of custom embedded shells scheduling. No other hardware is specifically referenced by
the operating system, but most devices will have a number
of peripherals.
Internationalization/Localization

Windows CE is a small-footprint, flexible operating
Support for localization of the operating system, system. The memory needed by a Windows CE-based
including built-in support for French, German, system is totally dependent on which components the
Italian, Portuguese (Brazilian), Spanish, Dutch, designer of the system selects. A Typical CE build may
Swedish, Japanese and Chinese (Beta) require 32 Meg of Flash and 32 Meg of RAM.
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
7. Commercial RTOS brands

Additional Component Features 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
ActiveX® and COM/OLE particularly well in avionics applications (where it ranked
Microsoft Virtual Machine for Java for Windows well above average) but somewhat poorer in automotive,
CE computer-related, and industrial segments (where it
Microsoft Foundation Classes for Windows CE 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.

Tied for second place are the Microsoft twins, Windows XP several popular embedded OSes with single-digit market
for Embedded and Windows CE (there were separated by shares. ThreadX is deliberately listed twice: once for the
one vote). In a predictable reversal, WinXP and WinCE Green Hills distribution and once for Express Logic's
were most popular where VxWorks was weakest: product. Oddly, Green Hills appears to sell more copies of
industrial and computer-related applications. XPe was ThreadX than the company that developed it.
especially strong in manufacturing industries, where Looking ahead, we asked those same survey takers what
VxWorks also made a good showing. OS they'd consider using in their next project. Would they
In the number four spot we have Texas Instruments' stay with their current OS or switch to another? We also
DSP/BIOS, a product with obvious hardware ties. That's asked non-OS users the same question to see if they were
followed by Red Hat's Linux, the first of the many Linux considering a commercial OS for the first time. The results
variants to make the list. are summarized in Figure 7.
After that, the numbers all drop to below 8%. QNX, RTX,
C/OS, and Mentor Graphics' Nucleus RTOS head the list of

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.

challenges for designers and technologists. A key issue is
Conclusion: the definition of the right methodologies to translate
Embedded Systems will play a key role to drive the system knowledge and competences into complex
technological evolution in the next decades. In this respect embedded systems, taking into account many system
they stand on the same level as Nano technologies, requirements and constraints. The key factor to win this
bioelectronics, and photonics. The central role of challenge is to build the right culture. This means to be
embedded systems in the economy grows stronger and able to build the right environment to exploit existing
stronger. The starting point is the convergence between design, architectural and technological solutions, and to
storage, security, video, audio, mobility and connectivity. favour the transfer of knowledge from one application field
Systems are converging and ICs are more and more into another.
converging with systems. This poses a number of

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.

Embedded operating systems

Recommended

More Related Content

What's hot (20)

Similar to Embedded operating systems (20)

Recently uploaded (20)

Embedded operating systems