RTOS - Real Time Operating System

A Real-Time Operating System (RTOS) comprises of two components, viz., “Real-Time” and “Operating System”.

An Operating system (OS) is nothing but a collection of system calls or functions which provides an interface between hardware and application programs. It manages the hardware resources of a computer and hosting applications that run on the computer. An OS typically provides multitasking, synchronization, Interrupt and Event Handling, Input/ Output, Inter-task Communication, Timers and Clocks and Memory Management. Core of the OS is the Kernel which is typically a small, highly optimised set of libraries.

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.

RTOS is therefore an operating system that supports real-time applications by providing logically correct result within the deadline required. Basic Structure is similar to regular OS but, in addition, it provides mechanisms to allow real time scheduling of tasks.

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.

Fig. 1: A Diagram Illustrating Real Time Embedded System with RTOS

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.

DIFFERENCE: RTOS v/s General Purpose OS

· Determinism – The 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.

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

· Hard real-time: Degree of tolerance for missed deadlines is negligible. A missed deadline can result in catastrophic failure of the system

· Firm real-time: Missing a deadly ne might result in an unacceptable quality reduction but may not lead to failure of the complete system

· 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, delay can be fatal. Parachute opening device deploys the parachute at a specific altitude based on various conditions. If it fails to respond in specified time, parachute may not get deployed at all leading to casualty. Similar situation exists during inflation of air bags, used in cars, at the time of accident. If airbags don’t get inflated at appropriate time, it may be fatal for a driver. So such systems must be 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

Fig. 2; A Figure Showing Structure of a Soft Real Time System

· 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 is referred to as jitter. RTOS are optimized to minimize jitter.

RTOS Features

RTOS Features

i. Multithreading and preemptability – The scheduler should be able to preempt any task in the system and allocate the resource to the thread that needs it most even at peak load.

ii. Thread Priority – All tasks are assigned priority level to facilitate pre-emption.The highest priority task that is ready to run will be the task that will be running.

iii. Inter Task Communication & Synchronization – Multiple tasks pass information among each other in a timely fashion and ensuring data integrity

iv. Priority Inheritance – RTOS should have large number of priority levels & should prevent priority inversion using priority inheritance.

v. Short Latencies – The latencies are short and predefined.

• Task switching latency: The time needed to save the context of a currently executing task and switching to another task.

• Interrupt latency: The time elapsed between execution of the last instruction of the interrupted task and the first instruction in the interrupt handler.

• Interrupt dispatch latency: The time from the last instruction in the interrupt handler to the next task scheduled to run.

POSIX COMPLIANCE

IEEE Portable Operating System Interface for Computer Environments, POSIX 1003.1b (formerly 1003.4) provides the standard compliance criteria for RTOS services. It is designed to allow application programmers to write applications that can easily be ported across OSs.

The basic RTOS services covered by POSIX 1003.1b include:

• Asynchronous I/O: Ability to overlap application processing and I/O operations

• Synchronous I/O: Ability to assure return of the interface procedure when the I/O operation is completed.

• Memory locking: Ability to guarantee memory residence by storing sections of a process that were not recently referenced on secondary memory devices.

• Semaphores: Ability to synchronize resource access by multiple processes.

• Shared memory: Ability to map common physical space into independent process specific virtual space.

• Execution scheduling: Ability to schedule multiple tasks. Common scheduling methods include round robin and priority-based preemptive scheduling.

• Timers: Timers improve the functionality and determinism of the system. A system should have at least one clock device (system clock) to provide good real-time services.

RTOS Architecture – Kernel

RTOS Architecture

For simpler applications, RTOS is usually a kernel but as complexity increases, various modules like networking protocol stacks debugging facilities, device I/Os are includes in addition to the kernel.

The general architecture of RTOS is shown in the fig.

Fig. 3: A Figure Illustrating the General Architecture of RTOS

A) 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). Microkernels are part of the operating systems like AIX, BeOS, Mach, Mac OS X, MINIX, and QNX. Etc

· 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. DragonFly BSD, etc

· Exokernel

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

Six types of common services are shown in the following figure below and explained in subsequent sections

Fig. 4: A Figure Showing Common Services Offered By a RTOS System

Architecture – Task Management

B) Task Management

· Task Object

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.

Fig. 5: A Diagram Illustrating Use of RTOS for Time Management Application

Each task may exist in following states

· Dormant : Task doesn’t require computer time

· Ready: Task is ready to go active state, waiting processor time

· Active: Task is running

· Suspended: Task put on hold temporarily

· Pending: Task waiting for resource.

Fig. 6: A Figure Representing Different Time Management Tasks Done by an RTOS

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: Task uses TCBs to remember its context. TCBs are data structures residing in RAM, accessible only by RTOS

Task_ID

Task_State

Task_Priority

Task_Stack_Pointer

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

· Polled Loop: Sequentially determines if specific task requires time.

Fig. 7: A Diagram Illustrating Process Flow of a Scheduler

· Polled System with interrupts. In addition to polling, it takes care of critical tasks.

Fig. 8: A Figure Illustrating Polled Systems with Interrupts

· Round Robin : Sequences from task to task, each task getting a slice of time

Fig. 9: A Diagram Representing Round Robin Sequences From Task to Task

· Hybrid System: Sensitive to sensitive interrupts, with Round Robin system working in background

· Interrupt Driven: System continuously wait for the interrupts

· Non pre-emptive scheduling or Cooperative Multitasking: Highest priority task executes for some time, then relinquishes control, re-enters ready state.

Fig. 10: A Figure Illustrating Non-Preemptive Scheduling or Cooperative Multitasking

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

Fig. 11: A Diagram Representing Preemptive Scheduling or Priority Multitasking

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

Architecture Contd.

C) 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

· Counting Semaphores

· Mutually Exclusion(Mutex) Semaphores

Semaphore functionality (Mutex) represented pictorially in the following figure

Fig. 12: A Diagram Showing Architecture of Semaphore Functionality

· 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 receive messages 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.

Fig. 13: A Diagram Showing Flow of a Message Queue in 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.

D) Memory Management

Two types of memory managements are provided in RTOS – Stack and Heap.

Stack management is used during context switching for TCBs. Memory other than 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.

E) Timer Management

Tasks need to be performed after scheduled durations. To keep track of the delays, timers- relative and absolute- are provided in RTOS.

F) Interrupt and event handling

RTOS provides various functions for interrupt and event handling, viz., Defining interrupt handler, creation and deletion of ISR, referencing the state of an ISR, enabling and disabling of an interrupt, etc. It also restricts interrupts from occurring when modifying a data structure, minimise interrupt latencies due to disabling of interrupts when RTOS is performing critical operations, minimises interrupt response times.

G) Device I/O Management

RTOS generally provides large number of APIs to support diverse hardware device drivers.

Popular RTOS

POPULAR RTOS

There are number of commercially available RTOS, each with some distinct features and targeted for a specific set of applications. Following table lists some of the widely used commercially available RTOS.

RTOS	Applications/Features
Windows CE	· Used for Small footprint, mobile and connected devices · Supported by ARM,MIPS, SH4 & x86 architectures
LynxOS	· Complex, hard real-time applications · POSIX-compatible, multiprocess, multithreaded OS. · Supported by x86, ARM, PowerPC architectures
VxWorks	· Most widely adopted RTOS in the embedded industry. · Used in famous NASA rover robots Spirit and Opportunity · Certi?ed by several agencies and international standards for real time systems, reliability and security-critical applications.
Micrium µC/OS-II	· Ported to more than a hundred architectures including x86, mainly used in microcontrollers with low resources. · certi?ed by rigorous standards, such as RTCADO-178B
QNX	· Most traditional RTOS in the market. · Microkernel architecture; completely compatible with the POSIX · Certi?ed by FAADO-278 and MIL-STD-1553 standards.
RT Linux	· Hard realtime kernel · Good real time performance, but no certification
Jbed	· Developed for embedded systems and Internet applications under the Java platform. · Allows an entire application including the device drivers to be written using Java
Symbian	· Designed for Smartphones · Supported by ARM, x86 architecture
VRTX	· Suitable for traditional board based embedded systems and SoC architectures · Supported by ARM, MIPS, PowerPC & other RISC architectures