Have you ever heard the term OSEK RTOS before and wondered what the difference between OSEK RTOS and an RTOS are? If you’ve had any exposure to the automotive industry, you’ve undoubtedly heard OSEK, but it isn’t always clear what an OSEK RTOS might provide when compared to an RTOS. In this post, we are going to quickly examine OSEK RTOS so that you can understand what it is and how it compares to an RTOS.
What is OSEK?
OSEK stands for Offene Systeme un deren Schnittstellen für die Elektronik in Kraftfahrzeugen. If that seem like a mouth full, it’s because it’s German! (Glad I took four years of German in High School). OSEK is a German consortium that was founded in 1993 by automotive companies like BMW, DaimlerChrysler and Volkswagen to create automotive standards for writing electronic control unit (ECU) software. At the time, the software complexity and costs were ballooning and OSEK was hoping to create a standard architecture that would allow portability and reuse within the industry.
Today, parts of OSEK standards have found there way into ISO standards such as ISO 17456 – open interface for embedded automotive applications.
OSEK RTOS versus RTOS
An OSEK compliant RTOS provides many of the same features and functionality that any RTOS designed to execute on a microcontroller will provide. For example, they will both have tasks/threads, mutexes, semaphores and so forth. So what’s the difference between them?
An OSEK RTOS may be used in safety-critical automotive applications. For that reason, there are often stricter requirements on the RTOS capabilities. For example, an OSEK RTOS will typically only allow static memory allocation. All tasks and objects must be created at compile time. This is a bit different from what you see in some open source operating systems like FreeRTOS.
Another interesting difference is that an OSEK RTOS supports two levels of tasks; basic and enhanced tasks. A basic task can be though of as a coroutine that never blocks but runs to completion. An enhanced task behaves like a typical RTOS task in that it can sleep or block.
An OSEK RTOS also does not typically support priority inheritance. Instead, there is the use of priority ceilings to prevent a deadlock or priority inversion. The reason for this strategy is that an OSEK RTOS only supports static task priorities. A mutex which typically support priority inheritance does not have a static priority.
OSEK RTOS Scheduling
An OSEK RTOS or operating system will support the typical types of task scheduling that can be found in any RTOS. For example, the scheduler can be configured to allow non-preemptive or preemptive scheduling. (Honestly, if you are using an RTOS, it rarely makes sense to use anything other than preemptive scheduling).
With OSEK, tasks can also be cooperatively grouped together. At first glance, grouping tasks might seem different; However, it isn’t. Typical RTOS solutions like FreeRTOS, ThreadX, and so forth will allow time slicing, and cooperative scheduling for tasks with he same priority level. The scheduling capabilities between a typical RTOS and an OSEK RTOS are very similar.
It’s all about the interface
The big difference between OSEK and your mainstream RTOS is that an OSEK RTOS / OS has a standard set of API’s and capabilities. The interface is standardized between all OSEK RTOSes! The standardization is part of the power of the OSEK standard. It allows developers to switch out an RTOS or operating system within a layer and not have to modify any of their application code.
The standard interface helps to decouple the application from the middleware, hardware, and even communication interfaces. If you look at many commercial and open source RTOS solutions within the embedded systems industry, you’ll find there is no standard! Everybody creates and uses a difference set of APIs. There have been attempts to standardize such as the Arm CMSIS-RTOSv2 specification, but that is not common beyond Arm parts.
Conclusions
An OSEK RTOS / operating system provides similar capabilities to your typical RTOS. The main differences is that OSEK compliant RTOSes are built to stricter real-time performance requirements. They are designed with a common interface so that they can be easily added to and removed from ECU software. Finally, they adhere to a stricter development model such as static task allocation and static task priorities.
To learn more about RTOSes in general, check out this RTOS blog reading list.
