Get this Ultimate Guide as a PDF
Click here to download the Ultimate Guide to Real-Time Operating Systems.
What is an RTOS?
A real-time operating system (RTOS) must be reliable; it must be fast and responsive, manage limited resources and schedule tasks so they complete on time, and ensure functions are isolated and free of interference from other functions. In this section, you’ll learn more about what a real-time OS is and the pros and cons of two types of RTOS architectures, monolithic and microkernel.
RTOS Definition
The main responsibility of an operating system is to manage hardware resources and activities in the system: scheduling application programs, writing files to disk, sending data across a network and so on. When the OS must handle multiple events concurrently and ensure that the system responds to those events within predictable time limits, it is called a real-time operating system (RTOS).
Why RTOS for Embedded Systems?
Many embedded systems require real-time behavior, and due to hardware resource constraints, performance and efficiency are top priorities. An RTOS provides the rigorous resource management and scheduling required to meet the demands of applications with multi-tasking, priority-driven pre-emptive scheduling and fast context-switching—all essential features of an embedded real-time system.
An RTOS typically has a small footprint and is optimized for performance. However, each RTOS must be customized with the capabilities needed for the hardware and system it supports. From a bare-bones kernel configuration managing a small number of tasks to a full-functionality RTOS managing hundreds of tasks and subsystems including graphics, networking, filesystem, audio and more, an RTOS should flexibly scale to address system requirements and resources.
RTOS Architectures
RTOS architecture affects the reliability of an embedded system and its ability to recover from faults. There are two RTOS architectures: monolithic and microkernel.
What Is a Monolithic RTOS?
Monolithic means “one huge stone.” By definition, a monolithic kernel runs all operating system components in the kernel space. For instance, a monolithic RTOS includes device drivers, file management, networking and a graphics stack as part of the kernel space. Applications, however, run in the user space. Although running user applications as memory-protected processes protects a monolithic kernel from errant user code, a single programming error in a file system, protocol stack or driver can crash the system. In addition, any change to a driver or system file requires OS modification and recompiling.
Advantages and Disadvantages of a Monolithic RTOS (e.g. RTLinux)
| Advantages | Disadvantages |
|---|---|
|
Process scheduling, memory management and file management all run as a single large process in the same address space, which can improve performance.
|
The failure of any service can crash the OS.
|
|
The entire OS is contained in a single static binary file, which may run faster and more reliably than dynamically linked libraries.
|
Adding or removing a service requires modifying and recompiling the OS.
|
|
The OS’s kernel services represent a large attack surface - if a service is compromised it can make the whole system vulnerable.
|
|
|
Larger footprint.
|
|
|
Difficult to debug and maintain.
|
In a monolithic OS, a single programming error in a file system, protocol stack or driver can crash the whole system.
What Is a Microkernel RTOS?
A microkernel RTOS is structured with a tiny kernel that provides minimal services. The microkernel works with a team of optional cooperating processes that run outside the kernel space (in the user space), which provides higher-level OS functionality. The microkernel itself lacks file systems and many other services normally expected of an OS. A microkernel RTOS embodies a fundamental innovation in the approach to delivering OS functionality: modularity is the key, and the small size is a side effect.
In a microkernel, only the core RTOS kernel is granted access to the entire system, which improves reliability and security. The microkernel protects and allocates memory for other processes and provides task switching. All other components, including drivers and system-level components, are each contained within their own isolated process space.
Isolation prevents errors in a component from affecting other parts of the system—the only thing that a component can crash is itself. Such crashes can be easily detected, and the faulty component can be restarted hot—while the system is still running—so quickly that the restart has no or minimal effect on performance.
In a microkernel RTOS, isolation prevents errors in a component from affecting the rest of the system—the only thing a component can crash is itself.
During code development, the isolation of all processes has two significant benefits:
- Bugs are found earlier in development and are easily traced to a line of code in the faulty process. In comparison, latent bugs can remain from driver development for a monolithic OS, even after deployment, because stray pointers or other bugs do not cause an easily identified process crash.
- Drivers are treated like application processes, making them far easier to write and debug. You don’t need to be a device driver specialist or a kernel debugger to write a driver for a microkernel.
Advantages and Disadvantages of a Microkernel RTOS (e.g. QNX Neutrino RTOS)
| Advantages | Disadvantages |
|---|---|
|
Fault isolation and recovery for high availability.
|
Requires more context switching, which can increase overhead.
|
|
Restart a failed system service dynamically without impacts to the kernel (no system reboot).
|
|
|
Easy expansion—develop device drivers and OS extensions without a kernel guru and without recompiling.
|
|
|
Easier to debug.
|
|
|
Small footprint.
|
|
|
Less code running in kernel space reduces attack surface and increases security.
|
Monolithic Kernel Versus Microkernel
Several differences stand out when comparing monolithic and microkernel architectures.
| Category | Microkernel | Monolithic |
|---|---|---|
|
Performance
|
Slightly slower performance due to higher number of context switches.
|
Better performance due to smaller number of context switches.
|
|
System Updates
|
New drivers and OS services updates can be performed with no changes to the kernel, and thus do not require an OS reboot.
|
New drivers and OS services updates require an OS rebuild and reboot.
|
|
Power Fail Recovery
|
Can restart any service individually, without interrupting the kernel.
|
Recovery of a failed service requires an OS reboot.
|
|
Qualification and Certification
|
Easier and less costly to qualify and certify the kernel. Most system updates do not require a full qualification and certification cycle but rather are limited to the updated service or driver.
|
Difficult and more costly to qualify and certify. System updates require a full qualification and certification cycle as the OS is generally rebuilt.
|
|
Maintenance
|
Easier and less time-consuming to maintain and troubleshoot deployed systems. Users can update, troubleshoot and reboot a service without requiring an entire OS reboot.
|
Challenging and more time-consuming to maintain and troubleshoot. Users require an OS reboot when performing most system updates, troubleshooting steps or a service reboot.
|
QNX Neutrino RTOS is a Commercial Microkernel RTOS
Since 1980, thousands of companies have deployed and trusted QNX® real-time technology to ensure the best combination of performance, security and reliability in the world’s most mission-critical systems. At the core of this offering is QNX® Neutrino® RTOS, a full-featured and robust RTOS designed to enable the next-generation of products for automotive, medical, transportation, military and industrial embedded systems.
The microkernel design and modular architecture enable BlackBerry QNX customers to create highly optimized and reliable systems with low total cost of ownership. With the QNX Neutrino RTOS, embedded systems designers can create compelling, safe and secure devices with a highly reliable RTOS serving as the foundation that helps guard against system malfunctions, malware and security breaches.
QNX Neutrino RTOS
Easily port Linux® prototypes to the POSIX-compliant QNX Neutrino RTOS or to its safety variant, the QNX® OS for Safety, which has been safety-certified to IEC 61508, ISO 26262, IEC 62304, EN 50657, and EN 50128.
What to Expect in an RTOS
An RTOS delivers functionality that helps embedded systems developers deliver safe, secure and reliable products. In this section, you’ll learn about key RTOS functionality to look for or to consider building into your own RTOS, such as spatial and temporal separation, adaptive partitioning, pre-emptive priority-based scheduling, and system determinism.
Spatial Separation
Spatial or hardware separation, or spatial isolation, provides each process with its own private address space. Embedded systems require the isolation of software components to ensure freedom from interference in hardware (spatial) and time (temporal). A memory management unit (MMU) provides spatial separation by mapping physical memory to virtual memory and protects parts of the physical address space from unwanted access.
An MMU allows an RTOS to use a process model as each task (process) is allocated its own virtual address space for much greater reliability. Without an MMU, code, data and the kernel itself would compete for and share the same memory space—a less reliable approach.
Temporal Separation
Temporal separation, or temporal isolation, allows each process to run without depending on the timing of another unrelated system sharing the same hardware or software resources. RTOS scheduling provides temporal separation by ensuring process threads run when they are supposed to, as well as ensuring that there are always enough CPU computing cycles to go around.
By partitioning resources, scheduling algorithms deliver temporal separation between tasks with different levels of criticality, ensuring that the higher priority task gets the resources it needs. Tasks generally include both periodic (regular) tasks and aperiodic (irregular) tasks. The most common ways to provide temporal separation are static and adaptive partitioning.
Interprocess Communication (IPC)
Interprocess communication (IPC) adds an additional layer of isolation between address spaces. Developers need to pass data between processes or tasks. In the QNX Neutrino RTOS, interprocess communication maps POSIX calls to messages, in addition to the hardware separation afforded by the MMU.
A message-based approach to interprocess communication provides a high level of architectural decoupling as required by safety standards such as ISO 26262. Although message passing is the primary form of interprocess communication in the QNX Neutrino RTOS, other forms of IPC are also available. Message passing is part of the POSIX standard and all BlackBerry® QNX® solutions are POSIX-compliant.
Static Versus Adaptive Partitioning
Partitioning prevents processes (or threads) from monopolizing CPU cycles needed by others. You don't want one application—whether defective or malicious—to corrupt another application or prevent it from running. To address this issue, some systems use virtual walls, or partitions, around a set of applications to ensure that each partition is given an engineered set of resources. The primary resource considered is CPU time but can also include any shared resource such as memory or file space.
An RTOS can enforce CPU partition budgets via static, partitioning, adaptive partitioning or another partitioning scheme.
- Static partitioning divides tasks into groups (partitions) and allocates a percentage of CPU time to each partition. No task can consume more than the amount allocated to its partition. When partitions don’t need their full allocation, CPU cycles are left unused and interrupts have to wait until the partition runs, which can cause unacceptable latency.
- Adaptive partitioning provides a dynamic scheduling algorithm that allows the system designer to reserve CPU cycles for a process or group of processes and to dynamically reassign CPU cycles from partitions of lower need to partitions with higher need. The result is a faster, more efficient and more responsive system that guarantees time for important tasks, with minimal unused CPU cycles.
The QNX Neutrino RTOS uses adaptive partitioning. A system designer can launch POSIX-based applications, and the OS scheduler will ensure that each partition receives its allocated budget. Within each partition, each task is scheduled according to the rules of priority-based pre-emptive scheduling.
Adaptive partitioning technology guarantees minimum budgets to defined groups of threads without wasting unused processing time.
Priority-Based Pre-Emptive Scheduling
Priority-based pre-emptive scheduling allows high-priority threads to meet their deadlines consistently, even when there is a lot of competition for resources. With priority-based pre-emptive scheduling, a high-priority thread can, within a short and bounded interval of time, take over the CPU from any lower-priority thread. The high-priority thread can run uninterrupted until it has finished—unless it is pre-empted by an even higher-priority thread.
System Determinism
Deterministic real-time scheduling ensures that the most urgent software runs when it needs to. Pre-emptive priority-based multitasking is deterministic. The scheduler uses priorities to determine which task should run next. Unexpected system loads, including third-party code, will not adversely affect safe operation.
A deterministic RTOS ensures that priority threads get the time they need when they need it by pre-empting a lower-priority task. For example, in a car crash, the airbags must deploy immediately—not wait for another task to finish.
A deterministic RTOS ensures that priority threads get the time they need, when they need it, by preempting a lower-priority task.
Responsiveness
Embedded systems with hard real-time constraints require responsiveness. Real-time applications depend on the OS to handle multiple events and to ensure that the system reacts within an expected timeframe to those events. In other words, the system’s response time must be predictable.
The QNX Neutrino RTOS is ideal for mission-critical systems that require responsiveness and absolute reliability.
How to Choose a Commercial RTOS
A commercial RTOS can save engineering time and effort, and can improve the reliability and performance of your embedded systems. While most RTOSs deliver high performance, other aspects of a commercial RTOS and related tools and services can affect your product quality and engineering effort. In this section, you’ll learn about what else you may need to deliver the features, security and safety your customers want and your development teams need.
When selecting a commercial RTOS, consider the following:
Safety: Will you need to certify your embedded system to IEC 61508 (industrial), IEC 61511 or EN 50128 (rail), IEC 62304 (medical) or ISO 26262 (automotive) or another industry standard? The choice of a pre-certified RTOS could help improve the system reliability and reduce your safety certification effort.
A pre-certified RTOS can simplify your safety-certification effort.
Security: A microkernel architecture, adaptive partitioning and a hypervisor can all help protect safety-critical processes from cyberattack. In addition, some commercial RTOSs, like the one from BlackBerry QNX, include a security policy. This enables system architects and integrators to control access to specific system resources and determine the type of access that is permitted (e.g., no root access). Security is achieved with a layered approach that includes mechanisms such as secure boot, integrity measurement, sandboxing, access controls and rootless execution.
Development environment: A POSIX-compliant RTOS will simplify migration from a Linux-based prototype to a more reliable, secure and safe production system. Developers ramp up quickly on the QNX® Software Development Platform (SDP) because it looks and feels like Linux and uses the same tools, such as the GNU Compiler Collection (gcc).
Graphics and human machine interface (HMI): Does your embedded system drive one or more displays with HMIs? Choosing an RTOS with a graphics subsystem that provides all the functionality necessary to develop interactive user interfaces is key. A graphics framework that supports industry standards such as OpenGL ES means developers can more readily build graphical user interfaces and benefit from the hardware acceleration provided by graphics processing units (GPUs).
Maintenance and updates: Keeping your product up to date over its lifetime may require the ability to apply patches or easily add functionality. In a microkernel-based OS, a new service can be added to the user address space without any kernel changes, whereas a monolithic OS requires the entire kernel to be modified.
Hardware support: An RTOS must be customized for each processor or board, so look for an RTOS that offers board support packages (BSPs) for your preferred hardware to jumpstart your development. In addition, an RTOS with an extensive list of BSPs indicates it is widely used in multiple embedded markets. For example, BlackBerry QNX provides BSPs for a long list of x86 and ARM processors.
An RTOS that supports your preferred boards with board support packages can save a lot of development time.
Licensing: Will you pay before, during or after your product is developed? An open-source OS comes with hidden costs—there can be considerable engineering effort required to keep up with OS maintenance, patches and modifications to the kernel. Commercial RTOS vendors offer a variety of licensing options.
Vendor reputation and quality of support: Look for a software vendor with a positive reputation that provides easy access to quality documentation and excellent customer support. Additionally, you may value a services team that helps you develop and secure your product and navigate safety certification, and helps ensure you hit your start of production dates.
Total cost of ownership: A commercial RTOS can provide lower total cost of ownership than an open-source OS such as Linux. BlackBerry QNX provides ongoing maintenance and support, allowing our customers to free up engineers for product innovation and differentiation instead of kernel code changes.
How Can BlackBerry QNX Help You?
BlackBerry QNX is trusted across multiple industries to provide the software foundation for safe, secure and reliable systems that get to market faster. In this section, you’ll learn about our other tools and services—including a hypervisor, middleware, professional services and supplementary solutions—as well as about our heritage and deep expertise in embedded system software.
BlackBerry QNX offers a broad range of safety-certified and secure
software products complemented by world-class professional services to
help embedded developers increase reliability, shorten time-to-market
and reduce development cost.
More than an RTOS
BlackBerry QNX offers a time-tested and field-proven RTOS—and so much more. With a hypervisor, middleware, professional services and supplementary solutions, we have everything you need to build a safe, reliable and secure embedded system.
- Hypervisor: Will you want guest OS support to provide design flexibility and software reuse in a complex system? As system on a chip (SoC) vendors add more computing cores with more processing power, developers gain long-term advantages with a hypervisor for virtualization, such as the QNX® Hypervisor.
- Additional frameworks and platforms: Will your project require advanced driver assistance systems (ADAS), connectivity or over-the-air updates? Starting with a framework or platform can be a big help to delivering features such as sensor data management, Wi-Fi connectivity, streaming media, speech recognition, infotainment systems and ADAS.
- Professional services: Will you need help? BlackBerry® QNX® Professional Services, including safety services and security services, extend your team to help you shorten development timelines with expertise in embedded software development.
- Language support and development tools: What tools are your developers already familiar with? The QNX Software Development Platform supports C/C++, HTML5, Qt, Python and more. QNX Neutrino RTOS looks and feels like UNIX. QNX is POSIX-compliant, so developers can port code easily from Linux and other operating systems to the QNX Neutrino RTOS.
- Training: Will your team need training? BlackBerry QNX offers hands-on, instructor-led training courses using real-world examples to give your development team a foundation in QNX best practices—and the features, services, and architecture of the QNX Neutrino RTOS.
- Board support packages: A board support package (BSP) is software responsible for the hardware-specific operations required to get an RTOS up and running. A QNX BSP typically includes an initial program loader (IPL), startup, default buildfile, networking support and board-specific device drivers, system managers and utilities.
Our Reputation
BlackBerry QNX has decades of experience in powering mission-critical embedded systems in automotive and other industries. We are proud to share our expertise with you.
- On time, every time: Having worked on hundreds of automotive programs, BlackBerry QNX has never missed a start of production deadline. That means there have been no software delays, no issues delivering new products and no task too complex to have affected the start of production.
- In more than 235 million automobiles on the road: BlackBerry QNX software is embedded in more than 235 million vehicles on the road today—with more on the way.
- Our products and expertise in safety certifications: We have achieved certification for our own products to the highest level of safety—ISO 26262 (ASIL D) and IEC 61508 (SIL 3). And we’ve helped our customers achieve ISO 26262 and IEC 61508 certification and IEC 62304 compliance with a 100-percent success rate.
- Our heritage in security: BlackBerry offers trusted mobile security—hardened, tested, trusted and certified—backed by decades of experience. Similarly, the QNX Neutrino RTOS offers the gold standard in RTOS security with the expertise and safety certifications to help our customers build more secure products.
Check Out Our Other Ultimate Guides
WP.29 Cybersecurity Vehicle Regulation Compliance
Information about the UNECE WP.29 regulations, the countries where they apply and how they aim to mitigate the cybersecurity risks posed to passenger vehicles.
READ THE GUIDE
Embedded Systems Security
Covers topics such as embedded systems protection, security exploits and mitigation, and best practices
READ THE GUIDE
Functional Safety
Offers key concepts and information on standards for safe system design
READ THE GUIDE
Contact Us
Our team of experts are here to answer your questions.