What is a Real-Time Operating System (RTOS)?

177 ratings | 3.51 out of 5 Read in | Print | PDF

Overview
This paper explains what a real-time operating system (RTOS) is, how real-time operating systems are useful for measurement and control applications, and how they differ from standard general-purpose operating systems like Windows.

Table of Contents
1. Introduction to Real-Time Operating Systems 2. Example Real-Time Applications 3. Under the Hood: How Real-Time OSs Differ from General-Purpose OSs 4. Next Step

Introduction to Real-Time Operating Systems

The sections below outline basic concepts and terminology related to real-time operating systems. After you have read through this paper, it is recommended that you visit Advantages of NI Real-Time Technology next to learn more about how National Instruments hardware and software can help you build a superior real-time system in as little time as possible.

What is a Real-Time OS?

In general, an operating system (OS) is responsible for managing the hardware resources of a computer and hosting applications that run on the computer. An RTOS performs these tasks, but is also specially designed to run applications with very precise timing and a high degree of reliability. This can be especially important in measurement and automation systems where downtime is costly or a program delay could cause a safety hazard. To be considered "real-time", an operating system must have a known maximum time for each of the operations that it performs (or at least be able to guarantee that maximum most of the time). Some of these operations include OS calls and interrupt handling. Operating systems that can absolutely guarantee a maximum time for these operations are referred to as "hard real-time", while operating systems that can only guarantee a maximum most of the time are referred to as "soft real-time". To fully grasp these concepts, it is helpful to consider an example. Imagine that you are designing an airbag system for a new model of car. In this case, a small error in timing (causing the airbag to deploy too early or too late) could be catastrophic and cause injury. Therefore, a hard real-time system is needed. On the other hand, if you were to design a mobile phone that received streaming video, it may be ok to lose a small amount of data occasionally even though on average it is important to keep up with the video stream. For this application, a soft real-time operating system may suffice. The main point is that, if programmed correctly, an RTOS can guarantee that a program will run with very consistent timing. Real-time operating systems do this by providing programmers with

a high degree of control over how tasks are prioritized, and typically also allow checking to make sure that important deadlines are met. In contrast to real-time operating systems, the most popular operating systems for personal computer use (such as Windows) are called general-purpose operating systems. While more indepth technical information on how real-time operating systems differ from general-purpose operating systems is given in a section below, it is important to remember that there are advantages and disadvantages to both types of OS. Operating systems like Windows are designed to smoothly run many programs and services at once, while real-time operating systems are typically designed to run one application very reliably and with precise timing.

Important Terminology and Concepts

Determinism: An application (or critical piece of an application) that runs on a hard real-time operating system is referred to as deterministic if its timing can be guaranteed within a certain margin of error. Soft vs Hard Real-Time: An OS that can absolutely guarantee a maximum time for the operations it performs is referred to as hard real-time. In contrast, an OS that can usually perform operations in a certain time is referred to as soft real-time. Jitter: The amount of error in the timing of a task over subsequent iterations of a program or loop is referred to as jitter. Real-time operating systems are optimized to provide a low amount of jitter when programmed correctly; a task will take very close to the same amount of time to execute each time it is run.

Figure 1. Jitter is a measure of how much the execution time of a task differs over subsequent iterations. Real-time operating systems are optimized to minimize jitter.

Example Real-Time Applications

Real-time operating systems were designed for two general classes of applications: event response and closed-loop control. Event response applications, such as automated visual inspection of assembly line parts, require a response to a stimulus in a certain amount of time. In this visual inspection system, for example, each part must be photographed and analyzed before the assembly line moves.

By carefully programming an application that runs on a hard real-time operating system, designers working on event response applications can guarantee that a response will happen deterministically (within a certain maximum amount of time). Considering the parts inspection example, using a general-purpose OS could result in a part not being inspected in time - therefore delaying the assembly line, forcing the part to be discarded, or shipping a potentially defective part. In contrast, closed-loop control systems, such as an automotive cruise control system, continuously process feedback data to adjust one or more outputs. Because each output value depends on processing the input data in a fixed amount of time, it is critical that loop deadlines are met in order to assure that the correct outputs are produced. What would happen if a cruise control system failed to determine what the throttle setting should be at a given point in time? Once again, hard real-time operating systems can guarantee that control system input data is processed in a consistent amount of time (with a fixed worst-case maximum). It should also be noted that many applications that must run for extended periods of time can benefit from the reliability that an RTOS can provide. Because real-time operating systems typically run a minimal set of software rather than many applications and processes at the same time, they are well suited for systems that require 24-7 operation or where down-time is unacceptable or expensive. If you are considering using an RTOS for an upcoming project, see the paper: Do I Need a RealTime System?

Under the Hood: How Real-Time OSs Differ from GeneralPurpose OSs
Operating systems such as Microsoft Windows and Mac OS can provide an excellent platform for developing and running your non-critical measurement and control applications. However, these operating systems are designed for different use cases than real-time operating systems, and are not the ideal platform for running applications that require precise timing or extended uptime. This section will identify some of the major under-the-hood differences between both types of operating systems, and explain what you can expect when programming a real-time application.

Setting Priorities
When programming an application, most operating systems (of any type) allow the programmer to specify a priority for the overall application and even for different tasks within the application (threads). These priorities serve as a signal to the OS, dictating which operations the designer feels are most important. The goal is that if two or more tasks are ready to run at the same time, the OS will run the task with the higher priority. In practice, general-purpose operating systems do not always follow these programmed priorities strictly. Because general-purpose operating systems are optimized to run a variety of applications and processes simultaneously, they typically work to make sure that all tasks receive at least some processing time. As a result, low-priority tasks may in some cases have their priority boosted above other higher priority tasks. This ensures some amount of run-time for each task, but means that the designer's wishes are not always followed. In contrast, real-time operating systems follow the programmer's priorities much more strictly. On most real-time operating systems, if a high priority task is using 100% of the processor, no other lower priority tasks will run until the high priority task finishes. Therefore, real-time

system designers must program their applications carefully with priorities in mind. In a typical real-time application, a designer will place time-critical code (e.g. event response or control code) in one section with a very high priority. Other less-important code such as logging to disk or network communication may be combined in a section with a lower priority.

Interrupt Latency
Interrupt latency is measured as the amount of time between when a device generates an interrupt and when that device is serviced. While general-purpose operating systems may take a variable amount of time to respond to a given interrupt, real-time operating systems must guarantee that all interrupts will be serviced within a certain maximum amount of time. In other words, the interrupt latency of real-time operating systems must be bounded.

Performance
One common misconception is that real-time operating systems have better performance than other general-purpose operating systems. While real-time operating systems may provide better performance in some cases due to less multitasking between applications and services, this is not a rule. Actual application performance will depend on CPU speed, memory architecture, program characteristics, and more. 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 operating systems.