OSEK

The OSEK (Offene Systeme und deren Schnittstellen für die Elektronik in Kraftfahrzeugen; English: “Open Systems and their Interfaces for the Electronics in Motor Ve

hicles“) is a standards body that has produced specifications for an embedded operating system, a communications stack, and a network management protocol for automotive embedded systems. It has also produced other related specifications. OSEK was designed to provide a standard software architecture for the various electronic control units (ECUs) throughout a car.

The OSEK was founded in 1993 by a German automotive company consortium (BMW, Robert Bosch GmbH, DaimlerChrysler, Opel, Siemens, and Volkswagen Group) and the University of Karlsruhe. In 1994, the French car manufacturers Renault and PSA Peugeot Citroën, which had a similar project called VDX (Vehicle Distributed eXecutive), joined the consortium. Therefore, the official name is OSEK/VDX.

OSEK Applications:

Although automotive companies developed OSEK for automotive applications, there is nothing in the standard that limits its usefulness to this context. Almost any application that requires a compact, predictable RTOS could utilize an OSEK system. Obviously other transportation applications may be considered, but the needs of other safety-critical systems are readily addressed. The key characteristics of a system, for which OSEK may be useful, are:

• Real-time.
• Deeply embedded.
• Safety-critical.
• Distributed.
• No requirement for dynamic object creation.

Why OSEK?

Clearly there are some excellent opensource RTOS alternatives(FreeRTOS,eCos,Jaluna,etc). The problem with these operating systems, from an automotive perspective, is:

• Alternatives are quite bulky and their real-time performance is not quite”real” enough.
• The API of most alternatives(typically POSIX)is not ideally suited to the combination of synchronous and asynchronous task scheduling.
• The OSEK API was designed by automotive suppliers.

Advantages Of OSEK:

• Clear savings in costs and development time.
• Enhanced quality of the software of control units.
• Standardized interfacing features.
• Utilization of the existing resources in the vehicle, enhance the performance of the overall system without requiring additional hardware.
• Absolute independence with regards to individual implementation, as the specification does not prescribe implementation aspects.
• Overhead in terms of memory usage and code footprint.

OSEK Standards:

• OS(Operating System): Provides a common API for OS features, it is configurable with OSEK OIL.
• OIL(OSEK Implementation Language): Provides system configuration and object description for the OS and COM implementations.
• COM(Communication): Provides the standard interfaces and protocols for data exchange in a network.
• NM(network management)
• ORTI(OSEK Run Time Interface): The internal OS data is made available to the debugger and the debugger displays the information of OSEK system objects.
• OSEK time OS.
• FTCOM(Fault Tolerant Communication).

OSEK Implementation Language (OIL) Concept:

• A specially designed language for the development of embedded applications based on the OSEK concept. –> describe the application structure/configuration as a set of system objects. –> C-like text-based configuration description for OSEK applications. –> have predefined structure and special(standard)grammar rules.
• The configuration of OS is object-oriented, each object defines a certain set of attributes to define.
• All system objects specified by OSEK and relationships between them can be described using OIL. –> OIL defines standard types for system objects. –> Each objective described by a set of attributes and references.
• The OIL file contains two parts: –> Implementation Definition – definition of implementation-specific features. –> Application Definition – definition of the structure of the application located on the particular CPU. –> The application definition comprises a set of objects and the values for their attributes.
• OS, COM, and NM objects must be 1, other objects can be more.
• Dependencies Between Attributes – infinite nesting.

Application Development using OSEK Operating System

There are three main standards in OSEK/VDX:

1. OS (Operating System version 2.2) – Provides a common API.
2. COM (Communication version 2.2.2) – Provides the standard interfaces and protocols for data exchange.
3. NM (Network Management version 2.5.1) – Provides the standard functionality to ensure proper operation of in-vehicle networks.

OIL- (OSEK Implementation Language version 2.3) – Provides system configuration and object description (OS and internal COM).

ORTI (OSEK Real Time Interface) – provides debuggers with OS Aware information

Tasks in OSEK/VDX OS:

OSEK Task Management:

• A task is an independent thread of execution that can compete with other concurrent tasks for processor execution time. A task is schedulable as –> A task provides the framework for the concurrent and asynchronous execution of functions.
• The task in an application is generated using the TASK system generation object with the set of properties in the OIL file.
• The OSEK operating system provides two kinds of tasks are: –> Basic Task. –> Extended Task.

Basic Task:

A basic task runs to completion unless preempted by a higher priority task or an interrupt means the Basic Tasks release the processor only if:

• they are being terminated.
• the OSEK OS is executing higher – priority tasks.
• interrupts have occurred.

Advantages Of Basic OSEK Task:

• Uses minimal resources.
• Used when inter-process synchronization is not required.

The basic task can exist in one of the states namely: –> Running. –> Ready. –> Suspend.

Transition	Former State	New State	Description
Activate	Suspended	Ready	A new task is set into ready state by a system service. The OSEK os ensures that the execution of the task will start with the first instruction
Start	Ready	Running	A Ready task selected by the scheduler is executed
Preempt	Running	Ready	The scheduler decides to start another task. The running task is put into Ready state.
Terminate	Running	Suspended	The running task causes its transition into the suspended state by a system service.

Extended Task:

Extended tasks differ with basic – have a waiting state: –> It allows the processor to be released and to be reassigned to a lower – priority task(no need to terminate the running extended task). –> in principle, more complex than management of basic tasks and requires more system resources.

The tasks may be preemptive [i.e. they can be preempted by another task of higher priority] or they can be non-preemptive.

Conformance classes: The configuration of an OSEK system is determined by a set of four Conformance Classes. These provide bounds to the characteristics of tasks, which, in turn, constrain the complexity of the system. Each class is a super-set of the ”lower” ones:

• BCC1: Only Basic tasks, with just one task per priority level. Each task may only be “activated” once – i.e. only a single instantiation of each task is permitted.
• BCC2: Only Basic tasks, but with multiple tasks per priority level. Multiple activation’s [instantiations] are permitted.
• ECC1: Extended tasks supported, with just one task per priority level. Each task may only be activated once.
• ECC2: Extended tasks, with multiple tasks per priority level and multiple activation’s.

OSEK System configuration: Since an OSEK system is configured at build time, most vendors provide source code, which lends itself most readily to such configuration. However, in order to protect their intellectual property, some vendors “scramble” the source code [i.e. intentionally render it unreadable]. This limits its use by the developer to just system configuration.

Task priority: As with most real-time operating systems, OSEK tasks have a priority. According to the OSEK specification, the higher the number, the higher the priority. The lowest priority is 0; the highest is implementation dependent [but 255 is common]. This is the reverse of some RTOSes, where 0 is highest. A task’s priority is defined at build time and cannot be adjusted at run time.

Transition	Former State	New State	Description
Active	Suspended	Ready	A new task is entered into the ready list by a system service
Start	Ready	Running	A ready task selected by the scheduler is executed
Wait	Running	Waiting	To be able to continue an operati. The running task requires an event. It causes its transition into waiting state by using a system service.
Release	Waiting	Ready	Events have occurred which a task has been waiting for.
Preempt	Running	Ready	The scheduler decides to start another task. The running task is put into ready state
Terminate	Running	Suspended	Running task causes its transition into suspended state by a system service

Task scheduling: The scheduler is invoked as a result of various events, depending upon whether a preemptive or non-preemptive task is running:

• Non-preemptive: calls to: ChainTask(), TerminateTask(), WaitEvent(), Schedule().
• Preemptive: calls to: ChainTask(), TerminateTask(), WaitEvent(), ActivateTask(), SetEvent(); message arrives; alarm expires.

The scheduler simply reviews which task in the Ready queue has the highest priority and moves it to the running state. The data structures [and hence code] of the scheduler for a system conforming to BCC1 or ECC1 is considerably simpler than a system conforming to BCC2 or ECC2. This is the result of the number of possible tasks at each priority level [just one for BCC1 or ECC1].

OSEK OS Interrupts: An OSEK system supports 3 types of interrupt:

1. Category-1: These are quite independent of the OS. Hence they are fast, but cannot make use of OS services.
2. Category-2: These are integrated into the OS and can make full use of OS facilities, but have somewhat limited performance.
3. Category-3: These are a hybrid. Most of the code has no access to OS services, but a section may be defined where such facilities are available. This is enclosed by calls to EnterISR() and LeaveISR().

Example:
interrupt void inputchar()
{
static char buffer[100];
static int index=0;
char c;
c = getcharacter();
if (c == EOM)
{
EnterISR();
SetEvent(InputProcess, MSG);
LeaveISR();
}
else
{
buffer[index++] = c;
}
}

OSEK Event Synchronization: Events are a key feature of an OSEK system for the synchronization of tasks with one another and external activity. An event is owned by a task [specifically an extended task]. An event may be set [asserted] by any task, but only the owner can wait on or clear an event.

OSEK Counters and Alarms Synchronization: The Counters and alarms are designed to synchronize recurring events. They can avoid the unnecessary use of specific tasks for such purposes. A counter is driven by a tick, which can represent a time interval or any other occurrence. An OSEK system, by definition, always has at least a timer counter. The counter API is implementation-specific, as particular hardware may be available.

An alarm is an aggregate object, consisting of a counter and an action [which is, in effect, association with an event/task]. On completion, an alarm may activate a task or set an event. Alarms may be cyclic, to enable a periodic activity to be scheduled, or a single shot, to implement timeouts, etc.

Priority inversion: A common problem, with all real-time systems, is the situation where a task locks a resource and effectively blocks a task of higher priority from running. This is termed priority inversion. There are various strategies available to address this difficulty. The OSEK specification defines a priority ceiling protocol. The task locking the resource has its priority temporarily raised to the level of the highest other tasks that are in contention for the resource. Thus, blocking of the higher priority task(s) is minimized.

OSEK Errors and Debug Handling: Since the focus of an OSEK system is speed and compactness, the specification makes minimal demands with respect to runtime error handling. This may be provided with a specific implementation. A common approach is to use macros to answer the OSEK API. When a debug flag is set, the macros include extra code for error checking; when the flag is clear, “production” code, with no error checking, is generated.

An OSEK system incorporates a number of “hooks”. These are opportunities for the OS to call a user-defined function, under specific circumstances. If no function is defined, no call takes place. There are six hook routines:

• StartupHook(): This function is called before the scheduler is started. It is a useful place to set up alarms, activate tasks, and send messages to other networked devices. In general, the application may be placed into a known state.
• PreTaskHook() and PostTaskHook(): These functions are called just before a task is scheduled and just before it is “de scheduled”, respectively. They offer the opportunity for tracing and debug. They are really of more use to OS developers and vendors than end-users.
• ErrorHook(): This function is called a result of an application error, which can be detected by the OS; e.g. attempt to activate a non-existent task. Such errors may be recoverable – i.e. there is no damage to the integrity of the OS – but that recovery is application dependent.
• ShutDownHook(): An OSEK system will attempt to call this function if a fatal error occurs. Typically, this will be the result of a lack of integrity being detected in the OS’s internal data structures. The only likely action is a system reset, but there is the opportunity for a “graceful” shutdown of external systems.

OSEK COM Module:

The COM provides a means for application tasks to communicate via messages. This communication may be “inter-process” [the tasks are running on the same processor] or “inter-processor” [communication is between networked devices].

No assumption about the network topology or technology is assumed in the design of COM and the applications programmer does not need to know. Typically it would be a CAN or J1850 bus but could be Ethernet or any other networking medium.

OSEK COM layers: Like most communication protocols, COM may be modeled as a series of layers. There are five layers, which map quite well onto the ISO/OSI seven-layer model.

Application layer: This layer is the application code itself.

Interaction layer: This layer provides the API, which includes functions for send, receive, status check, and resource lock/release. This layer handles all on-chip [inter-process] communication. All inter-process communication is passed on to the Network layer.

Network layer: This layer receives only interprocessor traffic. It handles any necessary segmentation of messages – division of a large message into two or smaller ones. Messages are passed on to the appropriate Data Link layer for transmission.

Data Link layer: This layer handles the network protocol – e.g. CAN. There may be several Data Link layers in a complex system, each handling a different protocol.

OSEK COM Module Operation:

The COM functions asynchronously in parallel with the application code. Successor failure may be indicated in a number of ways: task activation, event setting, and alarm expiry. The messages are defined as specific objects in an OSEK system. They are quite separate from tasks but have a defined association [see Sending/Receiving below]. The design is intended to reduce the requirement to define utility tasks to process messages.

COM is actually independent of the underlying OS. In principle, at least, the OS need not even be OSEK-compliant.

OSEK COM Message Characteristics: COM messages can have a wide range of characteristics. A system may be constrained by one of the four conformance classes:

Message Type	CCC0	CCC1	CCC2	CCC3
Direct transmission	X	X	X	X
Periodic transmission		X	X	X
Mixed direct/periodic		X	X	X
Message deadline monitoring		X	X	X
Unqueued messages	X	X	X	X
Queued messages				X
Unsegmented protocol	X	X	X	X
Segmented protocol			X	X
Notification by task activation		X	X	X
Notification by event setting		X	X	X
Static address/size	X	X	X	X
Dynamic address/size			X	X

Transmission mode: There are three available modes: Direct, Periodic, and Mixed. Direct Mode is when message transmission is simply initiated by a task. Periodic Mode is when a message is sent automatically at a predetermined frequency. Mixed Mode is when a message is sent periodically, but can also be sent on an “update” [when variable changes and the change meets specified criteria]; the periodic timer is not reset on an update transmission.

Message deadline monitoring: This is an optional facility. An alarm is started on transmission and canceled on the confirmation. Periodic messages may also be monitored.

Queued/unqueued messages: If messages are unqueued, there is a single object in COM for each message. Queued messages are held in a FIFO buffer.

Segmented/unsegmented protocol: Messages may or may not be divided into multiple frames, as required by the underlying communications link. This is handled by the Network layer and is only relevant to inter-processor communications.

Static/dynamic address/size: Message size may be fixed [in which case it may still be segmented] or variable. Similarly, the address may be determined at a build or run time.

OSEK Sending/receiving Message: Since each message is an independent entity, they are defined individually. The form of this definition is not covered by the OSEK standard, but typical parameters include:

• Message size.
• Queued/unqueued.
• Network/local.
• Transmission mode.
• Static/dynamic size/address.
• Monitoring alarm.

In addition, the message usage for each task must be defined:

• send/receive: There can by only one sending task, but many receivers.
• Copy or not: A copy or zero-copy mechanism may be selected.
• Ttask action: For each task, there is a need to select: task activation, event setting, alarm set/clear

FEW of the OSEK Implementations:

• Nucleus OSEK -Accelerated Technology (MPC555, MPC565).
• osCAN -Altera Corporation’s (Altera Nios II Processor).
• PICOS18 –Pragmatec Inc. open source.
• OSEKturbo –Metrowerks (Motorola HC08, HC12, MPC5xx, MPC52xx, MPC55xx architectures …)
• ProOSEK -Elektrobit.
• RTA-OSEK -ETAS / Live Devices.
• OSEK Works –Metrowerks.
• Open SEK / Free OSEK RTOS.

OSEK-NM (Network Management):

The OSEK NM describes node-related (local) and network-related (global) management methods. The global NM component is optional. However, it requires a minimum local component to be operational. Therefore, the following services are provided:

• Initialization of ECU resources, e.g. network interface.
• Start-up of the network.
• Providing network configuration.
• Management of different mechanisms for node monitoring.
• Detecting, processing, and signaling of operating states for network and node.
• Reading and setting of the network- and node-specific parameters.
• Coordination of global operation modes (e.g. network-wide sleep mode).
• Support of ECU diagnosis.

There are two main parts within the document:

1. Direct Network Management.
2. Indirect Network Management.

Scope of the OSEK Network Management:

The OSEK NM defines a set of services for node monitoring. Figure 1 shows how the NM is Embedded in a system. It is also shown that the NM has to be adapted to specific requirements of the bus system used or to the resources of the nodes.

Since it is very likely that OSEK systems will be deployed in networked environments (like a car), it is useful that some network management facilities are included in the standard. The facilities are basic – primarily aimed at giving each node of a system a “picture” of the network as a whole.

There are two distinct methods available: Direct and Indirect Network Management.

1. Direct Network Management.
2. Indirect network management.

Direct network management:

Each node is assigned a logical number. These numbers need not be sequential. There is a logical ring structure, where the next node is the next higher value, going back to the start after the highest value. The configuration state of other nodes in the network is determined by a series of “Ring” and “Alive” messages. A node’s own state is determined by its ability to send messages. There are two possible states: present or absent.