Tech Explained

Exploring Real-Time Operating Systems

Back in the 1980s, shipping company Federal Express (now FedEx) ran these great TV ad campaigns highlighting its overnight delivery service. The ads finished with the tag line: “Federal Express. When it absolutely, positively has to be there overnight. Real-time Operating Systems (RTOS) are a bit like that. Similar to FedEx, they are tuned to guarantee the delivery of bits on an exacting schedule, and like FedEx, you wouldn’t rely on RTOSes for every scenario. General purpose operating systems such as Windows or Linux are fine for the vast majority of activities, the same way most parcels can be sent by mail.

The difference is that an RTOS is architected to ensure that every application, every service, every message and every task and thread is handled in a way that guarantees prompt, consistent and assured execution – a concept known as determinism. Multithreading and multitasking – both core concepts in general purpose operating systems – are handled differently in an RTOS, enabling programmers to tightly control what programmatic elements enjoy supremacy in the queue and how the system will respond when it gets busy. The result: The most important stuff – say, real-time processing of, and response to, pressure and temperature data in a nuclear power plant – gets done within a rigorously defined time table, every time.

There are actually two flavors of RTOS, hard real-time operating systems and soft real-time operating systems. The most demanding scenarios require hard real-time operating systems.

  • Hard Real-Time: Designed to guarantee that response deadlines are always met. Missing a deadline is considered a total system failure
  • Soft Real-Time: Optimized to meet response deadlines. Missing a deadline results in incremental degradation in performance of the system, which can result in system failure if deadlines are repeatedly missed.

When Do You Need An RTOS?

Most RTOS applications fall into two broad classifications: event response and closed-loop control. A good example of the former is a manufacturing quality control application, where cameras image parts along an assembly line and optical recognition identifies defects in order to activate a remediation process. The system is able to recognize a complex event and take action in a very short time window. Closed-loop control scenarios address ongoing monitoring and control, such as a cooling system that continuously measures pressure and flow values and dynamically adjusts valve settings to stay within defined limits.

The emergence of the Industrial Internet of Things (IIoT) has ushered in a new generation of devices that rely on RTOS frameworks to enable effective decision making and process automation. As embedded systems become “smarter”, the need for an increased degree of autonomy makes real-time decision making a vital component of efficient hardware management. The devices within an IIoT environment not only need to be able to speak to each other, but also relay data to the cloud (or the fog, as we’ll discuss in an upcoming article) and receive commands just as quickly. Real-time environments are quickly becoming the go-to solution for network administrators and automation professionals driving Industry 4.0.

Are There Downsides to an RTOS?

Like FedEx’s priority overnight service, an RTOS commands a premium. These tightly bound and customized systems forego the niceties of general purpose OS software like Windows and many distros of Linux. And the software that developers write for an RTOS must be crafted with exacting precision, or risk hard failures. Consider the Mars Pathfinder spacecraft, which soon after landing in 1997 suffered a series of system resets due to a priority inversion flaw in the RTOS application code written by Jet Propulsion Laboratories. The team was fortunate that it could reproduce the flaw in its labs and upload a C language program to resolve the conflict. You can read a great account of this incident at the Microsoft Research site.

RTOS products like QNIX Neutrino, Wind River VxWorks and Microsoft Windows Embedded Compact (formerly Windows CE) are powerful tools that enable exacting consistency in mission-critical environments, but they are not for every task. That said, metaphorically speaking, when it “absolutely, positively has to get there overnight,” a RTOS may just be your best bet.

Darek Fanton

Darek is the Communications Manager at OnLogic. His passion for both journalism and technology has led him from the newsrooms of local papers to the manufacturing floor of IBM. His background in news gathering has him always on the lookout for the latest in emerging tech and the best ways to share that information with readers. In addition to his affinity for words, Darek is a music lover, juggler and huge fan of terrible jokes.

Published by
Darek Fanton

Recent Posts

OnLogic Headquarters – Creating a Sustainable Smart Building

Constructing a new building from the ground up gave us the rare opportunity to leverage…

1 week ago

Turning a Staircase into an Art Installation

At the heart of OnLogic’s headquarters is an incredible staircase - what our team of…

2 weeks ago

Edge AI Architecture: The Edge is the Place to be for AI

AI seems to be part of every technology-related conversation lately. While for some time AI…

2 months ago

Predictive Maintenance – how AI and the IoT are Changing Machine Maintenance

 The Internet of Things (IoT) and artificial intelligence (AI) are changing how we maintain equipment…

2 months ago

Deploying NVIDIA Jetson for AI-powered Automation

NVIDIA® Jetson™ has emerged as an early leader in the ongoing race for hardware platform…

3 months ago

Partnering with UVM Students on Sustainable Innovation

Developing and acting on initiatives for sustainable technology solutions is a team effort. At OnLogic,…

3 months ago