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: Soft 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 Kadak’s AMX 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 Microtec VRTX http://www.mentor.com/microtec/ QNX http://www.qnx.com/