RTOS Survey
The survey consists of a compilation of features and characteristics of readily available RTOS. This part of the analysis does only scratch the surface and its purpose is to get an overview of the landscape of RTOS.
Characterization
During the research of different RTOS information regarding the following characteristics was collected.
Scheduling Algorithm
There are different scheduling algorithms for operating systems for different use cases. The survey should reveal the most commonly used algorithms.
Ecosystem
An ecosystem of an RTOS consists of a kernel, IPC, modules for hardware access, file access and networking and build tools. The ecosystem has major influence on the workflow of a software developer. On an RTOS with lots of tools and custom hardware access layer (HAL) a developer is restricted to the OS specific system calls, on a slim RTOS the developer has more control over the software implementation.
Documentation & License
A thorough documentation is needed to analyze an RTOS. For a detailed insight into RTOS internals such as scheduler and IPC, it is sometimes necessary to read the source code. Consequently, RTOS with an open-source license is preferred for the analysis.
Functional Safety
Hard real-time systems are used in safety critical environments. To sell a device for a safety critical application the IEC61508 standard must be considered. IEC61508 SIL-3 will be used to check whether an RTOS meets the functional safety requirements.
Results
the table shows a vast landscape of different types of RTOS from hardware manufacturers, software companies and open-source communities. They differ in target application, safety and ecosystem completeness. The table does not contain IPC features, as all operating systems include them.
Groups
Looking at scheduler types, target application and hardware access we can classify the RTOS into two groups. The group affiliation is shown in the last column and is in most cases similar to target application for which an RTOS is marketed. The two groups that emerge are:
Group A: IoT centric these RTOS were designed or at least marketed for Internet of Things (IoT) devices and hence include networking stacks as well as connectivity drivers. Most of the RTOS provide built-in network drivers for WiFi, BLE and LoRa commonly used in IoT devices.
Group B: general purpose the RTOS from this group are used in commercial, industrial, medical and safety critical system. Networking stacks are tailored towards industrial use with TCP/IP as default and no built-in BLE support.
The two groups blend into each other, as some RTOS are in the transition from a general purpose to an IoT centric RTOS. Or some target the IoT market even though they can be used for any application.
The prospect of large IoT market seems to wake the interest of big software companies and hardware manufacturers. Amazon bought FreeRTOS and added AWS support, Microsoft bought ThreadX and added Azure Cloud support. Facebook, Google, Intel and Nordic Semiconductor support Zephyr. Texas Instruments develops TI-RTOS, ARM develops Mbed OS based on Keils RTX and Silicon Labs bought μC/OS.
Scheduling
Preemptive round-robin scheduling seems to be default technique. Contiki-NG chooses to solely schedule cooperatively. Other RTOS offer cooperative scheduling as an alternative to preemptive scheduling for the developer to choose. Zephyr in contrast to all the others offers more involved algorithms such as earliest deadline first, tasklet and multiple task queuing strategies.
Ecosystem
The general purpose RTOS generally provide a smaller ecosystem the ones from the IoT group. This might be due to fact, that it is easier to certify and sell individual components instead of one complex system. The general purpose RTOS are also easier to integrate into an existing development workflow. RTOS with a large ecosystem like ARM Mbed OS and Zephyr on the other hand dictate how software is developed.
The RTOS in the IoT group provide their own implementation and API for hardware access (OS Specific HAL in the table) similar to a desktop OS e.g. GNU/Linux. Development on already supported hardware is thus fast. But implementing new driver implies a high initial cost because a developer has to adapt to a new workflow and existing code cannot always be ported to RTOS with its own hardware access API. The general purpose RTOS provide an API for multitasking and IPC but leave the rest up to the developer. Additional features (file access, network stacks) are available as separate modules.
In the general purpose group connectivity drivers are rarely included in the RTOS. That is consistent with hardware access philosophy in which the developer has to provide the HAL. In contrast, the operating systems in IoT group provide multiple connectivity drivers, but generally lack drivers for industrial buses (e.g. CAN, Modbus).
Besides the differences in hardware access and networking, most RTOS supply a file system as well as TCP/IP network stack. So the user of an RTOS can expect to get a basic network stack and a basic file system.
Regarding the development workflow Mynewt, ARM Mbed OS, Contiki-NG and Zephyr Project go as far as providing their own build system or integrated development environment (IDE).
Functional Safety
All RTOS that have a SIL-3 certification belong to general purpose group. The certified RTOS are variants and none of them are open-source, FreeRTOS (SafeRTOS) [27] and μC/OS-II [23] are selling compatible versions through third-party companies.
Intel is working on the SIL-3 certification of Zephyr [30]. This would make Zephyr the first freely available safety certified RTOS.
Documentation
Most RTOS have an open-source codebase allowing for an examination of the specific implementation. Though, not all RTOS can be used freely, e.g. Azure RTOS code is on GitHub but can only be used for free if the hardware is pre-certified (e.g. STM32 MCUs and MPUs). Besides the source code all open-source operating systems also provide an online documentation.
Rust
Separated at the bottom of the table are the RTOS written in the Rust language. These operating systems are newer and do not offer as many features as the more established C/C++ RTOS. But they are going new ways in terms of implementation, RTIC for example is a real-time framework that assigns user code to the interrupt vector table of the microcontroller offloading task switching to hardware. With this multitasking technique there is only one stack, resolving critical stack overflow problems arising from many parallel tasks.
The Rust RTOS will not be examined in detail in this part but will be consulted for the realization at a later stage.