©

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)

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

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

Adam OpelAG

BMW AG

DaimlerChrysler AG

FIAT- Centro Ricerche

Ford Europe

GM Europe GmbH

Porsche AG

PSA

Renault

Volkswagen AG

Volvo Car Corporation

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

IO

SW

OSEK/VDX COM

System Bus (e.g. CAN)

Actuators

Sensors

OSEK/VDXNM

Function D

Function C

Function B

Function A

©

OSEK/VDX > OSEK COM Architecture

Data link layer

Bus communication HW

OSEK NM

Network Layer

Interaction layer

Application SW

OSEK COM

OSEK OS (Operating system)

©

OSEK/VDX > Goals & Motivations > Reusability

OSEK/VDX COM

OSEK/VDXNM

OSEK/VDX OS

OIL

HW Platform A

Application

Bus protocol x

OSEK/VDX COM

OSEK/VDXNM

OSEK/VDX OS

OIL

HW Platform B

Bus protocol y

Application

©

OSEK/VDX > Goals & Motivations > Distributed functions

OSEK/VDX COM

OSEK/

VDX

NM

OSEK/VDX OS

HW Platform

AB

C

OSEK/VDX COM

OSEK/

VDX

NM

OSEK/VDX OS

HW Platform

OSEK/VDX COM

OSEK/VDX OS

HW Platform

OSEK/VDX COM

OSEK/

VDX

NM

OSEK/VDX OS

HW Platform

OSEK/

VDX

NM

B

C

A

©

COUNTER

OSEK/VDX Operating System > Overview

ALARM

EVENT

HOOK

RESOURCE

TASK

ISR

MESSAGE

- 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 taskper priority and more thanone activation per task

Overheads

Features

BCC1

BCC2

ECC1

ECC2

©

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)

Running

Ready

SuspendedWaiting

Wait

Release

Preempt

Start

Activate

Terminate

©

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 > SchedulerThe 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 & Non-Preemptive Scheduling

Preemptive Scheduling

Non- 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

S1 ceiling = high

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

©

OSEK/VDX Operating System > Priority Inversion

©

OSEK/VDX Operating System > Deadlock

©

OSEK/VDX Operating System > Solution for Priority Inversion & Deadlock

1. Task T0 has the highest, and task T4 the lowest priority.

2. Task T1 and task T4 access the same standard resource.

3. Task T4 get the resource and raise its priority to the ceiling priority.

4. 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.

5. Task T1 which is ready to run get the resource and preempts task T4. Task T4 is put into ready state.

6. 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

©

OSEK/VDX Operating System > Alarms

Counter: 11

Counter Source

Imp

lem

enta

tion

Speci

fic

Sta

ndard

ised O

SE

KO

S A

pplic

ati

on V

iew

Alarm: 13(Activate T1)

Alarm: 15(Set Event E1)

. . .

Counter: 12Counter: 13Counter: 14Counter: 15

T1 Activated!

E1 Set!

©

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