1. Bertrand N’Goy, Vincent CAMUS pulse-AR
pulse your Business with
AUTOSAR OS
Bertrand N’Goy, Vincent CAMUS
pulse-AR

2. AUTOSAR OS, RTE & EcuM
Background

3. OSEK/VDX
OSEK stands for : „Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug“
Consortium founded in 1993 by German automotive companies
In 1994, French automotive manufacturers Renault and PSA which was developing a similar project called VDX joined the consortium.

4. OSEK/VDX
OSEK/VDX standard provides an open software architecture for various ECUs embedded on a car.
The standard specifies:
Communication stack (data exchange between different ECUs).
Network management
Embedded real-time operating system

5. OSEK/VDX
OSEK/VDX standard provides an open software architecture for various ECUs embedded on a car.
The standard specifies:
Communication stack (data exchange between different ECUs).
Network management
Embedded real-time operating system

6. OSEK/VDX OS Main features
OSEK/VDX OS – Main features – standardized Interfaces
Identical interfaces for all implementations of the OS on various processor families.
Interface between the application software and the OS is defined by system services.

7. OSEK/VDX OS Main features
OSEK/VDX OS – Main features – Scalability
Compliant with a broad spectrum applications and hardware :
Various scheduling mechanisms
Configuration features

8. OSEK/VDX OS Main features
OSEK/VDX OS – Main features – Portability of application software
Ensure the portability and the re-usability of application software.
Portability = application software transferability from on ECU to another.
Module 1
Module 2
Module 3
Module n
Application
software
OSEK/VDX OS
I/O System
MCU Hardware
Software interfaces inside ECU

9. OSEK/VDX OS Static configuration and scalability
OSEK/VDX OS – automotive requirements
Static configuration and scalability
Code execution from Read Only Memory (ROM) available
Support applications tasks portability
Allows the implementation of predictable performance parameters.
Provides OS implementation that meets automotive real-time requirements.

10. OSEK/VDX OS architecture
AUTOSAR OS, RTE & EcuM
OSEK/VDX OS architecture

11. OSEK/VDX OS Architecture
The OSEK/VDX OS architecture offers the following services :
Tasks management
Interrupt processing
Events mechanisms
Resources management
Alarms

12. OSEK/VDX OS Architecture
The OSEK/VDX OS architecture offers the following services :
Tasks management
Interrupt processing
Events mechanisms
Resources management
Alarms

13. OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Tasks management
Framework for functions execution.
OSEK/VDX OS provides concurrent and asynchronous execution of tasks.
Provides a task switching mechanism (idle-mechanism).
Possess statically configured priority.
Two different task concepts:
Basic tasks
Extended tasks
BT only
BT & ET
BCC1
ECC1
1 task/priority
No multiple activations
BCC2
ECC2
> 1 task/priority
multiple activations
Conformance classes

14. OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Basic tasks
Release the processor if:
They terminate,
The scheduler switches to a higher-priority task,
An interrupt occurs.

15. OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Basic tasks
State model:
Running:
CPU assigned to the task.
Only one task can be in this state at a time.
Ready:
All functional prerequisites for a transition to the Running state exists.
The scheduler decides which Ready task is executed next.
Suspended :
Task is passive.
Can be activated.

16. OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Basic tasks
Running
Terminate
Suspended
Start
Preempt
Ready
Activate

17. OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Extended tasks
Release the processor if:
They terminate,
The scheduler switches to a higher-priority task,
An interrupt occurs.
Can use the OS events management
Access to the WaitEvent system call.
More complex than basic tasks management.

18. OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Extended tasks
State model:
Running:
CPU assigned to the task.
One task can be in this state at a time.
Ready:
All functional prerequisites for a transition to the Running state exists.
The scheduler decides which Ready task is executed next.
Suspended:
Task is passive.
Can be activated.
Waiting:
Stop execution.
Waits for at least one event.

19. OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Extended tasks
Running
Terminate
Wait
Waiting
Suspended
Start
Preempt
Ready
Release
Activate

20. OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Basic vs. Extended Tasks
Basic tasks:
No waiting state.
Synchronization points only at the beginning and the end of the task.
Moderate requirement regarding run-time context (RAM).
Extended tasks:
Can handle a coherent job in a single task.
Can wait for a specific information required for further processing.
Contains more synchronization points.
Require more run-time context.

21. OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Tasks management
System services:
StatusType ActivateTask(TaskType <TaskID>)
StatusType TerminateTask(void)
StatusType ChainTask(TaskType <TaskID>)
StatusType Schedule(void)
StatusType GetTaskID(TaskRefType <TaskID>)
StatusType GetTaskState(TaskType <TaskID>, TaskStateRefType <State>)

22. OSEK/VDX OS Architecture
The OSEK/VDX OS architecture offers the following services :
Tasks management
Interrupt processing
Events mechanisms
Resources management
Alarms

23. OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Interrupts processing
ISR category 1:
Does not use any operating system service.
No influence on task management.
Few overhead.
ISR category 2:
Handled by the operating system.
ISR-frame that prepare a run-time environment for a dedicated user routine.
Rescheduling on termination.
ISR category 1 { /*
** code without any API calls */ }
ISR category 2
ISR(isr_name) { /*
** code with API calls */ }

24. OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – ISR category 1 {
IrqDisable(); /*
** ISR process */
IrqEnable(); }
IRQ { /*
** main process
** execution */ }
Save context
Restore context

25. OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – ISR category 2 {
IrqDisable();
SetCurrTaskReady();
IrqEnable();
isr_process();
Schedule(); } 1 { /*
** main process
** execution */ }
IRQ
Save context
Preempted task was the most prioritary 3
Get top prio task and activate it.
a more prioritary task was found, so execute it. { /*
** other task
** process */ }
Tasks pool 2 t1 t2 tn

26. OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Interrupts processing
System services:
void EnableAllInterrupts(void)
void DisableAllInterrupts(void)
void ResumeAllInterrupts(void)
void SuspendAllInterrupts(void)
void ResumeOSInterrupts(void)
void SuspendOSInterrupts(void)

27. OSEK/VDX OS Architecture
The OSEK/VDX OS architecture offers the following services :
Tasks management
Interrupt processing
Events mechanisms
Resources management
Alarms

28. OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Events mechanisms
Objects assigned to extended tasks.
Events are identified using their owner and name (or mask).
Event services provided by the OS:
SetEvent (BT/ET)
ClearEvent (owner)
GetEvent (ET)
WaitEvent (owner)

29. OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Events mechanisms
Full preemptive scheduling example:
Scheduler
set
Event of extended task T1
clear
clear
ready
Extended task T1
Priority: 2
waiting
running
waiting
ClearEvent
WaitEvent
Extended task T2
Priority: 1
running
ready
running
SetEvent

30. OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Events mechanisms
Synchronization of non preemptable tasks example:
Scheduler
set
Event of extended task T1
clear
clear
Extended task T1
Priority: 2
waiting
ready
running
waiting
WaitEvent
ClearEvent
Extended task T2
Priority: 1
running
ready
running
SetEvent
Rescheduling

31. OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Events mechanisms
System services:
StatusType SetEvent (TaskType <TaskID>, EventMaskType <Mask>)
StatusType ClearEvent (EventMaskType <Mask>)
StatusType GetEvent (TaskType <TaskID>, EventMaskRefType <Event>)
StatusType WaitEvent (EventMaskType <Mask>)

32. OSEK/VDX OS Architecture
The OSEK/VDX OS architecture offers the following services :
Tasks management
Interrupt processing
Events mechanisms
Resources management
Alarms

33. OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Resources management
Used to co-ordinate concurrent accesses of tasks with different priorities to shared resources like:
Program sequences .
Memory.
Hardware areas.
Etc…
It ensures that:
Two tasks cannot occupy the same resource at the same time.
Priority inversion and deadlocks can not occur.

34. OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Resources management
Priority inversion problem:
a low-priority task delays the execution of higher-priority tasks.
Access to semaphore 1 denied
ready T1
Priority: highest
suspended
running
waiting
running T2
suspended
ready
running
suspended T3
suspended
ready
running
suspended T4
Priority: lowest
running
ready
running
ready
Semaphore 1 released
Semaphore 1 occupied

35. OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Resources management
Priority inversion problem:
a low-priority task delays the execution of higher-priority tasks.
Access to semaphore 1 denied
ready T1
Priority: highest
suspended
running
waiting
running T2
suspended
ready
running
suspended T3
suspended
ready
running
suspended T4
Priority: lowest
running
ready
running
ready
Semaphore 1 released
Semaphore 1 occupied

36. OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Resources management
Deadlock problem:
Infinite waiting for mutually locked resources
Event happened
e.g. wait for event
Access to semaphore 2 denied
Access to semaphore 1
ready T1
running
waiting
running
waiting T2
ready
running
ready
running
waiting
Access to semaphore 2
Access to semaphore 1 denied

37. OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Resources management
Deadlock problem:
Infinite waiting for mutually locked resources
Event happened
e.g. wait for event
Access to semaphore 2 denied
Access to semaphore 1
ready T1
running
waiting
running
waiting T2
ready
running
ready
running
waiting
Deadlock!
Access to semaphore 2
Access to semaphore 1 denied

38. OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Resources management
Priority Ceiling Protocol (PCP):
OSEK/VDX solution to priority inversion and deadlocks problems.
Principles:
At the system generation, a static ceiling priority is assign to each resource:
Highest priority of all tasks accessing the resource.
Lower than the lowest priority of all tasks that does not access the resource but that have priorities higher than the highest priority of all tasks accessing the resource.
If a task requires a resource, the priority of this task is raised to the ceiling priority of the resource.
If a task release a resource, its priority is reset to the value assigned before acquiring the resource.

39. OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Resources management
Priority Ceiling Protocol (PCP):
Example:
5 tasks: T1, T2, T3, T4, T5
1 resource : R1
T2 and T5 want both to access R1.
Priorities: P5 < P4 < P3 < P2 < P1

40. OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Resources management
Priority Ceiling Protocol (PCP):
Example:
Release resource
Release resource
T1:
Priority: highest
suspended
running
suspended
Ceiling priority:
running
ready
T2:
suspended
ready
running
running
suspended
T3:
suspended
ready
running
suspended
T4:
suspended
ready
running
T5:
Priority: lowest
running
ready
Request resource
Request resource

41. OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Resources management
Internal resources
Not visible to the user (cannot be addressed by systems functions GetResource() or ReleaseResource()).
Managed strictly internally.
Besides that, exactly the same behavior than regular resources (PCP, etc…).
Restricted to tasks (at most one internal resource assigned per task during system generation).

42. OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Resources management
Internal resources
When assigned to a task, the internal resource is managed as follow:
Resource automatically taken when the task enters the running state (task’s priority changed to the ceiling priority of the task).
Resource released at the point of rescheduling (call to Schedule()).
can be used in a group of tasks to avoid not-wanted rescheduling.

43. OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Resources management
System services:
StatusType GetResource (ResourceType <ResID>)
StatusType ReleaseResource (ResourceType <ResID>)

44. OSEK/VDX OS Architecture
The OSEK/VDX OS architecture offers the following services :
Tasks management
Interrupt processing
Events mechanisms
Resources management
Alarms

45. OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Alarms
Services provided for processing recurring events such as:
Activate a task,
set events,
call an alarm-callback routine.
Statically assigned at system generation time to:
One counter,
One task/alarm-callback routine.
Implementation OS internal
Application view
task
Activate a task /
set event for this task
counter
alarm
alarm
Alarm-callback
ALARMCALLBACK(BrakePedalStroke) {
/* do application processing */ }
alarm
Call alarm-callback routine
Source for counter

46. OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Alarms
System services:
StatusType GetAlarmBase (AlarmType <AlarmID>, AlarmBaseRefType <Info>)
StatusType GetAlarm (AlarmType <AlarmID>, TickRefType <Tick>)
StatusType SetRelAlarm (AlarmType <AlarmID>, TickType <increment>, TickType <cycle>)
StatusType SetAbsAlarm (AlarmType <AlarmID>, TickType <start>, TickType <cycle>)
StatusType CancelAlarm (AlarmType <AlarmID>)

47. AUTOSAR improvement on OSEK/VDX OS
AUTOSAR OS, RTE & EcuM
AUTOSAR improvement on OSEK/VDX OS

48. AUTOSAR Improvement
Timers API (GetCounterValue(), GetElapsedTime()) with initialization and configuration used directly by the OS module.
Stack monitoring facilities (E_OS_STACKFAULT ).
Protection facilities:
Memory protection
Timing protection
Schedule Tables
OS-Application

49. AUTOSAR Improvement
Timers API (GetCounterValue(), GetElapsedTime()) with initialization and configuration used directly by the OS module.
Stack monitoring facilities (E_OS_STACKFAULT ).
Protection facilities:
Memory protection
Timing protection
Schedule Tables
OS-Application

50. AUTOSAR Schedule tables
Autosar OS – Schedule Tables
Schedule tables provide an encapsulation of a statically defined set of expiry points that define:
At least one action that must occur when it is processed such as:
activate a task,
setting an event.
An offset in ticks from the start of the schedule table
A schedule table can contain multiple expiry points.
An OS application can contain multiple schedule table.

51. AUTOSAR Schedule tables
Structure of a schedule table:
Initial expiry point
Final expiry point
Expiry point 1:
Task Activation
Task A
Task B
Event Setting
Event1-TaskC
Event2-TaskD
Offset
4 ticks
Expiry point 2:
Task Activation
<none>
Event Setting
Event1-TaskC
Event2-TaskD
Offset
12 ticks
Expiry point 1:
Task Activation
Task C
Task D
Event Setting
<none>
Offset
20 ticks
Expiry point 1:
Task Activation
Task E
Task A
Event Setting
Event2-TaskB
Event1-TaskD
Offset
32 ticks
Initial
Delay: 4
Final
delay: 8 4 12 20 32 40
Schedule table duration = 40 ticks

52. AUTOSAR Improvement
Timers API (GetCounterValue(), GetElapsedTime()) with initialization and configuration used directly by the OS module.
Stack monitoring facilities (E_OS_STACKFAULT ).
Protection facilities:
Memory protection
Timing protection
Schedule Tables
OS-Application

53. AUTOSAR OS-Application
A collection of OS objects (Tasks, ISRs, Alarms, Schedule tables, Counters, Resources) that form a cohesive functional unit.
All objects from the same OS-Application have access to each other (access means that these objects are allowed has services parameters).
The right to access objects from other OS-Application may be granted during configuration.

54. AUTOSAR OS-Application
Two classes of OS-Application exists:
Trusted:
Allowed to run without protection features.
Have unrestricted access to memory and OS module’s API.
Allowed to run in privileged mode when supported by the processor.
Non-Trusted:
Have to run with monitoring and protection features enabled at runtime.
Have restricted access to memory and OS module’s API.
Not allowed to run in privileged mode.
The Operating System module is itself trusted.

55. AUTOSAR OS-Application
OS-Application have a state which defines the availability of its objects from other OS-Applications.
After StartOS() and
before StartupHooks()
ProtectionHook without RESTART OR
TerminateApplication without RESTART
APPLICATION_TERMINATED
Terminated and not accessible,
objects cannot be accessed from
other OS-Applications.
State will not change.
APPLICATION_ACCESSIBLE
AllowAccess()
Active and accessible, objects
may be accessed from other
OS-Applications.
Default state at startup.
APPLICATION_RESTARTED
ProtectionHook with RESTART OR
TerminateApplication with RESTART
Currently in restart mode,
objects cannot be accessed from
other OS-Applications.
State is valid until AllowAccess() is called.