An RTOS, or Real Time Operating System, is an invaluable part of any complex embedded application. RTOS are typically deployed on microcontrollers and small microprocessors, although can now be seen in larger architectures.
An RTOS is a software component that rapidly switches between Tasks, giving the impression that multiple programs are being executed at the same time on a single processing core. The difference between an Operating System (OS) such as Windows or Linux and an RTOS is the response time to external events. OSs typically provide a non-deterministic, soft real time response, where there are no guarantees as to when each Task will complete, but they will try to stay responsive to the user. An RTOS differs in that it typically provides a harder real time response, providing quicker reaction to external events.
In this series of articles we look at the two different types of RTOS – safety or commercial – as well as what an operating system is; what are the typical features and how they work.
Emiliano Costagli
Principal Engineer at WHIS
14th October 2022
Related RTOS Topics
Further Your knowledge of RTOS with our RTOS Resource Centre
Safety Critical RTOS
A Safety Critical RTOS is a Real Time Operating System that has been designed to comply with a specific safety critical design standard. Further your knowledge of safety critical RTOS:
Related White Papers
The information on this page is expanded upon in the white papers below. See all of our white papers covering extensive number of RTOS topics.
RTOS as Part of the Embedded Platform
An RTOS is just one part of the embedded design. The embedded platform typically includes the microprocessor, an RTOS, the drivers, middleware, and low level verification routines. The design and requirements of the platform vary widely, and are dependent on the end use of the platform. A simple device for measuring water height in a reservoir, for example, will have much less complexity than an engine control unit in a new electric car.
Adapting the RTOS for different processor/compilers
RTOS require integration to this specific processor and compiler used by the embedded platform- known as porting. To make this as simple as possible, most RTOS design will consist of two distinct layers, a Core Layer that contains the majority of the RTOS functionality and implements the RTOS API, and a Portable Layer.
The Portable Layer contains the code that integrates with the microprocessor’s infrastructure, including the saving and restoring of the processor’s internal registers, the reprogramming of the processor’s Memory Protection Unit (MPU)/Memory Management Unit (MMU) registers, and the operation of the RTOS Tick. There is also self-test functionality and performance monitoring. The Portable Layer abstracts and encapsulates the specific microprocessor and compiler details and implementation from the RTOS Core Layer.
Generally, the Portable Layer will be kept small and concise. To facilitate porting the RTOS to new processor and complier configurations, ideally the only changes required should be contained within the Portable Layer, allowing the Core Layer to remain common across all RTOS ports. This approach of partitioning the Core and Portable Layers allows the same RTOS functionality and API to be ported across many different processor and compiler combinations. Therefore, the designer is free to choose the optimum processor and compiler for their new project, and still have the ability to use their preferred RTOS.
RTOS in Multicore Systems
It is becoming common for embedded systems to incorporate more than one CPU on a single System on Chip. From a hardware perspective, there are broadly two types of multicore design. If all the CPUs have exactly the same architecture, it is termed homogeneous multicore; if there is variability in the architectures, it is heterogeneous multicore.
From the RTOS perspective, the choice is between AMP and SMP. Where AMP stands for Asymmetric Multi- Processing and SMP means Symmetric Multi-Processing. An SMP system is typically arranged with multiple homogeneous CPUs. There is normally only a single instance of the RTOS, and Tasks are shared across cores with the objective of improving processor throughput. In embedded applications, SMP is used to implement processing heavy routines, for example AI or image processing activities.
An AMP system has multiple CPUs. Each CPU has its own instance of the RTOS, and the RTOS provides a communication facility between the CPUs to share data and provide coordination, using the standard RTOS API calls. AMP solutions are normally deployed where each CPU is undertaking a different role within the system. AMP is suited for use in safety critical or mixed safety critical embedded systems. As each processing core is performing a specific function, there could be a mix of different RTOSs within an AMP solution. For example, a large SoC used for autonomous driving is likely to contain ARM Cortex-A clusters alongside ARM Cortex-R safety cores; the RTOS requirements between these core types could be very different. RTOS multicore solutions are available as Functional Safety Components, and provide a very fast and effective way of creating functional safety capability across a multicore System on Chip.
Free Demos & Manuals
Download fully functional, time-limited SAFERTOS demos, plus manuals, datasheets, and more.
Should we Use an RTOS?
There are well-established techniques for writing good embedded software without the use of an RTOS. In some cases, these techniques may provide the most appropriate solution; however as the solution becomes more complex, the benefits of an RTOS become more apparent. These include:
- Priority Based Scheduling: The ability to separate critical processing from non-critical is a powerful tool.
- Abstracting Timing Information: The RTOS is responsible for timing and provides API functions. This allows for cleaner (and smaller) application code.
- Maintainability/Extensibility: Abstracting timing dependencies and task based design results in fewer interdependencies between modules. This makes for easier maintenance.
- Modularity: The task based API naturally encourages modular development as a task will typically have a clearly defined role.
- Promotes Team Development: The task based system allows separate designers/teams to work independently on their parts of the project.
- Easier Testing: Modular task based development allows for modular task based testing.
- Code Reuse: Another benefit of modularity is that similar applications on similar platforms will inevitably lead to the development of a library of standard tasks.
- Improved Efficiency: An RTOS can be entirely event driven; no processing time is wasted polling for events that have not occurred.
- Idle Processing: Background or idle processing is performed in the idle task. This ensures that things such as CPU load measurement, background CRC checking etc will not affect the main processing.
What are the Advantages of a Real Time Operating System?
- Determinism: RTOS, especially safety critical RTOS, are designed to deliver extremely high levels of determinism. Features frequently found in commercial grade RTOS’s that effect deterministic behaviour have been removed, such as dynamic memory allocation.
- Robustness: Safety RTOS uses a robust implementation, designed to comply with the most rigorous international design standards. A deterministic design, self-verification features, parameter validation and stack checking routines all contribute to ensure it performs as expected.
- Isolation and Separation of Individual Tasks: When a safety RTOS supports the isolation and separation of individual tasks using the processor’s memory protection features. This allows safety critical code to co-exist in the same code space as commercial code while remaining physically isolated, lowering development/ production costs.
- Ease of Product Certification: The process of certifying a safety RTOS in a product is simple and straightforward. All that is required is to follow the clear, concise instructions found within the Safety Manual on how to install, integrate and use your RTOS within an application, and submit the resulting evidence to your auditors.
- Designed to your Specific Compiler and Processor: Our safety RTOS is delivered configured for your specific compiler and processor combination; this ensures no re-testing is required, and safely integrating your safety RTOS into your application is smooth and hassle free.
- Lowers Risk: In many safety critical applications, the RTOS is the most critical component. The RTOS not only schedules the functionality of the software, it also schedules the operation of Safety Monitors and Safety Functions. Using a trusted component at the heart of your design shortens development schedules and de-risks the product certification process.
- Quality Assurance: SAFERTOS, our safety RTOS,is delivered with full source code and a Design Assurance Pack (DAP). The DAP contains every Design and Verification artefact created for your specific SAFERTOS port and provides complete transparency over the full Design Life Cycle. WHIS is also ISO 9001 certified.
- Proven: SAFERTOShas been independently certified many times on numerous platforms, for various different applications, to IEC 61508-3 SIL 3, the highest possible SIL level for a software only component.
Ask Us a Question
For pricing, licensing, or any other sales or product related questions, please contact us.
