0% found this document useful (0 votes)
45 views41 pages

01_AUTOSAR_in_Practice_OperatingSystem

The document provides an overview of the AUTOSAR operating system, detailing its structure, functionalities, and scalability classes. It discusses key components such as tasks, alarms, interrupts, and OS resources, emphasizing the system's preemptive and event-triggered nature. Additionally, it highlights new features and the importance of memory protection in multi-core systems.

Uploaded by

VivekHarshaN A
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
45 views41 pages

01_AUTOSAR_in_Practice_OperatingSystem

The document provides an overview of the AUTOSAR operating system, detailing its structure, functionalities, and scalability classes. It discusses key components such as tasks, alarms, interrupts, and OS resources, emphasizing the system's preemptive and event-triggered nature. Additionally, it highlights new features and the importance of memory protection in multi-core systems.

Uploaded by

VivekHarshaN A
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 41

cw

_1
82
02
2;
VI-
SA
UT
OS
AR
Cla
ssi
cB
AUTOSAR in Practice as
is B
Operating System
L
V1.0.0 | 2020-01-20
Agenda
cw
u Overview _1
Tasks 82
02
Alarms 2;
OS counter VI-
Interrupts SA
IOCs UT
OS Resources
OS
AR
Illustration
Cla
Scalability of the OS ssi
Tool example cB
Coming up next as
is B
L

2
Overview
MICROSAR OS
cw
u Static operating
system _1 Application Software

Fully-preemptive,
82 Component

u
event triggered E2E 02 SCHM MICROSAR RTE
Scalable in
2;
u
functionality and
DET
VI- DCM
NVM
size CSM SA DEM
COM IPDUM NM PDUR

u Elements COMM
FIM
UT HTTP1
u Tasks
MEMIF
OS J1939TP
LINTP
FRXCP

IOHWAB
ECUM V2G1,5
CRC FRTP
u
u
Events
Alarms
BSWM DLT AR
CANXCP

CANTP
LINNM
FRISOTP
ETHXCP
UDPNM
Complex

u Interrupts
OS STBM
EA
CANNM
Cla FRNM SOAD4
Drivers

u IOCs WDGM
DBG
CANSM
LINSM
ssi FRSM
TCP/IP1,3

u Resources
WDGIF XCP
FEE
CANIF
LINIF cB FRIF
ETHSM

as ETHIF
CAL
is B

PORTDRV
CORETST

WDGDRV

CANTRCV
FLASHTST

ETHTRCV
PWMDRV
CANDRV

DRVEXT3
MCUDRV

LINTRCV
ADCDRV

ETHDRV
DIODRV

RAMTST
GPTDRV
EEPDRV

ICUDRV
FLSDRV

LINDRV

SPIDRV

FRTRCV
FRDRV
L
Microcontroller
3
Overview
New functionality in Scalability Classes
cw
u
_1
AUTOSAR extends the OSEK/VDX Operating
System standard
82
02
u AUTOSAR Workflow supported (configuration

Language)
2;
not any more over OSEK Implementation Multi-Core MC MC MC MC

u Additional functionality
VI-
S A
AUTOSAR OS add-ons are segmented into
Memory
u
Scalability Classes (SCs) UT Protection SC 3

u Exception
OS
> Multi-Core support is independent of the used AR Timing
Protection
Scalability Class
Cla SC 4

ssi
Schedule SC 2
Tables cB
Memory Protection as
SC 1 SC 3

The hardware must contain a Memory Protection OSEK OS is B


Unit (MPU) to support this feature.
L

4
Agenda
cw
Overview _1
u Tasks 82
02
Alarms 2;
OS counter VI-
Interrupts SA
IOCs UT
OS Resources
OS
AR
Illustration
Cla
Scalability of the OS ssi
Tool example cB
Coming up next as
is B
L

5
Tasks
Basic Tasks
cw
BasicTask _1
BtInit
Initialization
82 StartOs

02
2;
TerminateTask
SUSPENDED VI-
SA
by User Activate UT
Task
OS
TerminateTask

Priority READY AR
Cla
by OS start preempt ssi
cB
Scheduling RUNNING as
is B
L
A Basic Task can be
activated, runs, and
terminates when
finished.
6
Tasks
Extended Tasks and Events
cw
ExtendedTask
_1
 Event_2

 Event_3 82 StartOs

EtTransmit
02
Application
Code 4 2;
SUSPENDED VI-
Wait Event_2,3
Application SA
Code 5
by User Activate UT
Task
OS
TerminateTask

Priority READY AR
Cla An Extended Task
by OS start preempt Release ssi performs a blocking
cB wait for the
occurrence of certain
Scheduling RUNNING WAITING as events.
is B
During the wait for
events, the OS will
WaitEvent
L
schedule the next
ready Task.
SetEvent
Events are assigned
to Extended Tasks.

7
Agenda
cw
Overview _1
Tasks 82
02
u Alarms 2;
OS counter VI-
Interrupts SA
IOCs UT
OS Resources
OS
AR
Illustration
Cla
Scalability of the OS ssi
Tool example cB
Coming up next as
is B
L

8
Alarms
Alarms
cw
u
_1
Alarms can be set to absolute or relative points
of the system timer
82 Task
02
u The time to which the alarms are set is an
argument to the Alarm API
2; Increment
u You can VI- Counter

u set alarms
Dynamically over API
SA SetRelAlarm/
SetAbsAlarm (Value) AlarmCallback
>
> Statically over configuration (AUTOSTART) UT
u cancel alarms OS BasicTask

u Once an alarm expires


AR Execute
ActivateTask

u An alarm action defines what happens


00:00 00
Cla
expiry
Alarm Actions

> Activate a task [Reset] ssi SetEvent ExtendedTask


 Event_2

cB

> Set an event  Event_3

Call a callback function


>
as
> Increment an OS counter
is B
If you set a series of alarms, the system timer may increase in
L
the midst of setting the alarms of the series. This results in
different starting times of the alarms. You can prevent this if
u a so called “High Resolution Timer” is used
u schedule tables are used

9
Agenda
cw
Overview _1
Tasks 82
02
Alarms 2;
u OS counter VI-
Interrupts SA
IOCs UT
OS Resources
OS
AR
Illustration
Cla
Scalability of the OS ssi
Tool example cB
Coming up next as
is B
L

10
OS counter
OS counter / PIT or High resolution timer
cw
_1
OS counters are used to provide a time base PIT (no HRT possible) STM (used as HRT)

82
“System Timer” for the operating system
OS Counter OS Counter
u Counter Driver (HARDWARE) 02
u PIT Periodical Interrupt Timer 2;
>
VI-
No HRT possible: OsDriverHighResolution = FALSE
increase
Counter is
HW counter
>
>
Equidistant periodic ticks
Increment counter by a tick
SA counter
value by 1
Reload STM with

> UT
High precision results in a high interrupt frequency
least distance
to next expiry
u STM System Timer Module OS
> HRT supported: OsDriverHighResolution is
> TRUE: HRT supported
AR
> FALSE: STM is working periodic like a PIT Cla
> High precision is possible ssi
PIT HRT

> Aperiodic ticks IRQ cB


periodical On demand
> Increment counter by last interval duration Precision Multiples of as Any time the timer
>
>
Program timer to next expiry
High precision possible with low interrupt
(Alarms, schedule
tables)
OsSecondsPerTick
is B
hardware can provide

frequency Interrupt Load Constant equally


distributed
L
No equally distributed,
bursts possible

11
OS counter
Periodical behavior vs High Resolution Timer
cw
_1 OS Counter ISR

82
ISR
02
Periodic
ISR
2; Inc by 1 Check for expiry no
superfluous
Interrupt
Timer VI-
Inc by 1 Check for expiry no
interrupts
(PIT/STM) ISR SA
Inc by 1 Check for expiry no
ISR Inc by 1 UT
Check for expiry yes expiry

OS
AR
OS Counter ISR
Cla
ssi
High
cB
Resolution as
Timer
(only STM)
ISR
HW count Reload STM timer
is B
expiry
Update next expiry
L
ISR HW count Update next expiry Reload STM timer expiry

12
OS counter
OS time base parameters
cw
u Time base
_1 Illustration of the OC counter configuration
82
u OsSecondsPerTick [s] resolution for SW 𝑂𝑠𝐶𝑜𝑢𝑛𝑡𝑒𝑟𝑇𝑖𝑐𝑘𝑠𝑃𝑒𝑟𝐵𝑎𝑠𝑒
counter increments
02 = 𝑂𝑠𝑆𝑒𝑐𝑜𝑛𝑑𝑠𝑃𝑒𝑟𝑇𝑖𝑐𝑘 𝑠 ∙ 𝐵𝑎𝑠𝑒𝐹𝑟𝑒𝑞 𝐻𝑧
u 2;
Counter increments each OsSecondsPerTick
u VI-
The OS provides macros to convert between OS Physical Unit 1 ms
ticks and seconds SA (Seconds)
OsSecondsPerTick
t
u Counter Type can be UT = “Tick Time”
e.g. =0.001 s
u HARDWARE OS
Counter Unit
(Os Ticks) t
u
u
Have to select a driver (PIT/STM…)
Hardware advances OS counter over interrupts
AR
u SOFTWARE
Driver Unit
(Hardware)
Cla t
u Can use the IncrementCounter API to advance the ssi
OsCounterTicksPerBase
System Time cB
e.g. =100000 for 100 MHz BaseFreq.

u PIT: as
u In every tick, the counter increments by 1 is B Timer Interrupt

u HRT: L
u TicksPerBase =1 → OS Counter increments by
HW Base
13
Agenda
cw
Overview _1
Tasks 82
02
Alarms 2;
OS counter VI-
u Interrupts SA
IOCs UT
OS Resources
OS
AR
Illustration
Cla
Scalability of the OS ssi
Tool example cB
Coming up next as
is B
L

14
Interrupts
Interrupt categories
cw
_1
8 IRQ
20 / source IRQ / source
22 Interrupt vector table

Interrupt source number ;V


Interrupt service routine I- SA
UT OS (dispatch, switch

OS context and execute)

Interrupt Service Routine Category 1 ISR AR Interrupt Service Routine


Category 2 ISR
FUNC(void) Cat1(void)
Interrupt function finished
with Return from Interrupt
{Cla
ISR(Cat2) Interrupt function finished
with Return from Subroutine
{
/* No OS Access */ (RTI). No access to OS service */ ssi
/* OS access possible
(RTS). Access to OS service

}
/* RTI [1]*/ functions is possible.
[3] }
/* RTS [2] */
cB functions is possible.
Not allowed:
as TerminateTask, WaitEvent,
is B
ClearEvent, Schedule,
ChainTask.

[3] OS locks all interrupts during context switch. This may take
L
Interrupt sources must be a few µs. For whom this is still too much, we also have “CAT0” An Interrupt can use OS
enabled/disabled over OS API Interrupts. (Vector specific implementation) Here, the OS functionality or not. This depends
Os_Enable/DisableInterruptSource interrupt locking times are significantly shorter. on the interrupt category.

15
Interrupts
Impact of the Interrupt category on the ECU software
cw
properties
_1 CAT1 ISR CAT2 ISR

Context 82 Runs in any context currently active Runs in its own dedicated context

02
Stack usage
2;
You’ll need to reserve a safety margin of RAM for
all CAT1 ISRs on all stacks of all tasks per core.
You’ll be able to decide on the amount of stack per
ISR. Efficient RAM usage possible.
VI-
Inefficient RAM usage.

Memory protection SA
Stack overflow can lead to a protection trap Both stack overflow and memory corruption can lead
UT
inside all OS applications on the core.
Memory corruption may remain undetected
to protection trap inside its OS application.
Memory corruption attempts are detectable
OS
Processor mode Runs regardless of supervisor/user mode.
AR
Unintended access to some processor registers /
Runs in the processor mode defined by the containing
OS application. No way to affect the processor

impact
peripherals possible.
Cla
registers /peripherals in an unintended way.

ssi
Safety projects (mixed ASIL):
requirements for ISRs
In safety scenarios with memory protection, all
CAT1 ISRs must be implemented according to cB
CAT2 ISRs can be used for all ASILs/QM.
Implementation according to the respective ASIL.
the highest ASIL in the system. Non ASIL ISRs
as
Memory corruption can be detected.
must be qualified. If this is not done, memory
corruption can happen and remain undetected. is B
How to decouple from ISR into
TASK context
Can not be used for decoupling from ISR to
TASK context using OS mechanisms. No task
L
Can be used for IMMEDIATE decoupling from ISR to
TASK using OS mechanisms. Tasks can be triggered.
can be triggered. Only flags work. (DEFERRED That is the way the RTE works.
operation)

16
IOCs
Inter OS Application Communicator (IOC)
cw
_1
82
02
2;
Task A
VI-
IocSend IocReceive
Task B

SA
UT
OS
AR IocRead
ISR 1

Task C

IocWrite
Cla
ssi
Task E
IocRead
cB
protected area as
is B
L
An IOC can have several
writers and several readers.
Therefore IOCs support n:m
data transfer across several OS
applications.

17
OS Resources
Deadlock prevention using OS Resources
cw
_1
82
02
2;
VI-
Task A
SA
GetResource UT GetResource Task B
ReleaseResource
OS
Resource

AR
memory Cla
ssi
cB
as
is B
L
A OS Resource can be used to protect
against concurrent access by at least
two concurrent tasks without using
Interrupt locks. Priority Ceiling
Protocol.

18
OS Resources
Deadlock prevention using OS Resources
cw
_1
82
Resource management coordinates the access to shared
resources: 02
memory (RAM)
2;
u
VI-
u hardware components
SA
application program sequences (critical sections)
u
UT
u elements of the operating system (Scheduler)
OS
OSEK/VDX and AUTOSAR OS guarantee that
AR
a resource is never occupied by two users
Cla
u
simultaneously ssi
u priority inversion is excluded
cB
as
u deadlocks are prevented
access to a resource never ends in a wait state
is B
u
L
Used for Exclusive Areas in AUTOSAR!
Illustration
Interaction of OS Elements
cw
_1 StartOs

AUTOSTART=true 82 AUTOSTART =true

02
2;
VI-
SA
AUTOSTART=true
UT
OS
BasicTask
BtInit
ExtendedTask
 Event_1 AR ExtendedTask
 Event_2
 Event_3
Initialization EtReceive
Application Cla EtTransmit
Code 2
ssi
Application
Code 4
Terminate
Wait Event_1

ActivateTask
cB
Wait Event_2,3
as
Application
Code 5 is B
Activation of Tasks after System Startup
L

19
Illustration
Interaction of OS Elements
cw
_1 StartOs

AUTOSTART=true 82 AUTOSTART =true

02
Alarms
2;
Activate 0:07 56 VI-
SA
ActivateTask AUTOSTART=true
UT
OS
BasicTask
BtInit
BasicTask
BtCyclic
ExtendedTask
 Event_1 AR ExtendedTask
 Event_2
 Event_3
Initialization Application
Code 1
EtReceive
Application Cla EtTransmit
Code 2
ssi
Application
Code 4
TerminateTask TerminateTask
Wait Event_1

ActivateTask
cB
Wait Event_2,3
as
Application
Code 5 is B
Alarm Triggered activation of Task
L
Alarm Activation
An Alarm can be activated via:
u System start
u User code
20
Illustration
Interaction of OS Elements
cw
_1 StartOs

AUTOSTART=true 82 AUTOSTART =true

02
Alarms
2;
Activate 0:07 56 VI-
Set
Event_1 SA
ActivateTask AUTOSTART=true
UT
OS
BasicTask
BtInit
BasicTask
BtCyclic
ExtendedTask
 Event_1
 AR
BasicTask
BtCyclic
ExtendedTask
 Event_2
 Event_3
Initialization Application
Code 1
EtReceive
Application
Application
Code 3 Cla EtTransmit
Code 2 SetEvent_2
ssi
Application
Code 4
TerminateTask TerminateTask
Wait Event_1

ActivateTask TerminateTask cB
Wait Event_2,3
as
Application
Code 5 is B
Events set by Alarm and by a Task
L

21
Illustration
Interaction of OS Elements
cw
_1 StartOs

AUTOSTART=true 82 AUTOSTART =true

02
Alarms
2;
Activate 0:07 56 VI-
Set
Event_1 SA
ActivateTask AUTOSTART=true
UT
OS
BasicTask
BtInit
BasicTask
BtCyclic
ExtendedTask
 Event_1

BasicTask
BtCyclic
AR ExtendedTask
 Event_2
 Event_3
Initialization Application
Code 1
EtReceive
Application
Application
Code 3 Cla EtTransmit
Code 2 SetEvent_2
ssi
Application
Code 4
TerminateTask TerminateTask
Wait Event_1

ActivateTask TerminateTask cB
Wait Event_2,3
as
Set Event by Interrupt using
Application
Code 5 is B
Interrupts Interrupts
category 2
L
ISR Cat1 ISR Cat2
/*No OS
Access*/
RTI SetEvent_3

22
Illustration
Interaction of OS Elements
cw
_1 StartOs

AUTOSTART=true 82 AUTOSTART =true

02
Alarms
2;
Activate 0:07 56 VI-
Set
Event_1 SA
ActivateTask AUTOSTART=true
UT
OS
BasicTask
BtInit
BasicTask
BtCyclic
ExtendedTask
 Event_1
 AR
BasicTask
BtCyclic
ExtendedTask
 Event_2
 Event_3
Initialization Application
Code 1
EtReceive
Application
Application
Code 3 Cla EtTransmit
Ioc_Write Ioc_Read Code 2 SetEvent_2
ssi
Application
Code 4
Terminate Terminate
Wait Event_1

ActivateTask Terminate cB
IOC
Wait Event_2,3
as
Using the IOC Mechanism
Application
Code 5 is B
Interrupts Interrupts L
ISR Cat1 ISR Cat2
/*No OS
Access*/
RTI SetEvent_3

23
Illustration
Interaction of OS Elements
cw
_1 StartOs

AUTOSTART=true 82 AUTOSTART =true

02
Alarms
2;
Activate 0:07 56 VI-
Set
Event_1 SA
ActivateTask AUTOSTART=true
UT
OS
BasicTask
BtInit
BasicTask
BtCyclic
ExtendedTask
 Event_1

BasicTask
BtCyclic
AR ExtendedTask
 Event_2
 Event_3
Initialization Application
Code 1
EtReceive
Application
Application
Code 3 Cla EtTransmit
Ioc_Write Ioc_Read Code 2 SetEvent_2
ssi
Application
Code 4
Terminate Terminate
Wait Event_1

ActivateTask
GetResource
Terminate cB
GetResource

IOC
Wait Event_2,3
as
Application
Code 5 is B
Interrupts Interrupts Using the OS Resource Mechanism L
ISR Cat1 ISR Cat2
/*No OS
Access*/
GetResource Resource
RTI SetEvent_3

24
Agenda
cw
Overview _1
Tasks 82
02
Alarms 2;
OS counter VI-
Interrupts SA
IOCs UT
OS Resources
OS
AR
Illustration
Cla
u Scalability of the OS ssi
Tool example cB
Coming up next as
is B
L

25
Scalability of the OS
SC1: Schedule Tables

u
c w_of sequences of actions with a fixed time distance
Definition
18 once or repeatedly
Can be executed
u
2
Can be autostarted 0or2activated by the application
u
2
Local task execution can be; synchronized to a global time base
u
VI- bus (cycle start)
u
SA
E.g., to the time base of a FlexRay
u
UT
Multiple schedule tables can be active at the same time Each schedule has so called
Expiry Points which occur
OS within the schedule table
AR duration.
Expiry Points are used to
Event 3 Cla Event 3 cause “actions” as soon as

Event 1
Task 3
Event 1 ssi Task 3
Event 1
they occur.

action Task 1 Task 2 Task 1 Task 2 cB


Task 1
An action is either a task
activation or a SetEvent()
Expiry point as
operation or both.

Schedule Table Schedule Table 1 Schedule Table 1 …


is B
Expiry Points are positioned
relative to the start of the
schedule.L
Each Expiry Point is signified
offset within the schedule table by
an individual “offset”.

26
Scalability of the OS
SC2: Timing Protection
cw
u
_1
Execution budgets are assigned to tasks and
monitored
82
u 02
If the budget is exceeded the Protection hook is
called 2; Budget
u VI-
Similarly, inter-arrival-times and resource Overrun
locking times are monitored SA Task 3
Deadline
UT violation
u Timing Protection vs. Watchdog OS
Task 2
u Timing protection does not detect deadline
violations!
AR
u Detects causes of deadline violations earlier
Task 1 Cla
than watchdog ssi
u Timing protection is limited to tasks / ISR 2
cB time

(ISRs of type 1 bypass the timing protection) as


is B
L

27
Scalability of the OS
SC2: Timing protection (execution time / inter arrival time)
cw
_1
OsTaskExecutionBudget (TEB)
u 82
maximum allowed execution time of the task StartOs

u 02
To detect too long execution times

OsTaskTimeFrame (TTF)
2; TerminateTask

u
V I-S activations
The minimum inter-arrival time between
 SUSPENDED

and/or releases of a task AU Activate /

u To detect too frequent activations TO Task

SA READY
     RC Release
/
TEB.. ..TEB TEB.. las start preempt

/ /
sic 
Ba
RUNNING WAITING
TTF TTF
sis
Task 1 SUS RDY RUN RDY RUN WTG RDY RUN WaitEvent
BL
SetEvent
time 
TEB Task Execution Budget TTF Task Time Frame
Scalability of the OS
SC2: Timing protection (execution time / inter arrival time)
cw
_1
OsTaskExecutionBudget (TEB)
u 82
maximum allowed execution time of the task
u 02
To detect too long execution times
OsTaskTimeFrame (TTF)
2;
u
V I-S activations and/or releases of a task
The minimum inter-arrival time between
u To detect too frequent activations AU
 
TOS  
AR TEB..
TEB.. ..TEB
Cla
/ / s
TTF
sic TTF
Ba
Task 1 SUS RDY RUN RDY RUN WTG RDY RUN sis
time
BL
TEB Task Execution Budget
TTF Task Time Frame
Scalability of the OS
SC2: Task Execution Budget / Time Frame
cw
_1
82 StartOs
02 
2;
TerminateTask
 VI- SUSPENDED
SA Activate /
UT Task
OS
READY AR Release
Cla
/
start preempt ssi
  cB
RUNNING WAITING as
is B
WaitEvent
L
SetEvent
 TEB Task Execution Budget
TTF Task Time Frame
Scalability of the OS
SC3: Memory Protection
c w_background
Motivation and
u 18 of applications
Easy integration
> 20
Faulty code of one application has no influence on others
u 22 (MPU)
Hardware support needed
u Stack protection ;V
u I-S
Immediate detection of stack overflow
u AU
Constituent parts of an OS-Application
u Data protection TO
SA
u Private data sections of OS-Applications are shared by all its tasks and
ISRs
u Code protection
RC
las
u Protect commonly used code (e.g. shared libraries) to prevent memory,
timing or service violation. sic
Ba
sis
BL

28
Scalability of the OS
SC3: OS-Applications
cw
u
_1
Collection of cohesive functional units
82
u Tasks, ISRs, alarms, hooks, etc.

u 02
AUTOSAR OS shares systems resources between
OS-Applications 2;
u VI-
All objects belonging to the same OS-Application Software MPU RAM
can access each other SA Application 1
Application A
Task1.1

u Access between OS-Applications may be granted UT Task 1.1


Task 1.2
r,w,rw,x

in configuration OS Application B
u Classes of OS-Applications AR Application 2
Task 2.1 r,w,rw,x
Task 1.2

u Trusted
Allowed to run without protection
Cla
>
> Unrestricted access to memory / APIs
Operating
System ssi r,x Task 2.1

u Non-Trusted
u Context
Switching
cB
> Run only with protection as
> Only limited access to memory / APIs is B
L

29
Scalability of the OS
Multi-core operating system
cw
Application 1 _1 Application 2 Application 3 Application 4 Application 5
SWC a 82 SWC b SWC c SWC d SWC e
02
2;
VI-
SA
UT
MICROSAR RTE
OS
AR ECU State
MICROSAR DIAG

ECU State MICROSAR COM MICROSAR DIAG


Manager
Cla Satellite
MICROSAR MEM

Manager

MICROSAR IO
Satellite

Complex Drivers
MICROSAR MOST

Complex Drivers
MICROSAR CAN

ssi
MICROSAR LIN

MICROSAR FR

MICROSAR OS
MICROSAR IP

Multi-Core
Watchdog Watchdog
Manager Manager cB
MICROSAR
Satellite
as
XCP

SYS is B
MICROSAR CAL MICROSAR EXT L
Core 1 Core 2

30
Scalability of the OS
Multi-core operating system
cw
_1
82
02
IOC: Inter-OS-Application Communicator
2;
For CDDs (Complex Device Drivers) and Multi-Core:
VI-
u SA
BSW resides on the Master core (Core0). If the CDD needs to access standardized
interfaces of the BSW, it needs to reside on the same core.
UT
u OS
In case a CDD resides on a Slave core (Core1), it can use the normal port mechanisms to
AR
access AUTOSAR interfaces and standardized AUTOSAR interfaces. This involves the RTE,
which uses the IOC mechanism of the operating system to transfer requests to the
Cla
master core.
ssi
u cB
Proxy solution: However, if the CDD needs to access standardized interfaces of the BSW
as
and does not reside on the master core, a stub part of the CDD needs to be implemented
is B
on the master core, and communication needs to be managed locally in the CDD using
the IOC mechanism of the operating system. Additionally, in this case the initialization
L
part of the CDD also needs to reside in the stub part on the master core.
Agenda
cw
Overview _1
Tasks 82
02
Alarms 2;
OS counter VI-
Interrupts SA
IOCs UT
OS Resources
OS
AR
Illustration
Cla
Scalability of the OS ssi
u Tool example cB
Coming up next as
is B
L

31
Tool example
OS in Configurator Pro
cw
_1
82
02
2;
VI-
SA
UT
OS Set task
Priority

AR Number of
Activations (for
Basic Task)
Cla
Non-preemptive or fully-
preemptive?

Enter name of ssi


Task
cB Set Task Type

as u Auto
u Basic
is B
u Extended

The RTE generator decides automatically how a task must be treated


L
(by the Function Trigger to Task mapping)
u Application task, BSW Scheduler task, non-RTE task

32
Tool example
Runnables in DaVinci Configurator Pro
cw
_1
82
02
2;
VI-
SA
UT
OS
AR
Cla
ssi
Runnables appear
as “Triggered Trigger cB
Functions” conditions
as
is B
Please note the Access Point cannot be changed or
L
viewed in Configurator. The Trigger also cannot be
changed in Configurator. These are design aspects
and have to be changed in Developer.

33
Tool example
Task mapping using the ECU Software Components view
cw
_1
82
02
2;
VI-
SA
UT
OS
AR
Cla
ssi
cB
as
is B
L
You can map Runnables to Tasks on a per-
SWC approach.

34
Tool example
Task mapping using the Task Mapping Assistant
cw
_1
82
02
2;
VI-
SA
UT
OS
AR
Cla
ssi
cB
as
is B
Columns in the Task Mapping Assistant have auto-filter functionality.
This makes it easy to map Runnables globally instead for just one
SWC.
L
For example, you can map several Runnables in one step to a specific
Task. The Assistant will choose the Position in the Task automatically.
35
Coming up next

cw
_1
Operating System
82
02
2;
VI-
SA


Software Components
UT
OS
AR
Cla
ssi
cB
as
is B
L

36

You might also like