What is a Real-Time Operating System

(RTOS)?
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 in-depth 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 Real-Time System?

Under the Hood: How Real-Time OSs Differ from

General-Purpose 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 up-time. 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.

Next Step
Continue on to the following paper to learn how you can use NI hardware and software to

Reader Comments | Submit a comment »

Not all RTOS are single purpose

I agree with most of what is presented here but the statement "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." implies that RTOS do not support multiple simultaneous
applications. Elsewhere it is implied that RTOS do not support UIs. This is certainly not
true. The thousands of applications ( such as flight reservation or simulators ) for RTOS
such as QNX etc ) are multiasking, multiple application and UI centered. The better
statement might be that RTOS generally do not allow the user to easily add or subtract
applications or hardware. In my 30 some years of experience In industrial applications,
many companies will not allow Windows, or Linux applications to control any machine
process in which people or equipment could be damaged. So we agree high reliability and
precise timing, are hall marks of an RTOS. But there is no lack of ability to perform
multiple applications, or complex UI.
- donericb@gmail.com - Jan 16, 2010

Not all RTOS are single purpose

I agree with most of what is presented here but the statement "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." implies that RTOS do not support multiple simultaneous
applications. Elsewhere it is implied that RTOS do not support UIs. This is certainly not
true. The thousands of applications ( such as flight reservation or simulators ) for RTOS
such as QNX etc ) are multiasking, multiple application and UI centered. The better
statement might be that RTOS generally do not allow the user to easily add or subtract
applications or hardware. In my 30 some years of experience In industrial applications,
many companies will not allow Windows, or Linux applications to control any machine
process in which people or equipment could be damaged. So we agree high reliability and
precise timing, are hall marks of an RTOS. But there is no lack of ability to perform
multiple applications, or complex UI.
- don.baker@gmail.com - Jan 16, 2010

good intro
sir real good introduction about real time
- rv.g@rediffmail.com - Oct 9, 2008

Good Explanation of Real Time

This article successfully answers the question posed in its title: "What is Real Time?" I
would suggest a few additional paragraphs at the end to briefly explain the diffeent NI
software and hardware options for real time.
- Edward Grood, University of Cincinnati. ed.grood@uc.edu - Aug 2, 2008

No tutorial
How is this page a tutorial ? There's no code sample, no walk through on any NI
application. It's just some generic info on what a real-time OS is...
- Guillaume Dargaud, LPSC/IN2P3/CNRS. guillaume@gdargaud.net - Apr 5, 2007

not enough program examples

- j, b. - Jul 26, 2004

REAL time
sir, all the information present related RTOS very nice, i want text formate notes or cd.
regards meganathan
- Jun 28, 2003

Legal
This tutorial (this "tutorial") was developed by National Instruments ("NI"). Although
technical support of this tutorial may be made available by National Instruments, the
content in this tutorial may not be completely tested and verified, and NI does not
guarantee its quality in any way or that NI will continue to support this content with each
new revision of related products and drivers. THIS TUTORIAL IS PROVIDED "AS IS"
WITHOUT WARRANTY OF ANY KIND AND SUBJECT TO CERTAIN
RESTRICTIONS AS MORE SPECIFICALLY SET FORTH IN NI.COM'S TERMS OF
USE (http://ni.com/legal/termsofuse/unitedstates/us/).