Transcript OSEK/VDX OS Architecture

pulse your Business with
AUTOSAR OS
Bertrand N’Goy, Vincent CAMUS
pulse-AR
AUTOSAR OS, RTE & EcuM
BACKGROUND
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.
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
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
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.
OSEK/VDX OS Main features
OSEK/VDX OS – Main features – Scalability
• Compliant with a broad spectrum applications and
hardware :
– Various scheduling mechanisms
– Configuration features
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
OSEK/VDX OS
MCU Hardware
Software interfaces inside ECU
Module
n
I/O System
Application
software
OSEK/VDX OS
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.
AUTOSAR OS, RTE & EcuM
OSEK/VDX OS ARCHITECTURE
OSEK/VDX OS Architecture
• The OSEK/VDX OS architecture offers the
following services :
– Tasks management
– Interrupt processing
– Events mechanisms
– Resources management
– Alarms
OSEK/VDX OS Architecture
• The OSEK/VDX OS architecture offers the
following services :
–
– Interrupt processing
– Events mechanisms
– Resources management
– Alarms
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 (idlemechanism).
• Possess statically configured priority.
• Two different task concepts:
– Basic tasks
– Extended tasks
BT only
BT & ET
1 task/priority
No multiple activations
BCC1
ECC1
> 1 task/priority
multiple activations
BCC2
ECC2
Conformance classes
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.
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.
OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Basic tasks
Running
Terminate
Start
Preempt
Suspended
Activate
Ready
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.
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.
OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Extended tasks
Running
Terminate
Wait
Start
Waiting
Preempt
Release
Suspended
Activate
Ready
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.
OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Tasks management
• System services:
–
–
–
–
–
–
StatusType
StatusType
StatusType
StatusType
StatusType
StatusType
ActivateTask(TaskType <TaskID>)
TerminateTask(void)
ChainTask(TaskType <TaskID>)
Schedule(void)
GetTaskID(TaskRefType <TaskID>)
GetTaskState(TaskType <TaskID>,
TaskStateRefType <State>)
OSEK/VDX OS Architecture
• The OSEK/VDX OS architecture offers the
following services :
– Tasks management
–
– Events mechanisms
– Resources management
– Alarms
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 1
{
/*
** code without any API calls
*/
}
ISR category 2
• 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(isr_name)
{
/*
** code with API calls
*/
}
OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – ISR category 1
IRQ
{
/*
** main process
** execution
*/
}
{
IrqDisable();
/*
** ISR process
*/
IrqEnable();
}
OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – ISR category 2
{
IrqDisable();
1
{
SetCurrTaskReady();
IRQ
IrqEnable();
isr_process();
IrqDisable();
/*
** main process
** execution
*/
Preempted task was
the most prioritary
}
Schedule();
}
3
{
/*
** other task
** process
*/
}
a more prioritary
task was found,
so execute it.
Get top prio task and activate it.
Tasks pool
2
t1
t2
tn
OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Interrupts processing
• System services:
–
–
–
–
–
–
void
void
void
void
void
void
EnableAllInterrupts(void)
DisableAllInterrupts(void)
ResumeAllInterrupts(void)
SuspendAllInterrupts(void)
ResumeOSInterrupts(void)
SuspendOSInterrupts(void)
OSEK/VDX OS Architecture
• The OSEK/VDX OS architecture offers the
following services :
– Tasks management
– Interrupt processing
–
– Resources management
– Alarms
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)
OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Events mechanisms
• Full preemptive scheduling example:
Scheduler
set
Event of extended
task T1
Extended task T1
Priority: 2
Extended task T2
Priority: 1
clear
clear
ready
waiting
running
SetEvent
ClearEvent
running
ready
WaitEvent
waiting
running
OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Events mechanisms
• Synchronization of non preemptable tasks example:
Scheduler
set
Event of extended
task T1
Extended task T1
Priority: 2
Extended task T2
Priority: 1
clear
clear
waiting
running
ready
SetEvent Rescheduling
ClearEventrunning
ready
WaitEvent
waiting
running
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>)
OSEK/VDX OS Architecture
• The OSEK/VDX OS architecture offers the
following services :
– Tasks management
– Interrupt processing
– Events mechanisms
–
– Alarms
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.
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
T1
suspended
running
T2
suspended
ready
T3
suspended
T4
running
Priority: highest
Priority: lowest
waiting
running
ready
ready
running
suspended
running
suspended
running
ready
Semaphore 1 released
Semaphore 1 occupied
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
T1
suspended
running
T2
suspended
ready
T3
suspended
T4
running
Priority: highest
Priority: lowest
waiting
running
ready
ready
running
suspended
running
suspended
running
ready
Semaphore 1 released
Semaphore 1 occupied
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 1
Access to semaphore 2 denied
T1
running
waiting
running
T2
ready
running
ready
Access to semaphore 2
waiting
running
Access to semaphore 1 denied
waiting
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 1
Access to semaphore 2 denied
T1
running
waiting
running
T2
ready
running
ready
Access to semaphore 2
waiting
running
Access to semaphore 1 denied
waiting
Deadlock!
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.
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
OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Resources management
• Priority Ceiling Protocol (PCP):
– Example:
Release resource
T1:
Priority: highest
suspended
T2: suspended
T3:
suspended
T4:
suspended
ready
ready
running
running
ready
suspended
running
ready
Request resource
suspended
running
ready
T5: running
Priority: lowest
Request resource
suspended
running
running
Ceiling priority:
Release resource
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).
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.
OSEK/VDX OS Architecture
OSEK/VDX OS Architecture – Resources management
• System services:
– StatusType GetResource (ResourceType <ResID>)
– StatusType ReleaseResource (ResourceType <ResID>)
OSEK/VDX OS Architecture
• The OSEK/VDX OS architecture offers the
following services :
– Tasks management
– Interrupt processing
– Events mechanisms
– Resources management
–
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
Activate a task /
set event for this task
counter
alarm
alarm
alarm
Call alarm-callback routine
Source for
counter
task
Alarm-callback
ALARMCALLBACK(BrakePedalStroke)
{
/* do application processing */
}
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>)
AUTOSAR OS, RTE & EcuM
AUTOSAR IMPROVEMENT ON
OSEK/VDX OS
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
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
•
• OS-Application
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.
AUTOSAR Schedule tables
• Structure of a schedule table:
Initial expiry point
Initial
Delay: 4
0
Final expiry point
Expiry point 1:
Expiry point 2:
Expiry point 1:
Expiry point 1:
Task Activation
Task A
Task B
Task Activation
<none>
Task Activation
Task C
Task D
Task Activation
Task E
Task A
Event Setting
Event1-TaskC
Event2-TaskD
Event Setting
Event1-TaskC
Event2-TaskD
Event Setting
<none>
Event Setting
Event2-TaskB
Event1-TaskD
Offset
4 ticks
Offset
12 ticks
Offset
20 ticks
Offset
32 ticks
20
32
4
12
Schedule table duration = 40 ticks
Final
delay: 8
40
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
•
AUTOSAR OS-Application
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.
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.
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_ACCESSIBLE
Active and accessible, objects
may be accessed from other
OS-Applications.
Default state at startup.
AllowAccess()
ProtectionHook with RESTART
OR
TerminateApplication with RESTART
APPLICATION_TERMINATED
Terminated and not accessible,
objects cannot be accessed from
other OS-Applications.
State will not change.
APPLICATION_RESTARTED
Currently in restart mode,
objects cannot be accessed from
other OS-Applications.
State is valid until AllowAccess() is called.