OSEK VDX KHASIM DURGAM OSEK VDX Agenda OSEKVDX

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 e. Xecutive 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 Opel. AG BMW AG Daimler. Chrysler AG FIAT- Centro Ricerche Ford Europe GM Europe Gmb. H Porsche AG PSA Renault Volkswagen AG Volvo Car Corporation Blaupunkt, Borg Instruments Gmb. H Continental Teves Cummins Engine Company Delco Electronics Denso Hella KG Lucas. Varity Magneti Marelli Philips Car Systems Robert Bosch Gmb. H Sagem Electronic Division Siemens. VDO Automotive AG TEMIC UTA - United Technologies Automotive Valeo Electronics Visteon Accelerated Technology Inc. ACTIA AFT Gmb. H Ashling ATM Computer Gmb. H C&C Electronics Cambridge Consultants EDS Epsilon Gmb. H ETAS Gmb. H & Co KG FZI Greenhills Grupo Antolin Hewlett Packard France Hitachi Micro Systems Europe Ltd. Hitex IBM Deutschland Entwicklung Gmb. H Infineon INRIA Integrated Systems Inc. IRISA IIIT - University of Karlsruhe Lauterbach Metrowerks Mecel Motorola National Semiconductor NEC Electronics Gmb. H Noral NRTA Softing Gmb. H ST Mircroelectronics Stenkil Systems AB Sysgo Real-Time Solutions Gmb. H TECSI Telelogic Gmb. H Texas Instruments Thomson-CSF Detexis Trialog Vector Informatik Wind River Systems 3 Soft Gmb. H ©

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/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 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/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 ECC 2 ECC 1 BCC 2 BCC 1 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 (Wait. Event API call) Waiting Running Preempt Release Start Ready Terminate Suspended Activate ©

OSEK/VDX Operating System > 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 & Non. 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 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 Get. Resource call to indicate they are going to use a shared resource Tasks (and interrupts make a Release. Resource 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 S 1 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 T 0 has the highest, and task T 4 the lowest priority. Task T 1 and task T 4 access the same standard resource. Task T 4 get the resource and raise its priority to the ceiling priority. Task T 0 preempts task T 4 because its has a higher priority. When task T 0 finishes, task T 4 continues to run and release the standard resource. Task T 1 which is ready to run get the resource and preempts task T 4. Task T 4 is put into ready state. Task T 1 finishes and release resource. Since task T 2 and T 3 are ready, task T 4 must wait for task T 2 and T 3 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 T 1) Alarm: 15 (Set Event E 1) . . . T 1 Activated! E 1 Set! Standardised OSEK OS Application View Implementation Specific OSEK/VDX Operating System > Alarms ©

OSEK/VDX Operating System > Hook Routines Startup. Hook • Called at OS startup, interrupt disabled • Can be used for initialization purpose Shutdown. Hook • Called at OS shutdown, interrupt disabled • Can be used for epilogue purpose Pre. Task. Hook • Called when a task enters the running state of a task • Not to be used due to CPU time consumption Post. Task. Hook • Called when a task exits the running state of a task • Not to be used due to CPU time consumption ©