It’s always nice to have a choice, but when it comes to real-time operating systems (RTOS), there are just too many! If you’ve ever taken the time to search the web, you’d find that there are over a hundred different RTOS’s out there! Some are general, some try to differentiate by industry such as the IoT. Others claim they are better because they are commercial products while open source ones claim they are free and just as good as the commercial ones. Ask any three engineers about their RTOS choice, and you’ll likely find they all have a different favorite.
I’ve always been a big fan of Lord of the Rings, with a single ring to rule them all. Wouldn’t it be nice if there was just a single RTOS? The answer is actually NO! The embedded systems space is just too diverse to create one RTOS that would meet the needs of everyone. People working in safety critical software would want robust, laser tight determinism where commercial developers would be happy with hitting soft real-time needs and view the robust determinism as overkill. There will never be a single RTOS to rule them all but what if the RTOS itself is more like the rings of power and an operating system abstraction layer (OSAL) is the one ring?
Ruling the RTOS through OSALs
OSALs are an incredibly useful tool that developers can leverage to abstract out the specific RTOS that they have chosen. An OSAL is essentially a generic interface that can be used to interact with and control any number of existing RTOS’s. If one developer likes FreeRTOS, they simply wrap the FreeRTOS API’s with the OSAL. If another developer wants to use ThreadX, or uC OS III, or some other RTOS, they simply wrap the RTOS calls with the OSAL interface.
There are actually quite a few advantages to using an OSAL. First, the OSAL allows developers to decouple their application code from the RTOS. With so many options out there, and many coming in and out of style, teams shouldn’t be writing their applications around an RTOS. The RTOS is just a component or tool and the less dependency there is on the RTOS in the application the better! A perfect example might be where one RTOS is used during proof-of-concept because it is free while a safety certified version may be used during development and production. With an OSAL in place, there is no need to rewrite application code, just redirect the OSAL interface to the other RTOS and recompile.
Second, the OSAL allows a developer to architect their software without caring about what RTOS is used. A software architect wants to work with details that are abstract so that they can focus on the architecture and the application business rules. The nitty gritty RTOS details therefore get pushed behind the OSAL and become an implementation detail that the application architects don’t need to think about. (Yes, this does limit the use of RTOS specific features but for scalable and flexible architecture design we push these details to the implementers).
Finally, with the RTOS behind the OSAL, it makes it much easier for the software to be tested and simulated. When an RTOS is tightly coupled to the application, developers need to figure out how to get the RTOS to run on a continuous integration server and how to get it to behave properly in simulation and integration testing. With the OSAL, the behavior can be much more easily mocked which can help save time but more importantly prevent developer stress levels from reaching critical.
Conclusions
There will never be just a single RTOS that everyone in the embedded systems industry uses. The best that we can hope for is for developers with the embedded systems industry to adopt a single OSAL that acts as a standard interface for any embedded application. There are potential OSALs out there such as CMSIS-RTOS v2 for Arm users and a few other microcontroller vendor specific ones out there. I don’t yet feel though that development teams are adopting them the way that they should.
An OSAL is advantageous because it allows developers to write their applications without needing to immediately select the RTOS they will use. They can simulate the behavior of a generic RTOS and write their application code, even testing it while delaying the specific RTOS they will use until the implementation phase of their project. The OSAL is the closest we will come to having one RTOS to rule them all.
