What Is a Real-Time Operating System (RTOS)?
A real-time operating system (RTOS) is an operating system built for real-time applications which can process data and events under strictly defined time constraints.
RTOS differs from Unix-like time-sharing operating systems:
- Unix systems use schedulers, data buffers, or fixed task priorities to manage the sharing of system resources, but do so in a manner that is not time critical.
- RTOS systems have strict time constraints. The scheduler is designed to work in a deterministic, predictable operating pattern, ensuring that all processing is done within these defined time constraints.
Real-time operating systems are event-based and preemptive. In other words, the operating system can monitor the relative priority of competing tasks and change task priorities. Unlike Unix-based systems, switch tasks based on clock interrupts event-driven systems like RTOS switch tasks based on priority.
RTOS Architecture and Components
Soft RTOS vs. Hard RTOS
Soft real-time systems typically have larger file sizes than those used in hard RTOS. In a soft RTOS, executions might behave somewhat unpredictably at peak load, but this is tolerated, because in case of an error the calculation is rolled back to a previously established checkpoint. In a soft RTOS, when an error occurs, the operating system can continue running, but some functions may not operate properly.
Soft RTOS systems are typically used for devices where time-based execution is less important, such as PCs, cameras, and smartphones.
A hard RTOS system usually has relatively small data files. If an error occurs, the system behaves exactly as expected and the calculation is rolled back, even during peak loads. Hard RTOS are typically used for systems where time-based execution is critical, such as aircraft sensors, autopilot systems, and medical devices.
If a hard RTOS system cannot perform calculations to make an object available within the specified time, the operating system will fail and shut down.
Monolithic vs. Microkernel Architecture
An RTOS system typically uses either a monolithic and microkernel architecture:
In a monolithic architecture:
- The kernel is the heart of the operating system, provides basic services for it’s other components and serving as the main layer between the OS and the hardware.
- The monolithic RTOS kernel and the operating process share one space—this enables higher performance compared to microkernel configurations.
- Monolithic RTOSs are fast, but they are difficult to update, and programming errors in the file system, protocol stack, or drivers can cause the system to crash.
In a microkernel architecture:
- The kernel and operating processes are in separate locations. This architecture is slower than a monolithic RTOS. This is because all operations must return to the kernel before they are passed to the component they reference.
- The microkernel does not have a filesystem.
- However, microkernel configurations are easier to program and update, and are more resilient to programming errors.
The Importance of RTOS in Embedded Systems
An embedded system is – in a sense – a computer embedded in a larger system, such as a microcontroller in an electronic device. For non-critical systems with some flexibility in their schedules, developers can use a general-purpose operating system such as Linux. Linux is full-featured, flexible, and mature. However, for critical systems, whether safety-critical or business-critical, it can be necessary to use a real-time operating system.
An RTOS can ensure that an embedded system is predictable and reliable. In many environments, variability in response time or behavior of embedded systems can lead to wasted resources, quality issues, and even physical damage or injury (e.g., in case of medical devices or sensors). This is why RTOS is most often used in embedded systems.
RTOSs are often embedded in intelligent edge devices, also known as electro-mechanical edges or cyber-physical systems, also known as internet of things (IoT) devices. In the past, edge devices had limited functionality and would rely on centralized systems for data processing. Today, with the advent of edge computing, these devices often combine artificial intelligence with substantial computing power and real-time components.
Key Features of RTOS for Embedded Systems
Maintainability and Coding Efficiency
Here are some key features of RTOS systems that provide improved maintainability of embedded systems:
- Abstracting time dependencies and task-based design reduces interdependencies between modules. This makes maintenance easier.
- Task-based APIs naturally encourage modular development because tasks have well-defined boundaries. A task-based system also makes it easier for different developers and teams to work independently on each part of a project.
- Task-based development enables modular testing, which makes it easier to comprehensively cover all software functionality.
- Broad use of RTOS encourages the development of standard libraries that can be reused across projects.
Improved Processing Speed
Here are key features of RTOS systems that enable faster, predictable processing:
- Priority-based scheduling enables separating non-critical and critical tasks.
- RTOS can be completely event-driven. This avoids wasting processing time by polling for events.
- Background processing like CPU load measurements and background cyclic redundancy checks (CRC) are managed using an “idle task”, without affecting the main process.
Example of Priority-based Scheduling in RTOS
Here is an example of how you might use priority-based scheduling in FreeRTOS, a popular open source RTOS:
#include "FreeRTOS.h"
#include "task.h"
void vTask1( void *pvParameters )
{
for( ;; )
{
// Task 1 code goes here
vTaskDelay( 1000 / portTICK_RATE_MS );
}
}
void vTask2( void *pvParameters )
{
for( ;; )
{
// Task 2 code goes here
vTaskDelay( 1000 / portTICK_RATE_MS );
}
}
int main( void )
{
// Create task 1 with a priority of 1
xTaskCreate( vTask1, "Task 1", 1000, NULL, 1, NULL );
// Create task 2 with a priority of 2 (higher than task 1)
xTaskCreate( vTask2, "Task 2", 1000, NULL, 2, NULL );
// Start the scheduler
vTaskStartScheduler();
// The program should never get here
return 0;
}
In this example, two tasks are created: vTask1 and vTask2. vTask1 has a priority of 1, and vTask2 has (you guessed it) a priority of 2. This means that vTask2 will be given higher priority by the scheduler.
The scheduler is started using the vTaskStartScheduler function. This function does not return until the scheduler is stopped.
Each task also uses the vTaskDelay function to pause for a specified amount of time (in this case, 1000 milliseconds). This allows the tasks to execute in a periodic manner. The portTICK_RATE_MS constant is used to convert the delay time from milliseconds to ticks, which is the unit used by the scheduler.
9 Popular RTOS Flavors to Know
1.FreeRTOS
License: Open Source
FreeRTOS is an RTOS designed to be small enough to run on a microcontroller, which typically runs programs directly from ROM or Flash storage. However, it is not intended exclusively for microcontroller applications.
Microcontrollers are used for deeply embedded applications that perform very specific and specialized tasks. These are applications that cannot see the processor itself or the running software. Due to size constraints and the nature of dedicated applications, it is typically not possible to use a full RTOS implementation.
For this reason, FreeRTOS provides only the core real-time scheduling features, inter-task communication, and timing and synchronization primitives. In other words, it is a real-time kernel or real-time executor and not a full operating system. Additional features such as a command console interface and network stack can be included as add-ons.
2.SafeRTOS
License: Open Source
SAFERTOS is a functionally secure and certified real-time operating system (RTOS) for embedded processors, developed by WHIS, a safety systems vendor. It provides high performance and certified reliability while using a minimal amount of resources.
SAFERTOS comes with a Design Assurance Package (DAP) that includes all design artifacts created throughout the development lifecycle. When integrated into safety-critical equipment, DAP ensures easy regulatory certification.
The operating system is based on the functional model of the FreeRTOS kernel, but was redesigned by WHIS. The company engineers took a functional model of the FreeRTOS kernel, performed a hazard and operability study (HAZOP), and generated a set of security requirements. The company used these requirements, and the IEC 61508-3 SIL 3 development lifecycle, to create the SAFERTOS codebase and DAP.
3.Keil RTX
License: Open Source
Keil RTX is a royalty-free, deterministic real-time operating system designed for ARM (Cortex-M) devices. It lets developers write programs that perform multiple functions at the same time, making applications more structured and easier to maintain.
Key features include flexible scheduling with algorithms like round robin, preemptive, and collaborative, low interrupt latency, a small footprint for resource-constrained systems, Unlimited mailboxes, semaphores, mutexes and timers, support for multithreading and thread-safe operations, kernel-aware debugging in MDK-ARM, and the µVision installation wizard.
4. Zephyr
License: Open Source
Project Zephyr is a scalable RTOS that supports multiple hardware architectures, is optimized for resource-constrained devices, and is built with security in mind.
Based on a minimal-footprint kernel, Zephyr is designed for use in resource-constrained systems, from simple embedded sensors to full IoT devices.
The Zephyr kernel supports multiple CPU architectures including ARM (Cortex-A, Cortex-R, Cortex-M), Intel x86, ARC, Nios II, Tensilica Xtensa, RISC-V, SPARC, and MIPS.
5. VxWorks
License: Proprietary
VxWorks was developed as proprietary software by Wind River Systems, a subsidiary of Aptiv. First released in 1987, it is designed for embedded systems that require real-time deterministic performance, typically in aerospace, defense, medical, and industrial equipment.
VxWorks supports CPU architectures including AMD, Intel, POWER, ARM, and RISC-V. It also supports multi-core asymmetric multiprocessing (AMP), symmetric multiprocessing (SMP), mixed-mode and multi-OS (via Type 1 hypervisor) for 32-bit and 64-bit processors.
VxWorks comes with a kernel, middleware, board support packages, Wind River Workbench development kits, and complementary third-party software and hardware. In its latest version, VxWorks 7, the RTOS aws redesigned for modularity and upgradeability by separating the OS kernel from middleware, applications, and other software packages.
6. EmbOS
License: Proprietary
embOS was developed by Segger and is a priority-controlled RTOS with zero interrupt latency, which minimizes memory consumption and is optimized for high speed, versatile use of RAM and ROM.
embOS supports platforms running 8, 16, and 32-bit processors, making it easy to port applications to other CPUs. Its highly modular architecture ensures only the necessary functions can be used, resulting in a very small ROM size.
Tasks are easy to create and can communicate securely with each other using communication mechanisms such as semaphores, mailboxes, and events. Interrupt service routines (ISRs) can also utilize these communication mechanisms.
7. MQX
License: Proprietary
Message Queue eXecutive (MQX) is a real-time operating system (RTOS) from Precise Software Technologies, currently available from NXP Semiconductors and Synopsys, Embedded Access, Inc.
Like many RTOS offerings, MQX has a multi-tasking kernel that preemptively schedules tasks. It has a file system, fast interrupt response, synchronization facilities, and extensive inter-process communication.
MQX has a configurable size, conserving memory space with a minimum of 6 KB ROM (read-only memory) – this includes the kernel, semaphores, interrupts, queues, and memory manager.
MQX also has RTCS (an Internet protocol suite TCP stack), MFS (a built-in DOS file system based on a file allocation table), USB host-device stack, and tools for remote and task-aware design, debugging, and performance analysis. It has support from popular SSL/TLS libraries like wolfSSL, which help increase security.
The main use case for MQX is embedded systems. Developers build MQX-based applications on host machines running Windows or Unix. This process involves cross-compiling software that runs on different target CPU architectures.
8. PikeOS
License: Proprietary
PikeOS is a hard, commercial RTOS that provides a separation kernel-based hypervisor with multiple logical partitions for other operating systems, known as GuestOSs, and applications. It lets teams create certifiable Internet of things (IoT) devices based on industry-specific quality, security, and safety standards.
PikeOS for MPU is useful for real-time, safety-critical real-time applications that run with an MPU instead of an MMU.
9. ThreadX
License: Proprietary
Azure RTOS ThreadX is Microsoft’s advanced industrial RTOS, designed for deeply embedded real-time IoT applications. The RTOS has been deployed billions of times in a variety of products, including consumer devices, medical electronics, and industrial controls, and provides advanced scheduling, communication, synchronization, timers, memory management, and interrupt management capabilities.
ThreadX has many advanced features such as a pico kernel architecture, preemptive threshold scheduling, event chaining, execution analysis, performance metrics, and system event tracking. It can support the most demanding embedded applications and is designed to be easy to use.
Challenges of Using an RTOS
Here are some of the main challenges you might encounter when using a real-time operating system.
Prioritizing tasks
Selecting the right priorities for your tasks can be challenging because there are different ways to prioritize them. For example:
- Response time—prioritizing the tasks with the shortest response times.
- Job length—prioritizing tasks with the shortest jobs (i.e., the shortest job will be first).
- Period—prioritizing the tasks with the shortest periods (also called rate-monotonic scheduling). This approach is most commonly used for real-time embedded systems and will prioritize most tasks except for the occasional aperiodic task.
Visualizing the system
When implementing an RTOS, it’s important to understand where the data is produced and where and how it travels. The resulting spaghetti code may require constant reworking and be difficult to visualize. A data flow diagram can simplify your view of the code by mapping components such as data producers, consumers, transfer mechanisms, storage, and task coordinators.
Protecting shared memory
Development teams often use a mutex to protect shared memory resources, but this can be a problem if created separately from the protected data. When someone uses the data structure, it might not be apparent that this is a protected shared resource. Creating a mutex to protect data doesn’t guarantee everyone will use it to access your data. A best practice is to treat shared memory as objects, and include the mutex in the data structure.
Operational and Security Challenges
In addition to above, using RTOS comes with a unique set of security and operations challenges, some of these are:
Platform proliferation
There are a lot (A LOT) of RTOS flavors, supporting hundreds of IoT device types – from sensors to embedded systems. For manufacturers dealing with different RTOS systems, across different device fleets, it can be difficult to manage security and for these many hardware-software combinations.
Security vs performance tradeoffs
Embedded RTOS devices, such as sensors or special-purpose controllers, typically lack the resources (CPU, memory, storage, etc) to adequately incorporate on-device or advanced (e.g., endpoint or agent-based) security solutions without performance degradation.
“Black box” effect
The same resource constrains that prevent manufacturers from implementing security controls also limit their remote monitoring option and many RTOS devices turn into “black boxes” once they are shipped in the field. This hinders, or even completely out rules, the option to remotely debug them when something goes wrong, spot emerging issues or even simply learn about their routines, to make informed product design decisions in the future.
Observability and compliance challenges
New regulatory standards (BSI, NIST, IEC 62443, EN, etc) and FDA guidelines (see our guide to medical device regulations) that set a high bar for security and post-market surveillance of embedded devices. However, as already mentioned, RTOS devices are typically resource-constrained and lack the ability to support real-time monitoring solutions and security controls (e.g., endpoint protection) demanded by these regulations.
Sternum: RTOS Security and Observability
Sternum is a security and observability platform built specifically for resource-restrained IoT systems. Leveraging binary instrumentation, it integrates directly into the firmware code; either via a OTA update or as part of the CI/CD, during development.
Once deployed, our patented EIV (embedded integrity verification) technology automatically starts to profile memory and code in runtime and deterministically block ALL memory and code manipulation attempts.
This enables the technology to protect the device from known and future threats, and the embedded presence also opens the door to granular device and fleet-level data collection, used by the platform to provide XDR-like threat detection and more developer-oriented debugging and health monitoring capabilities.
From a performance POV, the embedded integration translated into a minimal overhead of just 1-3%, even on legacy and/or resource-lean devices.
In the video below, you can get a peak of Sternum in action, and reach out here if you would like to learn more.
