DOCU-738 - Integration of Cyclic BSW Mainfunctions

Mapping of Runnables in RTE
Background Knowledge MICROSAR
Influences on the ECU behavior regarding the task

mapping of BSW MainFunctions and Runnable
Entities
Felix Zollner
V1.0.0 | Released
Background Knowledge MICROSAR – Integration of Cyclic BSW Mainfunctions
Document Information
History
Author Date Version Remarks

Felix Zollner 20.07.2020 1.0.0 Released
Reference Documents
No. Source Title Version

[1] Vector RTE OS Invocation – RTE Handling of Runnable Mappings on 1.0
Support Different Task Types
Note
Caution
We have configured the programs in accordance with your specifications in the
questionnaire. Whereas the programs do support other configurations than the one
specified in your questionnaire, Vector´s release of the programs delivered to your
company is expressly restricted to the configuration you have specified in the
questionnaire.
© 2020 Vector Informatik GmbH Version 1.0.0 2

based on template version 6.0.1
Contents
1 Definition and Configuration ................................................................................................ 6

1.1 Definition of a Runnable Entity .................................................................................... 6
1.2 Definition of Task Mapping .......................................................................................... 6
1.3 Multi-core and ASIL Partition Distribution – Definition of Os Applications .................... 6
1.3.1 Exceptions on Application Distribution - Dem .............................................. 7
1.4 Affecting Os Task Configurations ................................................................................ 7
1.5 Affecting Rte Configurations........................................................................................ 7
1.6 Configuring Task Mappings and Related Settings ....................................................... 8
1.6.1 Definition of Cycle Time and Activation Offset ............................................. 8
1.6.2 Configuration Editor - Add Task Mapping..................................................... 9
1.6.3 Configuration Editor – Os Configuration .................................................... 11
1.6.4 Configuration Editor – Task Mapping ......................................................... 11
2 Functional Description of Task Mapping Settings............................................................. 13

2.1 Generated Function Calls Via Task Implementation .................................................. 13
2.2 Trigger Realization - Basic Task vs Extended Task ................................................... 13
2.2.1 Extended Task .......................................................................................... 13
2.2.2 Basic task ................................................................................................. 14
2.2.3 Schedule-Table-like Implementation .......................................................... 16
2.2.4 Conclusions on BASIC vs EXTENDED Task ............................................. 16
2.3 CUSTOM Trigger Realization .................................................................................... 17
2.3.1 CUSTOM Triggers on BASIC Tasks .......................................................... 17
2.3.2 CUSTOM Triggers on EXTENDED Tasks.................................................. 17
2.4 Injecting Schedule() Calls on Task Execution ............................................................ 18
2.5 Runnable Trigger Types ............................................................................................ 18
2.5.1 Init ............................................................................................................. 18
2.5.2 Background Task Execution ...................................................................... 18
2.5.3 Periodic/Cyclic .......................................................................................... 19
2.5.4 On Data Events ......................................................................................... 19
2.5.5 Client Server Ports .................................................................................... 19
2.5.5.1 Client Port – On Operation Call Return ................................... 19
2.5.5.2 Server Runnables ................................................................... 20
2.5.5.3 When is a Mapping of Server Runnables Needed? ................. 20
2.5.6 Mode Ports................................................................................................ 20
2.5.6.1 Triggering On Mode Events .................................................... 20
2.5.6.2 Preventing Runnable Calls – Mode Disabling
Dependencies ......................................................................... 21
3 System Effects and Cross Dependencies .......................................................................... 22

3.1 Effects of Task Mapping Properties ........................................................................... 22

3.1.1 Task Priorities............................................................................................ 22
3.1.2 Task Preemptivity ...................................................................................... 23
3.1.2.1 FULL Preemptive .................................................................... 23
3.1.2.2 NON Preemptive ..................................................................... 23
3.1.2.3 NON-Preemptive and Injection of Schedule Calls ................... 23
3.1.3 Position in Task ......................................................................................... 25
3.1.4 Activation Offset ........................................................................................ 25
3.2 Effects of Runnable Implementations ........................................................................ 25
3.2.1 Can Be Invoked Concurrently?.................................................................. 25
3.2.2 BSW Exclusive Areas................................................................................ 26
3.3 Effects of Client Server Call Configurations ............................................................... 27
3.3.1 Synchronous Runnable Invocation ............................................................ 27
3.3.1.1 Unmapped .............................................................................. 27
3.3.1.2 Mapped to Task ...................................................................... 27
3.3.2 Asynchronous Server Runnable Invocation ............................................... 27
4 Runnable Mappings – Pitfalls and Best Practices............................................................. 29

4.1 Different Time Bases for BSW and SWC Runnables ................................................. 29
4.2 Event-based Triggers vs Number of Events Within a Task ........................................ 29
4.3 Map As Less Server Runnables As Possible ............................................................. 29
4.4 Mode Dependent Triggers......................................................................................... 30
4.4.1 Task Mapping of Mode Dependent Runnable – One Task for Mode
Triggers ..................................................................................................... 30
4.4.2 Possible Deadlocks - Mode Disabling Dependencies vs Mode
Switches ................................................................................................... 30
4.5 Cyclic Triggers - CPU Load Distribution vs Reducing Alarm Action ........................... 31
4.6 Synchronizing Runnable Entities to External Time Bases ......................................... 31
4.6.1 Synchronizing Via Restarting of Alarms ..................................................... 31
4.6.2 Synchronizing via Schedule Table Synchronization ................................... 32
4.7 Triggering BSW MainFunctions – Best Practices ...................................................... 33
4.7.1 Splitting Rx and Tx MainFunctions ............................................................ 33
4.7.2 Splitting Worker and Timer Tasks .............................................................. 34
4.7.3 Memory Stack Triggering .......................................................................... 34
5 Contact ................................................................................................................................. 36

Introduction
This article describes how to map BSW- and application functions to OS tasks.
It shows the influences and cross-dependencies of these mappings to your system and
gives hints and best practices for this topic.

1 Definition and Configuration
BSW MainFunctions are mapped via the SchM parts of the Rte. Cyclic application
runnables are mapped via the application implementation of the Rte. Both can be mapped
to Os tasks, the settings of the task and the mappings are defining the runtime behavior of
the ECU.
Mapping function calls of a BSW module or software component (SWC) is realized via task
mapping of SWC runnables and BSW MainFunctions.
Several BSW modules need a cyclic execution of some of their functions, these are normally
called void <BSW Module>_MainFunction<UseCasePrefix>(void);
Within these BSW modules the cycle time of the MainFunction call can be configured.
Also, application SWCs of type Application, SensorActuator, IO Hardware Abstraction
and Complex Driver have triggered runnables who need to be mapped.
The triggering of your SWC runnables can be configured to several different options like
cyclic or On Data Reception at Software design.
All these parts of your software need to be mapped to tasks, to define the context on which
they are executed.
1.1 Definition of a Runnable Entity

Let’s call the BSW MainFunctions and the SWC runnables runnable entity in the following.
These inherit the application / BSW code and have to be executed on certain events in the
ECU. They both have the same behaviors, but their configuration is slightly different.
E.g. each runnable entity with cyclic triggers defines the following items:
> Cycle time: in which cycle time does the runnable entity needs to be called
> Activation Offset: which offset from start of the triggering until first invocation of the
runnable entity shall be realized?
1.2 Definition of Task Mapping

Via the task mapping assistants in DaVinci Configurator Pro it can be defined
> On which task the runnable entity will be mapped
> On which position within the task execution the runnable entity will be called
1.3 Multi-core and ASIL Partition Distribution – Definition of Os Applications

Os applications are used to assign cores and memory protection contexts to tasks and
therefore to the runnable entities mapped to them. With Os configuration SC3 or SC4 or with
a multi-core-usage, Os applications will have to be inserted. An Os application is defining
the uC core and the memory protection context on which a task is running. Each task (or
interrupt) is then referenced by exactly one application whose core settings and MP settings
are used to execute the task. One application can inherit several tasks and interrupts. Since
runnable entities are mapped to tasks, the application defines the context of the runnable.

All runnable entities of a BSW module or SWC have to be mapped to the same Os
application. So as soon as a runnable entity of a SWC (or BSW module) is mapped to a
certain task, all the other runnables of the same SWC will have to be mapped to tasks with
the same application referencing them.
1.3.1 Exceptions on Application Distribution - Dem
Some BSW modules can be run in several applications at the same time, this is currently
developed for some modules.
The BSW module Dem for example often needs to be spread over all applications in an ECU
project, therefore there is one Dem_MasterMainFunction() which shall be mapped to
the application that initiates the module Dem, and there is the function
Dem_SatelliteMainFunction_<SatelliteId>(), which needs to be mapped to the
application where the Dem functionality is also needed.
1.4 Affecting Os Task Configurations

The task settings have influences on the execution priority and preemptivity of the runnable
entity which is mapped to it.
> The Priority of a task defines the order of the task executions. If there are runnable
triggered at the same time on different tasks, then the runnables mapped to the task
with the highest priority are executed first.
> The Task Schedule defines if the task (and therefore the triggered runnables) are
allowed to be interrupted by tasks with higher priority.
> The Task Type defines the strategy the Rte/SchM is implementing the cyclic triggers
of your runnable entities. A more detailed description about the configuration
possibilities can be found in [1].
> The Os Application’s Task Reference defines to which application context the task
belongs. This defines the execution context of the task implementation. Therefore, the
application’s reference defines the Safety Inhibition Level and the core on which your
runnable entity is then executed.
> Other settings are either generated automatically or do not affect the runnable entity
triggering
1.5 Affecting Rte Configurations

Within the Rte configuration some further extended adjustments to your runnable entity
triggering can be performed.
> An Os Schedule Point can be added to call the Os API Schedule() after the
execution of a runnable, this enables the Os to interrupt even a NON-preemptive task.
> The Cyclic Trigger Implementation can be set to None which allows the integrator to
implement a customized trigger so that the runnable entity is only called if the
integration code triggers it.

1.6 Configuring Task Mappings and Related Settings

1.6.1 Definition of Cycle Time and Activation Offset
> Cycle time – in which cycle time does the runnable entity need to be called
Figure 1-1 DaVinci Configurator Pro – Configuration of CanSM_MainFunction Cycle Time
Figure 1-2 DaVinci Developer – Configuration of Runnable’s Cycle Time of the Cyclic Trigger
> Activation Offset – which offset from start of the triggering until first invocation of the
runnable entity shall be realized?
Figure 1-3 DaVinci Configurator Pro – Configuration of CanSM_MainFunction’s Activation Offset)

Figure 1-4 DaVinci Configurator Pro – Configuration of SWC Runnable’s Activation Offset of a Cyclic Trigger)
1.6.2 Configuration Editor - Add Task Mapping

Initially, there are a lot of runnable entities to map, therefore the Add Task Mapping editor
can be used to map many runnable entities simultaneously.
It can show all unmapped functions and can filter them to only show all runnable entities
who really have to be mapped to a task. In this list view, several runnable entities can be
selected and mapped to the same task. In further processing of this assistant you can decide
to which task the runnables are mapped and in which execution order they are mapped to
the task.
This makes this assistant ideal for the initial task mapping of your system.

Background Knowledge MICROSAR – Integration of cyclic BSW Mainfunctions
First all runnable entities that need to be mapped to a certain task can be selected at the same time.
Figure 1-5 Select All Necessary Runnable Entities
Afterwards, a task has to be selected, …
Figure 1-6 Select One Task

… and then the execution order of the runnable entities can be modified.
1.6.3 Configuration Editor – Os Configuration

Use the configuration editor Os Configuration to get a more detailed overview over the Os
Configurations for tasks, alarms, applications that also have big influences on the runnable
entities.
Certain runnable entities can also be re-mapped in here:
Figure 1-7 Os Configuration
1.6.4 Configuration Editor – Task Mapping

To get a complete overview over all mapped runnable entities in your system you can use
this view. Particular changes on the task mapping can also be performed here.
Figure 1-8 Task Mapping

Use the several display settings to get an overview over your task mapping system like the
Trigger view above or the runnable owner’s view below.
Figure 1-9 Task Mapping Overview

2 Functional Description of Task Mapping Settings
2.1 Generated Function Calls Via Task Implementation

Both modules of the MICROSAR BSW, Rte and SchM are implementing these triggers via
generated task implementations. The runnable entities mapped to a task are then called by
this task function which is generated by SchM or Rte. Depending on the settings described
above, the implementation of the triggers differs.
Note
The following implementation samples are very simple ones which already differ a bit in
the actual generated Rte code. For several other runnable settings and core /
application distributions of these runnables, the implementation will differ and get much
more complex.
2.2 Trigger Realization - Basic Task vs Extended Task

If a task is configured to BASIC task or EXTENDED task in the Os settings, the Rte will
adjust its runnable entity calling to this setting. A more detailed description of these rules can
be found in [1]. If the task type is configured to AUTO then the Rte performs its default
triggering and the Os Generator will decide which task type this requires.
2.2.1 Extended Task
If runnable entities are mapped to an EXTENDED task,
> Every runnable trigger will be reflected in an Os Event
> identical triggers will be merged to one event if the runnables are mapped to the
same task
> the task will be activated at system start
> The task implementation will wait for one trigger event to proceed its task execution
> Events which trigger cyclic runnable entities are generated by an Os Alarm which is
started at system startup.
> Events for other trigger types (e.G. OnDataReception, OnModeEntry) will mostly be
generated by the generated Rte implementation itself.

Example
TASK(<YourTaskName>) /* Task started at System Startup */
{
EventMaskType ev;
for(;;)
{
(void)WaitEvent(<all Trigger conditions for this
task>);
(void)GetEvent(Bsw_Task, &ev);
(void)ClearEvent(ev & (<all Trigger conditions for
this task>));
if ((ev & <First Trigger condition>) !=
(EventMaskType)0)
{
/* call runnable entity triggered on first event */
<SWC>_RunnableEntity();
}
if ((ev & <Second Trigger Condition>) !=
(EventMaskType)0)
{
/* call BSW runnable entity which is triggered on
second event */
<BSW Module>_MainFunction<UseCase>();
/* call second runnable triggered on second event */
}
}
}
.
This is the default strategy of the Rte to realize runnable entity triggers.
2.2.2 Basic task

If application runnables or BSW MainFunctions are mapped to a BASIC task, the cyclic
function call is realized via cyclic activation of the task which executes the function calls.

Example
TASK(<YourTaskName>) /* Task activated cyclically */
{
/* call schedulable entity */
/* call runnable entity */
/* Terminate Task */
(void)TerminateTask();
}
Basically, all runnable entities mapped to a BASIC task shall have the same trigger,
otherwise a schedule-table-like implementation is used.

2.2.3 Schedule-Table-like Implementation

If runnable entities with different triggers are mapped to a BASIC task, the Rte can also
generate a task Implementation whose cyclic triggers are based on a ScheduleTable.
Example
TASK(Default_BSW_Sync_Task)
{
if (Rte_ScheduleTable_Default_BSW_Sync_Task_Step == 0)
{
/* call first schedulable entity */
/* call cyclic runnable entity */
Rte_ScheduleTable_Default_BSW_Sync_Task_Step = 1;
}
else if (Rte_ScheduleTable_Default_BSW_Sync_Task_Step ==
1)
{
/* call second schedulable entity */
/* call cyclic runnable entity */
Rte_ScheduleTable_Default_BSW_Sync_Task_Step = 0;
}
(void)TerminateTask();
}.
Depending on the Trigger configuration of these runnable entities the task implementations
can become much more complex. There are several further settings that could have
influence on the generation of these cyclic triggers.
2.2.4 Conclusions on BASIC vs EXTENDED Task

As conclusion it can be said that BASIC task implementations are getting more complex if
there are several different cyclic triggers to be realized in one task. This can result in very
long task implementations who could cost ROM. Non-cyclic triggers cannot be realized in
BASIC tasks if there are already cyclic triggers inherited in the task.
Advantage of BASIC tasks is the scheduling speed and the lower resource consumption,
but these are only slight optimizations compared to EXTENDED tasks.

EXTENDED tasks can merge several cyclic triggers and also non-cyclic triggers, but for
each different trigger an Os Event is needed. Some Os implementations are limited to 32
Events per task which limits the amount of different trigger implementations per task.
EXTENDED task implementations can handle more complex triggers and are therefore the
default strategy. For some easy use cases BASIC tasks would be the better strategy, so
keep the default and change to BASIC if you see the need and the possibility for it.
2.3 CUSTOM Trigger Realization

Runnable entities with cyclic trigger realization set to None will have to be triggered manually
by the application code. It has to be distinguished if the runnable entities are mapped to a
BASIC task or to an EXTENDED task.
Figure 2-1 Cyclic Trigger Implementation
This construct can be used if a runnable trigger is based on a cyclic ECU Event (e.g. Adc
conversion finished, Pwm signal was sent completely) which is reflected by an interrupt.
Since SWCs are not allowed to be executed in interrupt context, the event to trigger the
runnable can be set in the CAT2 interrupt context which then activates the task and its
runnable triggering.
2.3.1 CUSTOM Triggers on BASIC Tasks
BASIC tasks with customized triggers can only be realized if ALL triggers within this task are
configured customer-specific. The task which is implemented by the Rte then has to be
activated via ActivateTask(<TaskName>) by the application. Please refer to the
generated task Implementation when to activate the task.
2.3.2 CUSTOM Triggers on EXTENDED Tasks
EXTENDED tasks with customized triggers can merge custom- and automatically-created
trigger implementations within one task implementation. For each runnable entity trigger the
Rte is then generating one specific Event which has to be set via application code
SetEvent(<TaskName>, <EventName>).

2.4 Injecting Schedule() Calls on Task Execution

When runnable entities are mapped to non-preemptive tasks, the system’s timing behavior
can be delayed by the addition of all the maximum runtimes of the mapped runnables within
this task. Therefore, it could be necessary to insert some schedule points in the task
execution where it is allowed for other (higher priorized) tasks to interrupt this task execution.
This injection of the schedule calls enables the system designer to make runnables un-
interruptible, but still configure the task where the runnable is mapped to with a quite low
priority.
Figure 2-2 Injection of Schedule Call
2.5 Runnable Trigger Types

Runnable entities need a trigger when they have to be executed. The following chapters
describe the different types of runnable invocation events the Rte supports. It is possible to
configure several triggers for the same runnable entity
2.5.1 Init
The runnable entity is called OnActivation of the task where the runnable is mapped to. The
setting Position in Task in conjunction to non-init-triggers is ignored in this case.
Init runnables cannot be mapped to the same task as BSW MainFunctions.
2.5.2 Background Task Execution
Runnable entities who need to be executed periodically but do not have timing components
inherited (so do not increment timers on runnable/MainFunction invocation) can also be
called in a loop in a background task. This construct should be an exception for very special
use cases but can be used in the MICROSAR system if needed. Normally this is needed for
long-lasting algorithm executions where the timing constraints are very relaxed and where
they can be executed in the idle time of your ECU.

Take care
If you configure this, most CPU load measurement methods will detect a CPU load of
100%.
Figure 2-3 Background Task Execution
2.5.3 Periodic/Cyclic
Runnables will be called cyclically depending on their cycle time configuration.
2.5.4 On Data Events
If a SWC receives/transmits data elements from a sender/receiver port the events
> reception of a data element (On Data Reception…)
> reception timeout of an external data element (Ón Data Reception Error…) and
> transmission confirmation of an external data element (On Data Send Completion…)
can trigger a runnable entity.
Figure 2-4 On Data Events
2.5.5 Client Server Ports

2.5.5.1 Client Port – On Operation Call Return
When a client calls a server port asynchronously, the return of the server runnable can
trigger a runnable from the client.

2.5.5.2 Server Runnables

Server runnables that implement a client/server port are triggered by client port invocation
of the client of this port.
2.5.5.3 When is a Mapping of Server Runnables Needed?
Mapping of a server runnable is needed if the C/S port invocation is configured as
asynchronous at client side or if the server SWC is mapped to a different application than
the client SWC.
2.5.6 Mode Ports
Mode ports reflect state machine implementations either from the BSW or from SWCs.
Theses mode ports can trigger a runnable execution but can also prevent runnables from
being executed by a trigger.
2.5.6.1 Triggering On Mode Events
If a SWC receives or implements a mode port, runnables can be triggered on events of these
modes. Possible triggers can be
> On entry of a certain mode state
> On exit of a certain mode state
> On transition from one mode state to another
> On mode switch acknowledge, i.e. as soon as all connected mode receivers
acknowledged the reception of a mode transition
Figure 2-5 Trigger Definitions

2.5.6.2 Preventing Runnable Calls – Mode Disabling Dependencies

The setting Disabled in Modes reflects the Mode Disabling Dependency that can be set for
runnable triggers. It prevents this trigger from becoming active. Precondition for this is that
the SWC has to receive the mode which should disable the runnable triggering.
Figure 2-6 Mode Disabling

3 System Effects and Cross Dependencies
3.1 Effects of Task Mapping Properties

Task mappings highly define the behavior of your system. The task mapping of the BSW
MainFunctions and the application runnables define the context in which the functionality is
executed.
Note
To enable an ECU to react fast and smooth without bigger latencies, it is essential to
carefully design the task mapping of its functions.
3.1.1 Task Priorities

Runnables are mapped to tasks. Task execute runnables. Tasks can interrupt each other,
so if a higher priority task is activated, the lower priority task and therefore its runnable will
be interrupted by other runnable-executions.
Figure 3-1 Task Priorities and Interruption
The runnables mapped to lower priority tasks will be interrupted as soon as a higher priority
task is being activated (due to runnable triggers). Triggers for lower priority tasks will only
become active when the higher priority tasks are suspended.
The more important a runnable is, the higher the priority of the task should be on which it is
mapped. Otherwise, functional latencies could occur, and cycle times will be deviated. Two
basic rules shall help you here:
Two Basic Rules for Task Mapping:

> The faster the cycle time of a runnable, the higher the priority of the task where the
runnable is mapped
> The higher the priority of the task where the runnable is mapped, the shorter
execution time of the runnable should be
If you follow these rules the most important functionalities in your system will be executed
right on time (due to high task priorities), and they will not halt the complete system (due to
the short execution time).

3.1.2 Task Preemptivity

3.1.2.1 FULL Preemptive
FULL Preemptive is the default task property. The tasks (and therefore their mapped
runnables) can be interrupted at any time. This configuration reduces latencies in your
system but needs exclusive areas and careful system design to prevent from un-
synchronized state machines.
3.1.2.2 NON Preemptive
NON Preemptive tasks cannot be interrupted by other tasks. A runnable mapped to this kind
of task will be executed in one piece without interruption (except interrupts). Therefore, the
scheduling work of the Os will decrease, but this could lead to higher latencies on other
triggers of runnables. The runnables mapped to non-preemptive tasks shall be very short, a
typical worst case execution time of a whole non-preemptive task could be 1ms, but this
highly depends on your ECU requirements. E.g. if four runnables with slightly more than
250us worst case execution time are mapped to a non-preemptive task, a delay of more
than 1ms can (and will) happen.
Figure 3-2 Non-Preemptive Tasks
Even if the higher priority tasks have active triggers, the runnables in the lower priority task
are executed first since the task is non-preemptive. When the Task Prio 1 was finished,
then triggers for Task Prio 2 and Task Prio 3 were active, here the priority 3 wins.
Note
> Tasks on other Cores can run in parallel
> Interrupts still can interrupt this task, even CAT2 interrupts, this would delay other
tasks even more than the 1ms calculated before.
3.1.2.3 NON-Preemptive and Injection of Schedule Calls

To avoid such long delays there is an OS API void Schedule(void) that, if called in a
non-preemptive task context, triggers a rescheduling, so higher priority tasks that became
active will not be executed first. A runnable entity trigger can be configured to call the
Schedule() API after the runnable triggering. This can avoid long delays on your system
without the need to take care that your runnable entity can be interrupted by other runnables.

Figure 3-3 Predetermined Breaking Point
The schedule calls within a non-preemptive task create a predetermined breaking point
in task execution where higher priority tasks can be activated and executed at once. This
enables easier runnable design and implementation.

3.1.3 Position in Task

The task implementations of the Rte implement an order of the calls of the runnable entities.
So if
> several trigger conditions are met at the same time of task activation or
> several runnable entities have the same trigger and mapped to the same task
all the runnables have to be called within the same task activation. This can be taken as
advantage to sort your runnable entity calls in a logical order. E.g. if you have 3 runnables
1. ReadSensorData
2. CalculateData
3. TriggerActionsBasedOnSensorData
Exactly this order can be configured as Position in Task. This then enables you to minimize
the latency from gathering sensor data to performing actions based on the sensor data.
To make the picture complete you could map these runnables to a non-preemptive task and
insert Schedule() after processing the runnable
TriggerActionsBasedOnSensorData.
These cases happen very often since some cyclic triggers are very popular (5ms, 10ms,
50ms), in case of 50ms also the 10ms and 5ms triggers become active at the same time.
3.1.4 Activation Offset
All alarms for cyclic triggers are started at the same time (please refer to chapter 4.1, at the
moment there are two different times). It often happens that cyclic triggers cumulate to one
point in time where all runnable triggers are to be executed at the same time, this could lead
to CPU load peaks on certain cycles (e.g. every 50ms) that will last over several ms. This
could in turn produce larger latencies for your system than expected, at least worst case
scenarios will happen more often than necessary.
To avoid this the Activation Offset can be configured for each cyclic runnable trigger. The
alarm that triggers the affecting runnable is then started with the configured delay, from this
time on the cyclic trigger always comes cyclically, but with the offset configured.
This construct can be used to avoid peak loads on your system.
3.2 Effects of Runnable Implementations

3.2.1 Can Be Invoked Concurrently?
By default, tasks are fully preemptive. This means a task and its mapped runnable can be
interrupted by a higher priority task at any time. In the worst case a currently executed
runnable can be interrupted by a function call to the same runnable entity.
So, the easiest would be to design your software runnables in a way that they can be
interrupted all the time by any other function calls, even by a function call to themselves. If
this is the case, you can configure your SWC runnables with the property Can be invoked
concurrently.

Figure 3-4 Can Be Invoked Concurently
To reach this you can also define exclusive areas in the SWC, which prevent other tasks
from interrupting the currently executed task, but this costs execution time and therefore
CPU load. It could also lead to latencies if the exclusive area is active for a long time.
3.2.2 BSW Exclusive Areas
The MICROSAR basic software implements several of its functions preemptively, but not all
of them. For example, a function Dem_SetEventStatus can be invoked concurrently, so
it can be interrupted by a function call to the same function whereas a Dem_MainFunction
is not preemptive and therefore not allowed to interrupt itself. To protect the RAM content of
the basic software, nearly each BSW module is defining exclusive areas, which are by
default mapped to an interrupt lock. These exclusive areas are described in the technical
references of their modules and can be configured in the Rte section of the DaVinci
Configurator Pro. To optimize your system regarding latencies and CPU load, you could
configure some of these exclusive areas to None, but you will have to follow the rules for
exactly this exclusive area in the technical reference of the module.
Figure 3-5 Exclusive Area
To conclude
Exclusive areas basically prevent the system from activating tasks / interrupts and as a
result prevent calling runnables on their configured triggers
> Keep the runtime within exclusive areas as short as possible
> Measure the maximum runtime of an exclusive area, add the maximum runtime of
all interrupts that could be triggered at the same time, then you get the maximum
possible delay of your highest priority task

3.3 Effects of Client Server Call Configurations

Client server port interfaces define server runnable calls triggered from the client. This can
also be modelled as Remote Procedure Call to other tasks, cores or even ECUs.
3.3.1 Synchronous Runnable Invocation
Synchronous unmapped client/server invocations are generated as simple function calls,
but as soon as the server runnable is mapped to a task, the realization of these client/server
invocations is getting complex.
3.3.1.1 Unmapped
When the server runnable is not mapped to a task context, then the client calls the function
directly. In turn this means that the function call is performed in the same context as the
caller runnable. This requires that the server SWC and the client SWC are mapped to the
same application.
This is the easiest way of client/server port invocation which also produces nearly no
overhead in the Rte.
If the server runnable can be called from different task contexts, it has to be ensured that
the flag Can be invoked concurrently is set for this runnable.
3.3.1.2 Mapped to Task
As soon as client and server SWCs are mapped to different applications, the context of the
function call has to be switched, the passing parameters and the return values will have to
be exchanged. This leads to
> a significant overhead in the Rte
implementation
> the caller task has to busy-wait for the

server runnable task
> if there are higher priority tasks waiting

for activation, even these tasks will be
executed before the server runnable is
called and the busy-waiting is left.
Result: Synchronous client/server

calls can be configured with a timeout,
then the return value if the C/S
invocation will be RTE_E_TIMEOUT,
but the system is not delayed more
than the timeout time
3.3.2 Asynchronous Server Runnable Invocation

A better way to realize client/server invocations over the boundaries task, core or application
is to use asynchronous calls. This usage requires SW design changes if you had
synchronous invocations implemented before:

> with synchronous client/server invocation

the return value of the server runnable is
passed to the return of the client call
Rte_Call()
> with asynchronous client/server invocation
the return value of the server runnable has
to be gathered via the call Rte_Result()
after the client/server invocation was started
with Rte_Call()
In this sample the return value of the
client/server invocation is polled cyclically until
the server finished the call. This should be the
preferred way in realtime software designs.
It is also possible
> to trigger another runnable on server call
return or
> to busy-wait until the server finished, but
both would result in overheads in CPU load
and delays.

4 Runnable Mappings – Pitfalls and Best Practices
4.1 Different Time Bases for BSW and SWC Runnables

Rte is automatically configuring alarms to trigger the runnables of BSW modules and SWCs.
On startup, these alarms are automatically started by the Rte. Alarms that trigger BSW
runnables are started within function SchM_Init(). Alarms that trigger SWC runnables are
started within function Rte_Start().
SchM_Init is called before the call to NvM_ReadAll, Rte_Start is called at the end of
the initialization sequence. After Nvm_ReadAll and before Rte_Start there is by default
a busy-waiting loop that reads out the non-volatile data. Since this loop can last randomly
long, there is no deterministic time difference between SchM_Init and Rte_Start.
Offsets modelled via ActivationOffset between BSW MainFunction triggering and SWC
Runnable triggering will not be deterministic.
As workaround you can cancel and restart the alarms from SchM_Init manually right after
the call of Rte_Start. In future releases of the Rte there will be two APIs called
Rte_StartTiming and SchM_StartTiming which can be called one after another.
4.2 Event-based Triggers vs Number of Events Within a Task

Runnable triggers mostly create an Os event for the task where the runnable is mapped. Os
implementations differ in the number of events that can be handled within one task. E.g. the
latest MICROSAR implementations support 64 events per task. Some software designs
require more events per task which then will not be supported. Try to avoid such software
designs. In most cases an easier software design could be modelled which works with cyclic
polling mechanisms instead of event based triggers.
4.3 Map As Less Server Runnables As Possible

As soon as a server runnable out of a client/server port is mapped to a task there will be
necessary an overhead in the Rte implementation. Either software design has to be switched
from function calling to remote procedure calling with polling for return values or the
Rte needs to implement a kind of busy-waiting. Both constructs produce CPU load, RAM
and ROM overhead. This can be avoided if the server runnables are not mapped to a task.
This in turn often makes it necessary to design/implement the server runnables as
preemptive (runnable property Can be invoked concurrently), but it is worth it.

Figure 4-1 Task Mapping Assistant – Select Function Trigger
DaVinci Configurator Pro knows which runnables need to be mapped. In the Add Task
Mapping wizard there is a checkbox Don’t show functions where mapping is optional,
have this option always checked and only map these server runnables where it is really
necessary.
4.4 Mode Dependent Triggers

State machines in SWCs are modelled via mode declaration groups, mode switches, mode
switch acknowledges and mode ports. They are implemented in SWC runnables which call
mode switches and modify those mode ports. These changes and the runnable triggers for
mode changes are synchronized via the Rte. These complex interactions need to be
modelled and configured carefully, there are also some constraints to be thought on design
time.
4.4.1 Task Mapping of Mode Dependent Runnable – One Task for Mode Triggers
All mode-dependent runnable triggers are synchronized by the Rte. The Rte generates the
state machine synchronization code into one specific task.
Therefore, the Rte often requires a very specific task mapping of runnable entities. E.g.
runnables triggered by OnModeEntry shall have an earlier position in task than OnExit
runnables.
4.4.2 Possible Deadlocks - Mode Disabling Dependencies vs Mode Switches
Runnable triggers can be disabled on certain mode states. This allows to prevent the Rte
from calling a runnable regarding a certain mode state.
Caution.
Please make sure that runnables configured with Mode Disabling Dependencies for a
certain mode must not be responsible for switching this mode. Otherwise this can
result in a deadlock of the mode state machine.

4.5 Cyclic Triggers - CPU Load Distribution vs Reducing Alarm Action

An Os alarm is created for each cyclic trigger with each activation offset on each task. Each
Os alarm costs additional execution time on Os side. On the one hand merging cyclic
triggers reduces CPU load. On the other hand, a certain amount of CPU load distribution is
essential for a system without peak loads.
The following rules seem to contradict each other, but in some way, they can be
met altogether:
1. Use Activation Offsets
2. Avoid too much Os actions
3. Avoid too much rescheduling.
If we take another rule into account:
Short cycle time → higher priority → shorter execution time
Since the task defines the priority of the runnable which is mapped, we could assume that
runnable entities with the same cyclic trigger can be mapped to the same task. This merge
of one cyclic trigger on one task reduces the amount of needed Os alarms. If all these
runnables define the same activation offset, we could also distribute the CPU load of all the
5ms runnables to one certain offset time where no other runnable triggers are modelled.
If the 10ms runnables are also merged to another activation offset, they will never meet each
other, therefore the peak load is prevented and only 2 Os alarms are necessary.
For sure this will not be possible for all runnable entities. Properties like
> Safety inhibition level
> Core assignment
> Synchronization of functionalities to external time bases
> Required execution order of distributed functionalities
> Logical grouping of functionalities and their runnables to tasks would prevent you from
modelling this strategy, but at least for the BSW clusters and for functional units in your
applications this could be discussed.
4.6 Synchronizing Runnable Entities to External Time Bases

For the use cases STBM and FlexRay it might be necessary to synchronize some BSW and
application runnables to an external time base, sometimes it would make sense to
synchronize the whole ECU to this time base. For this purpose, there are two possibilities,
restarting alarms or synchronizing schedule tables.
4.6.1 Synchronizing Via Restarting of Alarms
If there is a time base event (e.g. a CAT2 interrupt) that indicates some kind of starting point
of a timing, this could be easily used to synchronize one or several Os alarms to this time
base. On FlexRay there is for example a Cycle Start Callback called from FrIf. This callback
indicates that the FlexRay cycle time now is overflowed and starts with macro tick 0 again,
this can be used to synchronize one or several alarms to this system.

On FlexRay systems it is essential that e.g. FrNm_MainFunction is called 4ms after cycle
start, whereas the FrTp_MainFunction has to be called 1ms after cycle start. Let’s
assume both MainFunctions are mapped to the same FrSynchtask with ActivationOffset
1ms and 4ms.
The generated function SchM_Init()is starting the corresponding two alarms at startup,
but at startup the ECU hardware is not synchronized to the FlexRay bus, so the alarms are
not synchronized either.
Figure 4-2 Schm_Init Function
On invocation of the function ApplFr_ISR_CycleStart(void) which is called on

CycleStart, the alarms need to be restarted with the same offsets already configured.
So you can easily stop the two alarms via CancelAlarm() and then restart them via the
same function calls given in the SchM_Init function: SetRelAlarm().
So in the end it would look like this:
Figure 4-3 Fr-ISR_CycleStart
The alarms are stopped at (nearly) macro tick 0, then they are restarted with second
parameter offset and 3rd parameter cycle time. Usually FlexRay cycles are 5ms long.
4.6.2 Synchronizing via Schedule Table Synchronization
Schedule tables are completely synchronizable time bases where on every timer tick an
action (like activating a task or setting an event) can be configured. These actions can be
used to implement the cyclic triggers of your runnable entities. If configured right, one
schedule table could trigger all runnable entities. This time base can be re-synchronized at
any time at runtime via function call SynchScheduleTable().

Caution
Using Os schedule tables is not automated via the tooling. All runnable entity’s Cyclic
Trigger Implementations will have to be set to None and you will have to configure
the schedule table on your own to set the events on the right timings.
4.7 Triggering BSW MainFunctions – Best Practices

4.7.1 Splitting Rx and Tx MainFunctions
BSW modules with communication aspects often give the possibility to split their
MainFunctions into Rx and Tx paths, sometimes also the state handling is separated in an
own MainFunction. This makes it possibe to sort the module functionalities according to the
communication path of the AUTOSAR System.
As this sample shows the MainFunction calls’
positions in the task are ordered upon the following
rules:
1. First Rx, then state handling, Tx last
2. Rx Path: Lower layers first
3. Tx Path: Higher layers first
So first all MainFunctions are called that are sticked
to the Rx paths of the PDUs. Since the lower layers
are the first affected modules, they have to be
called first so that the reception path from lowest to
highest affected module is reflected.
After Rx all MainFunctions are called that possibly
need to react on the reception of a PDU. This
lowers the reaction time on such PDU receptions.
After this the Tx MainFunctions are called to handle
a possible PDU transmission path. These calls are
ordered from highest Levels to the lowest levels to
reflect the transmission path where the higher
layers setup the transmit calls to the lower levels.
Only exception is the Can_MainFunction_Write. It
is not handling the transmission, this is performed
upon CanIf_Transmit invocations from
PduR/CanTp/CanNm MainFunctions. The function
Can_MainFunction_Write is just calling the Tx
confirmation functions to the higher layers and empties
the Tx mailboxes. This function has to be called at
least before CanNm_MainFunction or
CanTp_MainFunctionRx since these functions need
to know if a probable earlier transmission request was
already finished completely.

4.7.2 Splitting Worker and Timer Tasks

Some BSW modules have contradicting task mapping requirements, one with high CPU
load but low priority functionality, one with non-CPU load intensive but timing-sensitive
functionality. These modules provide the possibility to split the MainFunctions where these
functionalities are executed
This gives the integrator the possibility to map the time sensitive part to a high priority task
and the CPU load intensive part to a low priority task.
At the moment this is only supported by module Dcm:
Figure 4-4 Dcm – Split Task Enabled
Where now there is one Dcm_MainFunctionTimer and one

Dcm_MainFunctionWorker that can be mapped on different tasks:
Figure 4-5 Dcm – Task Mapping
4.7.3 Memory Stack Triggering

If there is a pending request at NvM of Fee/Ea, the corresponding MainFunctions execute
calculations until they can setup a request to their lower layers or they are idle again.
Therefore, they are dependent on the state of the lower layer module or they will get idle
after one MainFunction invocation.
The only blocking point in the state handling are the lower driver levels Eep and Fls. Their
MainFunctions are polling hardware states and can only execute actions for a certain
number of bytes.
Since NvM, Ea and Fee MainFunctions are implemented to return without action very fast if
there is nothing to do, these functions can be called in the same cycle time than the driver.
This leads to a quite easy mapping strategy where it is only important that you follow the
software design, either from lower to higher layers or vice versa. Which direction was tested
and simulated by Vector, but there was no difference in the performance.

In some configurations it made sense to oversample memory driver and abstraction

modules, then this triggering strategy would be feasible. Here both use cases are handled:
> Finishing a Fls job with low latency to NvM
> Starting a Fls job with low latency from NvM invocation until Fls hardware trigger

5 Contact
Visit our website for more information on
> News
> Products
> Demo software
> Support
> Training data
> Addresses


DOCU-738 - Integration of Cyclic BSW Mainfunctions

Uploaded by

Copyright:

Available Formats

DOCU-738 - Integration of Cyclic BSW Mainfunctions

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DOCU-738 - Integration of Cyclic BSW Mainfunctions

Uploaded by

Copyright:

Available Formats

Mapping of Runnables in RTE

Background Knowledge MICROSAR

Influences on the ECU behavior regarding the task

Author Date Version Remarks

No. Source Title Version

© 2020 Vector Informatik GmbH Version 1.0.0 2

1 Definition and Configuration ................................................................................................ 6

2 Functional Description of Task Mapping Settings............................................................. 13

3 System Effects and Cross Dependencies .......................................................................... 22

© 2020 Vector Informatik GmbH Version 1.0.0 3

3.1 Effects of Task Mapping Properties ........................................................................... 22

4 Runnable Mappings – Pitfalls and Best Practices............................................................. 29

© 2020 Vector Informatik GmbH Version 1.0.0 4

© 2020 Vector Informatik GmbH Version 1.0.0 5

1 Definition and Configuration

1.1 Definition of a Runnable Entity

1.2 Definition of Task Mapping

1.3 Multi-core and ASIL Partition Distribution – Definition of Os Applications

© 2020 Vector Informatik GmbH Version 1.0.0 6

1.4 Affecting Os Task Configurations

1.5 Affecting Rte Configurations

© 2020 Vector Informatik GmbH Version 1.0.0 7

1.6 Configuring Task Mappings and Related Settings

Figure 1-1 DaVinci Configurator Pro – Configuration of CanSM_MainFunction Cycle Time

Figure 1-3 DaVinci Configurator Pro – Configuration of CanSM_MainFunction’s Activation Offset)

© 2020 Vector Informatik GmbH Version 1.0.0 8

1.6.2 Configuration Editor - Add Task Mapping

© 2020 Vector Informatik GmbH Version 1.0.0 9

Figure 1-5 Select All Necessary Runnable Entities

Afterwards, a task has to be selected, …

Figure 1-6 Select One Task

© 2020 Vector Informatik GmbH Version 1.0.0 10

1.6.3 Configuration Editor – Os Configuration

Figure 1-7 Os Configuration

1.6.4 Configuration Editor – Task Mapping

Figure 1-8 Task Mapping

Figure 1-9 Task Mapping Overview

© 2020 Vector Informatik GmbH Version 1.0.0 12

2 Functional Description of Task Mapping Settings

2.1 Generated Function Calls Via Task Implementation

2.2 Trigger Realization - Basic Task vs Extended Task

© 2020 Vector Informatik GmbH Version 1.0.0 13

2.2.2 Basic task

© 2020 Vector Informatik GmbH Version 1.0.0 14

© 2020 Vector Informatik GmbH Version 1.0.0 15

2.2.3 Schedule-Table-like Implementation

2.2.4 Conclusions on BASIC vs EXTENDED Task

© 2020 Vector Informatik GmbH Version 1.0.0 16

2.3 CUSTOM Trigger Realization

Figure 2-1 Cyclic Trigger Implementation

© 2020 Vector Informatik GmbH Version 1.0.0 17

2.4 Injecting Schedule() Calls on Task Execution

Figure 2-2 Injection of Schedule Call

2.5 Runnable Trigger Types

© 2020 Vector Informatik GmbH Version 1.0.0 18

Figure 2-3 Background Task Execution

Figure 2-4 On Data Events

2.5.5 Client Server Ports

© 2020 Vector Informatik GmbH Version 1.0.0 19