An Introduction and Practical approach to RTOS concepts.

What is an Operating System? Piece of software that sits between applications and

hardware. Hides hardware details from applications. Provides standard interfaces to hardware and

software devices. Provides protection mechanisms. Typical services:

– Memory management (main memory, secondary memory, virtual memory, paging, file system)

– Process management (scheduling, task management, synchronization, interrupt and exception handling, inter task communication)

– Protection– Input - Output management (device driver)– Support of distributed applications and multiprocessors

What is a Real Time System? Timeliness is the single most important

aspect of a real-time system. 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.

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

Examples of RT Systems.

Control of production processes / industrial automation

Railway switching systems Automotive applications Flight control systems Environmental acquisition and monitoring Telecommunication systems Household appliances Robotics Military systems Space missions

An in-depth view Real-time

– Time: main difference to other classes of computation

– Real: reaction to external events must occur during their evolution.

System time (internal time) has to be measured with same time scale as controlled environment (external time)

Real time does not mean fast but predictable Concept of deadline:

– Time after which a computation is not just late, but also wrong

Hard Vs Soft RT systems Hard RT task:

– if missing its deadline may cause catastrophic consequences on the environment under control

Soft RT task: – if meeting its deadline is desirable (e.g. for

performance reasons) but missing does not cause serious damage

RTOS that is able to handle hard RT tasks is called hard real-time OS

Why is a desktop OS not suited?

Monolithic kernel is too feature rich. Monolithic kernel is not modular, fault-

tolerant, configurable, modifiable, … Takes too much space. Not power optimized. Not designed for mission-critical

applications.

Design goals of an RTOS Small: minimal memory footprint Open: many interfaces and protocols, open

system standards Modular: easy to integrate custom components Portable: run on lots of devices Real- time: support of hard deadlines, bounded

interrupts, scheduling, synchronization Power consumption: integrated power

management Robustness: fault tolerant, halts, guards,

exceptions, CRC, … Configurable: adaptable to required functionality

Desirable features of RTOS Timeliness

– OS has to provide mechanisms for: • time management • handling tasks with explicit time constraints

Predictability Fault tolerance Design for peak load Maintainability

Timeliness

In timeliness, we say that a given task should be completed in stipulated amount of time else there is no meaning of performing the task.

This is so strict in Hard RT systems and is adjustable in Soft RT systems

This is also referred as responsiveness

Predictability

This feature insists that the response of the system should be predictable for any unpredicted input to the system.

This takes care of the stability of the system.

When the system doesn’t have this feature, it leads to a chaos state.

Fault tolerance

This takes care of the exceptions that occurs in the system.

Fault tolerance is the feature by which the system can continue normally even a failure occurs.

This is also referred as fail-safe operation, exception handling.

Design for peak load The efficiency of the RTOS is taken

care by this factor While designing the system, the peak

load should be taken into account as the normal load

This would guarantee best operation even at fully loaded condition

Testing should be done to meet this peak load condition

Maintainability

This feature helps in the future development and maintenance of the RTOS

Not a strict need for one-time design systems

RTOS simplification factors (earlier) No display No disk drives (and no file system) One, dedicated “user” Limited security requirements Limited Tasks Limited connectivity Controlled interaction Closed system

RTOS complication factors (earlier) Limited resources Direct hardware access Unpredictable I/O Hardware reliability Limited I/O Required reliability Cost

Evolution of RTOS

Traditional monolithic kernel

Microkernel

RTOS elements

Scheduler I/O handler File handler (If any) Exception handler

Scheduler definition Given a set of tasks J = {J 1 , ...J n } a

schedule is an assignment of tasks to the processor so that each task is executed until completion.

A schedule is called feasible if all tasks can be completed according to a set of specified constraints

A set of tasks is called schedulable if there exist at least one algorithm that can produce a feasible schedule

Key fact of an RT scheduling

– Any RT scheduling policy must be preemptive:

• Tasks performing exception handling may need to preempt running tasks to ensure timely reaction

• Tasks may have different levels of criticalness. This can be mapped to a preemption scheme

• More efficient schedules can be produced with preemption

Task synchronizing Mechanisms:

– Mutex– Semaphore– Message Queue– Monitor

Must be manipulated in a critical section! Used for shared resources:

– Global variables– Memory buffers– Device registers

I/O handler

I/O can be using any device unlike traditional systems

I/O handler should be efficient to take care of the latency

File handler

Normally takes care of maintaining files like traditional systems except that the medium may be different

Efficient way of optimizing available space should be taken care

Exception handler

This take care of an abnormal condition. Guarantees fail-safe performance of the

RTOS Exhaustive testing is need on this

design

Hard reset

A hard reset is termed to be the reset of the system to its initial state loosing all the previous data and states of the system

There should be provision for this to handle if all fail-safe measure fails.

RTOS selection criteria Processor Performance (deterministic) Cost

– Initial– Royalties

Tools– Cross-compilers– Debuggers

RTOS selection criteria (contd…) Capability

– Scheduling– Device Drivers– Protocol stacks– Flash file systems

Availability of source code Technical Support Compatibility with 3 rd party tools Floating-point math Accommodates your constraints

An RTOS should

Support a wide range of hardware platforms Have a scalable kernel Support multi-level interrupt process-level

priorities Support multi-threaded operations with

predictable thread synchronization Support code sharing for re-entrant tasks Provide Real-Time memory management Support ANSI C Support the Real-Time POSIX® standards Provide a wide range of commercially

available software tools

Low end of the spectrum

Accelerated Technologies Nucleus– http://www.acceleratedtechnology.com

Kadak’s AMX– http://www.kadak.com/

High end of the spectrum Wind River VxWorks

– http://www.windriver.com/ Inegrated Systems’ pSOS

– http://www.windriver.com/ Microtec VRTX

– http://www.mentor.com/microtec/ QNX

– http://www.qnx.com/