Real time Systems & Common Operating System vs.

vs. Real time Operating System


Mr. Sandeep Delwadkar
Lecturer, SRIMCA

Introduction

To most people, embedded systems are not recognizable as computers. Instead, they are hidden inside everyday objects that surround us and help us in our lives. Embedded systems typically do not interface with the outside world through familiar personal computer interface devices such as a mouse, keyboard and graphic user interface. Instead, they interface with the outside world through unusual interfaces such as sensors, actuators and specialized communication links.

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 are Real-time Systems?

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.

Types of Real Time Systems

Based on Hard deadline:

Penalty due to missing deadline is a higher order of magnitude than the Reward in meeting the deadline.

Based on Soft deadline:

Penalty often equal / lesser magnitude than Reward.

RTOSs vs. general-purpose operating systems

Many non-real-time operating systems also provide similar kernel services. The key difference between general-computing operating systems and real-time operating systems is the need for "deterministic " timing behavior in the real-time operating systems. Formally, "deterministic" timing means that operating system services consume only known and expected amounts of time. In theory, these service times could be expressed as mathematical formulas. These formulas must be strictly algebraic and not include any random timing components. Random elements in service times could cause random delays in application software and could then make the application randomly miss real-time deadlines? A scenario clearly unacceptable for a real-time embedded system.

General-computing non-real-time operating systems are often quite non-deterministic. Their services can inject random delays into application software and thus cause slow responsiveness of an application at unexpected times. If you ask the developer of a non-real-time operating system for the algebraic formula describing the timing behavior of one of its services (such as sending a message from task to task), you will invariably not get an algebraic formula. Instead the developer of the non-real-time operating system (such as Windows, UNIX or Linux) will just give you a puzzled look. Deterministic timing behavior was simply not a design goal for these general-computing operating systems.

On the other hand, real-time operating systems often go a step beyond basic determinism. For most kernel services, these operating systems offer constant load-independent timing: In other words, the algebraic formula is as simple as: T(message send) = constant , irrespective of the length of the message to be sent, or other factors such as the numbers of tasks and queues and messages being managed by the RTOS.

RTOS KERNEL

RTOS Kernel provides an Abstraction layer that hides from application software the hardware details of the processor / set of processors upon which the application software shall run.



Figure 1: An RTOS Kernel provides an Abstraction Layer between Application Software and Embedded Hardware


Figure 2: Basic Services Provided by a Real-Time Operating System Kernel

Task Management

  1. Set of services used to allow application software developers to design their software as a number of separate chunks of software each handling a distinct topic, a distinct goal, and sometimes its own real-time deadline.
  2. Main service offered is Task Scheduling
    1. Controls the execution of application software tasks
    2. Can make them run in a very timely and responsive fashion.

Task Scheduling

  1. Non Real -time systems usually use Non-preemptive Scheduling
    1. Once a task starts executing, it completes its full execution
  2. Most RTOS perform priority-based preemptive task scheduling.
  3. Basic rules for priority based preemptive task scheduling
    1. The Highest Priority Task that is ready to Run will be the Task that must be running.

Priority based Preemptive Task Scheduling

  1. Every Task in a software application is assigned a priority.
  2. Higher Priority = Higher Need for Quick Response.
  3. Follows nested preemption

Nested Preemption


Figure 3: Timeline for Priority-based Preemptive Scheduling Examples

Task Switch

  1. Each time the priority-based preemptive scheduler is alerted by an External world trigger / Software trigger it shall go through the following steps that constitute a Task Switch:
    1. Determine whether the currently running task should continue to run.
    2. Determine which task should run next.
    3. Save the environment of the task that was stopped (so it can continue later).
    4. Set up the running environment of the task that will run next.
    5. Allow the selected task to run.
    6. A Non Real time operating system might do task switching only at timer tick times.
    7. Even with preemptive schedulers a large array of tasks is searched before a task switch.
    8. A Real time OS shall use incrementally arranged tables to save on time.

Inter-Task communication & Synchronization

  1. These services make it possible to pass information from one task to another without information ever being damaged.
  2. Makes it possible for tasks to coordinate & productively cooperate with each other.
  3. The most important communication b/w tasks in an OS are the passing of data from one task to another.


Figure 4: Inter task Message Communication

  1. If messages are sent more quickly than they can be handled, the OS provides message queues for holding the messages until they can be processed.

Message passing in Common OS

Most General Purpose OS actually copy messages twice as they transfer them from task to task via a message queue.



Figure 5: Message passing in Common OS

Message passing in RTOS


Figure 6: Message passing in RTOS

Dynamic Memory Allocation in Common OS

  1. Non-real-time operating systems offer memory allocation services from what is termed a Heap.
  2. Heaps suffer from a phenomenon called External Memory Fragmentation.
  3. Fragmentation problem is solved by Garbage collection / Defragmentation.
  4. Garbage collection algorithms are often wildly non-deterministic.

Dynamic Memory Allocation in RTOS

  1. RTOS does it by a mechanism known as Pools.
  2. Pools memory allocation mechanism allows application software to allocate chunks of memory of 4 to 8 different buffer sizes per pool.
  3. Pools avoid external memory fragmentation, by not permitting a buffer that is returned to the pool to be broken into smaller buffers in the future.
  4. When a buffer is returned the pool, it is put onto a free buffer list of buffers of its own size that are available for future re-use at their original buffer size.

Summary

Real-time and embedded systems are used in many applications such as airborne computers, medical instruments and communication systems. Embedded systems are characterized by limited processor memory, limited processing power, and unusual interfaces to the outside world. Real-time requirements impose stringent time deadlines for delivering the results of embedded processing.

RTOS kernels hide from application software the low-level details of system hardware, and at the same time provide several categories of services to application software. These include: task management with priority-based preemptive scheduling, reliable inter task communication and synchronization, non-fragmenting dynamic memory allocation, and basic timer services.

The issue of timing determinism is important in differentiating general-computing operating systems from real-time operating systems. This issue crops up in many parts of operating system kernels, such as task schedulers, dynamic memory allocation and inter task message communication. While general-computing operating systems often offer non-deterministic services in these areas, fully deterministic solutions are needed for real-time and embedded systems. A number of real-time operating systems implement these solutions in their compact high-performance kernels.


Back To Content