EB tresos classic AUTOSAR training

- Operating system
Os

Chapter overview

• Introduction
• Scheduling
• Multi-core Support
• Critical Section Protection
• OS-Application Protection
• Hints and Tips
• EB tresos OS products

© Elektrobit (EB) 2022 | Confidential 2

Introduction
Os - Introduction

Stack overview
Application
Application SW-C 1 Application SW-C 2 Application SW-C 3 Layer

Application
Runtime Environment (RTE) Abstraction
Layer
Management

Diagnosis
and Error
Handling

IO HW Abstraction
Mode

Service
Operating System

Layer

Complex Drivers
Communication

Security Stack
Memory Stack

stack
ECU
Abstraction
Layer

Drivers
Microcontroller

I/O
Abstraction
Layer

© Elektrobit (EB) 2022 | Confidential 4

Os - Introduction

Main characteristics

• AUTOSAR Os is a static operating system

– No dynamic handling of system resources
– AUTOSAR Os is configurable
– AUTOSAR Os has to be individually configured and generated for each application

• Advantage: AUTOSAR Os can be optimized

• Configuration: EB tresos Studio

© Elektrobit (EB) 2022 | Confidential 5

Scheduling
Os - Scheduling

Tasks
Task state machine:

• Tasks are C functions that can be scheduled by the Os running

terminate
wait
• Typically, most parts of the application are executed
within a Task

preempt

start
waiting suspended
• Tasks must be activated to take part in the scheduling
This can be done via API calls or other Os mechanisms

release
• Tasks have a configured priority activate

extended Tasks only ready

• There are basic and extended Tasks
Difference: Extended Tasks support waiting for Events.
© Elektrobit (EB) 2022 | Confidential 8
Os - Scheduling

Tasks: Example
DeclareTask(TaskA);

TASK(TaskA)
{
StatusType status;
TaskStateType stateB;

/* do stuff */
status = ActivateTask(TaskB);
/* check return value */
status = GetTaskState(TaskB, &stateB);
/* check return value and do more stuff */

TerminateTask();
}
© Elektrobit (EB) 2022 | Confidential 9
Os - Scheduling

Interlude: Events
Event

Events are a notification mechanism to notify

generates
extended Tasks: ISR
• Extended Tasks can wait for (one or several)
Events. While waiting, the processor can execute
other Tasks, …
wakes up
• Events can be set from Tasks (basic or extended), generates
waits and
for receives
ISRs or by the OS

Basic
Events are just notifications. They neither contain or Extended
any data nor any additional information like the Extended Task
source of the event Task

© Elektrobit (EB) 2022 | Confidential 10

Os - Scheduling

Interrupt Service Routines (ISRs)

• ISRs are C functions to handle hardware events. They are
typically not scheduled but directly triggered by hardware
Interrupt
interrupt requests*
ISR
(Cat. 2)
• ISRs preempt Tasks (unless the Task explicitly disables
interrupts)
• Also ISR nesting is typically supported nowadays (ISRs can activates
interrupt lower priority ISRs)
Event
• AUTOSAR defines two ISR categories: Task
– Category 1: Only few Os APIs are allowed. The ISR uses the
current stack. The implementation depends on the compiler
– Category 2: The Os provides an ISR frame which allows the
access to additional Os APIs like activating tasks or setting * There are Os implementations that explicitly schedule ISRs. In this
events. The ISR has its own stack case, the ISRs have higher priorities than the Tasks.
© Elektrobit (EB) 2022 | Confidential 11
Os - Scheduling

Tasks Scheduling policy

Basic Task scheduling policy Advanced Task scheduling policies

The AUTOSAR Os schedules the Tasks according to Each Task can be configured in one of the two ways
the following properties: • Non-preemptive
• Among all Tasks that are ready to run, the one - Such tasks will release the processor voluntarily
with the highest priority is taken
• Preemptive
• If there are several Tasks with the same highest
- Such tasks are preempted when a different task
priority that are ready to run, the oldest one is
of higher priority is activated
taken

Non-preemptive Tasks can use the API Schedule()

to allow Tasks with a higher priority to run

© Elektrobit (EB) 2022 | Confidential 12

Os - Scheduling

Scheduling: Example

activate TaskA activate TaskB

terminate TaskA
terminate TaskB
non-preemptive

suspended ready running suspended

priority

TaskB

TaskA running suspended

terminate TaskB
terminate TaskA
full-preemptive

TaskB suspended running suspended

priority

TaskA running ready running suspended

© Elektrobit (EB) 2022 | Confidential 13

Os - Scheduling

Tasks: Example (continued)

running
DeclareTask(TaskA); /* low priority */
terminate
DeclareTask(TaskB); /* high priority */ wait

preempt

start
TASK(TaskA) waiting suspended

{
StatusType status; release activate
TaskStateType stateB;
extended Tasks ready
only

/* do stuff */
status = ActivateTask(TaskB);
/* check return value */
status = GetTaskState(TaskB, &stateB);
What is the value of stateB
/* check return value and do more stuff */ after GetTaskState()?

TerminateTask();
}

© Elektrobit (EB) 2022 | Confidential 15

Os - Scheduling

Interlude: Task stacks

Stack 1

Stack 2
• Preempted tasks are resumed at the point, where they have
been preempted

• Task stack: memory used e.g. for

is preempted by …
– local variables (compiler), or
– to store data that shall be retained through function calls (compiler)
or preemptions (Os)
Task 2
• The AUTOSAR Os reserves memory for the Task stacks.
Task stack sizes are configurable

• Possible optimization: Task stacks may be shared by several

Tasks, if those Tasks can never preempt each other Task 1

© Elektrobit (EB) 2022 | Confidential 16

Os - Scheduling

Time triggered Task activation

Counter: An AUTOSAR Os mechanism to count events, e.g. timer ticks

Alarm: A Mechanism to trigger an action (e.g. a task activation), when the attached Counter reaches a given value

ScheduleTable Duration

• Predefined sequence of actions (expiry points) that are 0 5 10

attached to a Counter

SetEvent
• If the Counter reaches the value for an expiry point, the

ActivateTask
ActivateTask

ActivateTask

SetEvent
corresponding action is triggered
• Several expiry point actions are possible, e.g. activating
a Task or setting an Event
• ScheduleTable/Alarm modes: one-shot and periodic
• ScheduleTables can be synchronized to external sources

© Elektrobit (EB) 2022 | Confidential 17

Os - Scheduling

Summary
• Tasks are C functions, that can be scheduled concurrently by the AUTOSAR Os

• There are basic Tasks and extended Tasks. Extended Tasks support waiting for Events

• Tasks can be preemptive or non-preemptive

• Task scheduling is based on the priority. For Tasks with the same priority, the Task activation time decides
which task shall be scheduled next

• ISRs are handlers for hardware events (interrupts)

• ISRs interrupt the execution of Tasks (unless interrupts are explicitly disabled within the running Task)

© Elektrobit (EB) 2022 | Confidential 18

Multi-core Support
Os – Multi-core Support

OS-Applications

The AUTOSAR Os multi-core support is based on OS- Core 1 Core 2

Applications OS-Application 1 OS-Application 3

Task A Task E
OS-Application Task B Task F
• Group of AUTOSAR Os objects (Tasks, Counters, ISRs, …), ISR 1 ISR 3
that semantically belong together
ISR 2 ISR 4

OS-Application 2 ISR 5
Application to Core Assignment
Counter 2
• Os objects are assigned to processor cores via their OS- Task C
Application ScheduleTable 2
Task D
• The assignment is static: all objects of an OS-Application Counter 1
ScheduleTable 3
will always run on the core, to which the OS-Application
is assigned ScheduleTable 1

© Elektrobit (EB) 2022 | Confidential 20

Os – Multi-core Support

Cross-core Requests
Core 1 Core 2
• Os API calls are automatically forwarded to the
correct core Task A
Call to
ActivateTask()

• Os APIs wait for the result from the other core

ActivateTask()

• AUTOSAR 4.4. added two asynchronous Os APIs, Task A waits for

the API result.
Core 2 handles
the request.
one for activating a task and the other for setting Task activation result

an event

• Question: What is the state of the activated task

on core 2 when Task A is continued on core 1?

© Elektrobit (EB) 2022 | Confidential 21

Os – Multi-core Support

Startup
Single-core startup: StartOS() Core 1
(Master Core) Core 2

Multi-core startup (according to AUTOSAR) Startup

• The Master Core is the only core that is started Disabled or to be

synchronized for
StartCore()
automatically
• For other cores, StartCore() must be called. StartCore()
StartCore() result
• Call StartOS()on each core (including the Master
Core), after the core was started via StartCore() StartOS()

Consult the manual of your AUTOSAR Os for

StartOS()
deviations and additional information.

© Elektrobit (EB) 2022 | Confidential 22

Os – Multi-core Support

Summary

• AUTOSAR Os objects are assigned to the different processor cores via OS-Applications

• The core assignment is static

• Requests are forwarded to the correct core

• APIs will wait for the result from the other core

• Multi-core startup is done as a master-slave system

© Elektrobit (EB) 2022 | Confidential 23

Critical Section Protection
Os – Critical Section Protection

Overview

Critical Section Protection

Mechanisms to prevent concurrent access to shared Enter Critical Section
resources (e.g. memory or peripherals)
Exit Critical Section Task B

Critical Section
Read / Write
Read / Write Memory M
The AUTOSAR Os provides three protection mechanisms:
• Resources
• Interrupt Locks (several variants) Task A Enter Critical Section
Exit Critical Section
• Spinlocks

© Elektrobit (EB) 2022 | Confidential 26

Os – Critical Section Protection

Single-core Protection Mechanisms

Resources
• Os mechanism to protect critical sections on a single core
• Critical sections can be protected against preemption by other Tasks and (category 2) ISRs
• Resources must be configured for each Task and (category 2) ISR that uses the shared resource

Interrupt Locks
• APIs to lock interrupts Interrupt locks and Resources ensure that no other
• Different variants are available: Task/ISR that uses the same shared resource is
– Category 2 ISRs only vs. all ISRs1 scheduled while a critical section is executed.2
– Nestable vs. non-nestable APIs
• Only affects the processor core which executes the APIs 1 There might be some ISRs which are not locked. Check the documentation
2 If an appropriate mechanism is chosen and configured and used correctly.

© Elektrobit (EB) 2022 | Confidential 32

Os – Critical Section Protection

Multi-core Protection Mechanism

Spinlocks GetSpinlock(s)
• The only AUTOSAR Os multi-core protection mechanism {
• Active waiting in a loop („spin“), while repeatedly do {
checking if the lock is available try to acquire spinlock s;
• No protection against core local interruptions } while (spinlock s was occupied);
}
NOTE
• Combine Spinlocks with an Interrupt Lock or ReleaseSpinlock(s)
RES_SCHEDULER1 to protect a section against {
interruptions on the local core2 release spinlock s;
• Spinlocks can easily result in deadlocks when being used }
incorrectly. Make sure to use them decently!
1 RES_SCHEDULER is a Resource which blocks all Task scheduling.
2 Directly supported in the configuration since AUTOSAR 4.1.

© Elektrobit (EB) 2022 | Confidential 33

Os – Critical Section Protection

Summary
Mechanism Advantages Disadvantages
Resources • No interrupt locking as long as no ISRs are • Single-core only
involved • Typically slower than Interrupt Locks1
• Fine grained control via the configuration • No protection against category 1 ISRs
• Misconfiguration possible
Interrupt Locks • Typically faster than Resources1 • Single-core only
• Simple to understand and use • Lock all interrupts of the corresponding type2
Spinlocks • Multi-core protection mechanism • No protection against core-local interruption
• Efficient for small critical sections (unless combined with other locks)
• Can be combined with an Interrupt Lock or • Active waiting, therefore inefficient in case of
RES_SCHEDULER3 long critical sections
• Deadlocks easily possible
1 Depends on the actual implementation.
2 There might be exceptions.
3 Since AUTOSAR 4.1, if supported.

© Elektrobit (EB) 2022 | Confidential 34

OS-Application Protection
Os – OS-Application Protection

Trusted and Non-Trusted OS-Applications

Processors typically provide different modes that control the access to certain resources, e.g. to critical special purpose
registers, certain assembler instructions or some peripheral registers.

Trusted OS-Application Non-Trusted OS-Application

Os objects of a trusted OS-Application may be executed in Os objects of a non-trusted OS-Application should be
a privileged processor mode1 and may have unrestricted2 executed in a non-privileged processor mode1 and have
access to hardware resources as well as APIs. restricted access to hardware resources as well as APIs.

Trusted Function
• Trusted Functions are provided by Trusted OS-Applications and executed in the privileged processor mode1
• Trusted Functions can be provided to Non-Trusted OS-Applications, to allow them access to restricted resources
• Trusted Functions cannot be provided to OS-Applications on different processor cores
1 The used processor modes as well as the associated restrictions are hardware- and implementation-specific.
2 Since AUTOSAR 4.2, memory protection can be activated for Trusted OS-Applications.
© Elektrobit (EB) 2022 | Confidential 36
Os – OS-Application Protection

Interlude: Hooks

• Hooks are callback functions, which are called by the StartupHook

AUTOSAR Os in certain situations

• Hooks must be enabled in the configuration

PreTaskHook

• ErrorHook: Typically* called for errors, after which ErrorHook

the Task/ISR can continue its execution Task
Example: API called with invalid parameters ProtectionHook

PostTaskHook
• ProtectionHook: Typically* called for errors, which
must be handled before the Task/ISR can continue.
Example: Memory protection exception

* Consult the AUTOSAR specification for details. ShutdownHook

© Elektrobit (EB) 2022 | Confidential 37
Os – OS-Application Protection

Memory Protection
Memory

• Prevents Tasks, ISRs, Hooks as well as the Os itself from Task A Read/Write
…
accessing memory, that should not be accessible Data Task A (RAM)
OS-Application Data
(RAM)
• Hardware support (MPU or MMU) is necessary
Data Task B (RAM)
Task B Stack Task B (RAM)
• The ProtectionHook is called in case of a violation
Stack Task A (RAM)
Stack Os Kernel
• The configuration is hardware and implementation (RAM)

specific and tightly coupled with the linker script. …

Please consult the documentation for your Os on how to Os Kernel
Code (Flash)
use memory protection correctly. Read only

© Elektrobit (EB) 2022 | Confidential 38

Os – OS-Application Protection

Further Protection Mechanisms

Service Protection: Accessing Applications

• For Os objects like Tasks, Resources, Counters, etc. the „accessing Applications“ are configured
• If such an object shall be used by an OS-Application, which is not configured as „accessing Application“ for that object,
the access is prevented and the ErrorHook* is called

Service Protection: Invalid API parameters or calling contexts

• Invalid request is rejected, and an error is reported to the ErrorHook*

Timing Protection
• Task and ISR time budget monitoring, as well as some other variants
• The ProtectionHook* is called in case of such a violation
* If enabled in the configuration.

© Elektrobit (EB) 2022 | Confidential 39

Os – OS-Application Protection

Summary

• Non-Trusted OS-Applications have restricted access rights. Use them whenever possible

• Memory protection prevents access to memory regions without proper permissions

• The ErrorHook and the ProtectionHook are your friends - enable them

• The Os provides further protection mechanisms with the service- and the timing protection

© Elektrobit (EB) 2022 | Confidential 44

Hints and Tips
Os – Hints and Tips

Hooks
PreIsrHook

• Hooks are callback functions, which are called by StartupHook

ISR
the AUTOSAR Os in certain situations

PostIsrHook
• If Hooks are enabled in the configuration, they PreTaskHook
must be defined by the user with the predefined
names and prototypes ErrorHook
Task
ProtectionHook
• Inside Hooks, not all Os API functions are available
PostTaskHook

• There are global as well as OS-Application specific

Hooks. Consult your Os documentation for details
and possible deviations from AUTOSAR.
ShutdownHook
© Elektrobit (EB) 2022 | Confidential 46
Os – Hints and Tips

Debugging

General Tips
• Enable extended error checks and check API return values
• Enable the ErrorHook and check that it is never called on your ECU
• Enable the ProtectionHook and implement it decently
• If „strange“ things happen, make sure that this is not caused by too small stack sizes

Additional Help
• The AUTOSAR Os supports the generation of an ORTI file. If your debugger supports ORTI, use that file to
get easier access to Os internal information like task control blocks or stacks
• Check your documentation for extended debugging support like e.g. stack checking support

© Elektrobit (EB) 2022 | Confidential 47

EB tresos OS Products
Os – EB tresos OS products

EB tresos classic AUTOSAR OS products

• EB tresos AutoCore OS
• EB tresos Safety OS

Both the above EB tresos OS products are

• AUTOSAR compatible
• Available for many Hardware derivatives (eg. Tricore, RH850, PA and
ARM32 and ARM64) in single-core and multicore versions.

More info: https://www.elektrobit.com/products/ecu/eb-tresos/operating-systems/

© Elektrobit (EB) 2022 | Confidential 49

Os – EB tresos OS products

EB tresos AutoCore OS

• EB tresos AutoCore OS is an embedded real-time operating system that is

AUTOSAR (v4.0.3 or R19.11) compatible

• EB tresos AutoCore OS was developed for QM projects

• EB provides a safety application guide (SAG) with which EB tresos

AutoCore OS can be used in safety projects up to ASIL-B*

• EB tresos AutoCore OS supports all major AUTOSAR features, including

memory protection. Deviations, limitations, and restrictions are
documented in the release notes.

* The actually achievable safety level depends on the hardware

© Elektrobit (EB) 2022 | Confidential 50
Os – EB tresos OS products

EB tresos Safety OS - Overview

Goal:
• AUTOSAR compatible Os (v4.0.3; R19-11 is in preparation)
• Usable in safety projects up to level ASIL-D

Safety requirements:
• Provide spatial freedom from interference
• Support temporal freedom from interference

To ensure freedom from interference, EB tresos Safety OS differs from standard

AUTOSAR Os implementations in a few points that are listed on the following slides

© Elektrobit (EB) 2022 | Confidential 51

Os – EB tresos OS products

EB tresos Safety OS – Details (1)

Spatial freedom from interference: Memory protection and threads

• Tasks, ISRs, callout functions (hooks) as well as some Os APIs are executed in so called
threads
• Each thread has its own memory protection configuration (independent from „trusted/non-
trusted“) and processor mode (explicitly configurable)
• EB tresos Safety OS ensures that the environment is correctly set up when a thread is
executed. This includes memory protection and processor mode
• The EB tresos Safety OS kernel has its own memory protection configuration and is expected
not to have access to the data of other threads unless necessary

Temporal freedom from interference

• Execution budget monitoring is supported
• Other modules (i.e. TimE) are necessary for full temporal freedom from interference (e.g.
deadline monitoring, alive supervision)

© Elektrobit (EB) 2022 | Confidential 52

Os – EB tresos OS products

EB tresos Safety OS – Details (2)

• Safe start-up: Entry point is MK_Entry2(). With this function EB tresos Safety OS takes
control of the CPU and ensures a safe execution environment

• Safe API usage: EB tresos Safety OS provides defined behavior for wrong or undefined
API/feature usage (e.g. wrong calling contexts or missing TerminateTask() call)

• Simple Schedule Tables: A special form of a schedule table that can use a
(EB tresos Safety OS specific) hardware ticker timer which increments the
schedule table counter with a constant period

• Only functionality necessary to reach the safety requirements is qualified

for use up to ASIL-D. Other functionality/API services are qualified as QM only!

• Does not support all AUTOSAR features. See the deviations provided in the EB tresos Safety
OS user’s guide for more information

© Elektrobit (EB) 2022 | Confidential 53

Os – EB tresos OS products

Summary - EB treos OS Products

AutoCore OS Safety OS
Safety level QM, with SAG* up to ASIL-B (ISO Up to ASIL D (ISO 26262) / SIL 3 (IEC 61508)
26262)
Feature set • Mostly full feature set with some • Concentration on main features and safety
deviations and restrictions related features
• Some additional features like • Some special features like simple schedule
stack monitoring functionality tables or asynchronous APIs
Startup Standard AUTOSAR start up Safe start-up via MK_Entry2().
Memory Protection Based on AUTOSAR 4.0.3 Configurable per thread i.e. for each Task, ISR
(trusted/non-trusted application) and callout function
Timing protection Generally supported, some Supports only execution budget monitoring
limitations might apply

* SAG: Safety application guide

© Elektrobit (EB) 2022 | Confidential 54
Summary
Os

Summary

• Introduction
• Scheduling
• Multi-core Support
• Critical Section Protection
• OS-Application Protection
• Hints and Tips
• EB tresos OS products

© Elektrobit (EB) 2022 | Confidential 56

Get in touch!

[email protected]
www.elektrobit.com