OSEK OS Overview

The Autosar OS has the good old OSEK/VDX OS as a backbone. Learning about OSEK will put you on the right track to understanding the Autosar OS

This is the first part of our OSEK OS 101 course. Today, we'll learn about the backstory on OSEK/VDX and how it maps to the Autosar Classic platform we have today, and in the next part, we'll dive deep with practice.

Back in 1993, OSEK (Open Systems and their Interfaces for the Electronics in Motor Vehicles, we won't bother with the original german name) was founded, by an automotive consortium of some german companies (some of the usual suspects: BMSW, Bosch, Daimler, Opel, Siemens and Volkswagen) and the university of Karlsruhe. At the same time, a similar project was looming in some french OEM's (Renault, Peugeot PSA and Citroën), named VDX (Vehicle Distributed eXecutive), and joined the former consortium in 1994. Hence, OSEK/VDX was born and was registered under Continental (which bought Siemens back in 2007).

The motivations behind creating OSEK/VDX are more or less the same as you may have heard when starting your Autosar journey: interoperability between OEM's, cost reduction by sharing the same OS architecture, standardizing the interfaces with the underlying hardware, better use of the underlying resources and reusability of the applications developed.

Enough with the story lesson. OSEK is an open standard, which has some of its parts standardized in the norm ISO 17356 - Road Vehicles. Parts of this OSEK specification are reused by the Autosar classic platform, with the Autosar OS being a superset of the OSEK OS. But what is so particular about this OS that made the Autosar consortium choose it? (Apart from the obvious, they created it). One important attribute of resource-constrained microcontrollers for safety-citical systems such as ECU's in a vehicle is the absence of a MMU (Memory Management Unit). So, everything is configured at compile-time. You cannot create new tasks in runtime, or any OS resources, such as mutexes in runtime. The OSEK standard also defines generic API's for I/O and peripheral access. OSEK incides on some familiar Autosar concepts, namely:

• OS (Operating System) - The base for a controlled execution of a concurrent application

• COM (COMmunication) and NM (Network Management) - Protocols for the transfer of data in a vehicle network

• OIL (Osek/VDX Implementation Language) - Configuration language for an OSEK/VDX application for a specific ECU

The OSEK stack does look a similar to part of the layered Autosar Classic we have today

If we look inside the OSEK OS kernel, we will find what's expected in an OS: tasks, events, resources for mutual exclusion, counters and alarms, interrupt management, communication between tasks and error management. As mentioned before, all these objects have to be defined in compile-time and cannot be created dynamically. These attributes are defined via OIL files, which has a simple syntax. Although you don't deal with it directly in Autosar, it's very common to find within your generated files these .OIL files laying around. In the next article about OSEK, we'll learn how to create these files. Today, the main goal is to understand the internals of the OS. So, let's look at each of the components that make up the OSEK OS:

• Tasks - There are two different types of tasks in OSEK: basic and extended. Their main difference is the state machine. Basic tasks are sequential, while the extended tasks have a waiting state, which means they can depend on an event. Tasks in OSEK are preempted if they terminate, if a scheduling point occurs and decides to switch to a higher priority task or to an ISR.

OSEK/VDX Tasks state machine

• Scheduling - Since every OS-related configuration has to be done statically, there are no priority changes in runtime. There isn't a round-robin mechanism, so two tasks with the same priority will not preempt each other. The second task will only run after the first is finished. Regarding preemption, there are 3 different options: full preemptive (all tasks can be preempted, which means a higher priority task will run immediately if the running task has a lower priority), full non-preemptive (no task is preemptable, so, a higher priority task sits in the ready state until the next scheduling point, even if the running task has a lower priority) or mixed (each task is configured individually as preemptable or non-preemptable). OSEK also has control over the ISR's. Interrupts have higher priority than all tasks. In the next article about OSEK, we'll see this in greater detail.

• Events - Extended tasks can depend on events. These can be produced by many entities (any kind of task, or a CAT2 ISR - more on ISR's in a minute), but can only be consumed by a single task. A single task can also depend on multiple events.

• ISR's (Interrupt Service Routines) - OSEK defines two different kinds of interrupts: CAT1 and CAT2. CAT1 interrupts are faster, rely heavily on the microcontroller hardware, so, are very microcontroller-specific and cannot perform system calls. CAT2 ISR's, on the other hand, are not as fast but are allowed to perform some system calls, such as setting an event. CAT1 ISR's are also ignored by the operating system, while CAT2 ISR's are similarly handled to an OS task (have a context, and their HW trigger can be regarded as an event). Their priority is not related to hardware, it's a logical one, given by the OS.

• Counters - An abstraction of the hardware ticking source, which is dependent on the hardware. Since it's associated with the hardware, an interrupt is associated with the counters. There is at least one counter available, the System Counter.

• Alarms - Connected to a counter, to signal when the maximum counter value is reached. Multiple alarms can be connected to a single counter, but an alarm is associated with a single counter. After the alarm is signaled, an action can be performed, such as the activation of a task.

• OSEK Synchronization - mutual exclusion mechanism, that can be used to synchronize the use of shared resources between tasks and CAT2 ISR's.

• OSEK Priority Ceiling Protocol (PCP) - OSEK PCP tries to solve common scheduling problems, namely, deadlocks and priority inversion, by setting the ceiling priority of a resource. The ceiling priority is set to the highest priority of the tasks that use the said resource, at least. When a task accesses this resource, the task priority is set to the ceiling priority of the said resource. When it releases the resource, its priority is reset.

• Hooks - Hooks are callouts a user can implement, which will get called in a specific state of the OS. They are optional, although very useful. Some of these hooks are called on startup, shutdown, before and after task execution, and an error hook. The hooks have a greater priority than all tasks, cannot be preempted by CAT2 ISR's, and are able to call a subset of OS functions.

• Task Groups - Allows you to mix preemptable and non-preemptable tasks, by grouping tasks that belong to the same category.

After learning the theory behind the OSEK OS, I hope you stay tuned to the next article, when we'll show how these concepts appear in practice. In the meantime, if you are bored, you can check our article about What is Functional Safety (opens in a new tab), where we talk about how safety concept applies to Autosar, where the OS also plays an important part.

Author: Micael Coutinho (opens in a new tab)

References:

• ISO 17356 - Open interface for embedded automotive applications (opens in a new tab)