1 ee514 – real-time computing basic concepts on real-time systems ee514 – real-time computing...

1 EE514 – Real-Time Computing Basic Concepts on Real-Time Systems

EE514 – Real-Time Computing

Basic Concepts of

Real-Time Systems

Department of Electrical Engineering

The Hong Kong Polytechnic University

2 EE514 – Real-Time Computing

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.

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.



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.



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.



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 high-speed 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.



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.



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.



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.



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.



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


A Computer System Consists of …


The Operating System Zoo

• Mainframe operating systems

• Server operating systems

• Multiprocessor operating systems

• Personal computer operating systems

• Real-time operating systems

• Embedded operating systems

• Smart phone/card operating systems

Scale

Real-timeSystems


Real-Time / Embedded Operating Systems

Hardware

Operating

System

User Programs

Typical OS Configuration

Hardware

Including Operating

System Components

User Program

Typical Embedded Configuration

Hardware

Operating

System

User Programs


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.

Kernel

Other layers

Hardware

User Programs


Kernel Hierarchy

Users

User interface shell, NetworkingFile management, Security

OperatingSystem

Memory managementFile and disk support

Executive

Inter-processor communicationand synchronization

Kernel

Tasking scheduling Micro-kernel

Thread/task control blockmanagement

Nano-kernel

HardwareComplexity

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


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


Concept of Process and Thread

One process,one thread (MS-DOS)

One process,multiple threads (Java Runtime)

Multiple processes,multiple threads (W2K, Solaris, Linux)

Multiple processes,one thread per process (Unix)

• Process or task : Resource ownership

• Thread or Light Weight Process : Scheduling/execution

process

thread


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.


Single-Threaded & Multithreaded Process Model

User stack

Kernel stack

Process control block

User address space

Single-Thread Process Model

User stack

Kernel stack

Process control block

User address space

Single-Thread Process Model

Thread Thread Thread

User stack

Kernel stack

User stack

Kernel stack


Event-Driven System (..1)

• Any occurrence that causes the program counter to change non-sequentially is considered a change of flow-of-control, 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:


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.


Polled Loop System

• The simplest real-time kernel – single task only

• Allow for fast response to single devices but can’t 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

• Pros:‑ 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


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 CPU’s 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 (;;) { /* do forever */if (packet_here) /* check flag */{process_data(); /* process data */packet_here=0; /* reset flag */}

}


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.


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 (;;) { /* do forever */if (flag) /* check flag */{

pause(20); /* wait for 20ms */process_data(); /* process data */flag=0; /* reset flag */

}}

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


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


Cyclic Executives (Cont’)

• Different rate structures can be achieved by repeating a process in the list as below:

for (;;) { for (;;) {Process_1(); check_user_input();Process_2(); do_flight_simulation();Process_3(); check_user_input();

Process_3(); 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.

Example


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.


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;



}


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.


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.

• 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).

• Normally, interrupts are disabled during the critical context-switching period.


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.


Stack Model - Example

save() - saving of registers to a stack

restore() - restores those registers from the stack

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


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.


Round-Robin System - Time slicing of 3 tasks


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 round-robin 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.


Preemptive Scheduling


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.


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 pilot’s display every second has lowest priority.


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) dobegin process_a;

process_b; process_a process_c; process_a; process_b process_a; process_d;

end

Here, process_a runs 4 times more often than process_c or process_d and twice as often as process_b.

Major cycle: abacabad

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


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 round-robin 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.


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.


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.


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.


What makes an OS as RTOS

• An RTOS has to be multi-tasking and preemptible

• The notion of task priority has to exist

• The OS has to support task synchronization mechanisms

• A system of priority inheritance has to exist

• System should be deterministic



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



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)


1 ee514 – real-time computing basic concepts on real-time systems ee514 – real-time computing...

Documents