T S PRADEEPKUMARSCS, VIT University

OSEK/VDXA Real Time Operating

System

• Automotive Software Standards• Introduction to OSEK/VDX• OSEK/VDX Characteristics and Specification• OSEK Architecture• Conformance Classes (CC)• Tasks Concepts• Interrupts Processing• Events• Scheduling Policies• Other OS Services

Topics for discussion

Automotive Software Standard

• AUTOSAR• Automotive Open System Architecture

• OSEK/VDX• Open systems and the corresponding

interfaces for automotive electronics / Vehicle Distributed eXecutive

• MISRA C• Motor Industries Software Reliability

Association

OSEK/VDX Characteristics• Scalability

• Used for wide range of control units for 8bit to 32 bit controllers

• Uses four conformance classes that specifies the main features

• Portability of software• ISO/ANSI-C Standard interface between the application

and the OS• Configurability

• Standard configurable information is provided with the help of OIL (OSEK Implementation Language)

• Statically allocated OS• To simplify, The OS, application tasks, resources and

services are requested to define at the compile time

OSEK/VDX Specification• Three Processing Levels

• Interrupt Level• A logical level for OS Activities• Task Level The interrupt levels are assigned higher priorities

than the task levels• In addition

• OS Services provided for task management, event management, resource, counter, alarm and error treatment

OSEK/VDX Specification

OSEK/VDX Architecture

OSEK COM• The OSEK standard comprises also an agreement

on interfaces and protocols for in-vehicle communication called OSEK COM

• An Interaction layer which provides communication services for the transfer of application messages.

• A Network layer which provides services for the unacknowledged and segmented transfer of application messages

• A Data link layer interface which provides services for the unacknowledged transfer of individual data packets over a network to the layers above.

OSEK NW• Very often electronic control units (ECU) made by

different manufacturers are networked within vehicles by serial data communication links.

• For this reason the standard propose a Network Management system (OSEK NM) that provides standardized features which ensure the functionality of inter-networking by interfaces.

OSEK/VDX Architecture• Traditional Fixed Priority Approach• Each task in the system may be

• Basic Task (BT)• Extended Task (ET)• Each Task will be assigned a fixed Priority

(assigned at compile time)

OSEK/VDX Architecture• Conformance Classes

• To provide support for different features and requirements of the application in terms of number of tasks, memory consumption, etc

• BCC1• Only basic tasks limited to one activation request per

task and one task per priority, while all tasks have different priorities.

• BCC2• Like BCC1, plus more than one activation request per

task and more than one task per priority. • ECC1

• Like BCC1, plus extended tasks. • ECC2

• Like ECC1, plus more than one task per priority and multiple requesting of task activation allowed for basic tasks.

Conformance Classes

Tasks Concepts• Basic Task

• Basic tasks only release the processor, if• they terminate• the OSEK operating system switches to a higher-priority

task, or interrupt occurs which cause the processor to switch to an interrupt service routine (ISR).

• Extended Tasks• In contrast to basic tasks extended tasks are allowed to use

the operating system call WaitEvent, which may result in a waiting state

• The waiting state allows the processor to be released and to be reassigned to a lower-priority task without the need to terminate the running extended task

• In view of the operating system, management of extended tasks is, in principle, more complex than management of basic tasks and requires more system resources

Tasks Concepts

Tasks Concepts•Extended Tasks have four task states:• Running

• Only one task can be in this state at any point in time

• Ready • The scheduler decides which ready task is

executed next• Waiting

• A task cannot continue execution because it has to wait for at least one event

• Suspended • The task is passive and can be activated

Interrupt ProcessingIn particular, the standard provides two kind of ISR handlers: • ISR Category 1

• ISR does not use an OS Service. • No OS calls from the handler• The designer is free to write his own handler • These are the faster highest priority

Interrupt • ISR Category 2

• ISR is handled by the OS• So OS calls can be called from the

handler

Events• Event Mechanism is provided only for

Extended Tasks

• Each (ET) owns a set of events that can be triggered by other BT or ET or even ISR Category 2

• The behavior of an ET is to wait for an Asynchronous Event calling the OS Service WaitEvent()

• Events can be set only if the task is not in the suspended state

Scheduling Policy• Mixed Preemptive Scheduling

• Non Preemptive scheduling

Scheduling Policy• Mixed Preemptive Scheduling• Since preemptiveness is a task

attribute, preemptive and non-preemptive tasks can be mixed in the same application.

• The running task will influence the policy really used.

Other OS Services• Alarm Management• Error Management

• Application Error• Fatal Error

• Leads to System Shutdown• System Startup