How to Choose a Real-Time Operating System

Posted January 01, 2003

In the market for a commercial RTOS? This article provides an overview of RTOSes and how you can select the best one for your project.

Engineers often use the term "real time" to describe computing problems for which a late answer is as bad as a wrong one. These problems are said to have deadlines, and embedded systems frequently operate under such constraints. For example, if the embedded software that controls your anti-lock brakes misses one of its deadlines you might find yourself in an accident. So it's extremely important that the designers of real-time embedded systems know everything they can about the behavior and performance of their hardware and software.

Real-Time Systems

The designers of real-time systems spend a large portion of their time worrying about worst-case performance. They must constantly ask themselves questions like: what is the worst-case time between the human operator pressing the brake pedal and an interrupt signal arriving at the processor? What is the worst-case interrupt latency? And what is the worst-case time for the software to respond by triggering the braking mechanism? Average or expected-case analysis simply will not suffice.

Most of the commercial embedded operating systems available today are designed for possible inclusion in real-time systems. In the ideal case, their worst-case performance is well understood and documented. To earn the distinctive title "Real-Time Operating System" (RTOS), an operating system should be deterministic and have guaranteed worst-case interrupt latency and context-switch times. Given these characteristics and the relative priorities of the tasks and interrupts in your system, it is possible to analyze the worst-case performance of the software using a technique such as rate monotonic analysis.

An operating system is said to be deterministic if the worst-case execution time of each of its system calls is calculable. An operating system vendor that takes the real-time behavior of its product seriously will usually publish a datasheet providing the minimum, average, and maximum number of clock cycles required by each system call. These numbers may be different for different processors, but it is reasonable to expect that if the algorithm is deterministic on one processor it will be so on any other. (The actual times may differ, however.)

Interrupt latency is the total length of time from an interrupt signal arriving at the processor to the start of the associated interrupt service routine (ISR). When an interrupt occurs, the processor must take several steps before executing the ISR. First, the processor must finish executing the current instruction. Next, the interrupt type must be recognized. This is done by the hardware and does not slow or suspend the running task. Finally, and only if interrupts are enabled, the CPU's context is saved and the ISR associated with the interrupt is started.

Of course, if interrupts are ever disabled (say within a system call), the worst-case interrupt latency increases by the maximum amount of time that they are turned off. Each operating system will internally disable interrupts in several places and for different lengths of time, so it is important that you know what your system's requirements are. One real-time project might require a guaranteed interrupt response time as short as 1µs, while another may require only 100µs.

The third real-time characteristic of an operating system is the amount of time required to perform a context switch. This is important because it represents overhead across your entire system. For example, imagine if the average execution time of any task before it blocks is 100ms but that the context-switch time is also 100ms. In that case, fully one half of the processor's time is spent within the context-switch routine!

Again, there is no magic number and the actual times are usually processor-specific, since they are dependent on the number of registers that must be saved and where. Be sure to get these numbers from any operating system vendor you are thinking of using. That way, there won't be any last minute surprises.

RTOS Selection Process

Considering the cost of engineering time these days, a few thousand dollars is a bargain for a commercial RTOS. A wide variety of operating systems are available to suit most projects and pocketbooks. See the vendor listings following this article or go to the Embedded.com Buyer's Guide.

Commercial operating systems form a continuum of functionality, performance, and price. Those at the lower end of the spectrum offer just a basic preemptive scheduler and a few other key system calls. These operating systems are usually inexpensive, come with source code that you can modify, and do not require payment of any royalties.

Operating systems at the other end of the spectrum typically include a lot of functionality beyond the basic scheduler. These operating systems can be quite expensive, though, with startup costs ranging from $10,000 to $50,000 and royalties due on every copy shipped in ROM. However, this price often includes free technical support and training and a set of integrated development tools.

Between these two extremes are the operating systems that have modest up-front costs and/or royalties, but do not include source code; technical support may cost extra. Most commercial operating systems fall in this category.

With such a variety of operating systems and features to choose from, it can be difficult to decide which is the best for your project. Try putting your processor, real-time performance, and budgetary requirements first. These are criteria that you cannot change, so you can use them to narrow the possible choices to a smaller set of products. Then contact all of the vendors of the remaining operating systems for more detailed technical information.

At this point, many people make their decision based on compatibility with their choice of cross-compiler, debugger, and other development tools. But it's really up to you to decide what additional features are most important for your project. No matter what you decide to buy, the basic kernel will be about the same. The differences will most likely be measured in processor support, minimum and maximum memory requirements, availability of add-on software modules (for example, networking protocol stacks, device drivers, and flash filesystems), and compatibility with third-party development tools.

The best reason to choose a commercial operating system is the advantage of using something that is better tested and, therefore, more reliable than a kernel you have developed inhouse. So one of the most important things you should be looking for from your OS vendor is experience.

List of Commercial RTOSes

Despite some recent consolidation, there are still well over a hundred RTOS vendors. The list that follows contains the names of well-established products from trusted vendors.

AMX (KADAK)
C Executive (JMI Software)
RTX (CMX Systems)
eCos (Red Hat)
INTEGRITY (Green Hills Software)
LynxOS (LynuxWorks)
µC/OS-II (Micrium)
Nucleus (Mentor Graphics)
RTOS-32 (OnTime Software)
OS-9 (Microware)
OSE (OSE Systems)
pSOSystem (Wind River)
QNX (QNX Software Systems)
Quadros (RTXC)
RTEMS (OAR)
ThreadX (Express Logic)
Linux/RT (TimeSys)
VRTX (Mentor Graphics)
VxWorks (Wind River)

Though this list is clearly partial, the range of price and features across this subset is representative of what you'll find in the larger set.

This article was published in the January 2003 issue of Embedded Systems Programming. If you wish to cite the article in your own work, you may find the following MLA-style information helpful:

Barr, Michael. "Choosing an RTOS,", Embedded Systems Programming, January 2003.