Exploring Real-Time Operating Systems: On Time All the Time

Exploring Real-Time Operating Systems

Exploring Real-Time Operating Systems

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.Real Time Spectrum

  • 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.

Find Your Computer Here

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.

Understanding MTBF White Paper by Logic Supply

Leave a Comment

Your email address will not be published.