1 / 28

OSEK / VDX KHASIM DURGAM

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

kyoko
Download Presentation

OSEK / VDX KHASIM DURGAM

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. OSEK / VDXKHASIM DURGAM

  2. OSEK / VDX > Agenda • OSEK/VDX Standard - Overview • OSEK/VDX Operating System – Overview (Task Concept, Scheduler, Events)

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

  4. OSEK/VDX > Who is OSEK/VDX? • Steering Committee (initial partners) •  Decision level (ex. ISO standardization), Meeting every 3 months

  5. 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 • 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 • 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

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

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

  8. Electronic Control Unit Embedded Control Software OSEK/VDX OS IO SW Function D Actuators OSEK/VDX NM Function C Function B Function A Sensors OSEK/VDX COM System Bus (e.g. CAN) OSEK/VDX > Automotive Embedded Control Software >OSEK/VDX Architecture

  9. OSEK/VDX > OSEK COM Architecture

  10. HW Platform A HW Platform B OSEK/VDX OS OSEK/VDX OS Application Application OSEK/VDX NM OSEK/VDX NM OSEK/VDX COM OSEK/VDX COM OIL OIL Bus protocol x Bus protocol y OSEK/VDX > Goals & Motivations > Reusability

  11. HW Platform HW Platform OSEK/VDX OS OSEK/VDX OS HW Platform OSEK / VDX NM OSEK / VDX NM OSEK/VDX OS OSEK/VDX COM OSEK/VDX COM OSEK / VDX NM A B C B A C OSEK/VDX COM HW Platform OSEK / VDX NM OSEK/VDX COM OSEK/VDX OS OSEK/VDX > Goals & Motivations > Distributed functions

  12. ISR RESOURCE EVENT TASK HOOK MESSAGE COUNTER ALARM OSEK/VDX Operating System > Overview • - 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

  13. Overheads BCC1 BCC2 ECC1 ECC2 Features 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

  14. Wait Waiting Release 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 Terminate Suspended Preempt Start Ready Activate

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

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

  17. OSEK/VDX Operating System > Preemptive & Non-Preemptive Scheduling Non- Preemptive Scheduling Preemptive Scheduling

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

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

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

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

  22. 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 high S1 ceiling =

  23. OSEK/VDX Operating System > Priority Inversion

  24. OSEK/VDX Operating System > Deadlock

  25. OSEK/VDX Operating System > Solution for Priority Inversion & Deadlock • 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.

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

  27. OSEK/VDX Operating System > Alarms Counter Source ImplementationSpecific Counter: 11 Counter: 12 Counter: 13 Counter: 14 Counter: 15 Alarm: 13(Activate T1) T1 Activated! Standardised OSEKOS Application View Alarm: 15(Set Event E1) E1 Set! . . .

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

More Related