08.

705 RTOS

Module 3

Real Time Kernels

To understand real-time kernel design and development, consider a simple real-time kernel called
DICK (DIdactic C Kernel)
DICK is written in C language, able to handle periodic and aperiodic tasks with explicitly time
constraints.
Structure of Real-Time Kernels
A kernel represents the innermost part of OS that is in direct connection with the hardware of the
physical machine.
The basic activities of kernel are:
1. Process management
2. Interrupt handling
3. Process synchronization.
Process management:
Primary service of OS.
Provides various supporting functions, such as process creation and termination, job scheduling,
dispatching, context switching, and other related activities.
Interrupt handling:
Provide service to the interrupt requests that may be generated by any peripheral device, such as
the keyboard, serial ports, analog-to-digital converters, etc.
It executes dedicated ISR.
In real-time system, it is integrated with scheduling mechanism.
Process synchronization and communication:
It provides synchronization and communication between processes via semaphore, messages,
queues, pipelines etc.
Hierarchical level structure of DICK:

1. Machine layer:
Lowest level and directly interact with hardware.
Written in assembly language.
Not visible to users.
Deals with context switching, interrupt handling, timer handling etc.

Department of ECE, VKCET

Page 1

08.705 RTOS

Module 3

2. List management layer:

Keep track the status of various tasks.
Manage the task according to its state.
Provide preemption to tasks.
3. Processor management layer:
Provides scheduling and dispatching operations.
4. Service layer:
Provides all services visible at the user level as a set of system calls.
Typical services concern task creation, task abortion, suspension of periodic instances,
activation and suspension of aperiodic instances, and system inquiry operations.
Process states
Kernel that supports the execution of concurrent activities on a single processor, where
semaphores are used for synchronization and mutual exclusion, there are at least three states in
which a task can enter:
1. RUNNING: Task enter into executing on the processor
2. READY: Task ready to executes, ready to execute but cannot be executed because the
processor is assigned to another task.
3. WAITING: Task enter into this state, when it is wait for an event, to take a semaphore, to
read a queue etc.
In a real-time kernel, to execute periodic tasks, another state must be considered called IDLE
state. A periodic job enters this state when it completes its execution and has to wait for the
beginning of the next period. Usually a periodic task is put into IDLE state by the system call for
end cycle and is awakened from it by the timer. The timer verifies, at each tick, whether some job
has to be awakened.
The state transition diagram relative to the four states are shown below:

An additional state introduced by other kernel services are:

1. DELAY: It suspends the task for a given interval of time and put it on a sleep state. The
task will awakened by the timer after the elapsed interval.
2. RECEIVE: It is for message passing. A task enter into this state when it executes a
receive primitive on an empty channel. The task exits from this state when a send
primitive is executed by another task on the same channel.
3. ZOMBIE: It is the state to kill the time. To keep the guarantee test consistent, the
utilization factor of an aborted task can be subtracted from the total load only at the end
of the current period. It is the interval of time between the abort operation and the end of

Department of ECE, VKCET

Page 2

08.705 RTOS

Module 3
its period. Such state does not exist in the system, but it continues to occupy processor
bandwidth. An illustration is shown below:

A more complete state transition diagram including all these states is illustrated below:

The state transition diagram in DICK is shown below:

Department of ECE, VKCET

Page 3

08.705 RTOS

Module 3

In DICK, RECEIVE and DELAY states are not present. It has SLEEP state which is used to
activate or sleep aperiodic tasks.
An aperiodic task enters the SLEEP state by executing the sleep primitive and a task exits the
SLEEP state and goes to the READY state only when an explicit activation is performed by
another task.
Data Structures:
TCB
The information about a task are stored in a data structure, called Task Control Block(TCB).
TCB contains all the parameters specified by the programmer at creation time, and other
temporary information necessary to the kernel for managing the task.
Typical fields of a TCB in real-time system are:

1. Task identifier: It is a character string used by the system to refer the task in messages to the
user,
2. Task address: The memory address corresponding to the first instruction of the task.
3. Task type: The task type (periodic, aperiodic, or sporadic).
4. Task criticalness: The task criticality (hard, soft, or non-real-time).
5. Task priority: The priority (or value), which represents the importance of the task with
respect to the other tasks of the application.
6. Task state: The current state (ready, running, idle, waiting, and so on).
7. Task computation time: The worst-case execution time ( Ci ).
8. The task period: The period of periodic task.
9. The relative deadline: The deadline specified by the user.
10. The absolute deadline: The absolute deadline computed by the kernel at the arrival time.
11. The task utilization factor (only for periodic tasks).
Department of ECE, VKCET

Page 4

08.705 RTOS

SCB

Module 3

12. A pointer to the process stack, where the context is stored.

13. A pointer to a directed acyclic graph (DAG), if there are precedence constraints.
14. A pointer to a list of shared resources, if a resource access protocol is provided by the kernel.
In DICK, a TCB is an element of the vdes[MAXPROC] array, whose size is equal to the
maximum number of tasks handled by the kernel.
Another data structure contains information concerning a semaphore is stored in a Semaphore
Control Block (SCB).
Which contains at least the following three fields :
1. A counter: Represents the value of the semaphore.
2. A queue: Enqueueing the tasks blocked on the semaphore.
3. A pointer: To point the next SCB, to form a list of free semaphores.

In DICK, SCB is an element of the vsem[MAXSEM] array, whose size is equal to the maximum
number of semaphores handled by the kernel.

Kernel Primitives
They are used for implementing the kernel services at different levels.
Different kernel primitives are:
1. Low level primitives
2. List management primitives
3. Scheduling mechanism primitives
4. Task management primitives
5. Semaphores primitives
6. Status enquiry primitives

Department of ECE, VKCET

Page 5

08.705 RTOS

Module 3

Low level primitives:

To implement the mechanism for saving and loading the context of a task, ie for values of
processor registers.
The primitives are save_context and load_context and there code are shown below:

Department of ECE, VKCET

Page 6

08.705 RTOS

Module 3

List management primitives:

Different list management primitive functions are insert, extract, getfirst, firstdline and empty.
insert: It insert a task in a queue based on its deadline. It is called with two parameters, the index of the
task to be inserted and pointer of the queue. It uses two auxiliary pointers p and q and its meaning is
illustrated below.

Department of ECE, VKCET

Page 7

08.705 RTOS

Module 3

extract: It extract a task from the queue. Its illustration is shown below:

getfirst: It extract a task from the head of the queue. Its illustration is shown below:

Department of ECE, VKCET

Page 8

08.705 RTOS

Module 3

firstdline: It returns the deadline of the first task. Its illustration is shown below:

empty: It returns TRUE, if a queue is empty. Its illustration is shown below:

Schedule management primitives:

The primitive functions for scheduling mechanisms in DICK are: schedule, dispatch and
wake_up.
schedule: It verifies whether the running task is the one with the earliest deadline. If so, there is no action,
otherwise the running task is inserted in the ready queue and first ready task is dispatched. Its illustration
is shown below:

Department of ECE, VKCET

Page 9

08.705 RTOS

Module 3

dispatch: It assigns the CPU to the first ready task. Its illustration is:

wake_up: It is the ISR performs the activities for time management. It increments the sys_clock variable,
checks for system lifetime and possible deadline misses, remove those tasks in zombie state and resume
those periodic tasks in idle state at the beginning of their next period. Its illustration is shown below:

Department of ECE, VKCET

Page 10

08.705 RTOS

Module 3

Task management primitives

It concerns creation, activation, suspension, and termination of tasks.
Different functions for primitives are: create, guarantee, activate, sleep, end_cycle, end_process
and kill.
create: It creates a task and put it in SLEEP state. Its illustration is shown below:

Department of ECE, VKCET

Page 11

08.705 RTOS

Module 3

guarantee: It guarantees the feasibility of a hard task. Its illustration is shown below:

activate: It inserts a task in the ready queue. Its illustration:

sleep: It suspends itself in a SLEEP state. Its illustration:

Department of ECE, VKCET

Page 12

08.705 RTOS

Module 3

end_cycle: It inserts a task in the IDLE queue. Its illustration:

end_process: It terminates the running task. Its illustration:

Department of ECE, VKCET

Page 13

08.705 RTOS

Module 3

kill: It terminates a task. Its illustration:

Semaphores primitives:
In DICK, synchronization and mutual exclusion are handled by semaphores.
There are four primitives are provided: newsem, delsem, wait and signal
newsem: It allocates a free semaphore control block and initializes the counter field to the value passed as
a parameter.
delsem: It deallocates the semaphore and inserting it in the list of free semaphores.
wait: It is used by a task to wait for an event associated with a semaphore. If the semaphore counter is
positive, it is decremented, and the task continues its execution; if the counter is less than or equal to zero,
the task is blocked, and it is inserted in the semaphore queue. In this case, the first ready task is assigned
to the processor by the dispatch primitive.
signal: It is used by a task to signal an event associated with a semaphore.
Status inquiry primitives:
These primitives are for inquiring the kernel about internal variables and task parameters.
get_time: It returns the system time in milliseconds.
get_state: It returns the state of a task.

Department of ECE, VKCET

Page 14

08.705 RTOS

Module 3

get_dline: It returns the deadline of a task

get_period: It returns the period of a task
Intertask Communication Mechanism:
Intertask communication is a critical issue in real-time systems
It is necessary to use the shared resources for implementing message passing and may cause
priority inversion and unbounded blocking on tasks execution.
There are two types of communication model: synchronous and asynchronous.
In pure synchronous communication model, whenever two tasks want to communicate they must
be synchronized for a message transfer to take place. This synchronization is called a rendezvous.
Thus, if the sender starts first, it must wait until the recipient receives the message; on the other
hand, if the recipient starts first, it must wait until the sender produces its message.
In a dynamic real-time system, synchronous communication results unpredictable behavior, due
to the difficulty of estimating the maximum blocking time for a process rendezvous.
In a static real-time environment, the problem can be solved off-line by transforming all
synchronous interactions into precedence constraints. According to this approach, each task is
decomposed into a number of subtasks that contain communication primitives not inside their
code but only at their boundary.
An example of a task decomposition is illustrated below:

In a pure asynchronous scheme, communicating tasks do not have to wait for each other. The
sender just deposits its message into a channel and continues its execution, independently of the
recipient condition.
Asynchronous communication schemes are more suitable for dynamic real-time systems.
In most commercial RTOS, the asynchronous communication scheme is implemented through a
mailbox mechanism as shown below:

Department of ECE, VKCET

Page 15

08.705 RTOS

Module 3

Two basic operations are provided on a mailbox: send and receive. A send(MX, mes) operation
causes the message mes to be inserted in the queue of mailbox MX. If at least a message is
contained on mailbox MX,a receive(MX, mes) operation extracts the first message from its
queue.
Mailbox provides only a partial solution to the problem of asynchronous communication, since it
has a bounded capacity. Thus, if the queue is full, the sender must be delayed until some message
is received. If the queue is empty, the receiver must wait until some message is inserted.
Cyclic Asynchronous Buffers (CAB)
Avoid the limitation of mailbox for asynchronous communication.
CAB provides a one-to-many communication channel, which at any instant contains the latest
message or data inserted in it.
A message is not consumed by a receiving process but is maintained into the CAB structure until
a new message is overwritten.
As a consequence, once the first message has been put in a CAB, a task can never be blocked
during a receive operation. Similarly, since a new message overwrites the old one, a sender can
never be blocked.
In this a message can be read more than once if the receiver is faster than the sender, while
messages can be lost if the sender is faster than the receiver. This is not a problem in many
control applications; where tasks are require current data rather than previous ones.
CAB primitives are: open_cab for create and initial CAB, delete_cab to remove a CAB from the
system and releases the memory space.
The data structure used to implement a CAB is shown below:

CAB control block contains: max_buf store maximum number of buffers, dim_buff
dimension of buffer, free a pointer to a list of free buffer and mrb pointer to recent buffer.
Each buffer in the CAB can be implemented as a data structure with three field: next a pointer
to maintain a list of free buffers, use stores the current number of task accessing that buffer and
data - a memory area for storing message.

Department of ECE, VKCET

Page 16

08.705 RTOS

Module 3

System overhead
The overhead of an OS represents the time used by the processor for handling all kernel
mechanisms, such as enqueueing tasks, performing context switches, updating the internal data
structures, sending messages to communication channels, servicing the interrupt requests, and so
on.
The time required to perform these operations is usually much smaller than the execution times of
the application tasks. So it can be negligible comparing to execution time of application tasks.
If execution time of tasks is very small and has tight timing constraints, then activities performed
by the kernel may not be so negligible and may create significant interference on the tasks
execution.
In such situations, predictability can be achieved only by considering the effects of the runtime
overhead in the schedulability analysis.
Different overhead factors are:
1. Context switching: One of the most significant overhead factors in any OS. It is an intrinsic
limit of the kernel that does not depend on the specific scheduling algorithm, nor on the
structure of the application tasks.
2. Execution time of ISR: It is another important overhead factor in real-time system. If Q is the
system tick (ie the period of the interrupt request from the timer) and is the worst-case
execution time of the ISR, then timer overhead can be computed as the utilization factor Ut of
an equivalent periodic task.

The illustration shows the execution interval due to the timer routine and execution
intervals necessary for a context switch.

The effect of ISR schedulability of a periodic task also takes for task utilization factor Ut.
The net bound of utilization factor becomes

Where Ulub is upper bound of the utilization factor.

This shows that Unet > 0, system tick Q always greater than /Ulub.

Department of ECE, VKCET

Page 17

08.705 RTOS

Module 3

The plot of Unet as a function of Q is shown below:

The overhead due to other kernel mechanisms can also be taken for the performance. It is like the
context switches during the execution of kernel primitives.
If Ni is the maximum number of preemptions that a periodic task of period Ti and is the time
needed to perform a context switch, the total utilization factor is given as,

Hence we can write

Where Up is the utilization factor of the periodic task set and Uov is a correction factor that
considers the effects of thr ISR and the preemption overhead due to context switches.
Case study of RTOS
QNX Neutrino 2 RTOS
It is commercial RTOS with very small kernels (micro kernel) with a memory footprint of a few
kilobytes
It provides support for concurrency through processes and/or threads.
Applications: Mission-critical applications like medical instruments, Internet routers, telematics
devices, process control applications, air traffic control systems etc.
QNX Neutrino microkernel implements only the most fundamental services in the kernel, such as
signals, timers, and scheduling.
All other components file systems, drivers, protocol stacks, applications run outside the kernel, in
a memory-protected user space. Due to this, a faulty component can be automatically restarted
without affecting other components or the kernel.
Some of the real-time features include distributed priority inheritance to eliminate priority
inversion and nested interrupts to allow priority driven interrupt handling.
All components communicate via message passing, which allows the user to dynamically plug in,
or plug out, any component during execution.
Department of ECE, VKCET

Page 18

08.705 RTOS

Module 3

It provides support for transparent distributed processing using standard messages to access
hardware and software resources on remote nodes.
QNX Neutrino also provides advanced graphics features to create visual applications for markets
such as automotive, medical, industrial automation and interactive gaming.
It also support accelerated 3D graphics allows for the creation of sophisticated displays with little
impact on CPU performance.
Micro C/OS II RTOS
COS stands Micro Controller OS. Also known as MUCOS or MicroCOS or UCOS.
Non-commercial use, freeware and available from Micrium.
It is a very small real-time kernel and requires only 20KB memory for a fully functional kernel.
Source code is written mostly in C.
Highly portable, ROMable, very scalable, preemptive real-time, deterministic, multitasking
kernel.
Applications: Automotive, avionics, consumer electronics, medical devices, military, aerospace,
networking, SoC development
An advantage of using this RTOS is full source code availability
It is simple to use and simple to implement but very effective compared to the price/performance
ratio.
It supports all type of processors from 8-bit to 64-bit.
MicroC/OS-II is the second generation of a kernel originally published (with source code)

Department of ECE, VKCET

Page 19