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