OSEK / VDX
KHASIM DURGAM
©
OSEK / VDX > Agenda
OSEK/VDX Standard - Overview
OSEK/VDX Operating System – Overview (Task Concept, Scheduler, Events)
©
OSEK/VDX > What is OSEK/VDX?
• Joint project of the European automotive industry
 Target: Define an industry standard for an open-ended
architecture for distributed control units in vehicles.
• Founded 1993
 OSEK: Offene Systeme und deren Schnittstellen für die
Elektronik im Kraftfahrzeug (“Open Systems and the
Corresponding Interfaces for Automotive Electronics”)
 VDX: Vehicle Distributed eXecutive
 Joined OSEK in 1994  OSEK/VDX
• On the way to a worldwide ISO standard
 ISO 17356: Open interfaces for embedded automotive applications.
• Web site
 http://www.osek-vdx.org
©
OSEK/VDX > Who is OSEK/VDX?
• Steering Committee (initial partners)
 Decision level (ex. ISO standardization), Meeting every 3 months
©
OSEK/VDX > Who is OSEK/VDX?
• Technical Committee (Associated partners to actively co-operate)
Adam OpelAG
BMW AG
DaimlerChrysler AG
FIAT- Centro Ricerche
Ford Europe
GM Europe GmbH
Porsche AG
PSA
Renault
Volkswagen AG
Volvo Car Corporation
Blaupunkt, Borg Instruments GmbH
Continental Teves
Cummins Engine Company
Delco Electronics
Denso
Hella KG
LucasVarity
Magneti Marelli
Philips Car Systems
Robert Bosch GmbH
Sagem Electronic Division
SiemensVDO Automotive AG
TEMIC
UTA - United Technologies Automotive
Valeo Electronics
Visteon
Accelerated Technology Inc.
ACTIA
AFT GmbH
Ashling
ATM Computer GmbH
C&C Electronics
Cambridge Consultants
EDS
Epsilon GmbH
ETAS GmbH & Co KG
FZI
Greenhills
Grupo Antolin
Hewlett Packard France
Hitachi Micro Systems Europe Ltd.
Hitex
IBM Deutschland Entwicklung GmbH
Infineon
INRIA
Integrated Systems Inc.
IRISA
IIIT - University of Karlsruhe
Lauterbach
Metrowerks
Mecel
Motorola
National Semiconductor
NEC Electronics GmbH
Noral
NRTA
Softing GmbH
ST Mircroelectronics
Stenkil Systems AB
Sysgo Real-Time Solutions GmbH
TECSI
Telelogic GmbH
Texas Instruments
Thomson-CSF Detexis
Trialog
Vector Informatik
Wind River Systems
3Soft GmbH
©
OSEK/VDX > OSEK Specifications
OSEK OS
– serves as a basis for the controlled real-time execution of concurrent applications
OSEK OIL
– OIL provides a possibility to configure an OSEK/VDX application inside a particular CPU
OSEK COM / NM
– provides interfaces and protocols for the transfer of data within vehicle networks
©
OSEK/VDX > Goals & Motivations
• Definition of standardized interfaces & protocols (HW & Network independent)
 Portability, Reusability & Extendibility of SW (through different HW platforms
& different applications)
 Possible "co-habitation" of software from different suppliers
 Independence regarding a particular implementation
• Definition of configurable & scalable functionalities
 Optimal adjustment of the architecture to a particular context (i.e. same
OSEK/VDX interfaces, but different implementations, depending on the hardware
architecture and the performance required)
 Quality improvement
 Savings in costs and development time
©
OSEK/VDX > Automotive Embedded Control Software >
OSEK/VDX Architecture
Electronic Control Unit
Embedded Control Software
OSEK/VDX OS
Function D
OSEK/VDX
NM
Function C
Function B
IO
Actuators
SW
Function A
Sensors
OSEK/VDX COM
System Bus (e.g. CAN)
©
OSEK/VDX > OSEK COM Architecture
OSEK OS (Operating system)
Application SW
OSEK COM
Interaction layer
OSEK NM
Network Layer
Data link layer
Bus communication HW
©
OSEK/VDX > Goals & Motivations > Reusability
HW Platform A
HW Platform B
OSEK/VDX OS
OSEK/VDX
NM
OSEK/VDX OS
Application
OSEK/VDX
NM
OSEK/VDX COM
OIL
Application
OSEK/VDX COM
OIL
Bus protocol x
Bus protocol y
©
OSEK/VDX > Goals & Motivations > Distributed functions
HW Platform
HW Platform
OSEK
/
VDX
OSEK/VDX OS
OSEK
/
VDX
NM
A
B
HW Platform
OSEK/VDX OS
A
OSEK/VDX COM
OSEK
/
VDX
NM
OSEK/VDX OS
B
OSEK/VDX COM
C
NM
OSEK/VDX COM
HW Platform
OSEK OSEK/VDX COM
/
VDX
C
NM
OSEK/VDX OS
©
OSEK/VDX Operating System > Overview
ISR
COUNTER
ALARM
TASK
EVENT
MESSAGE
RESOURCE
HOOK
- Single processor operating system
 Implementations available for
8/16/32 bit µC
- Minimum ROM, RAM and CPU time
consumption
 Statically defined resources (tasks,
events, alarms, ...)
 Different levels of functionality
(conformance classes)
- Standardized operating system
behavior and interfaces for the
application
 Services defined according to the
ISO/ANSI-C syntax
 Independent from a specific µC
©
OSEK/VDX Operating System > Conformance Classes
Four conformance classes in the one standard
– provides convenient groups of features to ease understanding
– enables partial implementations
– scalability
BCC: Basic tasks
ECC: Extended tasks
Level 1: One task per priority,
one activation per task
Level 2: More than one task
per priority and more than
one activation per task
Overheads
ECC2
ECC1
BCC2
BCC1
Features
©
OSEK/VDX Operating System > Task management
Basic tasks only release the processor if
– they terminate, the OSEK OS switches to a higher priority task (preemption) or an
interrupt occurs
Extended tasks
– can also wait on events (WaitEvent API call)
Wait
Waiting
Running
Preempt
Release
Start
Ready
Terminate
Suspended
Activate
©
OSEK/VDX Operating System > Scheduler
Scheduler
•The scheduler decides on the basis of the task priority which is the next
of the ready tasks to be transferred into the running state.
• A preempted task is considered to be the first (oldest) task in the ready list of
its current priority.
• A task being released from the waiting state is treated like the last (newest) task
in the ready queue of its priority.
©
OSEK/VDX Operating System > Scheduler
The fundamental steps to determine the next task to be processed are:
• 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.
©
OSEK/VDX Operating System > Preemptive & NonPreemptive Scheduling
Non- Preemptive Scheduling
Preemptive Scheduling
©
OSEK/VDX Operating System > Scheduling Policy
Mixed preemptive scheduling
– Policy depends on the preemption property of the running task
• If running task is non-preemptable then non-preemptive
scheduling is performed
• If running task is preemptable then preemptive scheduling is
performed
Which to use?
– Non-preemption makes sense when execution time of a task is short (same order as
task switching overhead), when RAM need to be conserved (no context save required)
and when task must not be preempted to provide atomic activity
©
OSEK/VDX Operating System > Interrupt Processing
Two interrupt service routine categories
– Category 1:
• ISR does not use OS services
• ISR executes above the priority level of the scheduler
• No additional interrupt latency due to the OS
– Category 2:
• ISR can use OS services, e.g. activate tasks, etc.
• ISR executes under the control of the scheduler
• OS imposes some additional latency to set up the ISR
environment
©
OSEK/VDX Operating System > Messages, Events
Event mechanism gives a means of synchronisation for extended tasks
– Each extended task is associated with one or more events
– An extended task may wait for an event with which it is associated
– Any task or category 2 ISR may set an event
• This moves the waiting extended task from the waiting state to
the ready state
• Depending on the scheduling policy and the extended tasks
priority level it will then move into the running state
– An extended task may then clear the events with which it is associated
©
OSEK/VDX Operating System > Resource management
Resource management is used to co-ordinate concurrent access to shared resource,
e.g. memory, hardware, etc.
Resource management ensures
– two tasks (or interrupts) cannot occupy the same resource at the same time, i.e. provides
atomic access to critical sections
Tasks (and interrupts) make a GetResource call to indicate they are going to use a
shared resource
Tasks (and interrupts make a ReleaseResource call to indicate they have finished with
a shared resource
©
OSEK/VDX Operating System > Resource management
OSEK requires the use of the priority ceiling protocol for resource management:
–
–
–
–
Priority inversion minimised
Deadlock cannot occur
Access to resource never results in a waiting state
Can be analysed to enable real-time performance to be guaranteed
S1
ceiling =
high
©
OSEK/VDX Operating System > Priority Inversion
©
OSEK/VDX Operating System > Deadlock
©
OSEK/VDX Operating System > Solution for Priority
Inversion & Deadlock
1.
2.
3.
4.
5.
6.
Task T0 has the highest, and task T4 the lowest priority.
Task T1 and task T4 access the same standard resource.
Task T4 get the resource and raise its priority to the ceiling priority.
Task T0 preempts task T4 because its has a higher priority. When task T0 finishes, task T4 continues to run
and release the standard resource.
Task T1 which is ready to run get the resource and preempts task T4. Task T4 is put into ready state.
Task T1 finishes and release resource. Since task T2 and T3 are ready, task T4 must wait for task T2 and
T3 to complete before it can continues its tasks.
©
OSEK/VDX Operating System > Alarms
Provides support for processing recurring events
– The recurring events (sources) are registered by implementation specific counters
– Based on the counters the OSEK OS provides alarm mechanisms to the application
developer
Counters provide a counter value measured in ‘ticks’
Alarms expire when a predefined counter value is reached, it can then:
– Activate a task
– Set an event
©
Counter Source
Counter: 15
11
12
13
14
Alarm: 13
(Activate T1)
Alarm: 15
(Set Event E1)
...
T1 Activated!
E1 Set!
Standardised OSEK
OS Application View
Implementation
Specific
OSEK/VDX Operating System > Alarms
©
OSEK/VDX Operating System > Hook Routines
StartupHook
• Called at OS startup, interrupt disabled
• Can be used for initialization purpose
ShutdownHook
• Called at OS shutdown, interrupt disabled
• Can be used for epilogue purpose
PreTaskHook
• Called when a task enters the running state of a task
• Not to be used due to CPU time consumption
PostTaskHook
• Called when a task exits the running state of a task
• Not to be used due to CPU time consumption
©