OSEK OS

In this article, We will discuss following topics of OSEK OS

Reference document: OSEK OS Document 

ISO 17356 consists of the following parts:

• OSEK Glossary (located in OSEK Binding 1.4.1, part of ISO 17356-1, which consists of a ISO-style introduction and the glossary)
• OSEK Binding Specification (base: OSEK Binding 1.4.1, ISO 17356-2 with exception of the glossary)
• OSEK OS (base: OSEK OS 2.2.1, ISO 17356-3)
• OSEK COM (base: OSEK COM 3.0.2, ISO 17356-4)
• OSEK NM (base: OSEK NM 2.5.2, 17356-5)
• OSEK OIL (base: OIL 2.4.1, ISO 17356-6)

Note; Language "OIL" (OSEK Implementation Language) supports a portable description of all OSEK specific objects such as "tasks" and "alarms" etc.

OSEK Block Diagram

Architecture of the OSEK OS

Processing levels: Processing levels are defined for the handling of tasks and interrupt routines as a range of consecutive values. Mapping of operating system priorities to hardware priorities is implementation specific.

OSEK defines three processing levels:

1. Interrupt level
2. Logical level for scheduler
3. Task level

The interrupt level can contain one or more interrupt priorities which are statically assigned to interrupt service routines and depend on the implementation and hardware architecture. Within the task level, the tasks are scheduled according to their policy and priority, which are statically assigned by the user during system creation. Concerning task priorities, higher numbers refer to higher priority, but interrupts are always preferred over tasks.

Task and Task models

Task: Complex control software can conveniently be subdivided in parts executed according to their real-time requirements. These parts can be implemented by the means of tasks. A task provides the framework for the execution of functions. The operating system provides concurrent and asynchronous execution of tasks. The scheduler organizes the sequence of task execution.

Two different task concepts are provided by the OSEK operating system:

1. Basic tasks
2. Extended tasks

The main difference is that extended tasks are allowed to wait for events whereas basic tasks are not.





A task has to change between several states, as the processor can only execute one instruction of a task at any time, while several tasks may be competing for the processor at the same time. The OSEK operating system is responsible for saving and restoring task context in conjunction with task state transitions whenever necessary.

Activating a task 

• Task activation is performed using the operating system services Activate Task or ChainTask. After activation the task is ready to execute from the first statement.
• Depending on the conformance class a basic task can be activated once or multiple times. "Multiple requesting of task activation" means that the OSEK operating system receives and records parallel activations of a basic task already activated. The number of multiple requests in parallel is defined in a basic task specific attribute during system generation. If the maximum number of multiple requests has not been reached, the request is queued. The requests of basic task activations are queued per priority in activation order.

Task switching mechanism

The principle of multitasking allows the operating system to execute various tasks concurrently. Therefore the scheduling policy has clearly to be defined.

The scheduler is activated whenever a task switch is possible according to the implemented scheduling policy.

Task priority 

The scheduler decides on the basis of the task priority (precedence) which is the next of the ready tasks to be transferred into the running state. 

The value 0 is defined as the lowest priority of a task. Accordingly bigger numbers define higher priorities.
The following fundamental steps are necessary to determine the next task to be processed: 

• The scheduler searches for all tasks in the ready/running state.
• From the set of tasks in the ready/running state, the scheduler determines the set of tasks with the highest priority. Within the set of tasks in the ready/running state and of highest priority, the scheduler finds the oldest task.

The following fundamental steps are necessary to determine the next task to be processed:

• The scheduler searches for all tasks in the ready/running state.
• From the set of tasks in the ready/running state, the scheduler determines the set of tasks with the highest priority.
• Within the set of tasks in the ready/running state and of highest priority, the scheduler finds the oldest task. 

Termination of tasks 

In the OSEK operating system, a task can only terminate itself ("self-termination").

Each task shall terminate itself at the end of its code.

Scheduling policy

• Full preemptive scheduling: Full preemptive scheduling means that a task which is presently running may be rescheduled at any instruction by the occurrence of trigger conditions pre-set by the operating system. 
• Full preemptive scheduling will put the running task into the ready state, as soon as a higher priority task has got ready.
• The task context is saved so that the preempted task can be continued at the location where it was preempted.
• Non preemptive scheduling: The scheduling policy is described as non preemptive, if task switching is only performed via one of  a selection of  explicitly defined system  services (explicit points of  rescheduling).
• Specifically the non preemptable section of a running task with lower priority delays the start of a task with higher priority up to the next point of rescheduling.
• Mixed preemptive scheduling:  If preemptable and non preemptable tasks are mixed on the same system, the resulting policy is called "mixed preemptive" scheduling.
• If the running task is non preemptable, then non preemptive scheduling is performed. If the running task is preemptable, then preemptive scheduling is performed. 

Interrupt processing 

The functions for processing an interrupt (Interrupt Service Routine: ISR) are subdivided into two ISR categories: 

• ISR category 1: The ISR does not use an operating system service. After the ISR is finished, processing continues exactly at the instruction where the interrupt has occurred, i.e. the interrupt has no influence on task management. ISRs of this category have the least overhead. 
• Cat1 interrupts are not supported by the OS and are only allowed to make a very small selection of OS calls to enable and disable all interrupts
• ISR category 2: The OSEK operating system provides an ISR-frame to prepare a run-time environment for a dedicated user routine. During system generation the user routine is assigned to the interrupt. 
• Cat2 ISRs are supported by the OS and can make OS calls

Event mechanism

Events are objects managed by the operating system. They are not independent objects, but assigned to extended tasks. Each extended task has a definite number of events.

• Events are the criteria for the transition of extended tasks from the waiting state into the ready state. The operating system provides services for setting, clearing and interrogation of events and for waiting for events to occur. 
• The meaning of events is defined by the application, e.g. signalling of an expiring timer, the availability of a resource, the reception of a message, etc.

The event mechanism

• is a means of synchronisation
• is only provided for extended tasks
• initiates state transitions of tasks to and from the waiting state. 

Resource management 

The resource management is used to co-ordinate concurrent accesses of several tasks with different priorities to shared resources, e.g. management entities (scheduler), program sequences, memory or hardware areas.


Resource management ensures that

• two tasks cannot occupy the same resource at the same time.
• priority inversion can not occur.
• deadlocks do not occur by use of these resources.
• access to resources never results in a waiting state.

General problems with synchronisation mechanisms

• Priority inversion: This means that a lower-priority task delays the execution of higher-priority task. OSEK prescribes the OSEK Priority Ceiling Protocol to avoid priority inversion.
• Deadlocks: deadlock means the impossibility of task execution due to infinite waiting for mutually locked resources.

Alarms and Counters

Alarms are provides support for processing of recurring events

• recurring events are registered by implementation specific counters
• Based on the Counters the OSEK OS provides alarm mechanism to the application developer.
• An alarm will expire when a predefined counter value is reached.
• The OSEK operating system provides services to activate tasks, set events or call an alarm-callback routine when an alarm expires.

A counter is represented by a counter value, measured in ”ticks”, and some counter specific constants

• The OSEK operating system offers at least one counter that is derived from a (hardware or software) timer.
• Counters and alarms are defined statically. The assignment of alarms to counters, as well as the action to be performed when an alarm expires, is defined statically, too

Error handling, tracing and debugging

Hook routines: The OSEK operating system provides system specific hook routines to allow user-defined actions within the OS internal processing.

• StartupHook:  this corresponding hook routine is called  at OS start
• is called before the scheduler is running.
• can be used for Initialization purpose
• ShutdownHook: The corresponding hook routine (ShutdownHook) is called when a system shutdown is requested by the application or by the operating system in case of a severe error.
• PreTaskHook: This hook routine is called by the operating system before executing a new task, but after the transition of the task to the running state.
• PostTaskHook: This hook routine is called by the operating system after executing the current task, but before leaving the task's running state.
• ErrorHook: The error hook routine (ErrorHook) is called if a system service returns a StatusType value not equal to E_OK.

Error handling : An error service is provided to handle temporarily and permanently occurring errors within the OSEK operating system.

• Application errors: It is up to the user to decide what to do depending on which error has occurred
• Fatal errors: In this case the operating system calls the centralized system shutdown.
• In case of fatal errors, the system service does not return to the application, but activates ShutdownOS

Error management: ErrorHook also is called if an error is detected during task activation or event setting, for example upon alarm expiration or message arrival.

Debugging

PreTaskHook and PostTaskHook, These two hook routines may be used for debugging or time measurement (including context switch time)

• PostTaskHook is called each time directly before the old task leaves the RUNNING state.
• PreTaskHook is called each time directly after a new task enters the RUNNING state. Because the task is still/already in the RUNNING state, GetTaskId does not return INVALID_TASK. 

Specification of operating system services

Below table illustrates the available OS services and syntax.