EE514 Real-Time Computing

Basic Concepts of
Real-Time Systems
Department of Electrical Engineering
The Hong Kong Polytechnic University
EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

Real-Time Application

A real-time application is an application where the

correctness of the application depends on the timeliness
and predictability of the application as well as the results
of computations.

Real-time applications are becoming increasingly

important in our daily lives and can be found in various
environments such as automotive applications, medical
equipment, aircraft control, nuclear plant, etc.

Real-time applications provide an action or an answer to

an external event in a timely and predictable manner.

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

Real-Time Application - Timeliness

While many real-time applications require high-speed

compute power, real-time applications cover a wide
range of tasks with differing time dependencies.

Timeliness has a different definition in each real-time

application. What may be fast in one application may be
slow or late in another.
For example, a vehicle engine control needs to collect data and
control actuators with microseconds accuracy, while a scientist
monitoring the air pressure might need to collect data in intervals
of several minutes. The success of both applications depends on
well-defined time requirements.

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

Real-Time Application - Predictability

The concept of predictability may vary from field of

operation, but for real-time applications it generally means
that a task or set of tasks can always be completed within
a predetermined amount of time.

Depending on the situation, an unpredictable real-time

application can result in loss of data, loss of deadlines, or
loss of plant production.

Examples of real-time applications include process control,

factory automation robotics, vehicle simulation, scientific
data acquisition, image processing, built-in test equipment,
music or voice synthesis, and analysis of high-energy
physics.

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

Worst-case vs Average Time

To have control over the predictability of an application,

the programmer must understand which time bounds are
significant.
For example, an understanding of the average time it takes for a
context switch does not guarantee task completion within a
predictable timeframe.

Real-time programmers must know the worst-case time

requirements so that they can design an application that
will always meet worst-case deadlines.
It can be argued that all computing systems are real-time,
because they all have limitations on the execution of a particular
job. Therefore, real-time applications can be further classified as
either hard or soft real-time.

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

Hard Real-Time

Hard real-time applications require a response to events

within a predetermined amount of time for the application
to function properly.
If a hard real-time application fails to meet specified deadlines,
the application fails.

While many hard real-time applications require highspeed responses, the granularity of the timing is not the
central issue in a hard real-time application.
An example of a hard real-time application is a missile guidance
control system where a late response to a needed correction
leads to disaster.

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

Soft Real-Time

Soft real-time applications do not fail if a deadline is

missed.

Some soft real-time applications can process large

amounts of data or require a very fast response time, but
the key issue is whether or not meeting timing constraints
is a condition for success.
An example of a soft real-time application is an airline reservation
system where an occasional delay is tolerable, but unwanted.

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

High-performance I/O (..1)

Many real-time applications require high I/O throughput

and fast response time to asynchronous external events.
The ability to process and store large amounts of data is a key
metric for data collection applications.

Real-time applications that require high I/O throughput rely on

continuous processing of large amounts of data.

For some applications, the throughput requirements on a

single channel are modest. However, an application may
need to handle multiple data channels simultaneously,
resulting in a high aggregate throughput.
Real-time applications, such as medical diagnosis systems, need a
response time of about one second while simultaneously handling
data from, perhaps, ten external sources.

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

High-performance I/O (..2)

Another key metric for some real-time applications is the

speed at which the application responds to asynchronous
external events and its ability to schedule and provide
communication among multiple tasks.
Real-time applications must capture input parameters, perform
decision-making operations, and compute updated output parameters
within a given timeframe.

Some real-time applications may require a response time of

microseconds while simultaneously handling data from a
large number of external sources.
Flight simulation program needs to acquire several hundred input
parameters from the cockpit controls, compute updated position,
orientation and speed, and then send several hundred output
parameters to the cockpit console and a visual display subsystem.

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

Real-Time Operating System Fundamentals

Embedded systems are not recognizable as computers.

Instead, they are hidden inside everyday objects that
surround us and help us in our lives.

Real-time and embedded systems operate in constrained

environments in which computer memory and processing
power are limited.

They often need to provide their services within strict

time deadlines to their users and to the surrounding
world. It is these memory, speed and timing constraints
that dictate the use of real-time operating systems in
embedded software.

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

10

What is an Operating System Anyway ?

An operating system is primarily a resource manager,

and the primary resource it manages is computer
hardware. It provides many features including

Defining the user interface

Sharing the hardware among users
Allowing users to share data among themselves
Scheduling resources among users
Facilitating input/output
Recovering from errors

It is an extended machine
Hides the messy details which must be performed
Presents user with a virtual machine, easier to use

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

11

A Computer System Consists of

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

12

The Operating System Zoo

Scale

Mainframe operating systems

Server operating systems
Multiprocessor operating systems
Personal computer operating systems
Real-time operating systems
Embedded operating systems

Real-time
Systems

Smart phone/card operating systems

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

13

Real-Time / Embedded Operating Systems

User Programs

User Program

Operating

Including Operating

Hardware

Hardware

System

Typical OS Configuration

EE514 Real-Time Computing

System Components

Typical Embedded Configuration

Basic Concepts on Real-Time Systems

14

What is a Kernel?

A kernel, executive or nucleus is the smallest

portion of the operating system that provides for

task scheduling, dispatching, and inter-task
communication.

In embedded systems, the

kernel essentially represents

the entire real-time system
but the device drivers.

User Programs

Hardware

Kernel
Other layers
EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

15

Kernel Hierarchy
Kernel can be further broken down into smaller modules
including executive, kernel micro-kernel, nano-kernel.
Users

Complexity
EE514 Real-Time Computing

User interface shell, Networking

File management, Security

Operating
System

Memory management
File and disk support

Executive

Inter-processor communication
and synchronization

Kernel

Tasking scheduling

Micro-kernel

Thread/task control block

management

Nano-kernel

Hardware
Basic Concepts on Real-Time Systems

16

Real-Time Kernel

Here we will examine the strategies employed in

the design of real-time kernel, and

concentrate on the following aspects:

Task scheduling and dispatching
Intertask communication and synchronization
Real-time memory management

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

17

Concept of Process and Thread

Process or task : Resource ownership

Thread or Light Weight Process : Scheduling/execution
process
thread

One process,
one thread (MS-DOS)

Multiple processes,
one thread per process (Unix)
EE514 Real-Time Computing

One process,
multiple threads (Java Runtime)

Multiple processes,
multiple threads (W2K, Solaris, Linux)
Basic Concepts on Real-Time Systems

18

Concept of Process and Thread (cont)

In a multithreaded environment, the followings are

associated with a process:
Address space to hold the process image
Protected access to processors, other processes (IPC), files, and
I/O resources (devices & channels)

Within a process, there may be one or more threads,

each with the following:
A thread execution state (Running, Ready, etc)
A saved context when not running a separate program counter
An execution stack
Some static storage for local variables for this thread
Access to memory and resources of its process, global variables.

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

19

Single-Threaded & Multithreaded Process Model

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

20

Event-Driven System (..1)

Any occurrence that causes the program counter to

change non-sequentially is considered a change of flow-ofcontrol, and thus an event.

In real-time systems, we have to determine the type of

events that has to be executed, and the flow of these
events:

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

21

Event-Driven System (..2)

The release time is the time at which an instance of a

scheduled task is ready to run, and is generally associated
with an interrupt.

In scheduling theory, the release time of a task is similar to

an event.

Event types:
Synchronous events are those events that occur at predictable
times.

Asynchronous events occur at unpredictable times at regular

intervals.

Periodic events are those that occur at fixed intervals.

Aperiodic events are irregularly timed events.
EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

22

Polled Loop System

The simplest real-time kernel single task only

Pros:

Allow for fast response to single devices but cant do much else
Work well when
a single processor is dedicated to handling the I/O for some fast device
overlapping of events is not allowed or is kept to a minimum
simple to write and debug
response time is easy to determine

Cons:
often fail because of bursting of events
not sufficient to handle complicated system
inherently waste CPU time

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

23

Polled Loop System - Example

A software system is needed to handle packets of data that

arrive at a rate of no more than 1 packet per second.

A flag named packet_here is set by the network, which

writes the data into the CPUs memory via direct memory
access (DMA).

The data are available when packet_here = 1.

A polled loop can be used to handle such system.
for (;;) {
if (packet_here)
{
process_data();
packet_here=0;
}

/* do forever
/* check flag

/* process data */
/* reset flag
*/

}
EE514 Real-Time Computing

*/
*/

Basic Concepts on Real-Time Systems

24

Synchronized Polled Loop

A variation on the polled loop uses a fixed clock interrupt

to pause between the time when the signaling event is
triggered and then reset. Such a system is used to treat
events that exhibit switch bounce.
Switch bounce is a phenomenon that occurs because it is impossible
to build a switch that can change state instantaneously.

Here is a typical response

of a switch.

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

25

Synchronized Polled Loop - Example

A polled-loop system is used to handle an event that occurs

randomly, but no more than once per second. The event is
known to exhibit a switch-bounce effect lasted for 20 ms.

A 10 ms fixed-rate interrupt is available for synchronization.

The event is signaled by an external device that sets a
memory location via DMA.
for (;;) {
if (flag)
{
pause(20);
process_data();
flag=0;
}

/* do forever
/* check flag

*/
*/

/* wait for 20ms */

/* process data */
/* reset flag
*/

where pause(20) is a system timer call that provides a 20ms delay.

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

26

Cyclic Executives

Cyclic executives are noninterrupt-driven systems that can

provide the illusion of simultaneity by taking advantage of
relatively short processes on a fast processor in continuous
loop.

Consider the following set of self-contained processes in a

continuous loop:
for (;;) {
Process_1();
Process_2();
...
Process_N();
}

In this case, a de facto cycle rate is established, which is the

same for each process, as they execute in a round-robin.
EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

27

Cyclic Executives (Cont)

Different rate structures can be achieved by repeating a process

in the list as below:
for (;;) {
Process_1();
Process_2();
Process_3();
Process_3();
}

Example
for (;;) {
check_user_input();
do_flight_simulation();
check_user_input();
do_screen_update();
}

where Process 3 runs twice as frequently as Process 1 and 2.

The process list can be made adjustable by keeping a list of

pointers to the process functions and manage by the OS as
tasks are created and completed. Intertask synchronization
and communication can be implemented via global variables or
parameter lists.

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

28

State-Driven Code

It uses nested if-then statements, case statements, or a

finite state automata (FSA) to break up the processing of
a function into discrete code segments.

This allows the code segments to be temporarily suspended

before completion, without loss of critical data.

A good example is the network packet handler which is

often broken up into phases within a communications
program.

For complex systems, table-driven code is more efficient

and hence preferable. Often they are used in conjunction
with polled loops for the testing of the first state flag.

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

29

State-Driven Code - Example

There is a simple process consisted of 3 states.

At the end state, a flag is set and the process is terminated.
Upon restarting, the process resumes where it left off.
switch (flag) {
case 1: perform_part_1(); /do state 1 processing */
flag = 2;
break;
case 2: perform_part_2(); /do state 2 processing */
flag = 3;
break;
case 3: perform_part_3(); /do state 3 processing */
flag = 1;
break;
}

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

30

Interrupt Driven Systems

The various tasks in the system are scheduled via either

hardware or software interrupts, whereas dispatching is
performed by the interrupt-handling routines.

Interrupts may occur at fixed rates (fixed-rate systems),

aperiodically (sporadic systems), or both (hybrid
systems).

Upon switching tasks, a snapshot of the machine, called

the context, must be preserved upon so that it can be
restored upon reinitiating the interrupted process.

The context includes: (1) registers, (2) program counter,

and (3) other entities that could be altered by another
process.

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

31

Context Switching

This is the most important part of the real-time operation

of the interrupt driven system.

It is the process of saving and restoring sufficient

information for a real-time task so that it can be resumed
after being interrupted.

The context is ordinarily saved to a stack data structure.

Normally, interrupts are disabled during the critical

context-switching period.

Context switching time is a major contributor to response

times and is a factor that we strive to minimize (i.e. save
the minimum amount of information necessary to safely
restore any process after it has been interrupted).

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

32

Stack Model

The stack model for context switching is used mostly in

embedded system where the number of real-time or
interrupt-driven tasks is fixed.

Context is saved by the interrupt handler.

In this model, each interrupt handler is associated with a

hardware interrupt and is invoked by the CPU via the
interrupt vectors.

The context is saved to a specially designated memory

area that can be static for a single-interrupt system or a
stack for a multi-interrupt system.

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

33

Stack Model - Example

Consider the following code for a partial real-time system

consisting of a simple jump-to-self and three interrupt
handlers, which saves context using the stack model.

save()
- saving of registers to a stack
restore()
- restores those registers from
the stack

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

34

Round-Robin Systems

Several processes are executed sequentially to completion,

often in conjunction with a cyclic executive.

In round-robin systems with time-slicing, each executable task is

assigned a fixed-time quantum (e.g.10ms) called a time slice in
which to execute.

A fixed-rate clock is used to initiate an interrupt at a rate

corresponding to the time slice.

The task executes until it completes or its execution time

expires.

If the task does not execute to completion, its context must be

saved. The task is then placed at the end of the executable list.
The context of the next executable task in the list is restored,
and it resumes execution.

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

35

Round-Robin System - Time slicing of 3 tasks

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

36

Preemptive Priority Systems

A higher-priority task is said to preempt a lower-priority

task if it interrupts the lower-priority task.

Systems that use preemptive schemes instead of roundrobin or first-come-first-serve scheduling are called
preemptive priority systems.

The priorities assigned to each interrupt are based on the

urgency of the task associated with that interrupt.

Prioritized interrupts can be either fixed priority or

dynamic priority.

Preemptive priority schemes can lead to the hogging of

resources by higher priority tasks lower-priority tasks
have the problem of starvation.

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

37

Preemptive Scheduling

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

38

Preemptive Priority Systems 2 Examples

Fixed priority system the nuclear power station

monitoring system.
While the handling of intruder events is critical, nothing is more
important than processing the core over-temperature alert.

Dynamic priority system threat-management systems

of military aircrafts.
Upto 6 enemy aircrafts can be tracked by dynamic-prioritized
processes. The relative threat of each enemy aircraft is
recomputed at fixed rate based on proximity, posture, and other
factors. The priority of each process managing the individual
threat is then readjusted.

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

39

Rate-Monotonic Systems

Rate-monotonic systems are special class of fixed-rated

preemptive priority interrupt driven system where the
priorities are assigned so that higher the execution
frequency, the higher the priority.

This scheme is common in embedded applications,

particular avionics systems, e.g. in aircraft navigation
system:
the task that gathers accelerometer data every 5 ms has highest

priority
The task that collects gyro data, and compensates these data
and the accelerometer data every 40ms has the 2nd highest
priority.
The task that updates the pilots display every second has lowest
priority.

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

40

Major and Minor Cycles

This is a common terminology applied to tasks which

assign to run at specific frequencies (usually in periodic
systems but also in noninterrupt driven cyclic executives).
while (forever) do
begin
process_a;
process_b;
process_a
process_c;
process_a;
process_b
process_a;
process_d;
end

Major cycle: abacabad

Minor cycle: abac, abad, ab, ac, ad

Here, process_a runs 4 times more often than process_c or

process_d and twice as often as process_b.
EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

41

Hybrid Systems

Hybrid systems include interrupts that occur at both fixed

rates and sporadically.

The sporadic interrupts may be used to handle a critical

error that requires immediate attention, and thus have
highest priority. This type of system is common in
embedded application.

Another type of hybrid system is a combination of roundrobin and preemptive systems.

Tasks of higher priority can always preempt those of lower

priority. If two or more tasks of the same priority are ready
to run, they run in round-robin fashion.
EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

42

Foreground/Background Systems

An improvement over the interrupt-only systems in that the

dummy polled loop is replaced by useful code (background
process).

The most common solution for embedded applications which

involve a set of interrupt driven or real-time processes called the
foreground and a collection if noninterrupt driven process called
the background.

Foreground tasks: run in round-robin, preemptive priority, or

combination fashion.

Background tasks: fully preemptable by any foreground task

and represents the lowest priority task in the system.
Anything that is not time critical, e.g. CPU load monitor.
It is the lowest priority process which will always execute to completion
unless the system is time-overloaded.

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

43

Foreground/Background Systems (cont)

All real-time solutions are just special cases of the

foreground/background systems. For example

Polled loop a background only case

Phase-driven code a background only case
Interrupt only system foreground only case

Foreground/background systems represent a superset

of all the other real-time solutions discussed and are the
solution of choice for embedded real-time systems
because of their good response time with the use of
hardware scheduling.

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

44

Full-Featured Real-Time Operating Systems

The foreground/background solution can be extended to a

full-featured real-time operating system adding the additional
functions such as device drivers, networking support,
debugging tools, etc.

Using the same task scheduling approach: round-robin,

preemptive priority, or a combination of both schemes.

However, the task control block (TCB) model, rather than the
simple stack model, is most often used because the number of
real-time tasks is indeterminate and dynamic.

TCB model is the most popular method for implementing

commercial, full-feature, real-time operating systems because
the number of real-time tasks can be variable. The main
drawback is that when a large number of tasks are created,
the overhead of the scheduler can become significant.

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

45

What makes an OS as RTOS

An RTOS has to be multi-tasking and preemptible

A system of priority inheritance has to exist

The notion of task priority has to exist

The OS has to support task synchronization
mechanisms
System should be deterministic

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

46

How to choose RTOS

Factors to be considered

Support of your processor of choice

Portability to new processor
Scalability to match varied application requirement
Multiprocessor support
Extended services such network support
Standards/Portable Operating System Interface (POSIX)
compliance

Language support
Development environment
Licensing arrangements & price
EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

47

Case study Why Windows NT is not an

RTOS

An RTOS has to be multi-tasking and preemptible

(passed)

The notion of task priority has to exist

But has only few level of priority, therefore the

predictability is poor (failed)

The OS has to support task synchronization

mechanisms (passed)

A system of priority inheritance has to exist (failed)

System should be deterministic (failed)

EE514 Real-Time Computing

Basic Concepts on Real-Time Systems

48