Open systems and the corresponding interfaces for automotive electronics

Homepage of OSEK/VDX

Operating System 2.1r1

Automotive requirements :

Stringent real-time requirements
Low-level of resource usage (Memory resources)
Scaleability
Reliability
Cost sensitivity

Operating system requirements :

An OS to constitute the basis for the integration of software made by various manufacturers.
Support for portability of software modules to allow for re-use.
The OSEK/VDX OS specification does not cover :

Software development guidelines
File management system
Data allocation and stack usage of compilers
Memory architecture of ECU
Timing behaviour of ECU
Microcontroller specific architecture

Static configuration (scealability, scheduling policy)
ROMable

OSEK/VDX Operating System

Services

Task management

Activation and termination of tasks
Management of task states, task switch

Synchronisation

Resource management : access control for inseparable operations to jointly used (logic) resources or devices, or for control of a program flow.
Event control : event management for task synchronisation.

Interrupt management

Services for interrupt processing

Alarms

Relative and absolute alarms
Static (defined at compile-time) and dynamic (defined at run-time) alarms

Error treatment

Mechanisms supporting the user in case of various errors

Conformance Classes

To provide convenient groups of operating system features for easier understanding and discussion of the OSEK operating system.
To allow partial implementations along pre-defined lines. These partial implementations may be certified as OSEK compliant.
To create an upgrade path from classes of lesser functionality to classes of higher functionality with no changes to the application using OSEK related features.

Scheduling Policy

Non-preemptive scheduling

A task switch is only performed via one of a selection of explicitly defined system services (explicit points of rescheduling)
Non-preemptive scheduling imposes particular constraints on the possible timing requirements of tasks. 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.

Full-preemptive scheduling

A task which is presently running may be rescheduled at any instruction by the occurrence of trigger conditions pre-set by the operating system.
Restrictions are related to the increased (RAM-) memory space required for saving the context, and the enhanced complexity of features necessary for synchronisation between tasks.
Access to data which are used jointly with other tasks must be synchronised.

Mixed-preemptive scheduling

Mixture of Non-premptively and Full-preemptively scheduled task.

Resource Management

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.

The functionality of resource management is only required in the following cases :

full- or mixed-preemptive scheduling.
non-preemptive scheduling, if resources are also to remain occupied beyond a scheduling point.
non-preemptive scheduling, if the user intends to have the application code executed under other scheduling policies, too.

Last Update: 2000/11/16