Abhay Kumar Chaurasia
Roll No: 20083025
Reg No:2982 of 2008-09


  1. Introduction

  1. Real-time System
    1. Components Make Up a Real-Time System �������.�. 3

2.2 Do I Need a Real-Time System? ����������.� �...3

  1. Operating System ����������.�������..��..4

3.1 Common Tasks and standards of an OS ������.�.��... 4
3.2 Different types of an OS �������������..��... 5
3.3 OS for devices other than computers ��������..��� 6

  1. Real-time Operating system ���������.............................. 6

4.1 DIFFERENCE: RTOS v/s General Purpose OS ���..���... 8
4.2 RTOS CLASSFICATION����������..�����. 8
4.3 Misconception of RTOS ������������.���. .10
4.4 Basic Requirements of an RTOS ���������.���. 10
4.5 RTOS Architecture���������������..��... 11
4.6 Services by RTOS: ���������������......... 12
4.6.1 Task Management���������.����...13 4.6.2 Synchronisation and communication ����..�.....16
4.6.3 Memory Management ������...��...��... 18
4.6.4 Timer Management ����������.�..�..19
4.6.5 Interruop and event handling. ����...�..���.19
4.6.6 Device I/O Management � ���..��.�.���20
5. Case Studies�������������������.....��. 20

6. Conclusion .�����������������..��...��... 22

7. References �.���������������.������.... 23


Last few decades have seen the rise of computers to a position of prevalence in human affairs. It has made its mark in every field ranging personal home affairs, business, process automation in industries, communications, entertainment, defense etc.
For many engineers and scientists, running control program on a standard PC with a general-purpose OS installed (such as Windows) is unacceptable. At any time, the operating system might delay execution of a user program for many reasons: to run a virus scan, update graphics, perform system background tasks, and more. For programs that need to run at a certain rate without interruption (for example a cruise control system), this delay can cause system failure.
this behavior is by design: general-purpose operating systems are optimized to run many processes and applications at once and provide other features like rich user interface graphics. In contrast, real-time operating systems are designed to run a single program with very precise timing. Specifically, real-time operating systems can allow you to:

  • Perform tasks within a guaranteed worst-case timeframe
  • Carefully prioritize different sections of your program
  • Run loops with nearly the same timing each iteration (typically within microseconds)
  • Detect if a loop missed its timing goal

When researching real-time computing systems, you may run across the terms "hard real-time" and "soft real-time". To clarify, hard real-time systems are designed to absolutely guarantee that a task will execute within a certain worst-case timeframe. Therefore, for projects involving safety or systems that could result in a large investment in the event of failure, hard real-time is often a requirement. On the other hand, soft real-time systems are designed to satisfy your timing requirements most of the time but without absolute certainty. This can be acceptable for operations like video processing, where a lost data frame is not good but may not necessarily be a critical problem.
In addition to providing precise timing, real-time computing systems can be set up to run reliably for days, months, or years without stopping. This is important not only for engineers building systems that need 24-7 operation, but also for any application where down time is costly.
2.Real-time System

A real-time system is able to reliably execute programs with very specific timing requirements. A real-time system is one whose correctness involves both the logical correctness of outputs and their timeliness.

As defined by Donald Gillies �A real-time system is one in which the correctness of the computations not only depends upon the logical correctness of the computation but also upon the time in which the result is produced. If the timing constraints are not met, system failure is said to have occurred.�

These systems respond to a series of external inputs, which arrive in an unpredictable fashion. The real-time systems process these inputs, take appropriate decisions and also generate output necessary to control the peripherals connected to them. The design of a real-time system must specify the timing requirements of the system and ensure that the system performance is both correct and timely.

There are two types of time constraints:

Hard: degree of tolerance for missed deadlines is extremely small or zero. A late response is incorrect and implies a system failure.

Soft: deadlines may be missed and can be recovered from. Reduction in system quality is acceptable. If a single computation is late, it is not usually significant, although repeated late computation can result in system failures.

Figure 1. Hard real-time systems guarantee (when programmed correctly) that a deadline will be consistently met, while soft real-time systems may periodically exceed the deadline.
2.1 Components Make Up a Real-Time System
Though the major component needed to create a real-time system is a real-time operating system (RTOS), various pieces of software and hardware which are needed to build a real time system from start to finish.

  • Real-time operating system: This special OS is designed to run a user program reliably with very precise timing.
  • Development tools: A compiler, linker, and debugger are needed that can generate code compatible with the real time operating system.
  • I/O Drivers: For a real-time operating system to communicate with system hardware and I/O modules, real-time compatible drivers are needed that can guarantee worst-case timing for most I/O operations.
  • (Optional) Rugged hardware: Chassis used in a real-time system may be designed to sustain harsh environments for long periods of time.

2.2 Do I Need a Real-Time System?
building a real-time system can be a good idea if we need to make sure that certain parts of our program run in a certain amount of time, or if we need to run our program reliably for long periods of time.
So, If we are working on a mission-critical or safety-related project, then the need for building a real-time system is clear.

3.Operating System

An operating system (OS) is a set of programs that manage computer hardware resources and provide common services for application software. The operating system is the most important type of system software in a computer system. A user cannot run an application program on the computer without an operating system. Time-sharing operating systems schedule tasks for efficient use of the system and may also include accounting for cost allocation of processor time, mass storage, printing, and other resources.
For hardware functions such as input and output and memory allocation, the operating system acts as an intermediary between application programs and the computer hardware. Operating systems are found on almost any device that contains a computer�from cellular phones and video game consoles to supercomputers and web servers.
The job of an Operating Systems for a computer is mainly to manage the hardware and software resources of the system. In desktops or laptops, the hardware resources include processes, hard disk, memory, disk space, mouse, printers, other peripherals, etc.; whereas the software resources are the various software applications being used on that desktop/laptop. Operating Systems also play a very important role in providing a consistent interface for the applications irrespective of the hardware or peripherals used. There may be different drivers used along with the Operating Systems for this purpose.
Examples of popular modern operating systems inclue iOS, Linux, Mac OS X, all of which have their roots in Unix, and Microsoft Windows.
3.1 Common Tasks and standards of an Operating Systems
Following are the common tasks :
1. Operating Systems Processor Management: This involves ensuring that all the system resources receive sufficient process time for expected functioning as well as making sure that the processer is used to its optimum capacity.
2. Operating Systems-Memory Management or Storage Management: Computer systems have different types of memories such as temporary (RAM, Cache, etc.) as well as permanent memories (Hard Drives, USB Drives, etc.). It is the job of an
Operating System to allocate the relevant and necessary memory space to the applications & devices for efficient and optimum processing of information.
3. Operating Systems-Device Management: Managing the inputs and outputs of various devices / peripherals is also one of the critical functions of an Operating Systems. With the help of device drivers, the OS controls flow of information with the necessary allocation of system resources to ensure correct input and output.
4. Operating Systems-Application Management: As the OS manages the devices using drivers, it also manages the various applications running on a computer using different Application Program Interfaces (APIs). Based on the data received from the application through the APIs, the OS performs actions to provide the expected results.
5. Operating Systems-User Interface: A user interface provides a consistent way of interaction between the user and the computer system. The OS acts as an engine to provide means of interaction between user and computer through the user interfaces.
3.2 Different types of an Operating System
Following are the types of an Operating Systems:
1. Operating Systems for Real-time OS: These types of OS are used to control machinery, control systems and industrial systems and have very less or in certain case no user-interface capability.
2. Operating Systems for Single User, Single Task OS: This is a typical computer system where one user can work effectively only one task at a time. Cell phones and palm tops are examples where these types of systems are used.
3. Operating Systems for Single User, Multi-tasking: Computer Operating Systems of desktops or laptops typically fall within this category. Here, the user can use several applications at a time.
4. Operating Systems for Multi-User: Here, various users use the computer system through different terminal and the Operating Systems on that computer has to balance multiple users with multiple applications.

3.3 Operating Systems for devices other than computers
Electronic devices other computers also require Operating Systems of one form or another to function as per expectation. Example - cell phone, microwave, industrial systems, intelligent devices, etc. In case of such devices, the sources and form of inputs as well as outputs is different than that in a computer system. Accordingly, the Operating Systems designed to drive these devices are also programmed differently.
4. Real-time Operating system

A Real-Time Operating System (RTOS) comprises of two components, viz.,
�Real-Time� and �Operating System�
Real-time systems are those systems in which the correctness of the system depends not only on the logical result of computation, but also on the time at which the results are produced.

An Operating system (OS) is nothing but a collection of system calls or functions which provides an interface between hardware and application programs. Core of the OS is the Kernel which is typically a small, highly optimised set of libraries.

RTOS is therefore an operating system that supports real-time applications by providing logically correct result within the required deadline.

A multitasking operating system proposed for real-time applications is known as real-time operating system.

Basic Structure is similar to regular OS but, in addition, it provides mechanisms to allow real time scheduling of tasks.The applications comprise embedded systems like programmable thermostats, household appliance controllers, industrial robots, mobile telephones, scientific research equipment and spacecraft, industrial control.
Though real-time operating systems may or may not increase the speed of execution, they can provide much more precise and predictable timing characteristics than general-purpose OS.

RTOS is key to many embedded systems and provides a platform to build applications. All embedded systems are not designed with RTOS. Embedded systems with relatively simple/small hardware/code might not require an RTOS. Embedded systems with moderate-to-large software applications require some form of scheduling, and hence RTOS.

The RTOS should have predictable behavior to unpredictable external events.

�A good RTOS is one that has a bounded (predictable) behavior under all system load scenario i.e. even under simultaneous interrupts and
Thread execution.�

A true RTOS will be deterministic under all conditions. These operating systems occupy little space from 10 KB to 100KB as compared to the General Operating systems which take hundreds of megabytes. We observe that the choice of an operating system is important in Designing a real-time system. Designing a real-time system involves choice of a proper language, task partitioning and merging, and assigning priorities to manage response times. Depending upon scheduling objectives, parallelism and communication may be balanced. Merging highly cohesive parallel tasks for sequential execution may reduce overheads of context switches and inter-task communications. The designer must determine critical tasks and assign them high priorities. However, care must be taken to avoid starvation, which occurs When higher priority tasks are always ready to run, resulting in insufficient Processor time for lower priority tasks. Non-prioritized interrupts should be avoided if there is a task that cannot be preempted without causing system failure. Ideally, the interrupt handler should save the context, create a task that will service the interrupt, and return control to the operating system. Using a task to perform bulk of the interrupt service allows the service to be performed based on a priority chosen by the designer and helps preserve the priority system of the RTOS. Clearly the choice of an RTOS in the design process is important for support of priorities, interrupts, timers, inter-task communication, synchronization, multiprocessing and memory management.

4.1 DIFFERENCE: RTOS v/s General Purpose OS

DeterminismThe key difference between general-computing operating systems and real-time operating systems is the �deterministic " timing behavior in the real-time operating systems. "Deterministic" timing means that OS consume only known and expected amounts of time. RTOS have their worst case latency defined. Latency is not of a concern for General Purpose OS. Task Scheduling - General purpose operating systems are optimized to run a variety of applications and processes simultaneously, thereby ensuring that all tasks receive at least some processing time. As a consequence, low-priority tasks may have their priority boosted above other higher priority tasks, which the designer may not want. However, RTOS uses priority-based preemptive scheduling, which allows high-priority threads to meet their deadlines consistently. All system calls are deterministic, implying time bounded operation for all operations and ISRs. This is important for embedded systems where delay could cause a safety hazard. The scheduling in RTOS is time based. In case of General purpose OS, like Windows/Linux, scheduling is process based.
Preemptive kernel - In RTOS, all kernel operations are preemptible
Priority Inversion - RTOS have mechanisms to prevent priority inversion
Usage - RTOS are typically used for embedded applications, while General Purpose OS are used for Desktop PCs or other generally purpose PCs.
4.2 RTOS CLASSFICATION RTOS specifies a known maximum time for each of the operations that it performs. Based upon the degree of tolerance in meeting deadlines, RTOS are classified into following categories
1)Hard real-time: An OS that can absolutely guarantee a maximum time for the operations it performs is referred to as hard real-time. An application (or critical piece of an application) that runs on a hard real-time operating system is referred to as deterministic if its timing can be guaranteed within a certain margin of error. Degree of tolerance for missed deadlines is negligible. A missed deadline can result in catastrophic failure of the system.
2)Firm real-time: Missing a deadline might result in an unacceptable quality reduction but may not lead to failure of the complete system.
3)Soft real-time: An OS that can usually perform operations in a certain time is referred to as soft real-time. Deadlines may be missed occasionally, but system doesn�t fail and also, system quality is acceptable. For a life saving device, automatic parachute opening device for skydivers e.t.c, delay can be fatal. So such systems must have hard real time systems, whereas for TV live broadcast, delay can be acceptable. In such cases, soft real time systems can be used.
Important terminologies used in context of real time systems:
Determinism: An application is referred to as deterministic if its timing can be guaranteed within a certain margin of error.
Jitter: Timing error of a task over subsequent iterations of a program or loop referred to as jitter. RTOS are optimized to minimize jitter.
4.3 Misconception of RTOS

a) RTOS must be fast :- The responsiveness of an RTOS depends on its deterministic behavior and not on its processing speed. The ability of RTOS to response to events within a timeline does not imply it is fast.

b) RTOS introduce considerable amount of overhead on CPU :- An RTOS typically only require between 1% to 4% of a CPU time.

c) All RTOS are the same :- RTOS are generally designed for 3 types of real-time systems (i.e. hard, firm & soft). In addition, they are further classified according to the types of hardware devices (e.g. 8-bit, 16-bit) supported.

4.4 Basic Requirements of an RTOS:

The following are the basic requirements for an RTOS:

(i) Multi-tasking and preemptable:
To support multiple tasks in real time applications, an RTOS must be multi-tasking and preemptable. The scheduler should be able to preempt any task in the system and give the resource to the task that needs it most. An RTOS should also handle multiple levels of interrupts to handle multiple priority levels.

(ii) Dynamic deadline identification: In order to achieve preemption, an RTOS should be able to dynamically identify the task with the earliest deadline. To handle deadlines, deadline information may be converted to priority levels that are used for resource allocation. Although such an approach is error prone, nonetheless it is employed for lack of a better solution.

(iii) Predictable synchronization: For multiple threads to communicate among themselves in a timely fashion, predictable inter-task communication and synchronization mechanisms are required. Semantic integrity as well as timeliness constitutes predictability. Predictable synchronization requires compromises. Ability to lock/unlock resources is one of the ways to achieve data integrity. (iv) Sufficient Priority Levels: When using prioritized task scheduling, the RTOS must have a sufficient number of priority levels, for effective implementation. Priority inversion occurs when a higher priority task must wait on a lower priority task to release a resource and in turn the lower priority task is waiting upon a medium priority task. Two work arounds in dealing with priority inversion, namely priority inheritance and priority ceiling protocols (PCP), need sufficient priority levels. In a priority inheritance mechanism, a task blocking a higher priority task inherits the higher priority for the duration of the blocked task.

(v) Predefined latencies: The timing of system calls must be defined using the following specifications:
Task switching latency or the time to save the context of a currently executing task and switch to another.
Interrupt latency or the time elapsed between the execution of the last instruction of the interrupted task and the first instruction of the interrupt handler.
Interrupt dispatch latency or the time to switch from the last instruction in the interrupt handler to the next task scheduled to run.
4.5 RTOS Architecture
For simpler applications, RTOS is usually a kernel but as complexity increases, various modules like networking protocols, debugging facilities, device I/Os , device drivers stacks are included in addition to the kernel.

The general architecture of RTOS is shown in the fig.

Kernel : RTOS kernel acts as an abstraction layer between the hardware and the applications. There are three broad categories of kernels

Monolithic kernel:- Monolithic kernels are part of Unix-like operating systems like Linux, FreeBSD etc. A monolithic kernel is one single program that contains all of the code necessary to perform every kernel related task. It runs all basic system services (i.e. process and memory management, interrupt handling and I/O communication, file system, etc) and provides powerful abstractions of the underlying hardware. Amount of context switches and messaging involved are greatly reduced which makes it run faster than microkernel.

Microkernel:- It runs only basic process communication (messaging) and I/O control. It normally provides only the minimal services such as managing memory protection, Inter process communication and the process management. The other functions such as running the hardware processes are not handled directly by microkernels. Thus, micro kernels provide a smaller set of simple hardware abstractions. It is more stable than monolithic as the kernel is unaffected even if the servers failed (i.e. File System).

Hybrid Kernel:- Hybrid kernels are extensions of microkernels with some properties of monolithic kernels. Hybrid kernels are similar to microkernels, except that they include additional code in kernel space so that such code can run more swiftly than it would were it in user space. These are part of the operating systems such as Microsoft Windows NT, 2000 and XP etc

Exokernel:- Exokernels provides efficient control over hardware. It runs only services protecting the resources (i.e. tracking the ownership, guarding the usage, etc) by providing low-level interface for library operating systems and leaving the management to the application.

4.6 Services by RTOS:

Six types of common services are given by RTOS which is shown in the figure and explained in subsequent sections:

4.6.1 Task Management
In RTOS, The application is decomposed into small, schedulable, and sequential program units known as �Task�, a basic unit of execution and is governed by three time-critical properties; release time, deadline and execution time. Release time refers to the point in time from which the task can be executed. Deadline is the point in time by which the task must complete. Execution time denotes the time the task takes to execute.

Each task may exist in following states
Dormant : A state denoted task created but not activated
Ready: Task is ready to go active state, waiting process or time
Active: Task is running
Suspended: Task put on hold temporarily
Pending: Task waiting for resource or external events

During the execution of an application program, individual tasks are continuously changing from one state to another. However, only one task is in the running mode (i.e. given CPU control) at any point of the execution. In the process where CPU control is change from one task to another, context of the to-be-suspended task will be saved while context of the to-be-executed task will be retrieved, the process referred to as context switching.

A task object is defined by the following set of components:
Task Control block(TCB): Task uses TCBs to remember its context. TCBs are data structures residing in RAM, and are accessible only by RTOS.

Task_Prog _Counter

Task Stack: These reside in RAM, accessible by stack pointer.
Task Routine: Program code residing in ROM.

Scheduler:- The scheduler keeps record of the state of each task and selects from among them that are ready to execute and allocates the CPU to one of them. Various scheduling algorithms are used in RTOS
(1) Polled Loop Scheduling: Polled loops are used for fast response to singal devices. In a polled loop system , a single and repetitive flag is used to test a flag that indicates whether or not some event has occurred. It sequentially determines if specific task requires time.

� Very easy to code and debug.
� Response time is easy to determine.
� Cannot handle asynchronous events.
� Waste of CPU time, especially, when the program is continuously monitoring a status flag or variable.
(2) Polled System with interrupts Scheduling: In addition to polling, it takes care of critical tasks.

(3) Round Robin Scheduling: RRS is Sequences from task to task, each task getting a time slice. time slices are assigned to each process in equal portions, it handles all processes without priority.

(4) Hybrid System Scheduling: It is Sensitive to sensitive interrupts, with Round Robin system working in background.
(5) Interrupt Driven Scheduling: System continuously wait for the interrupts and when interrupt occurs performs scheduling.
(6) Non pre-emptive scheduling or Cooperative Multitasking: Highest priority task executes for some time, then relinquishes control, re-enters into ready any given time, the processor executes the highest priority task of all those tasks that are currently ready to execute.

(7) Preemptive scheduling Priority multitasking: Current task is immediately suspended Control is given to the task of the highest priority at all time.

Dispatcher :- The dispatcher gives control of the CPU to the task selected by the scheduler by performing context switching and changes the flow of execution.
4.6.2 Synchronisation and communication
Task Synchronisation & intertask communication serves to pass information amongst tasks.
Task Synchronisation
Synchronization is essential for tasks to share mutually exclusive resources (devices, buffers, etc) and/or allow multiple concurrent tasks to be executed (e.g. Task A needs a result from task B, so task A can only run till task B produces it).

Task synchronization is achieved using two types of mechanisms:
Event Objects: Event objects are used when task synchronization is required without resource sharing. They allow one or more tasks to keep waiting for a specified event to occur. Event object can exist either in triggered or non-triggered state. Triggered state indicates resumption of the task.

Semaphores: A semaphore has an associated resource count and a wait queue. The resource count indicates availability of resource. The wait queue manages the tasks waiting for resources from the semaphore. A semaphore functions like a key that define whether a task has the access to the resource. A task gets an access to the resource when it acquires the semaphore.

There are three types of semaphore:

  • Binary Semaphores (semaphore value of either 0 or 1 to indicate unavailability and availability respectively)
  • Counting Semaphores(semaphore value of 0 or greater indicating it can be acquired/released multiple times)
  • Mutually Exclusion(Mutex) Semaphores (semaphore value of 0 or 1 but lock count can be 0 or greater for recursive locking)

Semaphore functionality (Mutex) represented pictorially in the following figure

Intertask communication
Intertask communication involves sharing of data among tasks through sharing of memory space, transmission of data, etc.
Intertask communications is executed using following mechanisms
Message queues - A message queue is an object used for intertask communication through which task send or received messages is placed in a shared memory. The queue may follow 1) First In First Out (FIFO), 2) Last in First Out(LIFO) or 3) Priority (PRI) sequence. Usually, a message queue comprises of an associated queue control block (QCB), name, unique ID, memory buffers, queue length, maximum message length and one or more task waiting lists. A message queue with a length of 1 is commonly known as a mailbox.

Pipes - A pipe is an object that provide simple communication channel used for unstructured data exchange among tasks. A pipe does not store multiple messages but stream of bytes. Also, data flow from a pipe cannot be prioritized.

Remote procedure call (RPC) - It permits distributed computing where task can invoke the execution of another task on a remote computer.

4.6.3 Memory Management
An RTOS uses small memory size by including only the necessary functionality for an application while discarding the rest. Two types of memory managements are provided in RTOS � Stack and Heap. Below we discuss Static and dynamic memory management in RTOSs.
Static memory management provides tasks with temporary data space. The system�s free memory is divided into a pool of fixed sized memory blocks, which can be requested by tasks. Stack memory management is used during context switching for TCBs.
Dynamic memory management employs memory swapping, overlays, Multip - rogramming with a fixed number of tasks (MFT), multiprogramming with a variable number of tasks (MVT) and demand paging. memory used for program code, program data and system stack is called heap memory and it is used for dynamic allocation of data space for tasks. Management of this memory is called heap management.

4.6.4 Timer Management

Clocks are used to manage time in computers and it is a control API�s. Timers is H/w or S/w which allow functions to be evoked at specified time in future.
In embedded systems, system and user tasks are often scheduled to perform after a specified duration. To provide such scheduling, there is a need for a periodical interrupt to keep track of time delays and timeout. Timer management tasks need to be performed after scheduled durations to keep track of the delays. relative and absolute timers are provided in RTOS.�relative timers� work in units of ticks, and �absolute timers� that work with calendar date and time. For each kind of timer, RTOSs provide a �task delay� service, and also a �task alert� service based on the signaling mechanism (e.g. event flags).

4.6.5 Interrupt and event handling
An interrupt is a hardware mechanism used to inform the CPU that an asynchronous event has occurred. A fundamental challenge in RTOS design is supporting interrupts and thereby allowing asynchronous access to internal RTOS data structures. The interrupt and event handling mechanism of an RTOS provides the following functions:

� Defining interrupt handler
� Creation and deletion of ISR
� Referencing the state of an ISR
� Enabling and disabling of an interrupt
� Changing and referencing of an interrupt mask etc
and help to ensure:

  • Data integrity by restricting interrupts from occurring when modifying a data structure.
  • Minimum interrupt latencies due to disabling of interrupts when RTOS is performing critical operations.
  • Fastest possible interrupt responses that marked the preemptive performance of an RTOS.
  • Shortest possible interrupt completion time with minimum overheads.

4.6.6 Device I/O Management
An RTOS kernel is often equipped with a device I/O management service to provide a uniform framework (application programmer�s interface-�API�) and supervision facility for an embedded system to organize and access large numbers of diverse hardware device drivers. However, most device driver APIs and supervisors are �standard� only within a specific RTOS. i�e RTOS generally provides large number of APIs to support diverse hardware device drivers.

5. Case Studies

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

5.1 QNX RTOS v6.1
The QNX RTOS v6.1 has a client-server based architecture. QNX Adopts the approach of implementing an OS with a 10 Kbytes micro-kernel Surrounded by a team of optional processes that provide higher-level OS Services. Every process including the device driver has its own virtual memory space. The system can be distributed over several nodes, and is network transparent. The system performance is fast and predictable and is robust.

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

5.3 Windows CE 3.0
Windows CE 3.0 is an Operating system rich in features and is
available for a variety of hardware platforms. It exhibits true real-time
behavior most of the times. The system is complex and highly configurable.
CE 3.0 uses virtual memory protection to protect itself against faulty applications.

5.4 pSOSystem/x86 2.2.6
pSOSystem is a small kernel suitable for embedded applications. This uses the software bus to communicate between different modules. The choice of module to be used can be done at compile time making it suitable for embedded applications. System has a flat memory space. All threads share
the same memory space and also share all objects such as semaphores.

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

6. Conclusion

Real time Operating systems play a major role in the field of embedded systems especially for mission critical applications are involved. Selection of a particular RTOS for an application can be made only after a thorough study of the features provided by the RTOS. The choice of Operating System
generally comes after the selection of the processor and development tools.
Every RTOS is associated with a finite set of microprocessors and a suite of development tools. Hence the first step in choosing an RTOS must be to make the processor, real-time performance and the budget requirements clear. Then look at the available RTOS to identify the one which suits our application.

Generally an RTOS should have the Following features:

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

7. References


[1] �Real-Time Concepts for Embedded Systems� (Qing Li with Caroline Yeo)

[2] Dedicated Systems Experts, �What makes a good RTOS.� Brussels, Belgium: Dedicated Systems Experts, 2001.

[3] P.A. Laplante, �Real-Time Systems Design and Analysis: An Engineer�s
Handbook,� Second edition, IEEE Press, 1997.