This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

RTE

1: Rte Peer Review Checklists
2: SafetyGuide_Rte
3: SafetyGuide_Rte_ind
4: SafetyGuide_Rtes
5: TechnicalReference_Rte
6: TechnicalReference_Rte_ind
7: TechnicalReference_Rtes
8:

RTE

Component Documentation

1 - Rte Peer Review Checklists

Overview

Summary Sheet
Synergy Project

Sheet 1: Summary Sheet

Rev 1.2

8-Jun-15

Peer Review Summary Sheet

Synergy Project Name:

kzshz2: Intended Use: Identify which component is being reviewed. This should be the Module Short Name from Synergy Rationale: Required for traceability. It will help to ensure this form is not attaced to the the wrong change request. Rte

Revision / Baseline:

kzshz2: Intended Use: Identify which Synergy revision of this component is being reviewed Rationale: Required for traceability. It will help to ensure this form is not attaced to the the wrong change request. Rte_Vector_4.8.0.0_0

Change Owner:

kzshz2: Intended Use: Identify the developer who made the change(s) Rationale: A change request may have more than one resolver, this will help identify who made what change. Change owner identification may be required by indusrty standards. Lucas Wendling

Work CR ID:

EA4#3178

kzshz2: Intended Use: Intended to identify at a high level to the reviewers which areas of the component have been changed. Rationale: This will be good information to know when ensuring appropriate reviews have been completed. Modified File Types:

kzshz2: Intended Use: Identify who where the reviewers, what they reviewed, and if the reviewed changes have been approved to release the code for testing. Comments here should be at a highlevel, the specific comments should be present on the specific review form sheet. Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits. ADD DR Level Move reviewer and approval to individual checklist form Review Checklist Summary:

Reviewed:

N/A

MDD

N/A

Source Code

N/A

PolySpace

N/A

Integration Manual

N/A

Davinci Files

Comments:

3rd Party BSW component. Only reviewed 3rd party files for correctness to delivery and any Nexteer created

source files and documentation

General Guidelines:
- The reviews shall be performed over the portions of the component that were modified as a result of the Change Request.
- New components should include FDD Owner and Integrator as apart of the Group Review Board (Source Code, Integration Manual, and Davinci Files)
- Enter any rework required into the comment field and select No. When the rework is complete, review again using this same review sheet and select Yes. Add date and additional comment stating that the rework is completed.
- To review a component with multiple source code files use the "Add Source" button to create a Source code tab for each source file.
- .h file should be reviewed with the source file as part of the source file.

Sheet 2: Synergy Project

Peer Review Meeting Log (Component Synergy Project Review)

Quality Check Items:

Rationale is required for all answers of No

New baseline version name from Summary Sheet follows

Yes

Comments:

Follows convention created for

naming convention

BSW components

Project contains necessary subprojects

N/A

Comments:

Project contains the correct version of subprojects

N/A

Comments:

Design subproject is correct version

N/A

Comments:

General Notes / Comments:

LN: Intended Use: Identify who were the reviewers and if the reviewed changes have been approved. Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits. KMC: Group Review Level removed in Rev 4.0 since the design review is not checked in until approved, so it would always be DR4. Review Board:

Change Owner:

Lucas Wendling

Review Date :

01/20/16

Lead Peer Reviewer:

Jared Julien

Approved by Reviewer(s):

Yes

Other Reviewer(s):

2 - SafetyGuide_Rte

YourTopic

3 - SafetyGuide_Rte_ind

4 - SafetyGuide_Rtes

MICROSAR RTE
Safety Guide

Version 4.8.0

Authors
Sascha Sommer, Bernd Sigle
Status
Released

Safety Guide MICROSAR RTE
Document Information
History
Author
Date
Version
Remarks
4.1.0
2013-04-15
Sascha
Initial Creation for RTE 4.1 (AUTOSAR 4)
Sommer
4.2.0
2013-10-29
Sascha
Updated for RTE 4.2
Sommer
Explained MICROSAR OS interrupt locking
Bernd Sigle  APIs.
Corrected review findings especially the
used abbreviations.
4.3.0
2014-02-05
Sascha
Updated for RTE 4.3
Sommer
Clarified Assumptions about VFB Trace
Hooks
Described Inter-ECU sender/receiver from
the ASIL partition
Support for mapped client/server calls
between partitions
Multicore Support
SuspendAllInterrupts is no longer used
4.4.0
2014-06-11
Sascha
Updated for RTE 4.4
Sommer
4.5.0
2014-10-15
Bernd Sigle  Updated for RTE 4.5
Rte_DRead added
4.6.0
2014-12-10
Sascha
Updated for RTE 4.6
Sommer
4.7.0
2015-03-18
Sascha
Updated for RTE 4.7
Sommer
4.8.0
2015-07-15
Sascha
Updated for RTE 4.8
Sommer
Described APIs/scheduling of ASIL BSW
Reference Documents
No.
Source
Title
Version
[1]   AUTOSAR
AUTOSAR_SWS_RTE.pdf

3.2.0
[2]   AUTOSAR
AUTOSAR_SWS_OS.pdf

5.0.0
[3]   AUTOSAR
AUTOSAR_SWS_StandardTypes.pdf

1.3.0
[4]   AUTOSAR
AUTOSAR_SWS_PlatformTypes.pdf

2.5.0
[5]   AUTOSAR
AUTOSAR_SWS_CompilerAbstraction.pdf

3.2.0
2015, Vector Informatik GmbH
Version: 4.8
2 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
[6]   AUTOSAR
AUTOSAR_SWS_MemoryMapping.pdf

[7]   Vector
Technical Reference MICROSAR RTE
4.8.0
[8]   ISO
ISO/DIS 26262
2009

Scope of the Document
This document describes the use of the MICROSAR RTE with regards to functional safety.
All  general  aspects  of  the  MICROSAR  RTE  are  described  in  a  separate  document  [7],
which is also part of the delivery.

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.

2015, Vector Informatik GmbH
Version: 4.8
3 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
1
Purpose
The SEooC  is developed based on assumptions on the intended functionality, use and
context, including external interfaces.  To  have  a  complete  safety  case,  the  validity  of
these  assumptions  has to be  checked  in  the context of the actual item after integration
of the SEooC.
The application conditions for SEooC provide the assumptions made on the requirements
(including safety requirements) that are placed on the SEooC by higher levels of design
and also on the design external to the SEooC and the assumed safety requirements and
assumptions related to the design of the SEooC.
The  ASIL  capability  of  this  SEooC  designates the  capability  of  the  SEooC to
comply  with  assumed  safety requirements assigned with the given ASIL.
Information given by this document helps to check  if  the  SEooC  does fulfil  the  item
requirements,  or if a  change  to  the  SEooC  will be necessary in accordance with the
requirements of ISO 26262.

The following document describes the SEooC MICROSAR RTE in the version 4.8.

2015, Vector Informatik GmbH
Version: 4.8
8 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
2
Assumptions on the scope of the MICROSAR RTE
2.1
MICROSAR RTE overview
The MICROSAR RTE implements the AUTOSAR Standard of a Runtime Environment for
AUTOSAR Software Components (SWCs) and Basic Software Modules (BSW). This
means that the RTE is responsible for triggering the execution of SWC and BSW specific
code in the form of runnable and schedulable entities. Moreover, the RTE provides APIs,
for example for inter-ECU and intra-ECU communication and for exclusive area accesses.
These APIs can be used by the runnable entities and BSW modules.
The MICROSAR RTE is a generic software component that is not tied to a specific item.
Item specific functionality will be provided by the SWCs. The SWCs therefore also
determine the ASIL that is required for the RTE. Consequently, the MICROSAR RTE can
be seen as Safety Element out of Context (SEooC) according to ISO26262-10. This
document provides the assumptions regarding the software safety requirements and the
architectural design specification that were used for the development of the MICROSAR
RTE. These assumptions have to be confirmed during item development.
The MICROSAR RTE is completely generated by the MICROSAR RTE Generator that is
developed according to the established SPICE certified process (further referred to as
QM).
If the generated code shall be used in an ASIL context, it has to be qualified according to
the requirements of ISO 26262-6.
This document describes how the RTE configuration needs to look like so that it is in line
with the safety assumptions and so that the complexity of the generated RTE code for
ASIL SWCs is kept low enough to be reviewable for qualification. Review hints are
provided in chapter 6.
The final integration of the RTE into a safety related item then needs to be done by a
functional safety expert.

Please note that this document is an extension to the Technical Reference of the
MICROSAR RTE with focus on safety related issues. Refer to the Technical Reference [7]
for general topics like the RTE configuration, integration of the RTE into an ECU and a
description of the RTE APIs.
An overall description of the RTE and AUTOSAR in general can be found in the AUTOSAR
specifications.

Caution
The MICROSAR RTE Generator was not developed according to ISO26262. This
document gives hints on what needs to be done in order to use the generated code
within an item that is developed according to ISO26262.

2015, Vector Informatik GmbH
Version: 4.8
9 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
Safety goals identified for the development result from the following hazard and risk list
ID
Description of hazards that could occur
H&R_RTE_1

H&R_RTE_2

H&R_RTE_3

Table 2-1   Hazards
According to ISO26262,  the hazard  analysis and risk assessment shall be based on the
item  definition. As  the  development  started  with  the  unit  design,  the  hazards  have  to  be
identified by the integrator for the specific item in which the RTE shall be integrated.

2.2
Standards and Legal requirements
The  MICROSAR  RTE  Generator  was  developed  according  to  the  AUTOSAR  RTE
specification. The generated code can be qualified so that  it can be used within  an item
that is developed according to ISO26262.
2.3
Functions of the MICROSAR RTE
The MICROSAR RTE  provides the following functionality:
>  AUTOSAR Runtime Environment according to [1] for QM SWCs and BSW:
>  communication between different runnables within the same SWC (explicit and
implicit inter-runnable variables)
>  communication between different SWCs on the same ECU (queued and non-
queued explicit and implicit sender/receiver communication, client/server
communication, mode communication)
>  communication between SWCs and BSW modules located on the same ECU
(queued and non-queued explicit and implicit sender/receiver communication,
client/server communication, mode communication)
>  communication between SWCs on different ECUs (queued and non-queued
explicit and implicit sender/receiver communication)
>  Calibration Parameters
>  Per-Instance Memories
>  Exclusive Areas
Please see the RTE Technical Reference [7] for a full list of supported features.

2015, Vector Informatik GmbH
Version: 4.8
10 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
>  AUTOSAR Runtime Environment for ASIL SWCs and BSW when the generated RTE
code is qualified according to the requirements of ISO26262 (Code description and
configuration limitations described in this document):
>  Possibility to assign SWCs with different  safety levels to distinct  OS
applications, so that a MPU can be used to provide freedom from interference
with regards to memory
>  Support for Basic Tasks
>  Cyclic triggering of runnable entities
>  Cyclic triggering of schedulable entities
>  Per-Instance Memories
>  Explicit Inter-Runnable Variables
>  Explicit intra-ECU Sender/Receiver Communication with last-is best behaviour
between SWCs with the same and different safety levels
>  Explicit inter-ECU Sender/Receiver Communication with last-is best behaviour
>  Direct Synchronous Client/Server calls inside the same OS application
>  Calibration Parameters
>  Explicit Exclusive Areas

>  AUTOSAR Runtime Environment for ASIL SWCs when the generated RTE code is
qualified according to the requirements of ISO26262 (Not handled in this document due
to the many possible code variants):
>  Support for Extended Tasks
>  Init, Background, DataReceived, DataReceptionError, DataSendCompleted
Triggers
>  Implicit Sender/Receiver communication
>  Queued Sender/Receiver communication
>  Synchronous and Asynchronous Client/Server calls to mapped server runnables
in different OS applications

Table 2-2 summarizes the RTE features that are available for ASIL and QM SWCs.
2015, Vector Informatik GmbH
Version: 4.8
11 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE

1

on
W
tii
S

tr
B
e
Feature
h

pa
W
m t
S
or

e B
d f
h
e
W
S
n t
at
i
B

r
/
pa
Cs
e
Cs
W
s
W
Cs
SL
M S
I
W
S
Q
S
A
Multicore Support

    
Runnable Triggers
TimingEvent

    
InitEvent
  

BackgroundEvent
  

DataReceivedEvent4
  

DataReceivedErrorEvent4
  

DataSendCompletedEvent
  

OperationInvokedEvent4
    
AsynchronousServerCallReturnEvent4
  

ModeSwitchEvent4


ModeSwitchAckEvent


SWC Settings
Source Code

    
Object Code
  

Multiple Instantiation
  

Indirect API
  

Runnable Settings
Minimum Start Interval

  

Task Settings
Basic Tasks

    
Extended Tasks
  

Calibration Support
Rte_CData API

    
Rte_Prm API
    
Online Calibration


Per
Rte_Pim API
-Instance Memories

    
Inter
Rte_IrvWrite API
-Runnable Variables

    
Rte_IrvRead API
    
Rte_IrvIWrite API
  

Rte_IrvIRead API
  

Sender/Receiver Communication
Rte_Write API

    
Rte_Invalidate API
  

Rte_Read API
    

1 SWCs can either be assigned to the same partition as the BSW (recommended for QM SWCs, see column 1), or one
or  more  separate  partitions  can  be  created.  In  this  case,  no  features  that  require  special  handling  when  the  RTE  is
initialized by the BSW and no features that require direct access to the BSW can be used. The marked features can be
used for QM and ASIL SWCs but only the APIs marked in the column “ASIL SWCs” are described in this document.
2015, Vector Informatik GmbH
Version: 4.8
12 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE

1

on
W
tii
S

tr
B
e
Feature
h

pa
W
m t
S
or

e B
d f
h
e
W
S
n t
at
i
B

r
/
pa
Cs
e
Cs
W
s
W
Cs
SL
M S
I
W
S
Q
S
A
Rte_DRead API
  

Rte_IWrite API
  

Rte_IWriteRef API
  

Rte_IInvalidate API
  

Rte_IRead API
  

Rte_IStatus API
  

Rte_Feedback API
  

Rte_IsUpdated API
    
Rte_NeverReceived API4
  

Rte_Send API2
  

Rte_Receive API2
  

inter-ECU communication
    
intra-ECU communication
    
Unconnected Ports
  

transmission acknowledgement
  

alive timeout
  

rx filters4
  

Client/Server Communication
Rte_Call API

    
Rte_Result API
  

synchronous calls to unmapped runnables3
    
synchronous calls to mapped runnables on same task
    
synchronous calls to runnables on different tasks2
  

asynchronous calls
  

Mode communication
Rte_Switch API



Rte_Mode API4
    
Enhanced Rte_Mode API4
  

Rte_SwitchAck  API



2  Only  supported  when  all  senders/callers  are  within  the  same  partition.  The  servers/receivers  can  be  in  a  different
partition.
3 Please note that this might not be possible when the server runnable is located in a different  OS Application as the
server  is  executed  with  the  access  rights  of  the  caller.  Also  no  additional  protection  measures  are  applied  when  the
communication is between SWCs with different safety level.
4 Please note that this feature is not possible for QM SWCs when the sender is an ASIL SWC
2015, Vector Informatik GmbH
Version: 4.8
13 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE

1

on
W
tii
S

tr
B
e
Feature
h

pa
W
m t
S
or

e B
d f
h
e
W
S
n t
at
i
B

r
/
pa
Cs
e
Cs
W
s
W
Cs
SL
M S
I
W
S
Q
S
A
mode switch acknowledgement


mode disablings4


Exclusive Areas
implicit exclusive areas

  

explicit exclusive areas
    
Rte_Enter API
    
Rte_Exit API
    
Implementation Method All InterruptBlocking
  

Implementation Method OS InterruptBlocking
    
Implementation Method OsResources
  

Implementation Method CooperativeRunnablePlacement    

BSW Module Support (SchM)
TimingEvent

    
Background Event
  

explicit exclusive areas
    
SchM_Enter API
    
SchM_Exit API
    
EA Implementation Method All InterruptBlocking
    
EA Implementation Method OS InterruptBlocking
    
Table 2-2   RTE features for ASIL and QM SWCs
2015, Vector Informatik GmbH
Version: 4.8
14 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
2.4
Operating conditions
The MICROSAR RTE is part of the MICROSAR Safe Architecture (Figure 2-1).

Figure 2-1  MICROSAR Safe Architecture
This  architecture  is  based  on  the  MICROSAR AUTOSAR  stack  developed  with  Vector’s
ISO9001 and SPICE based standard quality management.
The Add-On MICROSAR Safe Context extends this stack with an Operating System with
memory protection in order to use the MICROSAR BSW with application software with a
safety integrity level up to ASIL D.
ASIL Decomposition in the MICROSAR Safe Architecture is implemented through software
partitioning as described in ISO 26262 (Figure 2-2).

Figure 2-2  ASIL Decomposition
2015, Vector Informatik GmbH
Version: 4.8
15 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
This means MICROSAR Safe Context provides freedom from interference with regards to
memory  so  that  the  QM  parts  of  the  software  cannot  overwrite  memory  from  the  ASIL
application. An additional Safe Watchdog module provides freedom from interference with
regards to CPU runtime.
For  Safe  Communication  between  different  ECUs,  the  AUTOSAR  E2E  Library  can  be
used.

The  MICROSAR  RTE  extends  the  MICROSAR  Safe  Context  concept  to  the  software
component level. SWCs inherit the ASIL from the safety requirements that are allocated to
them. With the MICROSAR RTE, it is possible to use SWCs with different ASIL as well as
QM  SWCs  and  BSW  within  the  same  ECU.  The  MICROSAR  RTE  furthermore  provides
communication mechanisms that can be used to implement communication between ASIL
and QM SWCs.

A list of assumptions regarding the overall system architecture and development process
is given in the next chapter.

2.5
Assumptions
ID
Description of assumption on the scope of the MICROSAR RTE
ASS_RTE_1
The OS provides freedom from interference for different OS Applications
with regards to memory. This means that code in one OS Application
cannot destroy memory in another OS Application.
ASS_RTE_2
The AUTOSAR Memory Abstraction for the target platform and the OS
make it possible to assign RTE/BSW variables to specific OS Applications
so that they can only be written by code that is executed within this OS
Application.
Moreover in case of Multicore, the RTE variables are mapped to
noncacheable RAM so that they can be accessed by all cores.
ASS_RTE_3
The tool chain initializes global variables or the API Rte_InitMemory is
called before the OS is started. Rte_InitMemory initializes variables from
different OS Applications. Therefore it needs to be started without
memory protection.
ASS_RTE_4
The OS allows non protected reads to RTE/BSW variables within the
same and foreign OS Applications.
ASS_RTE_5
Freedom from interference with regards to CPU runtime is provided
through external means, for example with the help of a control flow
monitor. The mechanisms for it are either implemented in a way that the
RTE cannot deactivate them or a review is performed that checks that the
RTE does not impact their operation.
ASS_RTE_6
The OS APIs that are used by the RTE in ASIL parts of the code can be
called from different contexts without interference:
>  TerminateTask
>  SuspendOSInterrupts
2015, Vector Informatik GmbH
Version: 4.8
16 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
>  osDisableLevelUM (MICROSAR OS)
>  osDisableLevelKM (MICROSAR OS)
>  osDisableLevelAM (MICROSAR OS)
>  osDisableGlobalUM (MICROSAR OS)
>  osDisableGlobalKM (MICROSAR OS)
>  osDisableGlobalAM (MICROSAR OS)
>  ResumeOSInterrupts
>  osRteEnableLevelUM (MICROSAR OS)
>  osRteEnableLevelKM (MICROSAR OS)
>  osRteEnableLevelAM (MICROSAR OS)
>  osRteEnableGlobalUM (MICROSAR OS)
>  osRteEnableGlobalKM (MICROSAR OS)
>  osRteEnableGlobalAM (MICROSAR OS)
>  GetSpinlock (Multicore Systems)
>  ReleaseSpinlock (Multicore Systems)
ASS_RTE_7
The OS provides at least the APIs
>  SuspendOSInterrupts
>  osDisableLevelUM (MICROSAR OS)
>  osDisableLevelKM (MICROSAR OS)
>  osDisableLevelAM (MICROSAR OS)
>  osDisableGlobalUM (MICROSAR OS)
>  osDisableGlobalKM (MICROSAR OS)
>  osDisableGlobalAM (MICROSAR OS)
>  ResumeOSInterrupts
>  osRteEnableLevelUM (MICROSAR OS)
>  osRteEnableLevelKM (MICROSAR OS)
>  osRteEnableLevelAM (MICROSAR OS)
>  osRteEnableGlobalUM (MICROSAR OS)
>  osRteEnableGlobalKM (MICROSAR OS)
>  osRteEnableGlobalAM (MICROSAR OS)
with the same or higher ASIL than the SWCs
2015, Vector Informatik GmbH
Version: 4.8
17 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
In Multicore Systems, the OS also needs to provide the APIs
>  GetSpinlock
>  ReleaseSpinlock
with the same or higher ASIL than the SWCs
ASS_RTE_8
The RTE configuration is chosen in such a way that the
OS/System mechanisms for freedom from interference (memory and
runtime) can also be used to implement freedom from interference for
SWCs with different ASIL. This makes it necessary to map SWCs with
different ASIL to different OS Applications. All OS Applications with SWCs
that do not have the highest ASIL need to be nontrusted. This includes
the OS Application of the BSW. See also chapter 5.2.
ASS_RTE_9
The RTE configuration is chosen in such a way that no OS APIs need to
be called in the RTE APIs or the TASK bodies that violate the safety
requirements of the ASIL SWCs.
The RTE code calls the following OS APIs:
>  SetRelAlarm
>  CancelAlarm
>  SetEvent
>  GetEvent
>  ClearEvent
>  WaitEvent
>  GetTaskID
>  ActivateTask
>  TerminateTask
>  Schedule
>  ChainTask
>  GetResource
>  ReleaseResource
In case of multicore systems also the API
>  GetCoreID
is called.
ASS_RTE_10
The RTE configuration is chosen in such a way that no SWC needs to
directly call methods in (Service-) SWCs with lower ASIL and no (Service-
) SWCs with lower ASIL needs to call methods in ASIL SWCs except for
the case when the SWCs explicitly allow this kind of usage. If necessary,
this work is delegated to wrapper SWCs in the same OS Application as
the called/calling SWC. Direct calls can moreover be avoided when the
server runnables are mapped to tasks. See also chapter 5.2.
ASS_RTE_11
The RTE configuration is chosen in such a way that the RTE APIs or
2015, Vector Informatik GmbH
Version: 4.8
18 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
TASKS for a SWC do not contain calls to BSW modules with lower ASIL
than the SWC itself that might cause interference. If necessary, this work
is delegated to wrapper SWCs in the same OS Application as the BSW
modules. For external communication, the RTE proxies the calls to the
Com module. See also chapter 5.2.
ASS_RTE_12
The RTE does not need to provide freedom from interference for
communication. In an AUTOSAR system, the E2ELibrary that is directly
called by the SWCs is responsible for Safe communication. Nevertheless,
the RTE provides APIs that can be called by the E2ELibrary.
ASS_RTE_13
The Generated RTE code for ASIL SWCs is qualified according to the
requirements of ISO26262 by the integrator so that it reaches the same
ASIL as the SWCs themselves. This is necessary because the RTE
Generator was only developed with Vectors standard quality
management (QM).
ASS_RTE_14
The hardware is suited for safety relevant software according to the
requirements of ISO26262. The hardware requirements are mostly
determined by the SWCs that shall be supported by the RTE. The
MICROSAR RTE does not impose other hardware safety requirements
as those that are already required by the SWCs and the OS.
ASS_RTE_15
The development tool chain (for example editors, compilers, linkers,
make environment, flash utilities) is suited for the development of safety
relevant software according to the requirements of ISO26262. All tools
need to reach the appropriate Tool Qualification Level (TCL).
Table 2-3 Assumptions regarding the system architecture and environment
2015, Vector Informatik GmbH
Version: 4.8
19 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
3
Assumptions on the safety goals of the MICROSAR RTE
ID
ASIL  Description of hazards  Ref assumption
Ref H & R
that could occur
SG_RTE_1

SG_RTE_2

Table 3-1   Safety Goals
According to ISO26262, safety goals are determined for each hazardous event evaluated
in  the  hazard  analysis.  As  the  hazard  analysis  could  not  be  done  due  to  the  unknown
target  item,  the  safety  goals  have  to  be  identified  by  the  integrator  once  the  hazard
analysis is done.

ID
Description of safe state
Ref safety goal
SS_RTE_1

SS_RTE_2

Table 3-2   Safe States
Due  to  the  missing  safety  goals,  no  safe  states  could  be  identified  that  can  be  used  to
achieve  a  safety  goal.  The  safe  states  have  to  be  identified  by  the  integrator  once  the
safety goals are known.
2015, Vector Informatik GmbH
Version: 4.8
20 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
4
Safety concept of the MICROSAR RTE
4.1
Functional concept
The MICROSAR RTE was developed with the following assumptions regarding the safety
requirements. No references to safety goals and target ASIL are listed for the requirements
as these depend on the particular context into which the RTE is integrated.

ID
Description of safety requirement
ASIL
Ref SG, ASS
SR_RTE_1  The RTE (with the help of a MPU and an appropriate

OS) shall provide freedom from interference with
regards to memory for ASIL SWCs. This means that
the RTE shall protect ASIL SWCs from BSW with
lower ASIL. Additionally, the RTE shall also protect
ASIL SWCs also from other SWCs with lower ASIL.
The protection shall include the inter-runnable
variables, per instance memories, sender buffers and
stacks of the SWCs. Moreover, the protection shall be
transparent to the SWCs, e.g. it shall be possible to
access the protected inter-runnable variables and
per-instance memories with the default AUTOSAR
RTE APIs Rte_IrvWrite, Rte_IrvRead and Rte_Pim.
SR_RTE_2  The RTE shall provide intra-ECU communication

mechanism for SWCs with the same and different
ASIL. The communication shall be possible through
the AUTOSAR RTE APIs Rte_Read and Rte_Write
that are used for non-queued sender/receiver
communication.
SR_RTE_3  The RTE shall provide mechanisms for data

consistency that can be used by the ASIL SWCs to
prevent concurrent accesses to shared ressources.
(explicit exclusive areas). The realization of the
exclusive areas shall be possible through the
AUTOSAR RTE APIs Rte_Enter and Rte_Exit.
SR_RTE_4  The RTE shall provide access to calibration

parameters for the ASIL SWCs. It shall be possible to
access the calibration parameters with the default
AUTOSAR RTE APIs Rte_Prm and Rte_CData.
Table 4-1   Safety Requirements
2015, Vector Informatik GmbH
Version: 4.8
21 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
4.2
Safe state and degradation concept
The MICROSAR RTE does not support degradation to the safe state as the safe state
depends on the functionality of the item. Safe state degradation therefore also has to be
implemented by the application or by the OS. Memory protection faults are supposed to be
handled by the OS.
4.3
Fault tolerance and diagnostics concept
The fault tolerance and diagnostics concept depends on the requirements of the
Application SWCs. It has to be implemented within the application SWCs.
2015, Vector Informatik GmbH
Version: 4.8
22 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
5
Integration of the MICROSAR RTE in a new particular context
5.1
Assumptions
ID
ASIL  Description of assumptions, safety goals, safety
Validity check
requirements
ASS_RTE_1

The OS provides freedom from interference for

different OS Applications with regards to memory.
This means that code in one OS Application cannot
destroy memory in another OS Application.
ASS_RTE_2

The AUTOSAR Memory Abstraction for the target

platform and the OS make it possible to assign
RTE/BSW variables to specific OS Applications so
that they can only be written by code that is executed
within this OS Application.
Moreover in case of Multicore, the RTE variables are
mapped to noncacheable RAM so that they can be
accessed by all cores.
ASS_RTE_3

The tool chain initializes global variables or the API

Rte_InitMemory is called before the OS is started.
Rte_InitMemory initializes variables from different OS
Applications. Therefore it needs to be started without
memory protection.
ASS_RTE_4

The OS allows non protected reads to RTE/BSW

variables within the same and foreign OS
Applications.
ASS_RTE_5

Freedom from interference with regards to CPU

runtime is provided through external means, for
example with the help of a control flow monitor. The
mechanisms for it are either implemented in a way
that the RTE cannot deactivate them or a review is
performed that checks that the RTE does not impact
their operation.
ASS_RTE_6

The OS APIs that are used by the RTE in ASIL parts

of the code can be called from different contexts
without interference:
>  TerminateTask
>  SuspendOSInterrupts
>  osDisableLevelUM (MICROSAR OS)
>  osDisableLevelKM (MICROSAR OS)
>  osDisableLevelAM (MICROSAR OS)
>  osDisableGlobalUM (MICROSAR OS)
>  osDisableGlobalKM (MICROSAR OS)
>  osDisableGlobalAM (MICROSAR OS)
2015, Vector Informatik GmbH
Version: 4.8
23 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
>  ResumeOSInterrupts
>  osRteEnableLevelUM (MICROSAR OS)
>  osRteEnableLevelKM (MICROSAR OS)
>  osRteEnableLevelAM (MICROSAR OS)
>  osRteEnableGlobalUM (MICROSAR OS)
>  osRteEnableGlobalKM (MICROSAR OS)
>  osRteEnableGlobalAM (MICROSAR OS)
>  GetSpinlock (Multicore Systems)
>  ReleaseSpinlock (Multicore Systems)
ASS_RTE_7

The OS provides at least the APIs

>  SuspendOSInterrupts
>  osDisableLevelUM (MICROSAR OS)
>  osDisableLevelKM (MICROSAR OS)
>  osDisableLevelAM (MICROSAR OS)
>  osDisableGlobalUM (MICROSAR OS)
>  osDisableGlobalKM (MICROSAR OS)
>  osDisableGlobalAM (MICROSAR OS)
>  ResumeOSInterrupts
>  osRteEnableLevelUM (MICROSAR OS)
>  osRteEnableLevelKM (MICROSAR OS)
>  osRteEnableLevelAM (MICROSAR OS)
>  osRteEnableGlobalUM (MICROSAR OS)
>  osRteEnableGlobalKM (MICROSAR OS)
>  osRteEnableGlobalAM (MICROSAR OS)
with the same or higher ASIL than the SWCs
In Multicore Systems, the OS also needs to provide
the APIs
>  GetSpinlock
>  ReleaseSpinlock
with the same or higher ASIL than the SWCs
ASS_RTE_8

The RTE configuration is chosen in such a way that

the
OS/System mechanisms for freedom from
interference (memory and runtime) can also be used
2015, Vector Informatik GmbH
Version: 4.8
24 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
to implement freedom from interference for SWCs
with different ASIL. This makes it necessary to map
SWCs with different ASIL to different OS Applications.
All OS Applications with SWCs that do not have the
highest ASIL need to be nontrusted. This includes the
OS Application of the BSW. See also chapter 5.2.
ASS_RTE_9

The RTE configuration is chosen in such a way that

no OS APIs need to be called in the RTE APIs or the
TASK bodies that violate the safety requirements of
the ASIL SWCs.
The RTE codes calls the following APIs:
>  SetRelAlarm
>  CancelAlarm
>  SetEvent
>  GetEvent
>  ClearEvent
>  WaitEvent
>  GetTaskID
>  ActivateTask
>  TerminateTask
>  Schedule
>  ChainTask
>  GetResource
>  ReleaseResource
In case of multicore systems also the API
>  GetCoreID
is called.
ASS_RTE_10
The RTE configuration is chosen in such a way that

no SWC needs to directly call methods in (Service-)
SWCs with lower ASIL and no (Service-) SWCs with
lower ASIL needs to call methods in ASIL SWCs
except for the case when the SWCs explicitly allow
this kind of usage. If necessary, this work is delegated
to wrapper SWCs in the same OS Application as the
called/calling SWC. Direct calls can moreover be
avoided when the server runnables are mapped to
tasks. See also chapter 5.2.
ASS_RTE_11
The RTE configuration is chosen in such a way that

the RTE APIs or TASKS for a SWC do not contain
calls to BSW modules with lower ASIL than the SWC
itself that might cause interference. If necessary, this
work is delegated to wrapper SWCs in the same OS
2015, Vector Informatik GmbH
Version: 4.8
25 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
Application as the BSW modules. For external
communication, the RTE proxies the calls to the Com
module.  See also chapter 5.2.
ASS_RTE_12
The RTE does not need to provide freedom from

interference for communication. In an AUTOSAR
system, the E2ELibrary that is directly called by the
SWCs is responsible for Safe communication.
Nevertheless, the RTE provides APIs that can be
called by the E2ELibrary.
ASS_RTE_13
The Generated RTE code for ASIL SWCs is qualified
according to the requirements of ISO26262 by the
integrator so that it reaches the same ASIL as the
SWCs themselves. This is necessary because the
RTE Generator was only developed with Vectors
standard quality management (QM).
ASS_RTE_14
The hardware is suited for safety relevant software

according to the requirements of ISO26262. The
hardware requirements are mostly determined by the
SWCs that shall be supported by the RTE. The
MICROSAR RTE does not impose other hardware
safety requirements as those that are already
required by the SWCs and the OS.
ASS_RTE_15
The development tool chain (for example editors,

compilers, linkers, make environment, flash utilities) is
suited for the development of safety relevant software
according to the requirements of ISO26262. All tools
need to reach the appropriate Tool Qualification Level
(TCL).
SR_RTE_1

The RTE (with the help of a MPU and an appropriate
OS) shall provide freedom from interference with
regards to memory for ASIL SWCs. This means that
the RTE shall protect ASIL SWCs from BSW with
lower ASIL. Additionally, the RTE shall also protect
ASIL SWCs also from other SWCs with lower ASIL.
The protection shall include the inter-runnable
variables, per instance memories, sender buffers and
stacks of the SWCs. Moreover, the protection shall be
transparent to the SWCs, e.g. it shall be possible to
access the protected inter-runnable variables and
per-instance memories with the default AUTOSAR
RTE APIs Rte_IrvWrite, Rte_IrvRead and Rte_Pim.
SR_RTE_2

The RTE shall provide intra-ECU communication

mechanism for SWCs with the same and different
ASIL. The communication shall be possible through
the AUTOSAR RTE APIs Rte_Read and Rte_Write
that are used for non-queued sender/receiver
communication.
SR_RTE_3

The RTE shall provide mechanisms for data

consistency that can be used by the ASIL SWCs to
prevent concurrent accesses to shared ressources.
(explicit exclusive areas). The realization of the
2015, Vector Informatik GmbH
Version: 4.8
26 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
exclusive areas shall be possible through the
AUTOSAR RTE APIs Rte_Enter and Rte_Exit
SR_RTE_4

The  RTE  shall  provide  access  to  calibration
parameters for the ASIL SWCs. It shall be possible to
access  the  calibration  parameters  with  the  default
AUTOSAR RTE APIs Rte_Prm and Rte_CData.
Table 5-1   Assumptions that need to be verified during the integration

The  MICROSAR  RTE  Generator  does  not  produce  ASIL  code.  However,  the  following
chapter tries to explain how an RTE configuration needs to look like so that it is both, in
line with the assumptions given in the previous table, and that it can be reviewed to reach
compliance with a certain ASIL level.
5.2
RTE Configuration
During the software design, it has to be decided if the SWCs need to be developed with a
certain ASIL. In the MICROSAR RTE, OS Applications are used to partition the SWCs of
an  ECU  according  to  their  ASIL.  Therefore,  for  every  used  ASIL,  at  least  one  OS
Application has to be created. Furthermore an  OS Application for the QM BSW needs to
be created. It can also be used for the QM SWCs. All OS Applications apart from the OS
Applications with the highest ASIL need to be nontrusted. An example  is given  in  Figure
5-1.
OsApplication1 (QM)
OsApplication2
OsApplication3
OsApplication4
(ASIL D)
(ASIL A)
(ASIL D)
Software
Software
Software
Software
Software
Component
Component
Component
Component
Component
MICROSAR RTE
OsApplication1
(QM)
BSW

Figure 5-1  SWC to OsApplication Mapping
The assignment of the SWCs to the OS Applications happens through the task mapping.
2015, Vector Informatik GmbH
Version: 4.8
27 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
That means the RTE tasks need to be assigned to the OS Applications. Every SWC then
needs to be mapped to the appropriate OS Application by mapping its runnables to tasks
of that OS Application.
As the BSW OS Application is nontrusted, the following memory protection limitations from
the RTE Technical Reference apply for all SWCs:
>  All schedulable entities of QM BSW Modules need to be assigned to the BSW OS
Application
>  All SWCs with mode provide ports need to be assigned to the BSW OS Application.
>  All SWCs that contain runnables with mode disabling dependencies or mode triggers
need to be assigned to the BSW OS Application.
>  Direct client/server calls between OS Applications are not allowed. Exceptions are
possible when the servers explicitly allow that they are run within the contexts of the
client OS Applications. The RTE generator issues a warning when it detects direct
client/server calls between OS Applications.

Caution
When a client directly calls a server in another OS Application, the server runnable will
  run within the OS Application of the client. This means it can access resources e.g.
memory that are normally only supposed to be accessed by runnables in the client OS
Application. Moreover the server is not able to access resources that can only be
accessed by his own OS Application.
This might violate the safety requirements of the SWCs.

It  is  assumed  that  the  MICROSAR  RTE  is  used  together  with  MICROSAR  OS  Safe
Context.  While  most APIs  of  MICROSAR  OS  Safe  Context  can  be  called  from  arbitrary
contexts  without  causing  interference,  only  certain APIs  are  implemented  in  a  way  that
ASIL code can rely on them. Therefore, the following RTE features that rely on ASIL OS
functionality cannot be used in ASIL SWCs:
>  Extended Tasks
>  Minimum Start Interval
>  Exclusive Areas with implementation methods other than Interrupt Blocking
>  Alive timeout
>  Triggering of runnables in other SWCs e.g. by OnDataReception,
OnDataReceptionError, OnDataSendCompletion triggers of a sender/receiver port

The following general RTE feature cannot be used when ASIL SWCs are present because
it requires calls to non ASIL BSW modules:
>  Measurement with XcpEvents

2015, Vector Informatik GmbH
Version: 4.8
28 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
To simplify the review, it is also recommended to only use a subset of the RTE features in
the ASIL SWCs. The review chapter in this document only describe the RTE APIs for the
case when the following features are not used:
>  VFB Trace Hooks
>  Invalidation
>  Rx Filters
>  Implicit Exclusive Areas
>  Implicit Inter-Runnable Variables
>  Multiple Instantiation
>  Object Code SWCs
>  Unconnected ports
>  Implicit sender/receiver communication
>  Online calibration
>  Transmission acknowledgement
>  Never Received API
>  Enhanced Rte_Mode API
>  Development Error Tracer (DET)
>  Data Prototype Mappings

Summarized, ASIL SWCs may use the following RTE features without violating the RTE
safety assumptions and with the goal in mind to have easy to review code:
>  Runnables with cyclic triggers
>  Runnables with OperationInvokedTriggers
>  Basic tasks. (This means all runnables on an ASIL task need to share the same cycle
time and offset.)
>  Explicit Intra-ECU Sender/Receiver communication (Last-Is-Best)
>  Explicit Inter-ECU Sender/Receiver communication (Last-Is-Best)
>  Rte_IsUpdated API
>  Synchronous Client/Server calls to unmapped runnables or runnables with
CanBeInvokedConcurrently set to true. The client and server need to be mapped to the
same OS Application. Exceptions are possible when the servers explicitly allow such
usage.
>  Explicit Inter-Runnable variables
>  Mode require ports without mode triggers and mode disabling dependencies
2015, Vector Informatik GmbH
Version: 4.8
29 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
>  Explicit exclusive areas
>  Per-instance memories
>  SWC local Calibration parameters
>  Calibration ports

Please note that the names of the objects in the RTE configuration are used in identifiers
in the generated RTE and OS C code. The names have to be chosen in such a way that
the identifiers do not exceed the limits of the target compiler and that they do not conflict
with other identifiers from other modules.
Also  the  filenames  of  the  generated  files  are  created  from  object  names  in  the  RTE
configuration. It also needs to be checked that the file names do not exceed the limits of
the target compiler.
5.3
RTE Generation
Once the RTE is configured it can be generated with the MICROSAR RTE Generator.
The MICROSAR RTE Generator will run some checks prior to the generation.
Errors in the Configuration are reported with an [Error] prefix. The generator will abort the
generation  in  this  case.  Warnings  are  reported  with  [Warning].  Every  warning  has  to  be
checked and it needs to be assured that the warnings do not cause any harm.
Moreover after the generation, it has to be checked that the output directory contains no
old  files  from  previous  generations.  The  RTE  Generator  provides  a  magic  number  pre-
processor check at the end of the files that will issue a compile error when it detects an old
file.  Please  note  that  selective  file  generation  needs  to  be  disabled  in  order  to  use  the
magic number check.
2015, Vector Informatik GmbH
Version: 4.8
30 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
6
Qualification of generated RTE Code
The following section gives some hints on what needs to be verified when the RTE shall
be used for ASIL SWCs. The API descriptions show how the RTE code is supposed to look
like according to the generator design when the configuration is based on the description
in chapter 5.2. If the generated code diverges from the code descriptions, the integrator
has to verify that the differences do not cause any harm.

Caution
The MICROSAR RTE generator does not generate ASIL code. If the RTE code shall be
used for ASIL SWCs, the generated code has to be qualified. ISO26262 lists various
methods that can or have to be applied to reach a certain ASIL. The integrator has to
decide which methods are suited for his project and take the required actions.

6.1
Introduction
As the generated RTE code heavily depends on the names of the objects from the RTE
configuration, the API descriptions use the following placeholders:

<oa> OS Application
<soa> sender OS Application
<roa> receiver OS Application
<bswoa> BSW OS Application

<c> component type name
<bsw> BSW module name
<sc> sender component type name
<rc> receiver component type name

<ci> component instance name
<sci> sender component instance name
<rci> sender component instance name

 port prototype
<sp> sender port prototype
<rp> receiver port prototype

<d> data element prototype
<sd> sender data element prototype
2015, Vector Informatik GmbH
Version: 4.8
31 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
<rd> sender data element prototype

<o> operation prototype
<re> runnable entity name
<res> runnable/schedulable entity symbol
<sre> server runnable entity name
<sres> server runnable entity symbol
<signalid> identifier for signal specific buffers
<nocache> _NOCACHE extension for variables that are accessed from multiple cores

<t> data type
<tp> pointer to data type

<name> per-instance memory, calibration parameter, exclusive area or inter-runnable
variable name
<Lock> Interrupt Locking / Spinlock function as described in chapter 6.3.4
<UnLock> Interrupt Unlocking / Spinlock function as described in chapter 6.3.4
<Rte_MemCpy> Memory Copy function as described in chapter 6.9.1

Placeholders written in upper case, for example , mean that the replacement string is
written in upper case.
6.2
Compiler and Memory Abstraction
The RTE code uses the AUTOSAR compiler and memory abstraction for functions,
function prototypes and variable declarations.
#define RTE_START_SEC_<secname>
#include "MemMap.h"

<Object0>
[<Object1>]
[<ObjectN>]

#define RTE_STOP_SEC_<secname>
#include "MemMap.h"
The memory abstraction is used to assign RTE variables to OS Applications. <secname>
is the used memory section, for example CODE, VAR, CONST.
All variables are assigned to the OS Application in which they are written.
Section defines contain the name of the OS Application with the exception of the section
defines for the OS Application that contains the BSW. It directly uses the section defines of
the RTE.
2015, Vector Informatik GmbH
Version: 4.8
32 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
In  case  of  multicore  systems,  the  memory  abstraction  defines  use  an  additional
_NOCACHE  extension  when  variables  are  accessed  from  multiple  cores.  It  has  to  be
assured that variables with this extension are mapped to noncacheable RAM and that  all
variables that are accessed from multiple cores are mapped with this extension.
The RTE includes the file MemMap.h that has to issue the  correct compiler pragmas for
the  platform  so  that  variables  within  the  memory  abstraction  are  mapped  to  the  correct
protected  memory  sections.  See  the Technical  Reference  of  the  OS  of  how  this  can  be
accomplished.  During  integration  it  has  to  be  assured  that  the  mapping  mechanisms
function properly. The RTE section and compiler abstraction defines are described in the
RTE Technical Reference.
Besides  these,  the  MICROSAR  RTE  uses  the  following  macros  from  the  compiler
abstraction:
  FUNC
  AUTOMATIC
  STATIC
  NULL_PTR
  FUNC_P2CONST
  P2VAR
  P2CONST
  CONST
  CONSTP2CONST
  P2FUNC
  VAR
Their functionality needs to be verified for correctness on the target platform.
6.3
DataTypes
6.3.1  Imported Types
The  MICROSAR  RTE  imports  the  following  types  from  Std_Types.h  and  the
Platform_Types.h header that is included by Std_Types.h. It needs to be assured that they
are mapped to the correct platform specific types:
  boolean
  uint8
  uint16
  uint32
  uint64
  sint8
  sint16
  sint32
  sint64
  float32
2015, Vector Informatik GmbH
Version: 4.8
33 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
 float64
 uint8_least
 uint16_least
 uint32_least
 sint8_least
 sint16_least
 sint32_least
 Std_ReturnType
Furthermore the following imported defines need to be correct:
 STD_ON
 STD_OFF
6.3.2 Application Types Generated by the RTE
The RTE Generator generates the data types from the configuration to the header
Rte_Type.h. It has to be checked that Rte_Type.h contains all configured data types and
that the datatypes are in line with the configuration. The RTE generator only generates
implementation data types.
Besides the name of the generated data type, also its properties have to be checked. For
primitive types, this means that the upper and lower limit defines are identical to the ones
that are specified in the configuration and that the base type that is used for the data type
covers its full range. Upper and lower Limits are only generated to the file Rte_<c>_Type.h
when a components uses the application data type that defines the limits.
For complex array types, it has to be checked that the base type is the same as the one
that is configured in the configuration. Furthermore, the length of the array needs to be
identical to the one from the configuration for array types.
For complex record types, the types, names and order of the contained elements needs to
be the same as specified in the configuration.
For enumerations, all generated enumeration literals also need to be defined to the values
that are specified in the configuration. It has to be checked that the list of literals is
complete and that no literal conflicts with other identifiers. The literals are generated to
Rte_<c>_Type.h when a component uses a datatype that references a compu method with
a texttable.

6.3.3
Handling of Array and String Data Types
In the RTE APIs, arrays are passed as pointer to the array base type.
For simplicity, the code descriptions in the following chapters only show examples with
primitive integer types.

6.3.4
Datatype specific handling of Interrupt Locks and Spinlocks
The RTE implements data consistency mechanisms in some of its APIs. Data consistency
is provided with the SuspendOSInterrupts and ResumeOSInterrupts OS APIs on a single
2015, Vector Informatik GmbH
Version: 4.8
34 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
core. As the calls to these OS APIs significantly increase the runtime of the RTE APIs, the
RTE tries to optimize them away when they are not needed.
The APIs are optimized away when the variables can be written atomically by the ECU.
The  behaviour  is  controlled  by  the  setting  of  the  parameter AtomicVariableAccess  in  the
configuration of the EcuC module in the ECUC configuration file.

For simplicity, the code descriptions in the following chapters only show APIs in which the
interrupt locks are not optimized away. When the RTE code for the ASIL SWCs is verified,
it  needs  to  be  checked  that  the optimization  is  correct,  e.g.  that  a  variable  can  really  be
accessed atomically by the ECU.

Some versions of MICROSAR OS provide optimized interrupt locking APIs. The RTE will
use these APIs when they are available.
For nontrusted OS Applications the RTE may call
>  osDisableLevelUM
>  osDisableLevelAM
>  osDisableGlobalUM
>  osDisableGlobalAM
to disable the interrupts and
>  osEnableLevelUM
>  osEnableLevelAM
>  osEnableGlobalUM
>  osEnableGlobalAM
to reenable the interrupts.

For trusted OS Applications the RTE may call
>  osDisableLevelKM
>  osDisableLevelAM
>  osDisableGlobalKM
>  osDisableGlobalAM
to disable the interrupts and
>  osEnableLevelKM
>  osEnableLevelAM
>  osEnableGlobalKM
>  osEnableGlobalAM
2015, Vector Informatik GmbH
Version: 4.8
35 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
to reenable the interrupts.

The optimized APIs are mapped to the macros
Rte_DisableOSInterrupts/Rte_DisableAllInterrupts and
Rte_EnableOSInterrupts/Rte_EnableAllInterrupts.

In the following code examples, <Lock> resolves to SuspendOSInterrupts, or
Rte_DisableOSInterrupts/Rte_DisableAllInterrupts.
<UnLock>
resolves
to
ResumeOSInterrupts or Rte_EnableOSInterrupts/Rte_EnableAllInterrupts. The RTE
generator tries to use the “Disable” variant whenever possible as it is usually faster. It has
to be assured that this variant is only used, when there are no nested calls to the locking
APIs. They cannot be used when the runnable is configured to enter or to run in an
exclusive area. For every locking operation the matching unlocking operation needs to be
called.
It needs to be assured that no included header breaks these operation (e.g. by redefining
them).

On multicore systems, locking the interrupts will only provide data consistency on the core
for which the RTE API is called. In order to provide data consistency also when variables
are accessed from different cores, the <Lock> and <UnLock> operations are extended
with additional GetSpinlock and ReleaseSpinlock calls.

Example:
SuspendOSInterrupts();
(void)GetSpinlock(<SpinlockId>);

Access data structures.

(void)ReleaseSpinlock(<SpinlockId>);
ResumeOSInterrupts();

All places where the protected data structures are accessed need to be protected by the
same Spinlock (same <SpinlockId>)
The interrupt lock APIs can be omitted when the spinlock cannot be accessed by multiple
tasks on the same core.
Instead
of
SuspendOSInterrupts
and
ResumeOSInterrupts
also
Rte_DisableOSInterrupts/Rte_DisableAllInterrupts
and
Rte_EnableOSInterrupts/Rte_EnableAllInterrupts can be used, the distinction is the same
as explained above.

2015, Vector Informatik GmbH
Version: 4.8
36 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE

6.4
SWC Implementation
The RTE is the module that glues the SWCs to the AUTOSAR stack. For this, the RTE
generator generates a list of files that provide the datatypes and APIs for the SWCs and
that call the runnable entities of the SWCs. A description of all generated files can be found
in the RTE Technical Reference.
From the generated files, the SWCs shall only include the appropriate RTE header
Rte_<c>.h directly. It provides the SWC specific functionality.
The SWC implementation shall at least contain all configured runnable entities.
The signature of the runnable entities is
FUNC(void, <c>_CODE) <res>(<parglist><arglist>)
or
FUNC(Std_ReturnType, <c>_CODE) <res>(<parglist><arglist>)

for server runnables with return type.
<arglist> is “void” for non-server runnables, otherwise it contains the arguments of the
server operation.
<parglist> is empty for runnables without port defined arguments, otherwise it contains the
port defined arguments.
# define <c>_START_SEC_CODE
# include "MemMap.h"

FUNC(void, <c>_CODE) <res>(<parglist><arglist>)
{

}

# define <c>_STOP_SEC_CODE
# include "MemMap.h"

Runnable entity implementations shall be surrounded by <c>_CODE memory abstraction
defines as shown above.
Every runnable entity shall have a prototype in Rte_<c>.h that is also surrounded by the
same memory abstraction defines.
Server runnables with return value shall return a value in all return paths.
The value shall be RTE_E_OK or one of the application return codes from the
configuration. The application return code defines are contained in the file Rte_<c>.h. It
needs to be checked that the return defines provide the same value as described in the
configuration.
2015, Vector Informatik GmbH
Version: 4.8
37 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE

Runnable entities in ASIL SWC should only contain calls to the following RTE APIs:
> Std_ReturnType Rte_Write__<d>(<data>)
> Std_ReturnType Rte_Read__<d>(<data>)
> boolean Rte_IsUpdated__<d>()
> Std_ReturnType Rte_Call__<o>(<data_1>, <data_n>)
> <type> Rte_Pim_<name>()
> <return> Rte_CData_<name>()
> <return> Rte_Prm__<name>()
> <return> Rte_IrvRead_<re>_<name>()
> void Rte_IrvWrite_<re>_<name>(<data>)
> void Rte_Enter_<name>()
> void Rte_Exit_<name>()
> Rte_ModeType_<m> Rte_Mode__<d>()

The Rte_Write, Rte_Read, Rte_IsUpdated, Rte_Call, Rte_IrvRead, Rte_IrvWrite,
Rte_Enter, Rte_Exit APIs are only allowed to be called from a runnable when the runnable
is configured to access the port data element/port operation/inter-runnable
variable/exclusive area for which the API is generated.
The Rte_CData and Rte_Pim APIs are only allowed to be called from runnables in the
SWCs in which they are configured.
The Rte_Prm API is only allowed to be called from runnables in the SWC that contains the
matching calibration receiver port.
For every API that is called by the SWC implementation, it needs to be checked, that the
called API is configured for the SWC and that Rte_<c>.h declares the API.
Furthermore, it needs to be assured that RTE and OS variables are only modified with
afore mentioned RTE API calls. The variables are not allowed to be modified directly within
the runnable code.
It also has to be assured that the RTE APIs with parameters are called with the correct
parameters with regards to type and access rights. When pointers are passed to the RTE
APIs, it has to be assured that the pointers stay valid during the whole runtime of the RTE
API and that the underlying objects are not modified outside the RTE API during the
runtime of the RTE API.

All RTE APIs for a SWC are declared in the header Rte_<c>.h. APIs are implemented
either as macro or as function. When the APIs are implemented as functions, the
2015, Vector Informatik GmbH
Version: 4.8
38 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
implementation is contained in the file Rte_<oa>.c of the OS Application to which the SWC
is mapped.
It needs to be assured that all functions that are called from within RTE code are imported
from the correct versions of the AUTOSAR, Com and OS source and header files.
The inclusion of files from these and other modules shall not re-define any identifier that is
defined in the generated RTE code, e.g. through #define macros. Exceptions are the RTE
memory section defines that can be redeclared in MemMap. However, it needs to be
checked that the mapping of the variables to the code sections works as expected.

6.5
BSW Implementation

The RTE is the module that glues the BSW to the AUTOSAR stack. For this, the RTE
generator generates a list of files that provide the datatypes and APIs for the BSW and that
call the schedulable entities of the BSW. A description of all generated files can be found in
the RTE Technical Reference.
From the generated files, the BSW shall only include the appropriate RTE header
SchM_<bsw>.h directly. It provides the BSW specific functionality.
The BSW implementation shall at least contain all configured schedulable entities.
The signature of the schedulable entities is
FUNC(void, <BSW>_CODE ) <res>()

Schedulable entity implementations shall be surrounded by <BSW>_CODE memory
abstraction defines.
Every schedulable entity shall have a prototype in SchM_<bsw>.h that is also surrounded
by the same memory abstraction defines.

Schedulable entities in ASIL BSW should only contain calls to the following RTE APIs:
> void SchM_Enter_<bsw>_<name>()
> void SchM_Exit_<bsw>_<name>()

All RTE APIs for a BSW module are declared in the header SchM_<bsw>.h. APIs are
implemented either as macro or as function. When the APIs are implemented as functions,
the implementation is contained in the file Rte_<oa>.c of the OS Application to which the
BSW is mapped.
It needs to be assured that all functions that are called from within RTE code are imported
from the correct versions of the AUTOSAR, Com and OS source and header files.
2015, Vector Informatik GmbH
Version: 4.8
39 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
The inclusion of files from these and other modules shall not re-define any identifier that is
defined in the generated RTE code, e.g. through #define macros. Exceptions are the RTE
memory section defines that can be redeclared in MemMap. However, it needs to be
checked that the mapping of the variables to the code sections works as expected.

6.6
SWC specific RTE APIs
6.6.1 Rte_Write
6.6.1.1 Configuration Variant Intra-ECU Without IsUpdated
> source code SWC
> no support for multiple instantiation
> no indirect API
> intra-ECU communication
> receiver is connected
> no receiver triggered on data reception
> no receiver triggered on data reception error
> no transmission acknowledgement
> no rx filtering
> no data prototype mapping
> no invalidation
> is updated is not configured for the receivers
> never received is not configured for the receiver
6.6.1.2 Generated Code Intra-ECU Without IsUpdated
Rte_<c>.h defines Rte_Write as follows:
#define Rte_Write__<d> Rte_Write_<c>__<d>

When the attribute “EnableTakeAddress” is not set for the port and when the data element
can be accessed atomically by the ECU and when the data element is not an array or
string type, Rte_Write_<c>__<d> is declared as macro that writes to a global RTE
variable.

# define RTE_START_SEC_VAR_<oa><nocache>_INIT_UNSPECIFIED
# include "MemMap.h"
2015, Vector Informatik GmbH
Version: 4.8
40 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE

extern VAR(<t>, RTE_VAR_INIT<nocache>) Rte_<ci>__<d>;

# define RTE_STOP_SEC_VAR_<oa><nocache>_INIT_UNSPECIFIED
# include "MemMap.h"

# define Rte_Write_<c>__<d>(data) (Rte_<ci>__<d> = (data),
((Std_ReturnType)RTE_E_OK))

Otherwise, the API is implemented in Rte_<oa>.c
#define RTE_START_SEC_CODE
#include "MemMap.h"

FUNC(Std_ReturnType, RTE_CODE) Rte_Write_<c>__<d>(<t> data)
{
Std_ReturnType ret = RTE_E_OK;

 Rte_WriteHook_<c>__<d>_Start(data);
 <Lock>();
 Rte_<ci>__<d> = *(&data);
<UnLock>();
Rte_WriteHook_<c>__<d>_Return(data);
 return ret;
}

#define RTE_STOP_SEC_CODE
#include "MemMap.h"

and Rte_<c>.h only contains the prototype:
# define RTE_START_SEC_CODE
# include "MemMap.h"

FUNC(Std_ReturnType, RTE_CODE) Rte_Write_<c>__<d>(<t> data);

# define RTE_STOP_SEC_CODE
# include "MemMap.h"

In both cases the global variable in Rte_<oa>.c is declared as
#define RTE_START_SEC_VAR_<oa><nocache>_INIT_UNSPECIFIED
#include "MemMap.h"
VAR(<dt>, RTE_VAR_INIT<nocache>) Rte_<ci>__<d> = <initializer>;
#define RTE_STOP_SEC_VAR_<oa><nocache>_INIT_UNSPECIFIED
#include "MemMap.h"
2015, Vector Informatik GmbH
Version: 4.8
41 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE

where <initializer> is the C representation of the init value that is configured for the port
data element.

For systems where the compiler does not initialize global variables, the API
Rte_InitMemory needs to do the initialization:
Rte_<ci>__<d> = <initializer>;

If the data element is of a string or array type, no direct assignments are used. Instead, the
assignment is replaced by a memcpy

<Rte_MemCpy>(Rte_<ci>__<d>, *(data), sizeof(<t>));

If the datatype can be read and written atomically, the <Lock>() and <UnLock>() calls are
omitted from the Rte_Write API.

When Rte_Write is not a macro, it needs to be assured that the macros
Rte_WriteHook_<c>__<d>_Start(data) and
Rte_WriteHook_<c>__<d>_Return(data) do not have any side effects.

6.6.1.3 Configuration Variant Intra-ECU With IsUpdated
> source code SWC
> no support for multiple instantiation
> no indirect API
> intra-ECU communication
> receiver is connected
> no receiver triggered on data reception
> no receiver triggered on data reception error
> no transmission acknowledgement
> no rx filtering
> no data prototype mapping
> no invalidation
> is updated is configured for one receiver
> never received is not configured for the receiver
2015, Vector Informatik GmbH
Version: 4.8
42 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE

6.6.1.4
Generated Code Intra-ECU With IsUpdated
Rte_Write with configured IsUpdated is similar to the variant without IsUpdated. However,
in the IsUpdated case, Rte_Write is always implemented as function in Rte_<oa>.c.

/******************************************************************************
* Update Flags for each Receiver with enableUpdate != 0
*****************************************************************************/
# define RTE_START_SEC_VAR_<oa><nocache>_ZERO_INIT_UNSPECIFIED
# include "MemMap.h"

VAR(Rte_<oa>_RxUpdateFlagsType, RTE_VAR_ZERO_INIT<nocache>)
Rte_<oa>_RxUpdateFlags = {
 0
};

# define RTE_STOP_SEC_VAR_<oa><nocache>_ZERO_INIT_UNSPECIFIED
# include "MemMap.h"

# define Rte_<oa>_RxUpdateFlagsInit() (Rte_MemClr(&Rte_<oa>_RxUpdateFlags,
sizeof(Rte_<oa>_RxUpdateFlagsType)))

#define RTE_START_SEC_CODE
#include "MemMap.h"

FUNC(Std_ReturnType, RTE_CODE) Rte_Write_<c>__<d>(<t> data)
{
 Std_ReturnType ret = RTE_E_OK;

 Rte_WriteHook_<c>__<d>_Start(data);
 <Lock>();
Rte_<ci>__<d> = *(&data);
 Rte_<oa>_RxUpdateFlags.Rte_RxUpdate_<rci>_<rp>_<rd>_Sender =
!Rte_<roa>_RxUpdateFlags.Rte_RxUpdate_<rci>_<rp>_<rd>;
 <UnLock>();
 Rte_WriteHook_<c>__<d>_Return(data);
 return ret;
}

#define RTE_STOP_SEC_CODE
#include "MemMap.h"

2015, Vector Informatik GmbH
Version: 4.8
43 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
Rte_<roa>.c declares the variable Rte_<roa>_RxUpdateFlags as follows:

# define RTE_START_SEC_VAR_<roa><nocache>_ZERO_INIT_UNSPECIFIED
# include "MemMap.h"

VAR(Rte_<roa>_RxUpdateFlagsType, RTE_VAR_ZERO_INIT<nocache>)
Rte_<roa>_RxUpdateFlags = {
 0
};

# define RTE_STOP_SEC_VAR_<roa><nocache>_ZERO_INIT_UNSPECIFIED
# include "MemMap.h"

# define Rte_<roa>_RxUpdateFlagsInit() (Rte_MemClr(&Rte_<roa>_RxUpdateFlags,
sizeof(Rte_<roa>_RxUpdateFlagsType)))

The extern declaration for Rte_<roa>_RxUpdateFlags is declared in Rte_Type.h:
# define RTE_START_SEC_VAR_<roa><nocache>_ZERO_INIT_UNSPECIFIED
# include "MemMap.h"

extern VAR(Rte_<roa>_RxUpdateFlagsType, RTE_VAR_ZERO_INIT<nocache>)
Rte_<roa>_RxUpdateFlags;

# define RTE_STOP_SEC_VAR_<roa><nocache>_ZERO_INIT_UNSPECIFIED
# include "MemMap.h"

For systems where the compiler does not initialize global variables, the API
Rte_InitMemory needs to call Rte_<oa>_RxUpdateFlagsInit() and
Rte_<roa>_RxUpdateFlagsInit().

The Update flag types are declared in Rte_Type.h
typedef struct
{
 Rte_BitType Rte_RxUpdate_<rci>_<rp>_<rd>_Sender : 1;
} Rte_<oa>_RxUpdateFlagsType;

typedef struct
{
 Rte_BitType Rte_RxUpdate_<rci>_<rp>_<rd> : 1;
} Rte_<roa>_RxUpdateFlagsType;

2015, Vector Informatik GmbH
Version: 4.8
44 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
6.6.1.5 Configuration Variant Inter-ECU
> source code SWC
> no support for multiple instantiation
> no indirect API
> pure inter-ECU communication
> no transmission acknowledgement
> no invalidation
> no data prototype mapping
6.6.1.6 Generated Code Inter-ECU
Rte_<c>.h defines Rte_Write as follows:
#define Rte_Write__<d> Rte_Write_<c>__<d>

The API is implemented in Rte_<oa>.c
# define RTE_START_SEC_VAR_<oa><nocache>_ZERO_INIT_UNSPECIFIED
# include "MemMap.h"

VAR(Rte_<oa>_TxUpdateFlagsType, RTE_VAR_ZERO_INIT<nocache>)
Rte_<oa>_TxUpdateFlags = {
 0,
 0,
};

# define RTE_STOP_SEC_VAR_<oa><nocache>_ZERO_INIT_UNSPECIFIED
# include "MemMap.h"

# define Rte_<oa>_TxUpdateFlagsInit() (Rte_MemClr(&Rte_<oa>_TxUpdateFlags,
sizeof(Rte_<oa>_TxUpdateFlagsType)))

#define RTE_START_SEC_CODE
#include "MemMap.h"

FUNC(Std_ReturnType, RTE_CODE) Rte_Write_<c>__<d>(<t> data)
{
Std_ReturnType ret = RTE_E_OK;

 Rte_WriteHook_<c>__<d>_Start(data);
 <Lock>();
2015, Vector Informatik GmbH
Version: 4.8
45 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
 Rte_<signalid> = *(&data);
Rte_<oa>_TxUpdateFlags.Rte_TxUpdate_<c>__<d>
=
RTE_COM_SENDSIGNALPROXY_SEND;
 Rte_<oa>_TxUpdateFlags.Rte_TxUpdateProxy_<c>__<d> =
!Rte_<bswoa>_TxUpdateFlags.Rte_TxUpdateProxy__<c>__<d>;
<UnLock>();
Rte_WriteHook_<c>__<d>_Return(data);
 return ret;
}

#define RTE_STOP_SEC_CODE
#include "MemMap.h"

and Rte_<c>.h only contains the prototype:
# define RTE_START_SEC_CODE
# include "MemMap.h"

FUNC(Std_ReturnType, RTE_CODE) Rte_Write_<c>__<d>(<t> data);

# define RTE_STOP_SEC_CODE
# include "MemMap.h"

The extern declaration for Rte_<oa>_TxUpdateFlags is declared in Rte_Type.h:

typedef struct
{
 Rte_BitType Rte_TxUpdate_<c>__<e> : 2;
 Rte_BitType Rte_TxUpdateProxy_<c>__<e> : 1;
} Rte_<oa>_TxUpdateFlagsType;

# define RTE_START_SEC_VAR_<oa><nocache>_ZERO_INIT_UNSPECIFIED
# include "MemMap.h"

extern VAR(Rte_<oa>_TxUpdateFlagsType, RTE_VAR_ZERO_INIT<nocache>)
Rte_<oa>_TxUpdateFlags;

# define RTE_STOP_SEC_VAR_<oa><nocache>_ZERO_INIT_UNSPECIFIED
# include "MemMap.h"

For systems where the compiler does not initialize global variables, the API
Rte_InitMemory needs to call Rte_<oa>_TxUpdateFlagsInit().

In both cases the global variable in Rte_<oa>.c is declared as
2015, Vector Informatik GmbH
Version: 4.8
46 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
#define RTE_START_SEC_VAR_<oa><nocache>_INIT_UNSPECIFIED
#include "MemMap.h"
VAR(<dt>, RTE_VAR_INIT<nocache>) Rte_<signalid> = <initializer>;
#define RTE_STOP_SEC_VAR_<oa><nocache>_INIT_UNSPECIFIED
#include "MemMap.h"

where <initializer> is the C representation of the init value that is configured for the port
data element.

For systems where the compiler does not initialize global variables, the API
Rte_InitMemory needs to do the initialization:
Rte_<signalid> = <initializer>;

If the data element is of a string or array type, no direct assignments are used. Instead,
the assignment is replaced by a memcpy
<Rte_MemCpy>(Rte_<signalid>, *(data), sizeof(<t>));

If the datatype can be read and written atomically, the <Lock>() and <UnLock>() calls are
omitted from the Rte_Write API.

When Rte_Write is not a macro, it needs to be assured that the macros
Rte_WriteHook_<c>__<d>_Start(data) and
Rte_WriteHook_<c>__<d>_Return(data) do not have any side effects.

6.6.2 Rte_Read
6.6.2.1 Configuration Variant Without IsUpdated
> source code SWC
> no support for multiple instantiation
> no indirect API
> alive timeout is not configured
> invalidation is not configured
> is updated is not configured
> never received is not configured
> no data prototype mapping
> sender is connected
2015, Vector Informatik GmbH
Version: 4.8
47 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
> intra-ECU or inter-ECU communication
6.6.2.2 Generated Code Without IsUpdated
Rte_<c>.h defines Rte_Read as follows:
#define Rte_Read__<d> Rte_Read_<c>__<d>

When the attribute “EnableTakeAddress” is not set for the port and when the data element
can be accessed atomically by the ECU, Rte_Read_<c>__<d> is declared as macro
that reads from a global RTE variable.

# define RTE_START_SEC_VAR_<soa><nocache>_INIT_UNSPECIFIED
# include "MemMap.h"

extern VAR(<t>, RTE_VAR_INIT<nocache>) Rte_<sci>_<sp>_<sd> ;

# define RTE_STOP_SEC_VAR_<soa><nocache>_INIT_UNSPECIFIED
# include "MemMap.h"

# define Rte_Read_<c>__<d>(data) (*(data) = Rte_<sci>_<sp>_<sd> ,
((Std_ReturnType)RTE_E_OK))

Otherwise, the API is implemented in Rte_<oa>.c
# define RTE_START_SEC_CODE
# include "MemMap.h"

FUNC(Std_ReturnType, RTE_CODE) Rte_Read_<c>__<d>(<tp> data)
{
 Std_ReturnType ret = RTE_E_OK;

 Rte_ReadHook_<c>__<d>_Start(data);
 <Lock>();
 *(data) = Rte_<sci>_<sp>_<sd> ;
 <UnLock>();
 Rte_ReadHook_<c>__<d>_Return(data);

 return ret;
}

#define RTE_STOP_SEC_CODE
#include "MemMap.h"

2015, Vector Informatik GmbH
Version: 4.8
48 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
and Rte_<c>.h only contains the prototype:

# define RTE_START_SEC_CODE
# include "MemMap.h"

FUNC(Std_ReturnType, RTE_CODE) Rte_Read_<c>__<d>(<tp> data);

# define RTE_STOP_SEC_CODE
# include "MemMap.h"

In both cases the global variable in Rte_<soa>.c is declared as
#define RTE_START_SEC_VAR_<soa><nocache>_INIT_UNSPECIFIED
#include "MemMap.h"
VAR(<dt>, RTE_VAR_INIT<nocache>) Rte_<sci>_<sp>_<sd> = <initializer>;
#define RTE_STOP_SEC_VAR_<soa><nocache>_INIT_UNSPECIFIED
#include "MemMap.h"

where <initializer> is the C representation of the init value that is configured for the sender
port data element.

For systems where the compiler does not initialize global variables, the API
Rte_InitMemory needs to do the initialization:

Rte_<sci>_<sp>_<sd> = <initializer>;

If the data element is a of a string or array type, no direct assignments are used. Instead,
the assignment is replaced by a memcpy
<Rte_MemCpy>(*(data), Rte_<sci>_<sp>_<sd> , sizeof(<t>));

The extern declaration for the global variable is contained in Rte_Type.h:
#define RTE_START_SEC_VAR_<soa><nocache>_INIT_UNSPECIFIED
#include "MemMap.h"
extern VAR(<dt>, RTE_VAR_INIT<nocache>) Rte_<sci>_<sp>_<sd>;
#define RTE_STOP_SEC_VAR_<soa><nocache>_INIT_UNSPECIFIED
#include "MemMap.h"

If the datatype can be read and written atomically, the <Lock>() and <UnLock>() calls are
omitted from the Rte_Read API.

When Rte_Read is not a macro, it needs to be assured that the macros
Rte_ReadHook_<c>__<d>_Start(data) and
Rte_ReadHook_<c>__<d>_Return(data) do not have any side effects.
2015, Vector Informatik GmbH
Version: 4.8
49 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE

When Rte_Read reads data from a component or BSW with lower safety level, sanity
checks have to be applied to the input data.

6.6.2.3 Configuration Variant With IsUpdated
> source code SWC
> no support for multiple instantiation
> no indirect API
> alive timeout is not configured
> invalidation is not configured
> no data prototype mapping
> is updated is configured
> never received is not configured
> sender is connected
> intra-ECU or inter-ECU communication
6.6.2.4 Generated Code With IsUpdated
Rte_Read with configured IsUpdated is similar to the variant without IsUpdated. However,
in the IsUpdated case, Rte_Read is always implemented as function in Rte_<oa>.c.

/******************************************************************************
* Update Flags for each Receiver with enableUpdate != 0
*****************************************************************************/
# define RTE_START_SEC_VAR_<oa><nocache>_ZERO_INIT_UNSPECIFIED
# include "MemMap.h"

VAR(Rte_<oa>_RxUpdateFlagsType, RTE_VAR_ZERO_INIT<nocache>)
Rte_<oa>_RxUpdateFlags = {
 0
};

# define RTE_STOP_SEC_VAR_<oa><nocache>_ZERO_INIT_UNSPECIFIED
# include "MemMap.h"

# define Rte_<oa>_RxUpdateFlagsInit() (Rte_MemClr(&Rte_<oa>_RxUpdateFlags,
2015, Vector Informatik GmbH
Version: 4.8
50 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
sizeof(Rte_<oa>_RxUpdateFlagsType)))

# define RTE_START_SEC_CODE
# include "MemMap.h"

FUNC(Std_ReturnType, RTE_CODE) Rte_Read_<c>__<d>(<tp> data)
{
 Std_ReturnType ret = RTE_E_OK;

 Rte_ReadHook_<c>__<d>_Start(data);
 <Lock>();
*(data) = Rte_<sci>_<sp>_<sd> ;
 Rte_<oa>_RxUpdateFlags.Rte_RxUpdate_<ci>__<d> =
Rte_<soa>_RxUpdateFlags.Rte_RxUpdate_<ci>__<d>_Sender;
 <UnLock>();
 Rte_ReadHook_<c>__<d>_Return(data);

 return ret;
}

#define RTE_STOP_SEC_CODE
#include "MemMap.h"

The variable Rte_<soa>_RxUpdateFlags is declared in Rte_<soa>.c as:

# define RTE_START_SEC_VAR_<soa><nocache>_ZERO_INIT_UNSPECIFIED
# include "MemMap.h"

VAR(Rte_<soa>_RxUpdateFlagsType, RTE_VAR_ZERO_INIT<nocache>)
Rte_<soa>_RxUpdateFlags = {
 0
};

# define RTE_STOP_SEC_VAR_<soa><nocache>_ZERO_INIT_UNSPECIFIED
# include "MemMap.h"

# define Rte_<soa>_RxUpdateFlagsInit() (Rte_MemClr(&Rte_<soa>_RxUpdateFlags,
sizeof(Rte_<soa>_RxUpdateFlagsType)))

For systems where the compiler does not initialize global variables, the API
Rte_InitMemory needs to call Rte_<oa>_RxUpdateFlagsInit() and
Rte_<soa>_RxUpdateFlagsInit().

2015, Vector Informatik GmbH
Version: 4.8
51 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE

The Update flags are declared in Rte_Type.h
typedef struct
{
Rte_BitType Rte_RxUpdate_<rci>_<rp>_<rd> : 1;
} Rte_<oa>_RxUpdateFlagsType;

typedef struct
{
Rte_BitType Rte_RxUpdate_<rci>_<rp>_<rd>_Sender : 1;
} Rte_<soa>_RxUpdateFlagsType;

# define RTE_START_SEC_VAR_<soa><nocache>_ZERO_INIT_UNSPECIFIED
# include "MemMap.h"

extern VAR(Rte_<soa>_RxUpdateFlagsType, RTE_VAR_ZERO_INIT<nocache>)
Rte_<soa>_RxUpdateFlags;

# define RTE_STOP_SEC_VAR_<soa><nocache>_ZERO_INIT_UNSPECIFIED
# include "MemMap.h"

# define RTE_START_SEC_VAR_<oa><nocache>_ZERO_INIT_UNSPECIFIED
# include "MemMap.h"

extern VAR(Rte_<oa>_RxUpdateFlagsType, RTE_VAR_ZERO_INIT<nocache>)
Rte_<oa>_RxUpdateFlags;

# define RTE_STOP_SEC_VAR_<oa><nocache>_ZERO_INIT_UNSPECIFIED
# include "MemMap.h"

Please note that in case of inter-ECU sender/receiver communication <soa> is the BSW
OS Application.
2015, Vector Informatik GmbH
Version: 4.8
52 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
6.6.3
Rte_IsUpdated
6.6.3.1
Configuration Variant

> source code SWC
> no support for multiple instantiation
> no indirect API
> alive timeout is not configured
> invalidation is not configured
> is updated is configured
> never received is not configured
> sender is connected
> intra-ECU or inter-ECU communication
6.6.3.2
Generated Code

Rte_<c>.h defines Rte_IsUpdated as follows:
# define Rte_IsUpdated__<d> Rte_IsUpdated_<c>__<d>
# define Rte_IsUpdated_<c>__<d>()
((Rte_<oa>_RxUpdateFlags.Rte_RxUpdate_<rci>_<rc>_<rd> ==
Rte_<soa>_RxUpdateFlags.Rte_RxUpdate_<rci>_<rp>_<rd>_Sender) ? FALSE : TRUE)

The Update flags are declared in Rte_Type.h

/******************************************************************************
* LOCAL DATA TYPES AND STRUCTURES
*****************************************************************************/

typedef unsigned int Rte_BitType;

typedef struct
{
 Rte_BitType Rte_RxUpdate_<rci>_<rp>_<rd> : 1;
} Rte_<oa>_RxUpdateFlagsType;

typedef struct
{
 Rte_BitType Rte_RxUpdate_<rci>_<rp>_<rd>_Sender :1;
} Rte_<soa>_RxUpdateFlagsType;

2015, Vector Informatik GmbH
Version: 4.8
53 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE

# define RTE_START_SEC_VAR_<oa><nocache>_ZERO_INIT_UNSPECIFIED
# include "MemMap.h"

extern VAR(Rte_<oa>_RxUpdateFlagsType, RTE_VAR_ZERO_INIT<nocache>)
Rte_<oa>_RxUpdateFlags;

# define RTE_STOP_SEC_VAR_<oa><nocache>_ZERO_INIT_UNSPECIFIED
# include "MemMap.h"

# define RTE_START_SEC_VAR_<soa><nocache>_ZERO_INIT_UNSPECIFIED
# include "MemMap.h"

extern VAR(Rte_<soa>_RxUpdateFlagsType, RTE_VAR_ZERO_INIT<nocache>)
Rte_<soa>_RxUpdateFlags;

# define RTE_STOP_SEC_VAR_<soa><nocache>_ZERO_INIT_UNSPECIFIED
# include "MemMap.h"

Variable initialization happens in Rte.c as described for the Rte_Read and Rte_Write APIs
(see 6.6.1.4 and 6.6.2.4).
2015, Vector Informatik GmbH
Version: 4.8
54 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
6.6.4 Rte_IrvWrite
6.6.4.1 Configuration Variant
> source code SWC
> no support for multiple instantiation
6.6.4.2 Generated Code
When the inter runnables variable can be accessed atomically by the ECU
Rte_IrvWrite_<re>_<name> is declared as macro that writes to a global RTE variable.
# define RTE_START_SEC_VAR_<oa>_INIT_UNSPECIFIED
# include "MemMap.h"

extern VAR(<t>, RTE_VAR_INIT) Rte_Irv_<ci>_<name>;

# define RTE_STOP_SEC_VAR_<oa>_INIT_UNSPECIFIED
# include "MemMap.h"

# define Rte_IrvWrite_<re>_<name>(data) (Rte_Irv_<ci>_<name> = (data))

Otherwise, the API is implemented in Rte_<oa>.c
#define RTE_START_SEC_CODE
#include "MemMap.h"

FUNC(void, RTE_CODE) Rte_IrvWrite_<c>_<re>_<name>(<t> data)
{
 Rte_IrvWriteHook_<c>_<re>_<name>_Start(data);
 <Lock>();
 Rte_Irv_<ci>_<name> = data;
<UnLock>();
Rte_IrvWriteHook_<c>_<re>_<name>_Return(data);
}

#define RTE_STOP_SEC_CODE
#include "MemMap.h"

and Rte_<c>.h only contains a define to the function:

2015, Vector Informatik GmbH
Version: 4.8
55 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
# define RTE_START_SEC_CODE
# include "MemMap.h"

FUNC(void, RTE_CODE) Rte_IrvWrite_<c>_<re>_<name>(<t> data);

# define RTE_STOP_SEC_CODE
# include "MemMap.h"

#define Rte_IrvWrite_<re>_<name> Rte_IrvWrite_<c>_<re>_<name>

In both cases the global variable in Rte_<oa>.c is declared as
#define RTE_START_SEC_VAR_<oa>_INIT_UNSPECIFIED
#include "MemMap.h"
VAR(<dt>, RTE_VAR_INIT) Rte_Irv_<ci>_<name> = <initializer>;
#define RTE_STOP_SEC_VAR_<oa>_INIT_UNSPECIFIED
#include "MemMap.h"

where <initializer> is the C representation of the init value that is configured for the inter-
runnable variable.

For systems where the compiler does not initialize global variables, the API
Rte_InitMemory needs to do the initialization:
Rte_Irv_<ci>_<name> = <initializer>;

If the datatype can be read and written atomically, the <LockInterupts>() and <UnLock>()
calls are omitted from the Rte_IrvWrite API.

When Rte_IrvWrite is not a macro, it needs to be assured that the macros
Rte_IrvWriteHook_<c>_<re>_<name>_Start(data) and
Rte_IrvWriteHook_<c>_<re>_<name>_Return(data) do not have any side effects.

2015, Vector Informatik GmbH
Version: 4.8
56 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
6.6.5 Rte_IrvRead
6.6.5.1 Configuration Variant
> source code SWC
> no support for multiple instantiation
6.6.5.2 Generated Code
When the inter runnables variable can be accessed atomically by the ECU
Rte_IrvRead_<re>_<name> is declared as macro that reads a global RTE variable.
# define RTE_START_SEC_VAR_<oa>_INIT_UNSPECIFIED
# include "MemMap.h"

extern VAR(<t>, RTE_VAR_INIT) Rte_Irv_<ci>_<name>;

# define RTE_STOP_SEC_VAR_<oa>_INIT_UNSPECIFIED
# include "MemMap.h"

# define Rte_IrvRead_<re>_<name>(data) Rte_Irv_<ci>_<name>

Otherwise, the API is implemented in Rte_<oa>.c
#define RTE_START_SEC_CODE
#include "MemMap.h"

FUNC(<t>, RTE_CODE) Rte_IrvRead_<c>_<re>_<name>(void)
{
<t> irvValue;

Rte_IrvReadHook_<c>_<re>_<name>_Start();

 <Lock>();
 irvValue = Rte_Irv_<ci>_<name>;
<UnLock>();

Rte_IrvReadHook_<c>_<re>_<name>_Return();

return irvValue;
}

#define RTE_STOP_SEC_CODE
#include "MemMap.h"
2015, Vector Informatik GmbH
Version: 4.8
57 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE

and Rte_<c>.h only contains a define to the function:
# define RTE_START_SEC_CODE
# include "MemMap.h"

FUNC(<t>, RTE_CODE) Rte_IrvRead_<c>_<re>_<name>(void);

# define RTE_STOP_SEC_CODE
# include "MemMap.h"

#define Rte_IrvRead_<re>_<name> Rte_IrvRead_<c>_<re>_<name>

In both cases the global variable in Rte_<oa>.c is declared as
#define RTE_START_SEC_VAR_<oa>_INIT_UNSPECIFIED
#include "MemMap.h"
VAR(<dt>, RTE_VAR_INIT) Rte_Irv_<ci>_<name> = <initializer>;
#define RTE_STOP_SEC_VAR_<oa>_INIT_UNSPECIFIED
#include "MemMap.h"
where <initializer> is the C representation of the init value that is configured for the inter-
runnable variable.

For systems where the compiler does not initialize global variables, the API
Rte_InitMemory needs to do the initialization:
Rte_Irv_<ci>_<name> = <initializer>;

If the datatype can be read and written atomically, the <Lock>() and <UnLock>() calls are
omitted from the Rte_IrvRead API.

When Rte_IrvRead is not a macro, it needs to be assured that the macros
Rte_IrvReadHook_<c>_<re>_<name>_Start() and
Rte_IrvReadHook_<c>_<re>_<name>_Return() do not have any side effects.

2015, Vector Informatik GmbH
Version: 4.8
58 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
6.6.6 Rte_Pim
6.6.6.1 Configuration Variant
> source code SWC
> no support for multiple instantiation
6.6.6.2 Generated Code
The API Rte_Pim is declared as access to a global RTE variable in Rte_<c>.h

# define RTE_START_SEC_VAR_DEFAULT_RTE_<oa>_PIM_GROUP_UNSPECIFIED
# include "MemMap.h"

extern VAR(<t>, RTE_VAR_DEFAULT_RTE_<oa>_PIM_GROUP) Rte_<ci>_<name>;

# define RTE_STOP_SEC_VAR_DEFAULT_RTE_<oa>_PIM_GROUP_UNSPECIFIED
# include "MemMap.h"

# define Rte_Pim_<name>() \\
(&Rte_<ci>_<name>)

Depending on the configuration of the memory section (see RTE Technical Reference) the
DEFAULT_RTE_<oa>_PIM_GROUP string is replaced by the configured group name.

The Rte_<c>_<name> variable is declared in Rte_<oa>.c:

# define RTE_START_SEC_VAR_DEFAULT_RTE_<oa>_PIM_GROUP_UNSPECIFIED
# include "MemMap.h"

VAR(<t>, RTE_VAR_DEFAULT_RTE_<d>_PIM_GROUP) Rte_<ci>_<name>;

# define RTE_STOP_SEC_VAR_DEFAULT_RTE_<oa>_PIM_GROUP_UNSPECIFIED
# include "MemMap.h"

2015, Vector Informatik GmbH
Version: 4.8
59 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
6.6.7 Rte_CData
6.6.7.1 Configuration Variant
> source code SWC
> no support for multiple instantiation
> no online calibration
6.6.7.2 Generated Code
The API Rte_CData is declared as access to a global RTE variable in Rte_<c>.h
# define RTE_START_SEC_CONST_DEFAULT_RTE_CDATA_GROUP_UNSPECIFIED
# include "MemMap.h"

extern CONST(<t>, RTE_CONST_DEFAULT_RTE_CDATA_GROUP) Rte_<c>_<name>;

# define RTE_STOP_SEC_CONST_DEFAULT_RTE_CDATA_GROUP_UNSPECIFIED
# include "MemMap.h"

# define Rte_CData_<name>() (Rte_<c>_<name>)

Depending on the configuration of the memory section (see RTE Technical Reference) the
DEFAULT_RTE_CDATA_GROUP string is replaced by the configured group name.
The Rte_<c>_<name> variable is declared in Rte_<oa>.c:

#define RTE_START_SEC_CONST_DEFAULT_RTE_CDATA_GROUP_UNSPECIFIED
#include "MemMap.h"

CONST(<t>, RTE_CONST_DEFAULT_RTE_CDATA_GROUP) Rte_<c>_<name> = <initializer>;

#define RTE_STOP_SEC_CONST_DEFAULT_RTE_CDATA_GROUP_UNSPECIFIED
#include "MemMap.h"

where <initializer> is the C representation of the init value that is configured for the
calibration parameter = <initializer> is omitted when the calibration parameter does not
have an init value.

2015, Vector Informatik GmbH
Version: 4.8
60 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
6.6.8 Rte_Prm
6.6.8.1 Configuration Variant
> source code SWC
> no support for multiple instantiation
> no indirect API
> no online calibration
> calibration port is connected
6.6.8.2 Generated Code
When the attribute “EnableTakeAddress” is not set for the calibration port, the API
Rte_Prm is declared as access to a global RTE variable in Rte_<c>.h
# define RTE_START_SEC_CONST_DEFAULT_RTE_CALPRM_GROUP_UNSPECIFIED
# include "MemMap.h"

extern CONST(<t>, RTE_CONST_DEFAULT_RTE_CALPRM_GROUP) Rte_<sc>_<sp>_<sd>;

# define RTE_STOP_SEC_CONST_DEFAULT_RTE_CALPRM_GROUP_UNSPECIFIED
# include "MemMap.h"

# define Rte_Prm__<d>() (Rte_<sc>_<sp>_<sd> )

Depending on the configuration of the memory section (see RTE Technical Reference) the
DEFAULT_RTE_CALPRM_GROUP string is replaced by the configured group name.

When “EnableTakeAddress” is set for the calibration port Rte_<c>.h maps the API to a
function in Rte_<oa>.c

# define RTE_START_SEC_CODE
# include "MemMap.h"

FUNC(<t>, RTE_CODE) Rte_Prm_<c>__<d>(void);

# define RTE_STOP_SEC_CODE
# include "MemMap.h"

# define Rte_Prm__<d> Rte_Prm_<c>__<d>

2015, Vector Informatik GmbH
Version: 4.8
61 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
Rte_<oa>.c then contains:

FUNC(<t>, RTE_CODE) Rte_Prm_<c>__<d>(void)
{
return Rte_<sc>_<sp>_<sd>;
}

In both cases the Rte_<sc>_<sp>_<sd> variable is declared in Rte.c:

#define RTE_START_SEC_CONST_DEFAULT_RTE_CALPRM_GROUP_UNSPECIFIED
#include "MemMap.h"

CONST(<t>, RTE_CONST_DEFAULT_RTE_CALPRM_GROUP) Rte_<sc>_<sp>_<sd> =
<initializer>;

#define RTE_STOP_SEC_CONST_DEFAULT_RTE_CALPRM_GROUP_UNSPECIFIED
#include "MemMap.h"

where <initializer> is the C representation of the init value that is configured for the
calibration parameter. No initializer is used when the calibration parameter does not have
an init value.

2015, Vector Informatik GmbH
Version: 4.8
62 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
6.6.9 Rte_Mode
6.6.9.1 Configuration Variant
> source code SWC
> no support for multiple instantiation
> no indirect API
> mode port is connected
6.6.9.2 Generated Code
The API Rte_Mode is declared as access to a global RTE variable in Rte_<c>.h

When the attribute “EnableTakeAddress” is not set for the mode port, the API is
implemented as macro.

# define RTE_START_SEC_VAR<nocache>_INIT_UNSPECIFIED
# include "MemMap.h"
extern VAR(<t>, RTE_VAR_INIT<nocache>) Rte_ModeMachine_<sci>_<sp>_<sd>;
# define RTE_STOP_SEC_VAR<nocache>_INIT_UNSPECIFIED
# include "MemMap.h"

# define Rte_Mode__<d>() Rte_ModeMachine_<sci>_<sp>_<sd>

Otherwise the API is defined to a function
# define RTE_START_SEC_CODE
# include "MemMap.h"
FUNC(<t>, RTE_CODE) Rte_Mode_<c>__<d>(void);
# define RTE_STOP_SEC_CODE
# include "MemMap.h"

# define Rte_Mode__<d> Rte_Mode_<c>__<d>

that is implemented in Rte_<oa>.c
2015, Vector Informatik GmbH
Version: 4.8
63 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE

# define RTE_START_SEC_CODE
# include "MemMap.h"

FUNC(<t>, RTE_CODE) Rte_Mode_<c>__<d>(void)
{
return Rte_ModeMachine_<sci>_<sp>_<sd>;
}

# define RTE_STOP_SEC_CODE
# include "MemMap.h"

In both cases the global variable in Rte_<soa>.c is declared as

#define RTE_START_SEC_VAR<nocache>_INIT_UNSPECIFIED
#include "MemMap.h"
VAR(<t>, RTE_VAR_INIT<nocache>) Rte_ModeMachine_<sci>_<sp>_<sd> = <mode>;
#define RTE_STOP_SEC_VAR<nocache>_INIT_UNSPECIFIED
#include "MemMap.h"
where <mode> is the mode mode define for the configured init mode.

The extern declaration is contained in Rte_Type.h:
#define RTE_START_SEC_VAR<nocache>_INIT_UNSPECIFIED
#include "MemMap.h"
extern VAR(<t>, RTE_VAR_INIT<nocache>) Rte_ModeMachine_<sci>_<sp>_<sd>;
#define RTE_STOP_SEC_VAR<nocache>_INIT_UNSPECIFIED
#include "MemMap.h"

For systems where the compiler does not initialize global variables, the API
Rte_InitMemory needs to do the initialization:

Rte_ModeMachine_<sci>_<sp>_<sd> = <mode>;
2015, Vector Informatik GmbH
Version: 4.8
64 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
6.6.10 Rte_Call
6.6.10.1 Configuration Variant
> source code SWC
> no support for multiple instantiation
> no indirect API
> Synchronous call
> Direct call:
> server runnable is not mapped
> server runnable is mapped to the same task
> server runnable has CanBeInvokedConcurrently set to true
6.6.10.2 Generated Code
When the server runnable has a return code and no port defined arguments, the API
Rte_Call is declared in Rte_<c>.h as macro:

# define <c>_START_SEC_CODE
# include "MemMap.h"
FUNC(Std_ReturnType, <c>_CODE) <sres>(<arglist>);
# define <c>_STOP_SEC_CODE
# include "MemMap.h"

# define Rte_Call__<o> <sres>

When the server runnable does not have a return code or if there are port defined
arguments and “EnableTakeAddress” is not set Rte_Call is declared as:
# define <c>_START_SEC_CODE
# include "MemMap.h"
FUNC(void, <c>_CODE) <sres>(<parglist><arglist>);
# define <c>_STOP_SEC_CODE
# include "MemMap.h"

# define Rte_Call__<o>(<arglist>) (<sres>(<parglist><arglist),
((Std_ReturnType)RTE_E_OK))

When the server runnable does not have a return code or if there are port defined
arguments and “EnableTakeAddress” is set, Rte_Call is declared as:
2015, Vector Informatik GmbH
Version: 4.8
65 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE

# define RTE_START_SEC_CODE
# include "MemMap.h"

FUNC(Std_ReturnType, RTE_CODE) Rte_Call_<c>__<o>(<parglist><arglist>);

# define RTE_STOP_SEC_CODE
# include "MemMap.h"

# define Rte_Call__<o> Rte_Call_<c>__<o>

and Rte_<oa>.c contains the code

# define RTE_START_SEC_CODE
# include "MemMap.h"

FUNC(Std_ReturnType, RTE_CODE) Rte_Call_<c>__<o>(<parglist><arglist>)
{
 Std_ReturnType ret = RTE_E_OK;
 Rte_CallHook_<c>__<o>_Start(<parglist><arglist>);

 Rte_Runnable_<sc>_<sre>_Start(<parglist><arglist>);
 <sres>(<arglist>);
 Rte_Runnable_<sc>_<sre>_Return(<parglist><arglist>);

 Rte_CallHook_<c>__<o>_Return(<parglist><arglist>);
 return ret;
}

# define RTE_STOP_SEC_CODE
# include "MemMap.h"

The return value of the Rte_Call API needs to be evaluated when the server operation has
configured application return codes.
When Rte_Call is not a macro, it needs to be assured that the Rte_CallHook_ and
Rte_Runnable_ macros do not have any side effects.

2015, Vector Informatik GmbH
Version: 4.8
66 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
6.6.11 Rte_Enter
6.6.11.1 Configuration Variant
> source code SWC
> no support for multiple instantiation
> Implementation method is set to OS interrupt blocking
6.6.11.2 Generated Code
The API Rte_Enter is declared in Rte_<c>.h as

# define Rte_Enter_<name>() \
 { \
 Rte_EnterHook_<c>_<name>_Start(); \
 SuspendOSInterrupts(); \
 Rte_EnterHook_<c>_<name>_Return(); \
}

It needs to be assured that the macros Rte_EnterHook_<c>_<name>_Start() and
Rte_EnterHook_<c>_<name>_Return() do not have any side effects.

It has to be assured that no included non-OS header or SWC code redefines the
SuspendOSInterrupts() and ResumeOSInterrupts() calls.
2015, Vector Informatik GmbH
Version: 4.8
67 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
6.6.12 Rte_Exit
6.6.12.1 Configuration Variant
> source code SWC
> no support for multiple instantiation
> Implementation method is set to OS interrupt blocking
6.6.12.2 Generated Code
The API Rte_Exit is declared in Rte_<c>.h as

# define Rte_Exit_<name>() \
 { \
 Rte_ExitHook_<c>_<name>_Start(); \
 ResumeOSInterrupts(); \
 Rte_ExitHook_<c>_<name>_Return(); \
}

It has to be assured that no included non-OS header or SWC code redefines the
SuspendOSInterrupts() and ResumeOSInterrupts() calls.

It needs to be assured that the macros Rte_ExitHook_<c>_<name>_Start() and
Rte_ExitHook_<c>_<name>_Return() are do not have any side effects.

2015, Vector Informatik GmbH
Version: 4.8
68 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
6.7
BSW specifc RTE APIs
6.7.1 SchM_Enter
6.7.1.1 Configuration Variant
> source code BSW
> Implementation method is set to All or OS interrupt blocking
6.7.1.2 Generated Code
The API SchM_Enter is declared in SchM_<bsw>.h as

# define SchM_Enter_<bsw>_<name>() \
 { \
 SuspendAllInterrupts(); \
}

for ImplementationMethod All Interrupt Blocking. Otherwise SuspendOSInterrupts() is
called.
It has to be assured that no included non-OS header or BSW code redefines the
SuspendAllInterrupts()/SuspendOSInterrupts()
and
ResumeAllInterrupts()/ResumeOSInterupts() calls.
6.7.2 SchM_Exit
6.7.2.1
Configuration Variant
> source code BSW
> Implementation method is set to All or OS interrupt blocking
6.7.2.2 Generated Code
The API SchM_Exit is declared in SchM_<bsw>.h as

# define SchM_Exit_<bsw>_<name>() \
 { \
 ResumeAllInterrupts(); \
}

for ImplementationMethod All Interrupt Blocking. Otherwise ResumeOSInterrupts() is
called.
2015, Vector Informatik GmbH
Version: 4.8
69 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
It has to be assured that no included non-OS header or BSW code redefines the
SuspendAllInterrupts()/SuspendOSInterrupts()
and
ResumeAllInterrupts()/ResumeOSInterupts() calls.

2015, Vector Informatik GmbH
Version: 4.8
70 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
6.8
RTE Lifecycle APIs
6.8.1 Rte_Start
Rte_Start is not called from the ASIL context.
6.8.2 Rte_Stop
Rte_Stop is not called from the ASIL context.
6.8.3 Rte_InitMemory
Rte_InitMemory needs to be called before the OS sets up the memory protection when the
compiler does not initialize global variables. The method itself and the method it calls need
to do all initialization for the APIs that are listed in chapter 6.6.
6.9
RTE Internal Functions
6.9.1 Rte_MemCpy
Rte_MemCpy is called by RTE code that is called from the ASIL SWCs in order to copy
data from the memory location “source” to the memory location „destination“. When
Rte_MemCpy is called from the ASIL SWCs it needs to be checked that the parameter
num which specifies the number of bytes that shall be copied is of type uint16 and that the
memory regions “destination” and “source” contain num bytes. Moreover destination needs
to be writable. For larger data sizes, the generator uses a method Rte_MemCpy32 that
copies in blocks of 4 byte when source and destination are aligned accordingly.

FUNC(void, RTE_CODE) Rte_MemCpy(P2VAR(void, AUTOMATIC, RTE_APPL_VAR)
destination, P2CONST(void, AUTOMATIC, RTE_APPL_DATA) source, uint16_least num)

FUNC(void, RTE_CODE) Rte_MemCpy32(P2VAR(void, AUTOMATIC, RTE_APPL_VAR)
destination, P2CONST(void, AUTOMATIC, RTE_APPL_DATA) source, uint16_least num)

The functionality of Rte_MemCpy and Rte_MemCpy32 needs to be checked.
Rte_MemCpy and Rte_MemCpy32 must not read and write outside the specified memory
regions and the alignment requirements of the target platform need to be fulfilled.
6.9.2 Rte_MemClr
Rte_MemClr is not called from the ASIL SWCs. It is used for the initialization of global
variables with zeros within Rte.c and Rte_<oa>.c.
STATIC FUNC(void, RTE_CODE) Rte_MemClr(P2VAR(void, AUTOMATIC, RTE_VAR_NOINIT)
ptr, uint16_least num);

2015, Vector Informatik GmbH
Version: 4.8
71 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
It has to be checked, that the first parameter is a pointer to a writable variable and that the
second parameter is the length of the variable. Rte_MemClr is not allowed to write outside
the specified memory region.
6.10 RTE Tasks
It needs to be checked that Rte_<oa>.c contains the implementation of all RTE tasks that
are assigned to ASIL OS Applications:

TASK(<name>)
{
 Rte_Task_Dispatch(<name>);

 /* call runnable */
 Rte_Runnable_<c>_<re>_Start();
 <res>();
 Rte_Runnable_<c>_<re>_Return();

 (void)TerminateTask();
}

It needs to be checked that the trace hooks
> Rte_Task_Dispatch
> Rte_Runnable_<c>_<re>_Start
> Rte_Runnable_<c>_<re>_Return
do not have any side effects.
The task body is only allowed to contain calls to runnables and schedulable entities that
are mapped to the task in the configuration and calls to TerminateTask. The call to
TerminateTask needs to be the last operation in the task and it always needs to be done.
It has to be assured that no included non-OS header or RTE code redefines the TASK()
and TerminateTask() calls.
The name within the TASK call needs to be the name of the configured OS task.
For schedulable entities, the calls to the hooks are omitted by default.
6.11 Verification of OS Configuration
The integrator is responsible for correctly configuring the OS.
It needs to be checked that the OS contains no trusted OS Applications that do not have
the highest ASIL.
It needs to be checked that the OS contains no tasks that are assigned to an ASIL OS
Application and that are not implemented with the given ASIL.
2015, Vector Informatik GmbH
Version: 4.8
72 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
6.12 Verification of Memory Mapping Configuration
It needs to be verified that all variables Rte_<sci>__<d> of sender port data elements,
Rte_<oa>_RxUpdateFlags, Rte_Irv_<ci>_<name> of inter-runnable variables and
Rte_<ci>_<name> of per-instance memories from ASIL SWCs are mapped to memory
sections of the SWC’s OS Application so that they are protected from writes outside this
OS Application.
When the variables are assigned to different sections or when other RTE variables are
assigned to the section, memory protection faults might occur.

2015, Vector Informatik GmbH
Version: 4.8
73 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
7
Safety Lifecycle Tailoring
The development of the MICROSAR RTE started as Safety Element out of context at the
software unit level.
The unit design is based on the requirements of the AUTOSAR RTE specification [1].
Based  on  the  requirements  and  the  RTE  design  a  set  of  test  cases  with  typical
configurations were derived. The RTE was generated for the test cases and compiled with
SWC stubs. Finally, the code was runtime tested on different target platforms and a MISRA
analysis was performed.
During the development of the MICROSAR RTE, assumptions regarding the architecture
and  the  safety  requirements  were  made.  The  integrator  is  responsible  for  creating  a
complete architecture design and for specifying the software safety requirements. He then
needs to verify the assumptions that are listed within this document.
As  the  generated  RTE  code  heavily  depends  on  the  input  configuration,  it  is  also  the
responsibility of the integrator to integrate and test the generated RTE code.
Furthermore, it needs to be verified that the generated code fulfils the safety requirements
of the target system.

2015, Vector Informatik GmbH
Version: 4.8
74 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
8  Glossary and Abbreviations
8.1
Glossary
Term
Description
DaVinci DEV
DaVinci Developer: The SWC and RTE Configuration Editor.
DaVinci CFG
DaVinci Configurator: The BSW and RTE Configuration Editor.
E2E PW
E2E Protection Wrapper: Wrapper Functions to access the E2E Library
Table 8-1   Glossary

8.2
Abbreviations
Abbreviation
Description
API
Application Programming Interface
ASIL
Automotive Safety Integrity Level
AUTOSAR
Automotive Open System Architecture
BSW
Basis Software
E2E
AUTOSAR End-to-End Communication Protection Library
ECU
Electronic Control Unit
H&R
Hazard and Risk Analysis
HIS
Hersteller Initiative Software
ISO
International Organization for Standardization
ISR
Interrupt Service Routine
MICROSAR
Microcontroller Open System Architecture (the Vector AUTOSAR
solution)
MPU
Memory Protection Unit (realized in hardware by the processor)
RTE
Runtime Environment
SEooC
Safety Element out of Context: a safety-related element which is not
developed for a specific item
SWC
Software Component
OS
Operating System
OS Application
An OS Application is a set of tasks and ISRs with a partial common MPU
setting
TCL
Tool Qualification Level
QM
Quality Management (used for software parts developed following only a
standard quality management process)
Table 8-2   Abbreviations
2015, Vector Informatik GmbH
Version: 4.8
75 / 76
based on template version 4.8.0

Safety Guide MICROSAR RTE
9  Contact
Visit our website for more information on

>  News
>  Products
>  Demo software
>  Support
>  Training data
>  Addresses

www.vector.com

2015, Vector Informatik GmbH
Version: 4.8
76 / 76
based on template version 4.8.0

Document Outline

5 - TechnicalReference_Rte

MICROSAR RTE

6 - TechnicalReference_Rte_ind

Outline
Page 1
Page 2
Page 3
Page 4
Page 5
Page 6
Page 7
Page 8
Page 9
Page 10
Page 11
Page 12
Page 13
Page 14
Page 15
Page 16
Page 17
Page 18
Page 19
Page 20
Page 21
Page 22
Page 23
Page 24
Page 25
Page 26
Page 27
Page 28
Page 29
Page 30
Page 31
Page 32
Page 33
Page 34
Page 35
Page 36
Page 37
Page 38
Page 39
Page 40
Page 41
Page 42
Page 43
Page 44
Page 45
Page 46
Page 47
Page 48
Page 49
Page 50
Page 51
Page 52
Page 53
Page 54
Page 55
Page 56
Page 57
Page 58
Page 59
Page 60
Page 61
Page 62
Page 63
Page 64
Page 65
Page 66
Page 67
Page 68
Page 69
Page 70
Page 71
Page 72
Page 73
Page 74
Page 75
Page 76
Page 77
Page 78
Page 79
Page 80
Page 81
Page 82
Page 83
Page 84
Page 85
Page 86
Page 87
Page 88
Page 89
Page 90
Page 91
Page 92
Page 93
Page 94
Page 95
Page 96
Page 97
Page 98
Page 99
Page 100
Page 101
Page 102
Page 103
Page 104
Page 105
Page 106
Page 107
Page 108
Page 109
Page 110
Page 111
Page 112
Page 113
Page 114
Page 115
Page 116
Page 117
Page 118
Page 119
Page 120
Page 121
Page 122
Page 123
Page 124
Page 125
Page 126
Page 127
Page 128
Page 129
Page 130
Page 131
Page 132
Page 133
Page 134
Page 135
Page 136
Page 137
Page 138
Page 139

7 - TechnicalReference_Rtes

MICROSAR RTE
Technical Reference

Version 4.8.0

Authors
Bernd Sigle, Martin Schlodder, Sascha Sommer,
Stephanie Schaaf, Katharina Benkert, Cornelius Reuss
Status
Released

Technical Reference MICROSAR RTE

Document Information
History
Author
Date
Version  Remarks
Bernd Sigle
2005-11-14  2.0.0
Document completely reworked and adapted to
AUTOSAR RTE
Bernd Sigle
2006-04-20  2.0.1
API description for Rte_IRead / Rte_IWrite added,
description of used OS/COM services added
Bernd Sigle
2006-07-11  2.0.2
API description for Rte_Receive / Rte_Send added;
Adaptation to RTE SWS 1.0.0 Final
Martin Schlodder  2006-11-02  2.0.3
Separation of RTE and target package
Martin Schlodder  2006-11-15  2.0.4
Client/Server communication
Martin Schlodder  2006-12-21  2.0.5
Serialized client/server communication
Martin Schlodder  2007-01-17  2.0.6
Array data types
Martin Schlodder  2007-02-14  2.0.7
Added exclusive areas, removed description of
TargetPackages
Bernd Sigle
2007-02-19  2.0.8
Added transmission acknowledgement  handling and
minor rework of the document
Bernd Sigle
2007-04-25  2.0.9
Added Rte_IStatus
Martin Schlodder  2007-04-27  2.0.10
Added IRV and Const/Enum
Martin Schlodder  2007-05-01  2.1.0
Completed documentation for Version 2.2
Bernd Sigle
Bernd Sigle
2007-07-27  2.1.1
Added Rte_InitMemory, Rte_IWriteRef Runnable.
Added description of runnable activation offset und
updated picture of MICROSAR architecture.
Martin Schlodder  2007-08-03  2.1.2
Added description of template update.
Martin Schlodder  2007-11-16  2.1.3
Added warning regarding IWrite / IrvIWrite.
Bernd Sigle
Added API descriptions of VFB trace hooks.
Updated data type info for nested types.
Martin Schlodder  2008-02-06  2.1.4
Updated descriptions on template merging and task
Bernd Sigle
mapping.
Added description of Rte_Pim, Rte_CData,
Rte_Calprm and Rte_Result.
Added support of string data type.
Updated command line argument description.
Added NvRAM mapping description.
Added chapter about compiler abstraction and
memory mapping.
Hannes Futter
2008-03-11  2.1.5
Additional command line switches to support direct
generation on xml and dcf files.
Bernd Sigle
2008-03-26  2.2.0
Updated description of NV Memory Mapping and
Chapter about limitations added.
Chapter about compiler and memory abstraction
updated.
Support for AUTOSAR Release 3.0 added.
2015, Vector Informatik GmbH
Version: 4.8.0
2 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

Bernd Sigle
2008-04-16  2.3.0
Added description about A2L file generation and
updated command line options and example calls to
cover also the AUTOSAR XML input files.
Bernd Sigle
2008-07-16  2.4.0
Removed limitations for multiple instantiation and
compatibility mode support.
Bernd Sigle
2008-08-13  2.5.0
Added description of indirect APIs Rte_Port, Rte_Ports
and Rte_NPorts. Added description of platform
dependent resource calculation.
Bernd Sigle
2008-10-23  2.6.0
Added description of memory protection support.
Bernd Sigle
2009-01-23  2.7.0
Added description of mode management APIs
Rte_Mode and Rte_Switch and updated description of
Rte_Feedback.
Added description of Rte_Invalidate and
Rte_IInvalidate and added new Com APIs.
Added additional runnable trigger events and removed
section for runnables without trigger, which is no
longer supported.
Deviation for [rte_sws_2648] added.
Usage of new document template
Bernd Sigle
2009-03-26  2.8.0
Removed limitations for unconnected ports and for
data type generation.
Sascha Sommer  2009-08-11  2.9.0
Added description about usage of basic / extended
Bernd Sigle
task
Added description of command line parameter -v
Sascha Sommer  2009-10-22  2.10.0
Added a warning for VFB trace hooks that prevent
Bernd Sigle
macro optimizations
Explained that the Activation task attribute has to be
set for basic tasks
Init-Runnables no longer need to have a special suffix
Explained the new periodic trigger implementation
dialog.
Server runnables with CanBeInvokedConcurrently set
to false do not need to be mapped to tasks when the
calling clients cannot interrupt each other
Resource Usage is now listed in a HTML report
Updated version of referenced documents and of
supported AUTOSAR release.
Updated examples with new workspace file extension.
Added new defines for memory mapping.
Bernd Sigle
2010-04-09  2.11.0
Added description of user header file Rte_UserTypes.h
Updated component history and interface functions to
the OS. Added pictures of Rte Interfaces and Rte
Include Structure. Updated picture of MICROSAR
architecture. Rework of chapter structure.
Bernd Sigle
2010-05-25  2.11.1
Added description of RTE optimization mode
2015, Vector Informatik GmbH
Version: 4.8.0
3 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

Bernd Sigle
2010-05-26  2.12.0
Added new measurement chapter, added description
Sascha Sommer
of COM Rx Filter, macros for access of invalid value,
initial value, lower and upper limit, added support of
minimum start interval and second array passing
variant. Support of AUTOSAR Release 3.1 (RTE SWS
2.2.0)
Bernd Sigle
2010-07-22  2.13.0
Added online calibration support. Removed limitation

of missing transmission error detection
Bernd Sigle
2010-09-28  2.13.1
Added more detailed description of extended record

data type compatibility rule
Bernd Sigle
2010-11-23  2.14.0
Removed obsolete command line parameters –bo, –bc

and –bn.
Stephanie Schaaf
2011-07-25  2.15.0
Added general support of AUTOSAR Release 3.2.1
Bernd Sigle
(RTE SWS 2.4.0).
Sascha Sommer
Added support of never received status.
Added support of S/R update handling.
Mentioned that –g c and –g i ignore service
components when –m specifies an ECU project.
Explained RTE usage with Non-Trusted BSW
Added hint for FUNC_P2CONST() problems
Explained measurement of COM signals
Stephanie Schaaf   2012-01-25  2.16.0
Enhanced command line interface (support for several
Bernd Sigle
generation modes in one command line call, optional
Sascha Sommer
command line parameter –m)
Split of RTE into OS Application specific files
Byte arrays no longer need to be mapped to signals
groups
Allow configuration of Schedule() calls in non-
preemptive tasks
Bernd Sigle
2012-05-18  2.17.0
Corrected description how the Rte_IsUpdated API can
be enabled
Bernd Sigle
2012-09-18  2.18.0
Added general support of AUTOSAR Release 3.2.2
(RTE SWS 2.5.0).
Added support of non-queued N:1 S/R communication
Bernd Sigle
2012-08-28  3.90.0
AUTOSAR 4.0.3 support, DaVinci Configurator 5
support
Bernd Sigle
2012-12-11  4.0.0
Updated API descriptions concerning
RTE_E_UNCONNECTED  return code
Added description of Rte_UserTypes.h file which is
now also generated with the template mechanism
Stephanie Schaaf  2013-03-26  4.1.0
Added support of Rte_MemSeg.a2l file
Added description of –o sub option for A2L file path
Bernd Sigle
2013-06-14  4.1.1
Added Multi-Core support (S/R communication)
Added support of Inter-Runnable Variables with
composite data types
2015, Vector Informatik GmbH
Version: 4.8.0
4 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

Katharina Benkert  2013-10-30  4.2.0
Added support for arrays of dynamic data length
Stephanie Schaaf
(Rte_Send/Rte_Receive)
Sascha Sommer
Added support for parallel generation for multiple
Bernd Sigle
component types
Multicore support
Added support for SchM Contract Phase Generation
Added support for Nv Block SWCs
Katharina Benkert  2014-02-06  4.3.0
Added support of VFB Trace Client Prefixes
Sascha Sommer
Optimized Multicore support without IOCs
Stephanie Schaaf
Memory Protection support for Multicore systems
Inter-ECU sender/receiver communication, queued
sender/receiver communication and mapped
client/server calls are no longer limited to the BSW
partition
Added support of Development Error Reporting
Added support of registering XCP Events in the XCP
module configuration
Stephanie Schaaf  2014-06-17  4.4.0
Support for unconnected client ports for synchronous
Bernd Sigle
C/S communication
Inter-Ecu C/S communication using SOME/IP
Transformer
Support for PR-Ports
S/R Serialization using SOME/IP Transformer and E2E
Transformer
Support LdCom
Bernd Sigle
2014-08-13  4.4.1
Described decimal coding of the version defines and
the return code of SchM_GetVersionInfo
Added chapter about additional copyrights of FOSS
Bernd Sigle
2014-09-12  4.4.2
Minor format changes only
Bernd Sigle
2014-08-13  4.5.0
Support Postbuild-Selectable for variant data
mappings and variant COM signals
Support E2E Transformer for Inter-Ecu C/S
communication
Support tasks mappings where multiple runnable or
schedulable entities using different cycle times or
activation offsets are mapped to a single Basic Task.
The realization uses OS Schedule Tables
Support Rte_DRead API
Enhanced support for PR-Ports
Support ServerArgumentImplPolicy = use
ArrayBaseType
Explicit order of ModeDeclarationGroups
2015, Vector Informatik GmbH
Version: 4.8.0
5 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

Bernd Sigle
2014-12-08  4.6.0
Support of PR Mode Ports
Support of PR Nv Ports
Support of bit field data types (CompuMethods with
category BITFIELD_TEXTTABLE)
Runtime optimized copying of large data
Support for SW-ADDR-METHOD on RAM blocks of
NvRAM SWCs
Bernd Sigle
2015-02-20  4.7.0
Support of background triggers
Support of data prototype mappings
Support of bit field text table mappings
Support of union data types
Support of UTF16 data type serialization in the
SOME/IP transformer
Runtime optimization in the generated RTE code by
usage of optimized interrupt locking APIs of the
MICROSAR OS
Support of further E2E profiles for data transformation
with the SOME/IP and E2E transformer
Support of OS counters with tick durations smaller
than 1µs
Bernd Sigle
2015-07-26  4.8.0
Support of COM based Transformer ComXf
Support of different strategies for writing NV data in Nv
Block SWCs
Support of C/S Interfaces for Nv Block SWCs
SWC Template generation provides user sections for
documentation of runnable entities
Wide character support in paths
Improved counter selection for operating systems with
multiple OS applications
Support of optimized macro implementation for
SchM_Enter and SchM_Exit
Enhanced OS Spinlock support
Enable optimizations in QM partitions
Table 1-1   History of the document
2015, Vector Informatik GmbH
Version: 4.8.0
6 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

Reference Documents
No.
Title
Version
[1]
AUTOSAR_SWS_RTE.pdf
3.2.0
[2]
AUTOSAR_EXP_VFB.pdf
2.2.0
[3]
AUTOSAR_SWS_COM.pdf
4.2.0
[4]
AUTOSAR_SWS_OS.pdf
5.0.0
[5]
AUTOSAR_SWS_NVRAMManager.pdf
3.2.0
[6]
AUTOSAR_SWS_ECU_StateManager.pdf
3.0.0
[7]
AUTOSAR_SWS_StandardTypes.pdf
1.3.0
[8]
AUTOSAR_SWS_PlatformTypes.pdf
2.5.0
[9]
AUTOSAR_SWS_CompilerAbstraction.pdf
3.2.0
[10]
AUTOSAR_SWS_MemoryMapping.pdf
1.4.0
[11]
AUTOSAR_TPS_SoftwareComponentTemplate.pdf
4.2.0
[12]
AUTOSAR_TPS_SystemTemplate.pdf
4.2.0
[13]
AUTOSAR_TPS_ECUConfiguration.pdf
3.2.0
[14]
AUTOSAR_TR_Glossary.pdf
2.4.0
[15]
AUTOSAR_TPS_BSWModuleDescriptionTemplate.pdf
2.2.0
[16]
AUTOSAR_SWS_XCP.pdf
2.0.0
[17]
AUTOSAR_SWS_ DevelopmentErrorTracer.pdf
3.2.0
[18]
Vector DaVinci Configurator Online help

[19]
Vector DaVinci Developer Online help

[20]
AUTOSAR Calibration User Guide
1.0
Table 1-2   Reference documents

Scope of the Document
This  document  describes  the  MICROSAR  RTE  generator.  It  assumes  that  the  reader  is
familiar with the AUTOSAR architecture, especially the software component (SWC) design
methodology  and  the AUTOSAR  RTE  specification.  It  also  assumes  basic  knowledge  of
some basic software  (BSW) modules like AUTOSAR Os, Com,  LdCom,  NvM and EcuM.
The  description  of  those  components  is  not  part  of  this  documentation.  The  related
documents are listed in Table 1-2.

2015, Vector Informatik GmbH
Version: 4.8.0
7 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

Please note
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.
2015, Vector Informatik GmbH
Version: 4.8.0
8 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

1  Component History
The  component  history  gives  an  overview  over  the  important  milestones  that  are
supported in the different versions of the component.

Component Version  New Features
2.3
 Complex hierarchical data types like arrays of records
 Optimization: Depending on the configuration the Rte_Read API is
generated as macro if possible
2.4
 String data type (Encoding ISO-8859-1)
 SWC local calibration parameters (Rte_CData)
 Optimization: Depending on the configuration the Rte_Write API is
generated as macro if possible
 Generation of unmapped client runnables enabled
 Asynchronous C/S communication (Rte_Result)
2.5
 Support of AUTOSAR 3.0 Revision 0001
 Access to calibration element prototypes of calibration components
(Rte_Calprm)
 Access to Per-Instance Memory (Rte_Pim)
 SWC implementation template generation (command line option -g i)
and Contract Phase generation (command line option -g c)  for a
complete ECU
2.6
 Intra-ECU timeout handling for synchronous C/S communication
 Parallel access of synchronous and asynchronous server calls to an
operation of one server port
 Generation of an ASAM MCD 2MC / ASAP2 compatible A2L file
fragment for calibration parameters and Per-Instance Memory
2.7
 Multiple instantiation of software components
 Compatibility mode
 Object code software components
2.8
 Indirect APIs (Rte_Ports, Rte_NPorts and Rte_Port)
 Port API Option 'EnableTakeAddress'
 Platform dependent resource calculation.
2.9
 Memory protection (OS with scalability class SC3/SC4)
2.10
 Mode management including mode switch triggered runnable entities
and mode dependent execution of runnable entities. (Rte_Switch,
Rte_Mode and Rte_Feedback for mode switch acknowledge)
 Data element invalidation (Rte_Invalidate and Rte_IInvalidate)
 Data reception error triggered runnable entities for invalidated and
outdated data elements
 Multiple cyclic triggers per runnable entity
 Multiple OperationInvokedEvent triggers for the same runnable entity
with compatible operations
 Extended A2L file generation for calibration parameters and Per-
2015, Vector Informatik GmbH
Version: 4.8.0
15 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

Component Version  New Features
Instance Memory for user defined attributes (A2L-ANNOTATION)
2.11
 Signal Fan-In
 Unconnected provide ports
 Generation of unreferenced data types
 Evaluation of COM return codes
2.12
 Basic task support (automatically selection)
 Several optimizations (e.g. unneeded interrupt locks and Schedule()
call removed)
 Enhanced error reporting with help messages (-v command line
option)
 Support of acknowledgement only mode for transmission and mode
switch notification
 Usage of compiler library functions (e.g. memcpy) removed
 Template file update mechanism also introduced for Rte_MemMap.h
and Rte_Compiler_Cfg.h
2.13
 Unconnected require ports
 Basic task support (manual selection)
 Init-Runnables no longer have name restrictions
 Automatic periodic trigger generation can be disabled e.g. useful for
Schedule Table support
 HTML Report including resource usage
 Explicit selection of task role (Application / BSW Scheduler / Non Rte)
 Runnables with CanBeInvokedConcurrently set to false no longer
require a mapping, if they are not called concurrently.
2.14
 Support composite data types where not all primitive members require
an invalid value
 Support inclusion of user header file 'Rte_UserTypes.h'
2.15
 Optimized runnable scheduling to reduce latency times
 Allow implementation template generation for service components,
complex device drivers and EcuAbstraction components
 Optimization mode (minimize RAM consumption /  minimize execution
time)
2.16
 MinimumStartInterval attribute (runnable de-bouncing)
 Measurement support for S/R communication, Interrunnable variables
and mode communication. Extended A2L File generation and support
of new ASAM MCD 2MC / ASAP2 standard. Measurement with
XcpEvents
 Com Filter (NewDiffersOld, Always)
 Invalid value accessible from application
 Support of second array passing variant
2.17
 Online calibration support
 Support transmission error detection
 Support of extended record data type compatibility for S/R
communication with different record layout on sender and receiver side
2.18
 Enhanced implicit communication support
2015, Vector Informatik GmbH
Version: 4.8.0
16 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

Component Version  New Features
2.19
 Support of AUTOSAR 3.2 Revision 0001
 Support never received status
 Support S/R update handling (Rte_IsUpdated based on AUTOSAR
4.0)
 Enhanced measurement support (Inter-Ecu S/R communication)
 Selective file generation (only if file content is modified)
 Support for Non-Trusted BSW
2.20
 Enhanced command line interface (support for several generation
modes in one call, optional command line parameter –m)
 Split of generated RTE into OS Application specific files
 Byte arrays no longer need to be mapped to signal groups
 Allow configuration of Schedule() calls in non-preemptive tasks
 Generation of MISRA justification comments
2.21
 Support of SystemSignals and SystemSignalGroups using the same
name
 Support of hexadecimal coded enumeration values
2.22
 Support of AUTOSAR 3.2 Revision 0002
 Support S/R update handling according AUTOSAR 3.2.2
 Support N:1 S/R communication
 Support unconnected calibration R-Ports
 Enhanced initial value handling
3.90
 Support of AUTOSAR 4.0 Revision 0003
4.0
 Support of pointer implementation data types
 Support of ‘On Transition’ triggered runnable entities
 Support of data type symbol attribute
 Support of component type symbol attribute
 Template generation mechanism added for Rte_UserTypes.h
4.1
 Support of Rte_MemSeg.a2l
 Enhanced command line interface (path for A2L files selectable)
4.1.1
 Multi-Core support (S/R communication)
 Support of Inter-Runnable Variables with composite data types
4.2
 Support for arrays of dynamic data length (Rte_Send/Rte_Receive)
 Support for parallel generation for multiple component types
 Multi-Core support:
  C/S communication
  Mode communication without ModeDisablings and ModeTriggers
  Inter-ECU S/R communication
 Support mapping of individual OperationInvoked triggers
 Support of SchM Contract Phase Generation
 Support of Nv Block SWCs
4.3
 Support of VFB Trace Client Prefixes
 Enhanced Memory Protection support
  Memory Protection support for Multi-Core systems
  Inter-ECU sender/receiver communication is no longer limited to the
2015, Vector Informatik GmbH
Version: 4.8.0
17 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

Component Version  New Features
BSW partition
  Mapped client/server calls are no longer limited to the BSW partition
  Queued sender/receiver communication is no longer limited to the
BSW partition
 Optimized Multi-Core support without IOCs
 Support of Development Error Reporting
 Support of registering XCP Events in the XCP module configuration
4.4
 Support for unconnected client ports for synchronous C/S
communication
 Inter-Ecu C/S communication using SOME/IP Transformer
 Support for PR-Ports
 S/R Serialization using SOME/IP Transformer and E2E Transformer
 Support LdCom
 Improved support for 3rd Party OS interoperability especially regarding
OS Counter handling
4.5
 Support Postbuild-Selectable for variant data mappings and variant
COM signals
 Support E2E Transformer for Inter-Ecu C/S communication
 Support tasks mappings where multiple runnable or schedulable
entities using different cycle times or activation offsets are mapped to a
single Basic Task. The realization uses OS Schedule Tables
 Support Rte_DRead API
 Enhanced support for PR-Ports
 Support ServerArgumentImplPolicy = use ArrayBaseType
 Support for Mode Declaration Groups with Explicit Order
4.6
 Support of PR Mode Ports
 Support of PR Nv Ports
 Support of bit field data types (CompuMethods with category
BITFIELD_TEXTTABLE)
 Runtime optimized copying of large data
 Support for SW-ADDR-METHOD on RAM blocks of NvRAM SWCs
4.7
 Support of background triggers
 Support of data prototype mappings
 Support of bit field text table mappings
 Support of union data types
 Support of UTF16 data type serialization in the SOME/IP transformer
 Runtime optimization in the generated RTE code by usage of
optimized interrupt locking APIs of the MICROSAR OS
 Support of further E2E profiles for data transformation with the
SOME/IP and E2E transformer
 Support of OS counters with tick durations smaller than 1µs
4.8
 Support of COM based Transformer ComXf
 Support of different strategies for writing NV data in Nv Block SWCs
 Support of C/S Interfaces for Nv Block SWCs
 SWC Template generation provides user sections for documentation of
2015, Vector Informatik GmbH
Version: 4.8.0
18 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

Component Version  New Features
runnable entities
 Wide character support in paths
 Improved counter selection for operating systems with multiple OS
applications
 Support of optimized macro implementation for SchM_Enter and
SchM_Exit
 Enhanced OS Spinlock support
 Enable optimizations in QM partitions
Table 1-1   Component history
2015, Vector Informatik GmbH
Version: 4.8.0
19 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

2  Introduction
The  MICROSAR  RTE  generator  supports  RTE  and  contract  phase  generation.
Additionally, application template code can be generated for software components and for
VFB trace hooks.
This document describes the MICROSAR RTE generation process, the RTE configuration
with DaVinci Configurator and the RTE API.
Chapter  3  gives  an  introduction  to  the  MICROSAR  RTE.  This  brief  introduction  to  the
AUTOSAR  RTE  can  and  will  not  replace  an  in-depth  study  of  the  overall  AUTOSAR
methodology  and  in  particular  the AUTOSAR  RTE  specification,  which  provides  detailed
information on the concepts of the RTE.
In  addition  chapter  3  describes deviations, extensions and  limitations  of  the  MICROSAR
RTE compared to the AUTOSAR standard.
The RTE  generation process including the command line parameters of the  MICROSAR
RTE generator is described in chapter 4. This chapter also gives hints for integration of the
generated  RTE  code  into  an  ECU  project.  In  addition  it  describes  the  memory  mapping
and compiler abstraction related to the RTE and finally, chapter 4.6 describes the memory
protection support of the RTE including hints for integration with the OS.
The  RTE  API  description  in  chapter  5  covers  the  API  functionality  implemented  in  the
MICROSAR RTE.
The description of  the  RTE  configuration  in chapter  6  covers the  task mapping,  memory
mapping  and  the  code  generation  settings  in  DaVinci  Configurator.  A  more  detailed
description  of  the  configuration  tool  including  the  configuration  of  AUTOSAR  software
components and compositions and their integration in an ECU project can be found in the
online help of the DaVinci Configurator [18].

Supported AUTOSAR Release*:
4
Supported Configuration Variants:
pre-compile
Vendor ID:
RTE_VENDOR_ID
30 decimal
(= Vector-Informatik,
according to HIS)
Module ID:
RTE_MODULE_ID
2 decimal
AR Version:
RTE_AR_RELEASE_MAJOR_VERSION
AUTOSAR Release
RTE_AR_RELEASE_MINOR_VERSION
version
RTE_AR_RELEASE_REVISION_VERSION
decimal coded
SW Version:
RTE_SW_MAJOR_VERSION
MICROSAR RTE
RTE_SW_MINOR_VERSION
version
RTE_SW_PATCH_VERSION
decimal coded
* For the precise AUTOSAR Release 4.x please see the release specific documentation.
2015, Vector Informatik GmbH
Version: 4.8.0
20 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

2.1
Architecture Overview
The RTE is the realization of the interfaces of the AUTOSAR Virtual Function Bus (VFB)
for  a  particular  ECU.  The  RTE  provides  both  standardized  communication  interfaces  for
AUTOSAR software  components  realized by  generated RTE APIs and it also  provides a
runtime environment for the component code – the runnable entities. The RTE triggers the
execution  of  runnable  entities  and  provides  the  infrastructure  services  that  enable
communication  between  AUTOSAR  SWCs.  It  is  acting  as  a  broker  for  accessing  basic
software modules including the OS and communication services.
The  following  figure  shows  where  the  MICROSAR  RTE  is  located  in  the  AUTOSAR
architecture.

Figure 2-1  AUTOSAR architecture

RTE functionality overview:
  Execution of runnable entities of SWCs on different trigger conditions
  Communication mechanisms between SWCs (Sender/Receiver and Client/Server)
  Mode Management
  Inter-Runnable communication and exclusive area handling
2015, Vector Informatik GmbH
Version: 4.8.0
21 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

  Per-Instance Memory and calibration parameter handling
  Multiple instantiation of SWCs
  OS task body and COM / LDCOM callback generation
  Automatic configuration of parts of the OS, NvM and COM / LDCOM dependent of the
needs of the RTE
  Assignment of SWCs to different memory partitions/cores

SchM functionality overview:
  Execution of cyclic triggered schedulable entities (BSW main functions)
  Exclusive area handling for BSW modules
  OS task body generation

2015, Vector Informatik GmbH
Version: 4.8.0
22 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

composite structure Component
Interfaces to SWCs and BSW Moduls
«EmbeddedInterface»
«EmbeddedInterface»
RTE::S/R (explicit)
RTE::Mode Handling
+ Rte_Write__<o>([IN Rte_Instance <instance>,] IN <data>)() :Std_ReturnType
+ Rte_Switch__<o>([IN Rte_Instance <instance>,] IN <mode>)() :Std_ReturnType
+ Rte_Read__<o>([IN Rte_Instance <instance>,] OUT <data>)() :Std_ReturnType
+ Rte_Mode__<o>([IN Rte_Instance <instance>])() :Std_ReturnType
+ Rte_Send__<o>([IN Rte_Instance <instance>,] IN <data> [,IN uint16 <length>])() :Std_ReturnType
+ Rte_Mode__<o>([IN Rte_Instance <instance>,] OUT previous, OUT next)() :<currentmode>
+ Rte_Receive__<o>([IN Rte_Instance <instance>,] OUT <data> [,OUT uint16 <length>])() :Std_ReturnType
+ Rte_SwitchAck__<o>([IN Rte_Instance <instance>])() :<currentmode>
+ Rte_Feedback__<o>([IN Rte_Instance <instance>])() :Std_ReturnType
+ Rte_Invalidate__<o>([IN Rte_Instance <instance>])() :Std_ReturnType
+ Rte_IsUpdated__<o>([IN Rte_Instance <instance>])() :boolean
«EmbeddedInterface»
RTE::C/S
«EmbeddedInterface»
+ Rte_Call__<o>([IN Rte_Instance <instance>,] <data_1> ... <data_n>)() :Std_ReturnType
RTE::S/R (implicit)
+ Rte_Result__<o>([IN Rte_Instance <instance>,] <data_1> ... <data_n>)() :Std_ReturnType
+ Rte_IWrite_<re>__<o>([IN Rte_Instance <instance>,] IN <data>)() :void
+ Rte_IWriteRef_<re>__<o>([IN Rte_Instance <instance>])() :<return ref>
+ Rte_IRead_<re>__<o>([IN Rte_Instance <instance>])() :<return>
«EmbeddedInterface»
+ Rte_IStatus_<re>__<o>([IN Rte_Instance <instance>])() :Std_ReturnType
RTE::Indirect API
+ Rte_IInvalidate_<re>__<o>([IN Rte_Instance <instance>])()
+ Rte_Port_([IN Rte_Instance <instance>])() :Rte_PortHandle__<R/P>
+ Rte_Ports_<pi>_<R/P>([IN Rte_Instance <instance>])() :Rte_PortHandle__<R/P>
«provide optionally»
+ Rte_NPorts_<pi>_<R/P>([IN Rte_Instance <instance>])() :uint8
«EmbeddedInterface»
RTE::Inter-Runnable Variable
+ Rte_IrvWrite_<v([IN Rte_Instance <instance>,] IN <data>)() :void
«EmbeddedInterface»
+ Rte_IrvRead_<v>([IN Rte_Instance <instance>])() :<return>
«provide optionally»
RTE::Calibration Parameter
+ Rte_IrvIWrite_<re>_<v([IN Rte_Instance <instance>,] IN <data>)() :void
+ Rte_CData_<c>([IN Rte_Instance <instance>])() :<parameter>
+ Rte_IrvIRead_<re>_<v>([IN Rte_Instance <instance>])() :<return>
+ Rte_Prm__<c>([IN Rte_Instance <instance>])() :<parameter>
«provide optionally»
«EmbeddedInterface»
RTE::Exclusiv e Area
«EmbeddedInterface»
«provide optionally»
+ Rte_Enter_<ea>([IN Rte_Instance <instance>])() :void
RTE::Per-Instance Memory
«provide optionally»
+ Rte_Exit_<ea>([IN Rte_Instance <instance>])() :void
+ Rte_Pim_([IN Rte_Instance <instance>])() :<pim>
«EmbeddedInterface»
«provide optionally»
«EmbeddedInterface»
SchM::Exclusiv e Area
RTE::Error Handling
+ SchM_Enter_<ea>([IN Rte_Instance <instance>])() :void
+ Rte_HasOverlayedError(Std_ReturnType) :boolean
+ SchM_Exit_<ea>([IN Rte_Instance <instance>])() :void
«provide optionally» + Rte_ApplicationError(Std_ReturnType) :Std_ReturnType
+ Rte_IsInfrastructureError(Std_ReturnType) :boolean
«provide optionally»
«provide optionally»
«provide optionally»
Module
RTE
«use optionally»
«provide optionally»
«use optionally»
«use optionally»
Interfaces to Os
Interfaces to Com
«EmbeddedInterface»
«EmbeddedInterface»
«EmbeddedInterface»
Used Interfaces::Os
RTE::COM Callback
Prov ided Interfaces::
+ ActivateTask(TaskType) :StatusType
+ Rte_COMCbk_<SignalName>() :void
Memory Initialization
+ CancelAlarm(AlarmType) :StatusType
+ Rte_COMCbkRxTOut_<SignalName>() :void
+ Rte_InitMemory() :void
+ ChainTask(TaskType) :StatusType
+ Rte_COMCbkTAck_<SignalName>() :void
+ ClearEvent(EventMaskType) :StatusType
+ Rte_COMCbkTxTOut_<SignalName>() :void
+ DisableAllInterrupts() :void
+ Rte_COMCbkTErr_<SignalName>() :void
+ EnableAllInterrupts() :void
+ Rte_COMCbkInv_<SignalName>() :void
+ GetEvent(TaskType, EventMaskType*) :StatusType
+ GetResource(ResourceType) :StatusType
«provide optionally»
+ GetTaskID(TaskType*) :StatusType
+ IocRead_<iocid>(OUT <data>)() :Std_ReturnType
+ IocReadGroup_<iocid>(OUT <data0>,..., OUT <data_n>)() :Std_ReturnType
«EmbeddedInterface»
+ IocReceive_<iocid>(OUT <data>)() :Std_ReturnType
Used Interfaces::Com
Interfaces to Xcp
+ IocSend_<iocid>[_<sid>](IN <data>)() :Std_ReturnType
+ Com_SendDynSignal(Com_SignalIdType, const void*, uint16) :uint8
+ IocWrite_<iocid>[_<sid>](IN <data>)() :Std_ReturnType
«EmbeddedInterface»
+ Com_SendSignal(Com_SignalIdType, const void*) :uint8
+ IocWriteGroup_<iocid>[_<sid>](IN <data0>,..., IN <data_n>)() :Std_ReturnType
Used Interfaces::Xcp
+ Com_UpdateShadowSignal(Com_SignalIdType, const void*) :void
+ ReleaseResource(ResourceType) :StatusType
+ Com_SendSignalGroup(Com_SignalGroupIdType) :uint8
+ ResumeOSInterrupts() :void
+ Xcp_Event(uint8) :void
+ Com_ReceiveDynSignal(Com_SignalIdType, void*, uint16*) :uint8
+ Schedule() :StatusType
+ Com_ReceiveSignal(Com_SignalIdType, void*) :uint8
+ SetEvent(TaskType, EventMaskType) :StatusType
+ Com_ReceiveShadowSignal(Com_SignalIdType, void*) :uint8
+ SetRelAlarm(AlarmType, TickType, TickType) :StatusType
+ Com_ReceiveSignalGroup(Com_SignalGroupIdType) :uint8
+ SuspendOSInterrupts() :void
+ Com_InvalidateSignal(Com_SignalIdType) :uint8
+ TerminateTask() :StatusType
+ Com_InvalidateSignalGroup(Com_SignalGroupIdType) :uint8
+ WaitEvent(EventMaskType) :StatusType
Interfaces to EcuM
Interfaces to NvM
«EmbeddedInterface»
«EmbeddedInterface»
«EmbeddedInterface»
RTE::Lifecycle
SchM::Lifecycle
RTE::Nv M Callback
+ Rte_Start() :Std_ReturnType
+ SchM_Init([IN SchM_ConfigType ConfigPtr])() :void
+ Rte_GetMirror__<d>(void*) :Std_ReturnType
+ Rte_Stop() :Std_ReturnType
+ SchM_Deinit() :void
+ Rte_SetMirror__<d>(const void*) :Std_ReturnType
+ SchM_GetVersionInfo(Std_VersionInfoType*) :void

Figure 2-2 Interfaces to adjacent modules of the RTE

2015, Vector Informatik GmbH
Version: 4.8.0
23 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

3  Functional Description
3.1
Features
The features listed in the following tables cover the complete functionality specified for the
RTE.
The AUTOSAR  standard  functionality  is  specified  in  [1],  the  corresponding  features  are
listed in the tables
  Table 3-1   Supported AUTOSAR standard conform features
  Table 3-2   Not supported AUTOSAR standard conform features
Vector Informatik provides further RTE functionality beyond the AUTOSAR standard. The
corresponding features are listed in the table
  Table 3-3   Features provided beyond the AUTOSAR standard

The following features specified in [1] are supported:
Supported AUTOSAR Standard Conform Features
Explicit S/R communication (last-is-best)  [API: Rte_Read, Rte_Write]
Explicit S/R communication (queued polling)  [API: Rte_Receive, Rte_Send]
Variable length arrays
Explicit S/R communication (queued blocking)  [API: Rte_Receive]
Implicit S/R communication  [API:Rte_IRead, Rte_IWrite, Rte_IWriteRef]
Timeout handling (DataReceiveErrorEvent) [API: Rte_IStatus]
Data element invalidation [API: Rte_Invalidate, Rte_IInvalidate]
Intra-Ecu S/R communication
Inter-Ecu S/R communication
1:N S/R communication (including network signal Fan-Out)
N:1 S/R communication (non-queued, pure network signal Fan-In or pure Intra-Ecu)
C/S communication (synchronous, direct calls)  [API: Rte_Call]
C/S communication (synchronous, scheduled calls)  [API: Rte_Call]
C/S communication (asynchronous calls)  [API: Rte_Call]
C/S communication (asynchronous) [API: Rte_Result]
Intra-Ecu C/S communication
Inter-Ecu C/S communication using SOME/IP Transformer
N:1 C/S communication
Explicit exclusive areas [API: Rte_Enter, Rte_Exit]
Implicit exclusive areas
Explicit Inter-Runnable Variables [API: Rte_IrvRead, Rte_IrvWrite]
Implicit Inter-Runnable Variables [API: Rte_IIrvRead, Rte_IIrvWrite]
2015, Vector Informatik GmbH
Version: 4.8.0
24 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

Supported AUTOSAR Standard Conform Features
Transmission ack. status (polling and blocking) [API: Rte_Feedback]
Runnable category 1a, 1b und 2
RTE Lifecycle-API [API: Rte_Start, Rte_Stop]
Nv Block Software Components
Runnable to task mapping
Data element to signal mapping
Task body generation
VFB-Tracing
Multiple trace clients
ECU-C import / export
Automatic OS configuration according the needs of the RTE (basic and extended task support)
Automatic COM / LDCOM configuration according the needs of the RTE
Primitive data types
Composite data types
Data reception triggered runnables entities (DataReceivedEvent)
Cyclic triggered runnable entities (TimingEvent)
Data transmission triggered runnable entities (DataSendCompletionEvent)
Data reception error triggered runnables entities (DataReceiveErrorEvent)
Mode switch acknowledge triggered runnable entities (ModeSwitchedAckEvent)
Mode switch triggered runnable entities (ModeSwitchEvent)
Background triggered runnable and scheduleable entities (BackgroundEvent)
Contract phase header generation
Port access to services (Port defined argument values)
Port access to ECU-Abstraction
Compatibility mode
Per-Instance Memory [API: Rte_Pim]
Multiple instantiation on ECU-level
Indirect API [API: Rte_Port, Rte_NPorts, Rte_Ports]
SWC internal calibration parameters [API: Rte_CData]
Shared calibration parameters (CalprmComponentType) [API: Rte_Prm]
Mode machine handling [API: Rte_Mode/Rte_Switch]
Mode switch ack. status (polling and blocking) [API: Rte_SwitchAck]
Multi-Core support (S/R communication, C/S communication, Mode communication (partially))
Memory protection
Unconnected ports
COM-Filter (NewDiffersOld, Always)
Measurement (S/R-Communication, Mode-Communication, Inter-Runnable Variables)
Runnable de-bouncing (Minimum Start Interval)
2015, Vector Informatik GmbH
Version: 4.8.0
25 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

Supported AUTOSAR Standard Conform Features
Online calibration support
Never received status
S/R update handling [API: Rte_IsUpdated]
Contract Phase Header generation for BSW-Scheduler
PR-Ports
Optimized S/R communication [API: Rte_DRead]
Variant Handling support (Postbuild selectable for variant data mappings and COM signals)
Data prototype mapping
Bit field texttable mapping
Table 3-1   Supported AUTOSAR standard conform features
3.1.1
Deviations
The following features specified in [1] are not supported:
Not Supported AUTOSAR Standard Conform Features
COM-Filter (only partially supported)
Measurement (Client-Server arguments)
external Trigger (via port) [API: Rte_Trigger]
Inter-Runnable Trigger (SWC internal) [API: Rte_IrTrigger]
Tx-Ack for implicit communication [API: Rte_IFeedback]
BSW-Scheduler Mode Handling [API: SchM_Mode, SchM_Switch, SchM_SwitchAck]
external Trigger between BSW modules [API: SchM_Trigger]
BSW-Scheduler Trigger [API: SchM_ActMainFunction]
BSW-Scheduler Calibration Parameter Access [API: SchM_CData]
Post Build Variant Sets
Debugging and Logging Support
Variant Handling support (Pre-Compile variability, Postbuild variability for Connectors and
ComponentPrototypes)
Multi-Core support (Mode communication with ModeSwitchTriggers or ModeDisablings,
Rte_ComSendSignalProxyImmediate, RteIocInteractionReturnValue=RTE_COM)
Restarting of partitions
Re-scaling of ports / Data conversion
Pre-Build data set generation phase
Post-Build data set generation phase
Initialization of PerInstanceMemories
Asynchronous Mode Handling
MC data support
Generated BSWMD
Range checks
2015, Vector Informatik GmbH
Version: 4.8.0
26 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

Not Supported AUTOSAR Standard Conform Features
RTE memory section initialisation strategies
External conﬁguration switch strictConfigurationCheck
Table 3-2   Not supported AUTOSAR standard conform features
3.1.2
Additions/ Extensions
The following features are provided beyond the AUTOSAR standard:
Features Provided Beyond The AUTOSAR Standard
Rte_InitMemory API function. See Chapter 5.14.3 for details.
Init-Runnables. See Chapter 3.6.9 for details.
VFB Trace Hooks for SchM APIs. See Chapter 5.16.3 and 5.16.4 for details.
Measurement support for mode communication. See Chapter 6.6 for details.
Measurement with XCP Events. See Chapter 6.6 for details.
S/R Serialization using SOME/IP Transformer and E2E Transformer (AR4.2.1)
C/S Serialization using SOME/IP Transformer and E2E Transformer (AR4.2.1)
LdCom Support (AR4.2.1)
ComXf Support (AR4.2.1)
Table 3-3   Features provided beyond the AUTOSAR standard
3.1.3
Limitations
There are no known limitations.
2015, Vector Informatik GmbH
Version: 4.8.0
27 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

3.2
Initialization
The  RTE  is  initialized  by  calling  Rte_Start.  Initialization  is  done  by  the  ECU  State
Manager (EcuM).
The Basis Software Scheduler (SchM) is initialized by calling  SchM_Init. Initialization is
done by the ECU State Manager (EcuM).
3.3
AUTOSAR ECUs
Besides  the  basic  software  modules  each AUTOSAR  ECU  has  a  single  instance  of  the
RTE  to  manage  the  application  software  of  the  ECU.  The  application  software  is
modularized and assigned to one or more AUTOSAR software components (SWC).
3.4
AUTOSAR Software Components
AUTOSAR  software  components  (SWC)  are  described  by  their  ports  for  communication
with  other  SWCs  and  their  internal  behavior  in  form  of  runnable  entities  realizing  the
smallest schedulable code fragments in an ECU.
The following communication paradigms are supported for port communication:
  Sender-Receiver (S/R): queued and last-is-best, implicit and explicit
  Client-Server (C/S): synchronous and asynchronous
  Mode communication
  Calibration parameter communication
S/R and C/S communication may occur Intra-ECU or between different ECUs (Inter-ECU).
Mode communication and calibration parameters can only be accessed ECU internally.
In addition to Inter-SWC communication over ports, the description of the internal behavior
of  SWCs  contains  also  means  for  Intra-SWC  communication  and  synchronization  of
runnable entities.
  Inter-Runnable Variables
  Per-Instance Memory
  Exclusive Areas
  Calibration Parameters
The description of the internal behavior of SWCs finally contains all information needed for
the handling of runnable entities, especially the events upon which they are triggered.
3.5
Runnable Entities
All  application  code  is  organized  into  runnable  entities,  which  are  triggered  by  the  RTE
depending  on  certain  conditions.  They  are  mapped  to  OS  tasks  and  may  access  the
communication and data consistency mechanisms provided by the SWC they belong to.
2015, Vector Informatik GmbH
Version: 4.8.0
28 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

The trigger conditions for runnable entities are described below, together with the
signature of the runnable entities that results from these trigger conditions. A detailed
description of the signature of runnable entities may be found in section 5.3 Runnable
Entities.
3.6
Triggering of Runnable Entities
AUTOSAR has introduced the concept of RTEEvents to trigger the execution of runnable
entities. The following RTEEvents are supported by the MICROSAR RTE:
 TimingEvent
 DataReceivedEvent
 DataReceiveErrorEvent
 DataSendCompletedEvent
 OperationInvokedEvent
 AsynchronousServerCallReturnsEvent
 ModeSwitchEvent
 ModeSwitchedAckEvent
 InitEvent
 BackgroundEvent

The RTEEvents can lead to two different kinds of triggering:
 Activation of runnable entity
 Wakeup of waitpoint
Activation of runnable entity starts a runnable entity at its entry point while
wakeup of waitpoint resumes runnable processing at a waitpoint. The second is not
possible for all RTEEvents and needs an RTE API to setup this waitpoint inside the
runnable entity code.
Depending on the existence of a waitpoint, runnable entities are categorized into category
1 or category 2 runnables. A runnable becomes a category 2 runnable if at least one
waitpoint exists.
3.6.1
Time Triggered Runnables
AUTOSAR defines the TimingEvent for periodic triggering of runnable entities. The
TimingEvent can only trigger a runnable entity at its entry point. Consequently there
exists no API to set up a waitpoint for a TimingEvent. The signature of a time triggered
runnable is:
void <RunnableName>([IN Rte_Instance instance])

2015, Vector Informatik GmbH
Version: 4.8.0
29 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

3.6.2
Data Received Triggered Runnables
AUTOSAR defines the DataReceivedEvent to trigger a runnable entity on data
reception (queued or last-is-best) or to continue reception of queued data in a blocking
Rte_Receive call. Both intra ECU and inter ECU communication is supported. Data
reception triggered runnables have the following signature:
void <RunnableName>([IN Rte_Instance instance])

3.6.3
Data Reception Error Triggered Runnables
AUTOSAR defines the DataReceiveErrorEvent to trigger a runnable entity on data
reception error. A reception error could be a timeout (aliveTimeout) or an invalidated
data element. The DataReceiveErrorEvent can only trigger a runnable entity at its
entry point. Consequently there exists no API to set up a waitpoint for a
DataReceiveErrorEvent. The signature of a data reception error triggered runnable is:
void <RunnableName>([IN Rte_Instance instance])

3.6.4
Data Send Completed Triggered Runnables
AUTOSAR defines the DataSendCompletedEvent to signal a successful or an
erroneous transmission of explicit S/R communication. The DataSendCompletedEvent
can either trigger the execution of a runnable entity or continue a runnable, which waits at
a waitpoint for the transmission status or the mode switch in a blocking Rte_Feedback
call. Both intra ECU and inter ECU communication is supported. Data send completed
triggered runnables have the following signature:
void <RunnableName>([IN Rte_Instance instance])

3.6.5
Mode Switch Triggered Runnables
AUTOSAR defines the ModeSwitchEvent to trigger a runnable entity on either entering
or exiting of a specific mode of a mode declaration group. The ModeSwitchEvent can
only trigger a runnable entity at its entry point. Consequently there exists no API to set up
a waitpoint for a ModeSwitchEvent. The signature of a mode switch triggered runnable
is:
void <RunnableName>([IN Rte_Instance instance])

3.6.6
Mode Switched Acknowledge Triggered Runnables
AUTOSAR defines the ModeSwitchedAckEvent to signal a successful mode transition.
The ModeSwitchedAckEvent can either trigger the execution of a runnable entity or
continue a runnable, which waits at a waitpoint for the mode transition status. Only intra
ECU communication is supported. Runnables triggered by a mode switch acknowledge
have the following signature:
void <RunnableName>([IN Rte_Instance instance])

2015, Vector Informatik GmbH
Version: 4.8.0
30 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

3.6.7
Operation Invocation Triggered Runnables
The OperationInvokedEvent is defined by AUTOSAR to always trigger the execution
of a runnable entity. The signature of server runnables depends on the parameters defined
at the C/S port. Its general appearance is as follows:
{void|Std_ReturnType} <Runnable>([IN Rte_Instance inst] {,paramlist}*)

The return value depends on application errors being assigned to the operation that the
runnable represents. The parameter list contains input in/output and output parameters.
Input parameters for primitive data type are passed by value. Input parameters for
composite data types and all in/output and output parameters independent whether they
are primitive or composite types are passed by reference. The string data type is handled
like a composite type.
3.6.8
Asynchronous Server Call Return Triggered Runnables
The AsynchronousServerCallReturnsEvent signals the end of an asynchronous
server execution and triggers either a runnable entity to collect the result by using
Rte_Result or resumes the waitpoint of a blocking Rte_Result call.
The runnables have the following signature:
{void|Std_ReturnType} <Runnable>([IN Rte_Instance inst] {,paramlist}*)

3.6.9
Init Triggered Runnables
Initialization runnables are called once during startup and have the following signature:
void <RunnableName>([IN Rte_Instance instance])

3.6.10 Background Triggered Runnables
Background triggered runnables have to be mapped to tasks with lowest priority. The
runnables are called by the RTE in an endless loop – in the background – when no other
runnable runs. The signature of a background triggered runnable is:
void <RunnableName>([IN Rte_Instance instance])
2015, Vector Informatik GmbH
Version: 4.8.0
31 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

3.7
Exclusive Areas
An exclusive area (EA) can be used to protect either only a part of runnable code (explicit
EA access) or the complete runnable code (implicit EA access). AUTOSAR specifies four
implementation methods which are configured during ECU configuration of the RTE. See
also Chapter 6.9.
  OS Interrupt Blocking
  All Interrupt Blocking
  OS Resource
  Cooperative Runnable Placement
All of them have to ensure that the current runnable is not preempted while executing the
code inside the exclusive area.
The  MICROSAR  RTE  analyzes  the  accesses  to  the  different  RTE  exclusive  areas  and
eliminates redundant ones if that is possible e.g. if runnable entities accessing the same
EA they cannot preempt each other and can therefore be dropped.

Info
For SchM exclusive areas the automatic optimization is currently not supported.
  Optimization must be done manually by setting the implementation method to NONE.

3.7.1
OS Interrupt Blocking
When an exclusive area uses the implementation method  OS_INTERRUPT_BLOCKING, it
is
protected
by
calling
the
OS
APIs
SuspendOSInterrupts()
and
ResumeOSInterrupts(). The OS does not allow the invocation of event and resource
handling  functions  while  interrupts  are  suspended.  This  precludes  calls  to  any  RTE API
that  is  based  upon  an  explicitly  modeled  waitpoint  (blocking  Rte_Receive,
Rte_Feedback,  Rte_SwitchAck  or  Rte_Result API)  as  well  as  synchronous  server
calls (which sometimes use waitpoints that are not explicitly modeled or other rescheduling
points).  Additionally,  all  APIs  that  might  trigger  a  runnable  entity  on  the  same  ECU  or
cause a blocking queue access to be released are forbidden, as well as exclusive areas
implemented as OS Resource.
3.7.2
All Interrupt Blocking
When an exclusive area uses the implementation method ALL_INTERRUPT_BLOCKING, it
is
protected
by
calling
the
OS  APIs
SuspendAllInterrupts()
and
ResumeAllInterrupts(). The OS does not allow the invocation of event and resource
handling  functions  while  interrupts  are  suspended.  This  precludes  calls  to  any  RTE API
that  is  based  upon  an  explicitly  modeled  waitpoint  (blocking  Rte_Receive,
Rte_Feedback,  Rte_SwitchAck  or  Rte_Result API)  as  well  as  synchronous  server
calls (which sometimes use waitpoints that are not explicitly modeled or other rescheduling
points).  Additionally,  all  APIs  that  might  trigger  a  runnable  entity  on  the  same  ECU  or
cause a blocking queue access to be released are forbidden, as well as exclusive areas
implemented as OS Resource.
2015, Vector Informatik GmbH
Version: 4.8.0
32 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

3.7.3
OS Resource
An  exclusive  area  using  implementation  method  OS_RESOURCE  is  protected  by  OS
resources entered and released via GetResource() / ReleaseResource()calls, which
raise the task priority so that no other task using the same resource may run. The OS does
not  allow  the  invocation  of  WaitEvent()  while  an OS  resource  is  occupied. This  again
precludes  calls  to  any  RTE API  that  is  based  upon  an  explicitly  modeled  waitpoint  and
synchronous server calls.
3.7.4
Cooperative Runnable Placement
For exclusive areas with implementation method COOPERATIVE_RUNNABLE_PLACEMENT,
the RTE generator only applies a check whether any of the tasks accessing the exclusive
area are able to preempt any other task of that group. This  again precludes calls to any
RTE API that is based upon an explicitly modeled waitpoint and synchronous server calls.

2015, Vector Informatik GmbH
Version: 4.8.0
33 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

3.8
Error Handling
3.8.1
Development Error Reporting
By default, development errors are reported to the DET using the service
Det_ReportError() as specified in [17], if development error reporting is enabled in the
RteGeneration parameters (i.e. by setting the parameters DevErrorDetect and / or
DevErrorDetectUninit).
If another module is used for development error reporting, the function prototype for
reporting the error can be configured by the integrator, but must have the same signature
as the service Det_ReportError(). The reported RTE ID is 2.
The reported service IDs identify the services which are described in chapter 5. The
following table presents the service IDs and the related services:
Service ID
Service
0x00
SchM_Init
0x01
SchM_Deinit
0x03
SchM_Enter
0x04
SchM_Exit
0x13
Rte_Send
0x14
Rte_Write
0x15
Rte_Switch
0x16
Rte_Invalidate
0x17
Rte_Feedback
0x18
Rte_SwitchAck
0x19
Rte_Read
0x1A
Rte_DRead
0x1B
Rte_Receive
0x1C
Rte_Call
0x1D
Rte_Result
0x1F
Rte_CData
0x20
Rte_Prm
0x28
Rte_IrvRead
0x29
Rte_IrvWrite
0x2A
Rte_Enter
0x2B
Rte_Exit
0x2C
Rte_Mode
0x30
Rte_IsUpdated
0x70
Rte_Start
0x71
Rte_Stop
0x90
Rte_COMCbkTAck_<sn>
0x91
Rte_COMCbkTErr_<sn>
0x92
Rte_COMCbkInv_<sn>
2015, Vector Informatik GmbH
Version: 4.8.0
34 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

Service ID
Service
0x93
Rte_COMCbkRxTOut_<sn>
0x94
Rte_COMCbkTxTOut_<sn>
0x95
Rte_COMCbk_<sg>
0x96
Rte_COMCbkTAck_<sg>
0x97
Rte_COMCbkTErr_<sg>
0x98
Rte_COMCbkInv_<sg>
0x99
Rte_COMCbkRxTOut_<sg>
0x9A
Rte_COMCbkTxTOut_<sg>
0x9F
Rte_COMCbk_<sn>
0xF0
Rte_Task
0xF1
Rte_IncDisableFlags
0xF2
Rte_DecDisableFlags
Table 3-4 Service IDs
The errors reported to DET are described in the following table:
Error Code
Description
RTE_E_DET_ILLEGAL_NESTED_EX
The same exclusive area was called nested or exclusive
CLUSIVE_AREA
areas were not exited in the reverse order they were
entered
RTE_E_DET_UNINIT
Rte/SchM is not initialized
RTE_E_DET_MODEARGUMENT
Rte_Switch was called with an invalid mode parameter
RTE_E_DET_TRIGGERDISABLECOU Counter of mode disabling triggers is in an invalid state
NTER
RTE_E_DET_TRANSITIONSTATE
Mode machine is in an invalid state
RTE_E_DET_MULTICORE_STARTUP Initialization of the master core before all slave cores
were initialized
RTE_E_DET_ILLEGAL_SIGNAL_ID
RTE callback was called for a signal that is not active in
the current variant.
Table 3-5 Errors reported to DET

The error RTE_E_DET_UNINIT will only be reported if the parameter
DevErrorDetectUninit is enabled. The reporting of all other errors can be enabled by
setting the parameter DevErrorDetect.
2015, Vector Informatik GmbH
Version: 4.8.0
35 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

4  RTE Generation and Integration
This  chapter  gives  necessary  information  about  the  content  of  the  delivery,  the  RTE
generation process including a description about the different RTE generation modes and
finally information how to integrate the MICROSAR RTE into an application environment of
an ECU.
4.1
Scope of Delivery
The delivery of the RTE contains no static RTE code files. The RTE module is completely
generated  by  the  MICROSAR  RTE  Generator. After  the  installation,  the  delivery  has  the
following content:
Files
Description
DVCfgRteGen.exe
Command line MICROSAR RTE generator
(including several DLLs and XML files)
MicrosarRteGen.exe
MICROSAR RTE File generator
Rte.jar
DaVinci Configurator 5 adaptation modules
Settings_Rte.xml
Rte_Bswmd.arxml
BSWMD file for MICROSAR RTE
TechnicalReference_Asr_Rte.pdf
This documentation
ReleaseNotes_MICROSAR_RTE.htm  Release Notes
Table 4-1   Content of Delivery

Info
The RTE Configuration Tool DaVinci Developer is not part of MICROSAR RTE / BSW
  installation package. It has to be installed separately.

2015, Vector Informatik GmbH
Version: 4.8.0
36 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

4.2
RTE Generation
The MICROSAR RTE generator can be called either from the command line application
DVCfgCmd.exe or directly from within the DaVinci Configurator.
4.2.1
Command Line Options
Option
Description
--project <file>
–p <file>
Specifies the absolute path to the DPA project file.
--generate
-g
Generate the given project specified in <file>.
--moduleToGenerate
-m <module> Specifies the module definition references, which
should be generated by the -g switch. Separate
multiple modules by a ','.
E.g. /MICROSAR/Rte, /MICROSAR/Nm
--genArg=”<module>: <params>”
Passes the specified parameters <params> to the
generator of the specified module <module>. For
details of the possible parameters of the RTE module
see Table 4-3.
--help
-h
Displays the general help information of
DVCfgCmd.exe
Table 4-2 DVCfgCmd Command Line Options
4.2.2
RTE Generator Command Line Options
Option
Description
–m <obj>
Selects the DaVinci model object, where <obj> is either
<ECUProjectName> or <ComponentTypeName>.
Note: If –g i or –g c are selected, which accepts both,
<ComponentTypeName> or <ECUProjectName> and the
configuration contains such objects with the same name, the
component type object takes preference over the ECU project.
When the workspace contains only a single ECUProject or a single
ComponentType, the -m parameter can be omitted.
With the –m parameter also multiple component types can be selected,
delimited with semicolons.
–g [r|c|i|h]
Selects generation of the RTE with the following sub options:
r Selects RTE generation for the ECU project specified via option -
m <ECUProjectName>. This is the default option. Therefore –g is
equal to –g r.

2015, Vector Informatik GmbH
Version: 4.8.0
37 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

c Selects RTE contract phase header generation for a single
component type or BSW module if -m
<ComponentTypeName/BswModuleName> or for multiple
component types and BSW modules if –m
<ComponentType1Name/BswModule1Name>;
<ComponentType2Name/BswModule2Name> or for all non-
service component types and BSW modules of an ECU project if
-m <ECUProjectName>.

i Selects implementation template generation for a single
component type if -m <ComponentTypeName> or for multiple
component types if –m
<ComponentType1Name>;<ComponentType2Name> or for all
non- service component types of an ECU project if -m
<ECUProjectName>.
The optional –f <file> parameter specifies the file name to use
for the implementation template file. If the –f <file> parameter
is not given, or –m contains an ECU project name, the filename
defaults to <ComponentTypeName>.c.
Already existing implementation files are updated and a backup is
created.

h Selects VFB trace hook template generation for the ECU project
specified via option -m <ECUProjectName>.
The optional –f <file> parameter specifies the file name to use
for the VFB trace hook template file. If the –f <file> parameter
is not given, the filename defaults to
VFBTraceHook_<ECUProjectName>.c.
Already existing implementation files are updated and a backup is
created.

This parameter can be used more than one time to generate several
modes in one step.
–o <path>
Output path for the generated files.
-o r=<path>
If more than one generation mode is active, a special path can be
-o c=<path>
specified for each generation mode by assigning the path to the
-o i=<path>
character that is used as sub option for the –g parameter.
-o h=<path>
Furthermore the path for the application header files in the RTE
-o s=<path>
generation mode can be selected via option –o s=<path>. By default
-o a=<path>
they are generated into the subdirectory “Components”.
The path for A2L files can be specified with the option –o a=<path>.
These files are generated into the RTE directory by default.
Note: The <path> configured with -o parameter overwrites the path
which is specified in the dpa project file.
–f <file>
Optional parameter to specify the output file name for options –g i
and –g h.
Note: For option –g i the output file name can only be specified if –m
specifies a component type. The output file name cannot be specified
2015, Vector Informatik GmbH
Version: 4.8.0
38 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

when –m specifies multiple component types.
-v
Enables verbose mode which includes help information for error,
warning and info messages.
–h
Displays the general help information.
Table 4-3 RTE Generator Command Line Options
4.2.3
Generation Path
The RTE output files are generated into the path which is either specified within the dpa
project file or which is specified in the –o command line option. If several generation
modes are activated in parallel, for each phase a special path can be specified with the –o
command line option.
In RTE generation phase (command line option –g or –g r), the component type specific
application header files are generated into the subdirectory Components. This
subdirectory can be changed in the RTE generation phase with the option –o
“s=<path>”. In addition the directory for the A2L files, which are generated into the RTE
directory by default, can be specified with the option –o “a=<path>”.
4.3
MICROSAR RTE generation modes
The sections give an overview of the files generated by the MICROSAR RTE generator in
the different RTE generation modes and some examples how the command line call looks
like.
4.3.1
RTE Generation Phase
The following files are generated by the RTE generation: (Option –g or –g r)
File
Description
Rte_<ComponentType>.h
Application header file, which has to be included into the SWC
code. This header file is the only file to be included in the
component code. It is generated to the Components subdirectory
by default.
Rte_<ComponentType>_Type.h Application type header file. This header file contains SWC specific
type definitions. It is generated to the Components subdirectory
by default.
SchM_<BswModule>.h
Module interlink header file, which has to be included into the BSW
module code.
SchM_<BswModule>_Type.h
Module interlink types header file. This header file contains BSW
module specific type definitions.
<ComponentType>_MemMap.h Template contains SWC specific part of the memory mapping. It is
generated to the Components subdirectory by default.
Rte.c
Generated RTE
Rte_<OsApplication>.c
OsApplication specific part of the generated RTE (only generated

when OsApplications are configured)
Rte_PBCfg.c
The RTE post build data set configuration file contains the data
structures for the postbuild RTE initialization.
Rte.h
RTE internal declarations
2015, Vector Informatik GmbH
Version: 4.8.0
39 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

Rte_Main.h
Header file for RTE lifecycle API
Rte_Cfg.h
Configuration file for the RTE
Rte_Cbk.h
Contains prototypes for COM callbacks
Rte_Hook.h
Contains relevant information for VFB tracing
Rte_Type.h
Contains the application defined data type definitions and RTE
internal data types
Rte_DataHandleType.h
The RTE data handle types header file contains the data handle

type declarations required for the component data structures.
Rte_PBCfg.h
The RTE post build data set configuration header contains the
declarations for the data structures that are used for the postbuild
RTE initialization.
Rte_UserTypes.h
Template which is generated if either user defined data types are
required for Per-Instance memory or if a data type is used by the
RTE but generation is skipped with the typeEmitter attribute.
Rte_MemMap.h
Template contains RTE specific part of the memory mapping
Rte_Compiler_Cfg.h
Template contains RTE specific part of the compiler abstraction
usrostyp.h
Template which is only generated if memory protection support is
enabled. In that case this file is included by the MICROSAR OS.
Rte.oil
OS configuration for the RTE
Rte_Needs.ecuc.arxml
Contains the RTE requirements on BSW module configuration for
Os, Com and NvM.
Rte.a2l
A2L file containing CHARACTERISTIC and MEASUREMENT

objects for the generated RTE
Rte_MemSeg.a2l
A2L file containing MEMORY_SEGMENT objects for the
generated RTE
Rte_rules.mak,
Make files according to the AUTOSAR make environment proposal
Rte_defs.mak,
are generated into the mak subdirectory.
Rte_check.mak,
Rte_cfg.mak
Rte.html
Contains information about RAM / CONST consumption of the
generated RTE as well as a listing of all triggers and their OS
events and alarms.
Table 4-4   Generated Files of RTE Generation Phase

Example:

DVCfgCmd -p "InteriorLight.dpa" –m /MICROSAR/Rte –g
2015, Vector Informatik GmbH
Version: 4.8.0
40 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

4.3.2
RTE Contract Phase Generation
The following files are generated by the RTE contract phase generation: (Option –g c)
File
Description
Rte_<ComponentType>.h
Application header file, which must be included into the SWC
code. This header file is the only file to be included in the
component code.
Rte_<ComponentType>_Type.h Application type header file. This header file contains SWC specific
type definitions.
<ComponentType>_MemMap.h Template contains SWC specific part of the memory mapping.
Rte.h
RTE internal declarations
Rte_Type.h
Contains the application defined data type definitions and RTE
internal data types
Rte_DataHandleType.h
The RTE data handle types header file contains the data handle
type declarations required for the component data structures.
Rte_UserTypes.h
Template which is generated if either user defined data types are
required for Per-Instance memory or if a data type is used by the
RTE but generation is skipped with the typeEmitter attribute.
Rte_MemMap.h
Template contains RTE specific part of the memory mapping
Rte_Compiler_Cfg.h
Template contains RTE specific part of the compiler abstraction
SchM_<BswModule>.h
Module interlink header file, which has to be included into the BSW
module code.
SchM_<BswModule>_Type.h
Module interlink types header file. This header file contains BSW
module specific type definitions.
Table 4-5 Generated Files of RTE Contract Phase

Example:

DVCfgCmd -p "InteriorLight.dpa"
 -m /MICROSAR/Rte
 –g
 --genArg=”Rte: -g c –m SenderComponent”

The generated header files are located in a component type specific subdirectory. The
application header file must be included in each source file of a SWC implementation,
where the RTE API for that specific SWC type is used.
The application header file created in the RTE contract phase can be used to compile
object code components, which can be linked to an RTE generated in the RTE generation
phase. The application header files are generated in RTE compatibility mode.

Caution
During the RTE generation phase an optimized header file is generated. This optimized
 header file should be used when compiling the source code SWCs during the ECU
build process.
2015, Vector Informatik GmbH
Version: 4.8.0
41 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

The usage of object code SWCs, which are compiled with the application header files
of the contract phase, require an “Implementation Code Type” for SWCs set to “object
code” in order to tell the RTE generator in the RTE generation phase NOT to create
optimized RTE API accesses but compatible ones.
2015, Vector Informatik GmbH
Version: 4.8.0
42 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

4.3.3
Template Code Generation for Application Software Components
The following file is generated by the implementation template generation: (Option –g i)
File
Description
<FileName>.c
An implementation template is generated if the –g i option is
selected. The –f option specifies the name of the generated c file.
If no name is selected the default name <ComponentTypeName>.c
is used.
Table 4-6 Generated Files of RTE Template Code Generation

Example:

DVCfgCmd -p "InteriorLight.dpa"
 –m /MICROSAR/Rte
 –g
 --genArg=”Rte: -g i –m SenderComponent -f Component1.c”

The generated template files contain all empty bodies of the runnable entities for the
selected component type. It also contains the include directive for the application header
file. In addition, the available RTE API calls are included in comments.

Caution
When the destination file of the SWC template code generation is already available,
 code that is placed within the user code sections marked by “DO NOT CHANGE”-
comments is transferred unchanged to the updated template file.
Additionally, a numbered backup of the original file is made before the new file is
written.
The preservation of runnable code is done by checking for the runnable symbol. This
implies that after a change of the name of a runnable the runnable implementation is
preserved, while a change of the symbol results in a new empty function for the
runnable.
Code that was removed during an update is kept in the “removed code” section at the
bottom of the implementation file and in the numbered backups.
The template update is particularly useful when e.g. access to some interfaces has
been added or removed from a runnable, because then the information of available
APIs is updated by the generation process without destroying the implementation.

2015, Vector Informatik GmbH
Version: 4.8.0
43 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

4.3.4
VFB Trace Hook Template Code Generation
The following file is generated by the VFB trace hook template generation: (Option –g h)
File
Description
<FileName>.c
An implementation template of the VFB trace hooks is generated if
the –g h option is selected. The –f option specifies the name of
the generated c file. If no name is selected the default name
VFBTraceHook_< ECUProjectName >.c is used.
Table 4-7 Generated Files of VFB Trace Hook Code Generation
Example:

DVCfgCmd -p "InteriorLight.dpa"
 –m /MICROSAR/Rte
 –g
 --genArg=”Rte: -g h –f VFBTraceHook_myEcu.c”

Caution
When the destination file of the VFB trace hook template generation is already
 available, code that is placed within the user code sections marked by “DO NOT
CHANGE” comments is transferred unchanged to the updated template file.
Additionally, a numbered backup of the original file is made before the new file is
written.
The preservation of trace hook code is done by checking for the trace hook name.
When the name of a hook changes, e.g. because the name of a data element
changed, then the code of the previous trace hook is removed.
Code that was removed during an update is kept in the “removed code” section at the
bottom of the implementation file and in the numbered backups.
The template update is particularly useful when some trace hooks have been added or
removed due to changed interfaces or OS usage.

2015, Vector Informatik GmbH
Version: 4.8.0
44 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

4.4
Include Structure
4.4.1
RTE Include Structure
class RTE Include Structure
Legend
Generated RTE C File
Generated RTE Header Files
Com.h
Rte_Cbk.h
Header Files of other Modules
Xcp.h
SchM_<Bsw>.h
«include»
«include»
«include»
«include»
Os.h
«include»
«include» «include»
«include»
Rte_<Swc>.h
«include»
Ioc.h
«include»
«include»
Rte.c
«include»
«include»
SchM_<Bsw>_Type.h
«include»
«include»
«include»
Rte_<Swc>_Type.h
<Swc>_MemMap.h
«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
Rte_Type.h
Rte_Hook.h
«include»
«include»
Rte_DataHandleType.h
«include»
«include»
«include»
«include»
«include»
MemMap.h
Rte_Main.h
Rte.h
Rte_Cfg.h
«include»
«include»
Rte_MemMap.h
«include»
«include»
«include»
«include»
Rte_PBCfg.h
«include»
Det.h
Std_Types.h
Rte_UserTypes.h
«include»
«include»
Platform_Types.h
Compiler_Cfg.h
Compiler.h
«include»
«include»
Rte_Compiler_Cfg.h

Figure 4-1 RTE Include Structure

2015, Vector Informatik GmbH
Version: 4.8.0
45 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

4.4.2
SWC Include Structure
The following figure shows the include structure of a SWC with respect to the RTE
dependency. All other header files which might be included by the SWC are not shown.
class Sw c Include Structure
Legend
User SWC Implementation File(s)
Generated RTE Header Files
Header Files of other Modules
<Swc>.c
1..*
«include»
Rte_<Swc>.h
Com.h
«include»
«include»
«include»
<Swc>_MemMap.h
Rte_<Swc>_Type.h
«include»
Rte_DataHandleType.h
«include»
«include»
«include»
Rte_Type.h
Rte_MemMap.h
«include»
«include»
«include»
MemMap.h
Rte.h
Rte_UserTypes.h
«include»

Figure 4-2 SWC Include Structure

2015, Vector Informatik GmbH
Version: 4.8.0
46 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

4.4.3
BSW Include Structure
The following figure shows the include structure of a BSW module with respect to the
SchM dependency. All other header files which might be included by the BSW module are
not shown.
class Bsw Include Structure
Legend
BSW Module File(s)
Generated RTE Header Files
Header Files of other Modules
<Bsw>.c
1..*
«include»
SchM_<Bsw>.h
«include»
«include»
Os.h
SchM_<Bsw>_Type.h
«include»
Rte_PBCfg.h
«include»
«include»
Rte.h
Rte_Type.h

Figure 4-3 BSW Include Structure

2015, Vector Informatik GmbH
Version: 4.8.0
47 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

4.5
Compiler Abstraction and Memory Mapping
The objects (e.g. variables, functions, constants) are declared by compiler independent
definitions – the compiler abstraction definitions. Each compiler abstraction definition is
assigned to a memory section.
The following two tables contain the memory section names and the compiler abstraction
definitions defined for the RTE and illustrate their assignment among each other.
Compiler Abstraction
Definitions

E

A
R
T

T I
OD
A
A
T I
NI

C
V
D

_
_
_

NI
T
O_
I
k>
l>

L
L
L

R
T
T I
N

c

a
E
P
P
P
C
P
P
P

A

O_
I
lo
l>
T
R
E
N
OI
R
Z
T
N
m>
a
T

OD
A
A
A
A
A
_
I
I
N
_
N
_
OI
_
mB
T
S
T_<
E
C
>_
>
>_
V
D

ZE

_
_
_
_
R
I_ R N_ R <Pi_ a <C_ S
S
E
L
L
L
R
A
A
A
R
ON
OD
V
R
V
R
V
R
v
R
C
C
P
P
P
Memory Mapping
A
A
A
A
N
A
ON
ON
OD
P
P
P
V_ >_ V_ >_ V_ >_ V_ <_ V_ C_ >_ C_ C_ >_ A_ <SWC_ <SWC_ <SWC_ A_ A_
Sections
TE
TE
TE
TE
TE
TE
TE
TE
TE
TE
TE
TE
TE
TE
TE
R
<Swc
R
<Swc
R
<Swc
R
R
R
R
<Swc
R
R
<Swc
R
R
R
R
R
R
RTE_START_SEC_VAR_ZERO_INIT_8BIT

RTE_STOP_SEC_VAR_ZERO_INIT_8BIT
RTE_START_SEC_VAR_ZERO_INIT_UNSPECIFIED

RTE_STOP_SEC_VAR_ZERO_INIT_UNSPECIFIED
RTE_START_SEC_VAR_<OsAppl>_ZERO_INIT_UNSPECIFIED1 
RTE_STOP_SEC_VAR_<OsAppl>_ZERO_INIT_UNSPECIFIED1
<Swc>_START_SEC_VAR_ZERO_INIT_UNSPECIFIED
 
<Swc>_STOP_SEC_VAR_ZERO_INIT_UNSPECIFIED
RTE_START_SEC_VAR_INIT_UNSPECIFIED
 
RTE_STOP_SEC_VAR_INIT_UNSPECIFIED
RTE_START_SEC_VAR_<OsAppl>_INIT_UNSPECIFIED1
 
RTE_STOP_SEC_VAR_<OsAppl>_INIT_UNSPECIFIED1
<Swc>_START_SEC_VAR_INIT_UNSPECIFIED
 
<Swc>_STOP_SEC_VAR_INIT_UNSPECIFIED
RTE_START_SEC_VAR_NOINIT_UNSPECIFIED
 
RTE_STOP_SEC_VAR_NOINIT_UNSPECIFIED
RTE_START_SEC_VAR_<OsAppl>_NOINIT_UNSPECIFIED1
 
RTE_STOP_SEC_VAR_<OsAppl>_NOINIT_UNSPECIFIED1
<Swc>_START_SEC_VAR_NOINIT_UNSPECIFIED
 
<Swc>_STOP_SEC_VAR_NOINIT_UNSPECIFIED
RTE_START_SEC_VAR_<Pim>_UNSPECIFIED
 
RTE_STOP_SEC_VAR_<Pim>_UNSPECIFIED
RTE_START_SEC_<NvRamBlock>
 
RTE_STOP_SEC_<NvRamBlock>
RTE_START_SEC_VAR_<Cal>_UNSPECIFIED
 
RTE_STOP_SEC_VAR_<Cal>_UNSPECIFIED
RTE_START_SEC_CONST_UNSPECIFIED
 
RTE_STOP_SEC_CONST_UNSPECIFIED
<Swc>_START_SEC_CONST_UNSPECIFIED
 
<Swc>_STOP_SEC_CONST_UNSPECIFIED

1 This memory mapping sections are only used if memory protection support is enabled
2015, Vector Informatik GmbH
Version: 4.8.0
48 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

RTE_START_SEC_CONST_<Cal>_UNSPECIFIED
 
RTE_STOP_SEC_CONST_<Cal>_UNSPECIFIED
RTE_START_SEC_CODE
 
RTE_STOP_SEC_CODE
<Swc>_START_SEC_CODE
 
<Swc>_STOP_SEC_CODE
RTE_START_SEC_APPL_CODE
 
RTE_STOP_SEC_APPL_CODE
Table 4-8 Compiler abstraction and memory mapping
Compiler Abstraction E
Definitions HC

A
E

H
OC
E
C
N
H
A

_
C
TI
A
OC
N

NI
OC
_
N
TI

O_
_
R
T
N
I
N
OI

ZE_
I_
N_
R
R
R
Memory Mapping
A
A
A
V_
V_
V_
Sections
TE
TE
TE
R
R
R
RTE_START_SEC_VAR_NOCACHE_ZERO_INIT_8BIT


RTE_STOP_SEC_VAR_NOCACHE_ZERO_INIT_8BIT
RTE_START_SEC_VAR_NOCACHE_ZERO_INIT_UNSPECIFIED


RTE_STOP_SEC_VAR_NOCACHE_ZERO_INIT_UNSPECIFIED
RTE_START_SEC_VAR_<OsAppl>_NOCACHE_ZERO_INIT_UNSPECIFIED


RTE_STOP_SEC_VAR_<OsAppl>_NOCACHE_ZERO_INIT_UNSPECIFIED
RTE_START_SEC_VAR_NOCACHE_INIT_UNSPECIFIED


RTE_STOP_SEC_VAR_NOCACHE_INIT_UNSPECIFIED
RTE_START_SEC_VAR_<OsAppl>_NOCACHE_INIT_UNSPECIFIED


RTE_STOP_SEC_VAR_<OsAppl>_NOCACHE_INIT_UNSPECIFIED
RTE_START_SEC_VAR_NOCACHE_NOINIT_UNSPECIFIED


RTE_STOP_SEC_VAR_NOCACHE_NOINIT_UNSPECIFIED
RTE_START_SEC_VAR_<OsAppl>_NOCACHE_NOINIT_UNSPECIFIED


RTE_STOP_SEC_VAR_<OsAppl>_NOCACHE_NOINIT_UNSPECIFIED
Table 4-9 Compiler abstraction and memory mapping for non-cacheable variables
The memory mapping sections and compiler abstraction defines specified in Table 4-9 are
only used for variables which are shared between different cores on multicore systems.
These variables must be linked into non-cacheable memory.
The RTE specific parts of Compiler_Cfg.h and MemMap.h depend on the configuration
of the RTE. Therefore the MICROSAR RTE generates templates for the following files:
 Rte_Compiler_Cfg.h
 Rte_MemMap.h
They can be included into the common files and should be adjusted by the integrator like
the common files too.
2015, Vector Informatik GmbH
Version: 4.8.0
49 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

4.5.1
Memory Sections for Calibration Parameters and Per-Instance Memory
The variable part of the memory abstraction defines for calibration parameters <Cal> and
Per-Instance Memory <Pim> depends on the configuration. The following table shows the
attributes, which have to be defined in DaVinci Developer in order to assign a calibration
parameter or a Per-Instance Memory to one of the configured groups. The groups
represented by the enumeration values of the attributes can be configured in the attribute
definition dialog in DaVinci Developer without any naming restrictions. Only the name of
the attribute itself is predefined as described in the table below.
Object Type
Attribute Name
Attribute Type
Calibration Parameter
PAR_GROUP_CAL
Enumeration
Calibration Element Prototype PAR_GROUP_EL
Enumeration
Per-Instance Memory
PAR_GROUP_PIM
Enumeration
NvBlockDataPrototype
PAR_GROUP_NVRAM
Enumeration

Details of configuration and usage of User-defined attributes can be found in the DaVinci
Online Help [19].
Example for Calibration Parameters:
If the attribute PAR_GROUP_CAL contains e.g. the enumeration values CalGroupA and
CalGroupB and calibration parameters are assigned to those groups, the RTE generator
will create the following memory mapping defines:
RTE_START_SEC_CONST_CalGroupA_UNSPECIFIED
RTE_STOP_SEC_CONST_CalGroupA_UNSPECIFIED
RTE_START_SEC_CONST_CalGroupB_UNSPECIFIED
RTE_STOP_SEC_CONST_CalGroupB_UNSPECIFIED

In addition the following memory mapping defines are generated, if the calibration method
Initialized RAM is enabled (see also Chapter 6.6):
RTE_START_SEC_VAR_CalGroupA_UNSPECIFIED
RTE_STOP_SEC_VAR_CalGroupA_UNSPECIFIED
RTE_START_SEC_VAR_CalGroupB_UNSPECIFIED
RTE_STOP_SEC_VAR_CalGroupB_UNSPECIFIED

2015, Vector Informatik GmbH
Version: 4.8.0
50 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

Example for Per-Instance Memory:
If the attribute PAR_GROUP_PIM contains e.g. the enumeration values PimGroupA and
PimGroupB and Per-Instance Memory is assigned to those group, the RTE generator will
create the following memory mapping defines:
RTE_START_SEC_VAR_PimGroupA_UNSPECIFIED
RTE_STOP_SEC_VAR_PimGroupA_UNSPECIFIED
RTE_START_SEC_VAR_PimGroupB_UNSPECIFIED
RTE_STOP_SEC_VAR_PimGroupB_UNSPECIFIED
4.5.2
Memory Sections for Software Components
The MICROSAR RTE generator generates specific memory mapping defines for each
SWC type which allows to locate SWC specific code, constants and variables in different
memory segments.
The variable part <Swc> is the camel case software component type name. The RTE
implementation template code generator (command line option –g i) uses the SWC
specific sections to locate the runnable entities in the appropriate memory section.
The SWC type specific parts of MemMap.h depend on the configuration. The MICROSAR
RTE generator creates a template for each SWC according the following naming rule:
 <Swc>_MemMap.h
2015, Vector Informatik GmbH
Version: 4.8.0
51 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

4.5.3
Compiler Abstraction Symbols for Software Components and RTE
The RTE generator uses SWC specific defines for the compiler abstraction.
The following define is used in RTE generated SW-C implementation templates in the
runnable entity function definitions.
<Swc>_CODE

In addition, the following compiler abstraction defines are available for the SWC developer.
They can be used to declare SWC specific function code, constants and variables.
<Swc>_CODE
<Swc>_CONST
<Swc>_VAR_NOINIT
<Swc>_VAR_INIT
<Swc>_VAR_ZERO_INIT

If the user code contains variable definitions, which are passed to the RTE API by
reference in order to be modified by the RTE (e.g. buffers for reading data elements) the
RTE uses the following define to specify the distance to the buffer.
RTE_APPL_VAR (RTE specific)

If the user code contains variable or constant definitions, which are passed to the RTE API
as pure input parameter (e.g. buffers for sending data elements) the RTE uses the
following define to specify the distance to the variable or constant.
RTE_<SWC>_APPL_DATA (SWC specific)
RTE_APPL_DATA (RTE specific)

All these SWC and RTE specific defines for the compiler abstraction might be adapted by
the integrator. The configured distances have to fit with the distances of the buffers and the
code of the application.

Caution
The template files <Swc>_MemMap.h, Rte_MemMap.h and Rte_Compiler_Cfg.h
 have to be adapted by the integrator depending on the used compiler and hardware
platform especially if memory protection is enabled.
When the files are already available during RTE generation, the code that is placed
within the user code sections marked by “DO NOT CHANGE”-comments is transferred
unchanged to the updated template files. The behavior is the same as for template
generation of other files like SWC template generation.
2015, Vector Informatik GmbH
Version: 4.8.0
52 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

4.6
Memory Protection Support
The MICROSAR RTE supports memory protection as an extension to the AUTOSAR RTE
specification. Therefore the memory protection support of the Operating System provides
the  base  functionality.  The  support  is  currently  limited  to  the  Vector  MICROSAR  OS
because the RTE requires read access to the data from all partitions what is not required
by AUTOSAR. Moreover when trusted functions are used, the RTE uses wrapper functions
that are only generated by MICROSAR OS.
4.6.1
Partitioning of SWCs
The partitioning of SWCs to memory areas can be done DaVinci CFG. The partitioning is
based  on  assignment  of  tasks  to  OS  applications,  which  is  part  of  the  OS  configuration
process.
There exists the restriction that all Runnable Entities of a single SWC have to be assigned
to  the  same  OS  application.  This  restriction  and  the  assignment  of  tasks  to  OS
applications  indirectly  assign  SWCs  to  OS  applications.  This  is  the  basis  for  grouping
SWCs  to  different  memory  partitions.  Additional  information  about  memory  protection
configuration can be found in Chapter 6.3.
4.6.2
OS Applications
The operating system supports different scalability classes (SC). Only in SC3 and SC4 the
memory  protection  mechanism  is  available.  Therefore  the  configuration  of  the  required
scalability  class  is  the  first  step  to  enable  memory  partitioning.  The  second  step  is  the
assignment  of  SWCs to  partitions  (OS  applications)  which  is done  by  assigning  tasks  to
OS applications as described above.
The OS supports two types of OS applications:
  Non-Trusted
  Trusted
Non-Trusted OS applications run with enabled memory protection, trusted OS applications
with disabled memory protection.
Both  types  are  supported  by  the  MICROSAR  RTE  and  can  be  selected  in  the  OS
application configuration dialog or directly in the OS configuration tool.
Caution
If no assignment of tasks to OS applications exist memory protection is disabled.


2015, Vector Informatik GmbH
Version: 4.8.0
53 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

4.6.3
Partitioning Architecture
When  memory  protection  is  used,  one  or  more  SWCs  can  be  assigned  to  an  OS
application but it is not allowed to split up a SWC between two or more OS applications.
That means that all runnables of a SWC have to be assigned to tasks, which belong to the
same OS application.  It is the responsibility of the RTE to transfer the data of S/R and the
arguments of C/S port interfaces over the protection boundaries.
Caution
Client-Server invocations implemented as direct function calls should be used inside
  one OS application only.

The MICROSAR RTE itself and the BSW can either run in a trusted OS application or in a
non-trusted OS application. Both architectures are described below.
4.6.3.1
Trusted RTE and BSW
trusted application
trusted application
Non-trusted
application
AUTOSAR
Software
Software
Software
Software
Component
Component
Component
Software
Component
..............
MICROSAR RTE
Service
Component
Communication
Complex
Device Driver
Ecu Abstraction
Operating
System
Basic Software
trusted/non-trusted
application
ECU-Hardware

Figure 4-4  Trusted RTE Partitioning example

This architecture overview assumes that the RTE and the BSW modules that are used by
the  RTE  run  in  one  or  more  trusted  OS  applications.  Application  software  components
(SWC) above the RTE can either be trusted or non-trusted. When this architecture is used,
2015, Vector Informatik GmbH
Version: 4.8.0
54 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

the RTE uses trusted functions so that non-trusted SWCs can access the BSW and SWCs
in  other  OS  applications.  In  this  architecture,  Rte_Start()  has  to  be  called  from  a
trusted task and the Com module needs to run in trusted context, too. The RTE will use the
same OS application as the BSW Scheduler tasks.
An architecture where the BSW modules and the RTE are assigned to a non-trusted OS
application is described in the next chapter.
4.6.3.2
Non-Trusted RTE and BSW
non-trusted
trusted application
Non-trusted
application
application
AUTOSAR
Software
Software
Software
Software
Component
Component
Component
Software
Component
..............
MICROSAR RTE
Service
Component
Communication
Complex
Device Driver
Ecu Abstraction
Operating
System
Basic Software
trusted/non-trusted
application
ECU-Hardware

Figure 4-5  Non-trusted RTE Partitioning example

This architecture overview assumes that the BSW modules below the RTE, as well as the
RTE itself run in a single non-trusted OS application. The SWCs above the RTE can either
be assigned to the same non-trusted OS application as the BSW or they can be assigned
to one or more other non-trusted or trusted OS applications. Every OS application has its
own buffers which are only written by runnables that run in the same OS application. The
RTE does not use trusted functions in this architecture. Therefore it is possible to create a
system where all SWCs and the BSW are assigned to non-trusted OS applications and all
runnables/tasks always run with enabled memory protection.
2015, Vector Informatik GmbH
Version: 4.8.0
55 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

The  non-trusted  RTE  architecture  is  automatically  chosen  when  the  RTE  configuration
fulfills the following criterions:
  The tasks that contain the BSW modules are known by the RTE. This can be achieved
by configuring them as BSW Scheduler tasks (See chapter 6.2).
  All BSW Scheduler tasks are assigned to the same non-trusted OS application (further
referred to as BSW OS Application). It is assumed that this is also the OS application
that initializes the RTE by calling Rte_Start. The application tasks can either be
assigned to the BSW OS Application or to other non-trusted or trusted OS
applications.
  All SWCs with mode provide ports are assigned to the BSW OS Application.
  All SWCs that contain runnables with mode disabling dependencies or mode triggers
are assigned to the BSW OS Application.
  There are no direct client/server calls across OS applications

No special limitations apply to SWCs that are assigned to the same OS application as the
BSW.  Moreover,  the  following  RTE  features  can  also  be  used  by  SWCs  in  other  OS
applications:
  direct or buffered inter-runnable variables
  per-instance memories
  SWC local calibration parameters
  access to calibration software components
  queued and nonqueued intra-ECU sender/receiver communication (when there is only
a single sender partition)
  inter-ECU sender/receiver communication (see also chapter 4.8.1)
  direct client/server calls to runnables within the same OS application
  mapped client/server calls to runnables in the same and different OS applications (see
also chapter 4.8.2)
  reading modes with the Rte_Mode API
  explicit and implicit exclusive areas
2015, Vector Informatik GmbH
Version: 4.8.0
56 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

4.6.4
Conceptual Aspects
For intra OS application communication no additional RTE interaction is required. Special
memory  protection  handling  is  required  only  if  communication  between  different  OS
applications exists. In that case, the RTE has to provide means to transfer data over the
protection boundaries. The only possibility is the usage of trusted function calls inside the
generated RTE code. Those trusted function calls are expensive concerning code usage
and runtime. Therefore the usage of trusted function calls should be minimized if possible.
The  MICROSAR  RTE  generator  uses  trusted  function  calls  only  if  necessary.  In  some
cases the usage of trusted function calls can be avoided by assigning the RTE buffers to
the  appropriate  OS  application.   The  Vector  MICROSAR  OS  only  provides  write  access
protection but doesn’t support read access protection. This behavior is the basis to avoid
trusted function calls, because the writing OS application can be seen as the owner of the
memory buffer. Only a simple assignment of the buffer to the appropriate OS application is
necessary. This also makes it possible to completely avoid trusted function calls when the
“Non-trusted RTE“ architecture (chapter 4.6.3.2) is chosen.
Only if the memory assignment cannot be used, the RTE needs trusted functions to cross
the protection boundaries.
For that purpose, the RTE generator uses the OS application of the BSW Scheduler tasks
as its own OS application, which always needs to be trusted. The trusted functions called
by the RTE are assigned to that trusted OS application. In addition to the communication
between SWCs of different OS applications, there also exists communication between the
COM BSW module and the RTE. Especially the notifications of the COM  are done in an
undefined call context. The MICROSAR RTE assumes that the calls of the COM callbacks
are done from the OS application that contains the BSW Scheduler tasks.
2015, Vector Informatik GmbH
Version: 4.8.0
57 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

4.6.5
Memory Protection Integration Hints
4.6.5.1
Enabling of Memory Protection support
Please make sure that memory protection is enabled by assigning tasks to OS
applications and by selecting scalability class SC3 or SC4 in the OS configuration.
4.6.5.2
Memory mapping in Linker Command File
If memory protection is enabled, the RTE generator creates additional OS application
specific memory sections for variables: In addition, the user has to split up his Per-
Instance Memory (PIM) sections to the different OS applications. These additional memory
sections have to be mapped in the linker command file to the appropriate memory
segments. See OS and compiler / linker manual for details.
The individual memory sections are listed in chapter 4.5.
The standard RTE memory section defines need to be mapped to the same segments as
the BSW.
OS Application specific parts of the RTE implementation are generated to separate
Rte_<OsApplicationName>.c files.
4.6.5.3
OS Configuration extension
In addition to the RTE extensions in the OS configuration which are done automatically by
the RTE generator, the following steps have to be done by the Integrator.
All OS objects, used by BSW modules e.g. ISRs, BSW-Tasks, OS resources, alarms etc.
have to be assigned to an OS application. COM callbacks have to run in the same OS
application as the RTE/BSW Scheduler tasks. Dependent on the implementation of the
COM Stack, the tasks or ISRs, which call the COM callbacks must therefore be assigned
to the right OS application.
In the OS configuration of an SC3 or SC4 OS, the tasks must explicitly allow access by
other OS applications. Due to possible calls of ActivateTask or SetEvent inside RTE
implemented COM callbacks, the accessing BSW OS applications for all application tasks,
which are affected by these calls need to be configured. This is automatically done when
the RTE configuration contains all BSW Scheduler tasks. Otherwise, the configuration
needs to be extended by the integrator.
If the RTE configuration contains not all BSW Scheduler tasks, also the OS application
that sets up the tasks and alarms by calling Rte_Start needs to be configured for the
task and alarm objects in the OS configuration.
This configuration extension has to be done in the OS configuration tool.
2015, Vector Informatik GmbH
Version: 4.8.0
58 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

4.7
Multicore support
Similar  to  the  mapping  of  SWCs  to  partitions  with  different  memory  access  rights,  the
MICROSAR RTE also supports the mapping of  SWCs to partitions on different  cores for
parallel execution.
4.7.1
Partitioning of SWCs
The  mapping  of  SWCs  to  cores  happens  with  the  help  of  OS  Applications  like  in  the
memory protection use case. The user has to assign runnables to tasks and tasks to OS
Applications  in  order  to  map  SWCs  to  partitions.  The  OS  Applications  can  then  be
assigned  to  one  of  the  cores  of  the  ECU.  SWCs  can  only  be  assigned  to  a  single  OS
Application. This means that  all runnables  of a SWC  need to be mapped to tasks within
the same OS Application.
When  two  SWCs  on  different  cores  communicate  with  each  other,  the  RTE  will
automatically apply data consistency mechanisms.
4.7.2
BSW in Multicore Systems
The  MICROSAR  RTE  assumes  that  all  BSW  modules  with  direct  RTE  interaction  (e.g.
COM and NVM) are located in a single BSW OS Application on a single  BSW core. The
only  exceptions  are  BSW  modules  like  OS  and  ECUM  that  need  to  be  available  on  all
cores.  For AUTOSAR4,  the BSW OS Application  is  the  OS Application  that  contains  the
tasks  with  the  schedulable  entities. The  RTE  assumes  that  all  COM  and  NVM  callbacks
are called from this BSW OS Application.
All  RTE  Lifecycle  APIs  (Rte_Start(),  Rte_Stop(),  Rte_InitMemory(),
SchM_Init(), SchM_Deinit()) have to be called on all cores.
Cyclic triggered runnables will start to run as soon as Rte_Start() is called on the BSW
core.
It is recommended to use only a single BSW OS Application per core. The RTE will then
configure  the  access  rights  so  that  Rte_Start()  can  be  called  from  the  core  specific
BSW OS application.

Caution
The RTE will start the scheduling of cyclic triggered runnable entities as soon as
  Rte_Start() is called on the BSW Core. Therefore, Rte_Start() on the BSW core
should only be invoked when the Rte_Start() calls on all other cores finished
execution. This is checked with a DET check.

2015, Vector Informatik GmbH
Version: 4.8.0
59 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

4.7.3
IOC Usage
In multicore systems, the OS provides Inter OS-Application Communicator (IOC) Objects
for  the  communication  between  the  individual  cores.  However,  on  many  systems  the
memory of the different cores can also be accessed without IOCs. This is the case when
the  RTE  variables  that  are  used  for  communication  are  mapped  to  non-cacheable  RAM
and when they can either be accessed atomically or when the accesses are protected with
a spinlock. Moreover in case of memory protection, this is only possible when a variable is
only written by a single partition and when the variable can be read by the other partitions.
The MICROSAR RTE Generator tries to avoid IOCs so that it can use the same variables
for intra and inter partition communication. Moreover spinlocks are only used for variables
that cannot be accessed atomically.
If the RTE variables cannot be mapped to globally readable, shared, non-cacheable RAM
the  usage  of  IOCs  can  be  enforced  with  the  EnforceIoc  parameter  in  the
RteGeneration parameters.

Caution
RTE variables that are mapped to NOCACHE memory sections need to be mapped to
  non-cacheable RAM. See also chapter 4.5.

4.8
BSW Access in Partitioned systems
When  the  SWCs  are  assigned  to  different  OS  Applications,  only  the  SWCs  that  are
assigned  to  the  BSW  OS  Application  can  access  the  BSW  directly.  SWCs  that  are
assigned to other cores or partitions do not always have the required access rights. The
same is true for runnable entities that are directly called by the BSW through client/server
interfaces. The RTE can transparently provide proxy code for such BSW accesses but the
user needs to map the SendSignal proxy and the server runnables to tasks in which they
can be executed.
4.8.1
Inter-ECU Communication
IOCs or additional global RTE variables are automatically inserted by the RTE generator
when data needs to be sent from a partition without BSW to another ECU. This is required
because the COM APIs cannot be called directly in this case.
Instead, the RTE provides a schedulable entitiy  Rte_ComSendSignalProxyPeriodic,
which periodically calls the COM APIs when a partition without BSW transmitted data.
The schedulable entity Rte_ComSendSignalProxyPeriodic should be mapped to the
same task as Com_MainFunctionTx  with a lower position in task so that  it can update
the signals before they are transmitted by COM. Rte_ComSendSignalProxyPeriodic
will be scheduled with the same cycle time as Com_MainFunctionTx. For this, the RTE
generator reads the period from the COM configuration.
For  the  reception  of  signals  no  special  handling  is  required.  The  RTE  will  automatically
forward the received data to the appropriate partition in the COM notifications.

2015, Vector Informatik GmbH
Version: 4.8.0
60 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

4.8.2
Client Server communication
Also client server calls between SWCs in different partitions are possible.
In order to execute the server runnable in another partition, the server runnable needs to
be  mapped  to  a  task.  The  RTE  will  then  make  the  server  arguments  available  in  the
partition of the server runnable, execute the server runnable in the context of its task and
return the results to the calling partition.
Direct  client  server  calls  to  servers  on  other  cores  are  not  possible  because  this  would
enforce that the server is executed in the context of the client core. This would lead to data
consistency problems for RTE APIs that only provide buffer pointers like Rte_Pim(). The
RTE  cannot  use  IOCs  for  these  APIs  because  the  actual  buffer  update  is  done  by  the
application code.
You can instruct the RTE to generate a context switch. You can decide this over the task
mapping of a function trigger.
If you consider RTE calls which originate from the same partition as the server runnable, a
context switch into the task of the server runnable may not be required. Here, doing a task
switch would mean an additional overhead which can be avoided.
Therefore  it  is  also  possible  to  configure  an  additional  server  port  prototype  for  clients
which are local to the server partition. The triggers from both server ports can then trigger
the same server runnable. However, only  the  trigger  from  the  port  that  is  connected
to    foreign  partitions needs  to  be mapped onto  a  task. As  a  consequence,  the  RTE  can
implement calls from partition local clients as efficient direct function calls.
Please take into account, that this is only allowed when the server runnable is not invoked
concurrently  or  marked  as  “can  be  invoked  concurrently”.  In  addition,  you  can  use
Exclusive Areas to protect the runnable against concurrent access problems.

2015, Vector Informatik GmbH
Version: 4.8.0
61 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5 API Description
The RTE API functions used inside the runnable entities are accessible by including the
SWC application header file Rte_<ComponentType>.h.

Info
The following API descriptions contain the direction qualifier IN, OUT and INOUT. They
 are intended as direction information only and shall not be used inside the application
code.

For an interfaces overview please see Figure 2-2.
5.1
Data Type Definition
The MICROSAR RTE has special handling for the implementation data types, which are
defined in Std_Types.h and Platform_Types.h (see [7] and [8] for details). The RTE
generator assumes that these data types are available and therefore skips the generation
of type definitions.
In addition implementation data types where the typeEmitter attribute is set to a value
different to RTE or where the value is not empty the RTE generator also skips generation
of the type definition. In this case the user has to adopt the generated template file
Rte_UserTypes.h which should contain the type definitions for the skipt implementation
data types because the RTE itself needs the type definition.
All other primitive or composite application and implementation data types are generated
by the RTE generator. This includes the data types which are assigned to a SWC by a
definition of an IncludedDataTypeSet.
Floating point data types with double precision may not be used for data elements with
external connectivity, because the MICROSAR COM layer lacks support for 64 bit data
types.
5.1.1
Invalid Value
The MICROSAR RTE provides access to the invalid value of a primitive data type. It can
be accessed with the following macro:
InvalidValue_<DataType>

Caution
Because the macro does not contain the Rte_ prefix, care must be taken not to define
data types conflicting with any other symbols defined by the RTE or the application
 code.

2015, Vector Informatik GmbH
Version: 4.8.0
62 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.1.2
Upper and Lower Limit
The range of the primitive application data types is specified by an upper and a lower limit.
These limits are accessible from the application by using the following macro if the limits
are specified:
<DataType>_LowerLimit
<DataType>_UpperLimit

Caution
Because the macro does not contain the Rte_ prefix, care must be taken not to define
data types conflicting with any other symbols defined by the RTE or the application
 code.

5.1.3
Initial Value
Like the limits also the initial value of an un-queued data element of an S/R port prototype
is accessible from the application:
Rte_InitValue_<PortPrototype>_<DataElementPrototype>

Caution
The initial value of an Inter-Ecu S/R communication might be changed by the post-build
 capabilities of the communication stack. Please note that the macro of the RTE still
provides the original initial value defined at pre-compile time. Please don’t use the
macro if the initial value will be changed in the communication stack at post-build time.

5.2
API Error Status
Most of the RTE APIs provide an error status in the API return code. For easier evaluation
the MICROSAR RTE provides the following status access macros:
Rte_IsInfrastructureError(status)
Rte_HasOverlayedError(status)
Rte_ApplicationError(status)

The macros can be used inside the runnable entities for evaluation of the RTE API return
code. The boolean return code of the Rte_IsInfrastructure and Rte_HasOverlayedError
macros indicate if either the immediate infrastructure error flag (bit 7) or the overlay error
flag (bit 6) is set.
The Rte_ApplicationError macro returns the application errors without overlayed errors.
2015, Vector Informatik GmbH
Version: 4.8.0
63 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.3
Runnable Entities
Runnable entities are configured in DaVinci and must be implemented by the user. DaVinci
features the generation of a template file containing the empty bodies of all runnable
entities that are configured for a specific component type.
5.3.1
<RunnableEntity>

Prototype
void <RunnableEntity> ( [IN Rte_Instance instance] )
{Std_ReturnType|void} <ServerRunnable> ( [IN Rte_Instance instance] {,
IN type [*]inputparam}* {, OUT type *outputparam}* )
Parameter
Instance
Instance handle, used to distinguish between the different instances in
case of multiple instantiation.
Note: This is an optional parameter depending on the configuration of
supportsMultipleInstantiation attribute.
[*]inputparam, *outputparam
Parameters are only present for server runnables, i.e. runnable
entities triggered by an OperationInvokedEvent. Input (IN) parameters
are passed by value (primitive types) or reference (composite and
string types), output (OUT) parameters are always passed by
reference.
Return code
RTE_E_OK
Server runnables return RTE_E_OK for successful operation
execution if an application error is referenced by the operation
prototype. Application errors are defined at the client/server port
interface.
RTE_E_<interf>_<error>
Server runnables may return an application error (in the range of 1 to
63) if the operation execution was not successful. Application errors
are defined at the client/server port interface and are referenced by
the operation prototype.
Existence
If configured in DaVinci.
Functional Description
The user function <RunnableEntity>() is the specific implementation of a runnable entity of a
software component and has to be provided by the user. It is called from the MICROSAR RTE.
The first prototype form with no return value and only the optional instance parameter is valid for the
following trigger conditions:
 TimingEvent: Triggered on expiration of a configured timer.
 DataReceivedEvent: Triggered on reception of a data element.
 DataReceiveErrorEvent: Triggered on reception error of a data element.
 DataSendCompletionEvent: Triggered on successful transmission of a data element.
 ModeSwitchEvent: Triggered on entering or exiting of a mode of a mode declaration group.
 ModeSwitchedAckEvent: Triggered on completion of a mode switch of a mode declaration
group.
 AsynchronousServerCallReturnsEvent: Triggered on finishing of an asynchronous server
2015, Vector Informatik GmbH
Version: 4.8.0
64 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

call. The Rte_Result() API shall be used to get the out parameters of the server call.
The first prototype form is also valid for initialization runnables (Init-Runnables):
  Triggered on startup of the RTE.
The second prototype form is valid for server runnables:
  OperationInvokedEvent: Triggered on invocation of the operation in a C/S port interface
(server runnable). A return value is only present if application errors are referenced by the
implemented operation. The parameter list is directly derived from the configured operation
prototype with the addition of the optional instance parameter.
The configuration of the trigger conditions can be done in the runnable entities tab of the component type
configuration.
Call Context
The call context of server runnables depends on the task mapping. Server runnables mapped to a task
are executed in the context of this task, unmapped server runnables are executed in the context of the
task that invoked the operation. All other runnables are invoked by the RTE in the context of the task the
runnables are mapped to.
Caution
The relative priority of the assigned OS tasks is responsible for the call sequence
  of Init-Runnables. The RTE ensures that the Init-Runnable is called before any
other runnable mapped to the same task, but does not enforce that all Init-
Runnables have been executed before any other runnable is called. To make sure
that all Init-Runnables are executed before any other runnable is called, all Init-
Runnables should be mapped to the task with the highest priority.

Caution
Init runnables are a Vector extension to the AUTOSAR standard and may not be
  supported by other RTE generators.

2015, Vector Informatik GmbH
Version: 4.8.0
65 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.4
SWC Exclusive Areas
5.4.1
Rte_Enter

Prototype
void Rte_Enter_<ExclusiveArea> ( [IN Rte_Instance instance] )
Parameter
Instance
Instance handle, used to distinguish between the different instances in
case of multiple instantiation.
Note: This is an optional parameter depending on the configuration of
supportsMultipleInstantiation attribute.
Return code
-

Existence
This API exists when at least one runnable has configured explicit access
(canEnterExclusiveArea) to an exclusive area of a component.
Functional Description
The function Rte_Enter_<ea>() implements explicit access to the exclusive area. The exclusive
area is defined in the context of a component type and may be accessed by all runnables of that
component, either implicitly or explicitly via this API.
This function is the counterpart of Rte_Exit_<ea>(). Each call to Rte_Enter_<ea>() must be
matched by a call to Rte_Exit_<ea>() in the same runnable entity. One exclusive area must not
be entered more than once at a time, but different exclusive areas may be nested, as long as they
are left in reverse order of entering them.
For restrictions on using exclusive areas with different implementations, see section 3.6.10.
Call Context
This function can be used inside runnable entities.

2015, Vector Informatik GmbH
Version: 4.8.0
66 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.4.2
Rte_Exit

Prototype
void Rte_Exit_<ExclusiveArea> ( [IN Rte_Instance instance] )
Parameter
instance
Instance handle, used to distinguish between the different instances in
case of multiple instantiation.
Note: This is an optional parameter depending on the configuration of
supportsMultipleInstantiation attribute.
Return code
-

Existence
This API exists when at least one runnable has configured explicit access
(canEnterExclusiveArea) to an exclusive area of a component.
Functional Description
The function Rte_Exit_<ea>() implements releasing of an explicit entered exclusive area. The
exclusive area is defined in the context of a component type and may be accessed by all runnables
of that component, either implicitly or explicitly via this API.
This function is the counterpart of Rte_Enter_<ea>(). Each call to Rte_Enter_<ea>() must
be matched by a call to Rte_Exit_<ea>() in the same runnable entity. One exclusive area must
not be entered more than once at a time, but different exclusive areas may be nested, as long as
they are left in reverse order of entering them.
For restrictions on using exclusive areas with different implementations, see section 3.6.10.
Call Context
This function can be used inside runnable entities.
2015, Vector Informatik GmbH
Version: 4.8.0
67 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.5
BSW Exclusive Areas
5.5.1
SchM_Enter

Prototype
void SchM_Enter_<Bsw>_<ExclusiveArea> ( void )
Parameter
-

Return code
-

Existence
This API exists when at least one schedulable entity has configured access
(canEnterExclusiveArea) to an exclusive area in the internal behavior of the BSW module
description.
Functional Description
The function SchM_Enter_<bsw>_<ea>() implements access to the exclusive area. The
exclusive area is defined in the context of a BSW module and may be accessed by all schedulable
entities of that module via this API.
This function is the counterpart of SchM_Exit_<bsw>_<ea>(). Each call to
SchM_Enter_<bsw>_<ea>() must be matched by a call to SchM_Exit_<bsw>_<ea>() in the
same schedulable entity. One exclusive area must not be entered more than once at a time, but
different exclusive areas may be nested, as long as they are left in reverse order of entering them.
For restrictions on using exclusive areas with different implementation methods, see section 3.6.10.
Call Context
This function can be used inside a schedulable entity in Task or Interrupt context.

2015, Vector Informatik GmbH
Version: 4.8.0
68 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.5.2
SchM_Exit

Prototype
void SchM_Exit_<Bsw>_<ExclusiveArea> ( void )
Parameter
-

Return code
-

Existence
This API exists when at least one schedulable entity has configured access
(canEnterExclusiveArea) to an exclusive area in the internal behavior of the BSW module
description.
Functional Description
The function SchM_Exit_<bsw>_<ea>() implements releasing of the exclusive area. The
exclusive area is defined in the context of a BSW module and may be accessed by all schedulable
entities of that module via this API.
This function is the counterpart of SchM_Enter_<bsw>_<ea>(). Each call to
SchM_Enter_<bsw>_<ea>() must be matched by a call to SchM_Exit_<bsw>_<ea>() in the
same schedulable entity. One exclusive area must not be entered more than once at a time, but
different exclusive areas may be nested, as long as they are left in reverse order of entering them.
For restrictions on using exclusive areas with different implementation methods, see section 3.6.10.
Call Context
This function can be used inside a schedulable entity in Task or Interrupt context.

2015, Vector Informatik GmbH
Version: 4.8.0
69 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.6
Sender-Receiver Communication
5.6.1
Rte_Read

Prototype
Std_ReturnType Rte_Read__<d> ( [IN Rte_Instance instance,] OUT <DataType> *data )
Parameter
instance
Instance handle, used to distinguish between the different
instances in case of multiple instantiation.
Note: This is an optional parameter depending on the
configuration of supportsMultipleInstantiation
attribute.
*data
The output <data> is passed by reference. The <DataType> is
the type, specified at the data element prototype in the SWC
description.
Return code
RTE_E_OK
Data read successfully.
RTE_E_UNCONNECTED
Indicates that the receiver port is not connected.
RTE_E_INVALID
An invalidated signal has been received by the RTE.
RTE_E_MAX_AGE_EXCEEDED
Indicates a timeout, detected by the COM module in case of
inter ECU communication, if an aliveTimeout is specified.
RTE_E_NEVER_RECEIVED
No data received since system start.
RTE_E_SOFT_TRANSFORMER_ERROR An error during transformation occurred which shall be notified
to the SWC but still produces valid data as output.
RTE_E_HARD_TRANSFORMER_ERROR An error during transformation occurred which produces invalid
data as output.
Existence
This API exists, if the runnable entity of a SWC has configured direct (explicit) access in the role
dataReceivePointByArgument for the data element in the DaVinci configuration and the referenced data
element prototype is configured without queued communication (isQueued=false).
Functional Description
The function Rte_Read__<d>() supplies the current value of the data element. This API can be used
for explicit read of S/R data with isQueued=false. After startup Rte_Read provides the initial value.
Call Context
This function can be used inside a runnable entity of an AUTOSAR software component (SWC).

2015, Vector Informatik GmbH
Version: 4.8.0
70 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.6.2
Rte_DRead

Prototype
<DataType> Rte_DRead__<d> ( [IN Rte_Instance instance] )
Parameter
instance
Instance handle, used to distinguish between the different
instances in case of multiple instantiation.
Note: This is an optional parameter depending on the
configuration of supportsMultipleInstantiation
attribute.
Return code
<DataType>
The return value contains the current value of the data element.
The <DataType> is the (primitive) type, specified at the data
element prototype in the SWC description.
Existence
This API exists, if the runnable entity of a SWC has configured direct (explicit) access in the role
dataReceivePointByValue for the data element in the DaVinci configuration and the referenced data
element prototype is configured without queued communication (isQueued=false).
Functional Description
The function Rte_DRead__<d>() supplies the current value of the data element. This API can be used
for explicit read of S/R data with isQueued=false. After startup or if the receiver port is unconnected,
Rte_DRead provides the initial value. The API is only available for primitive data types.
Call Context
This function can be used inside a runnable entity of an AUTOSAR software component (SWC).

2015, Vector Informatik GmbH
Version: 4.8.0
71 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.6.3
Rte_Write

Prototype
Std_ReturnType Rte_Write__<d> ( [IN Rte_Instance instance,] IN <DataType> data )
Std_ReturnType Rte_Write__<d> ( [IN Rte_Instance instance,] IN <DataType> *data )
Parameter
instance
Instance handle, used to distinguish between the different
instances in case of multiple instantiation.
Note: This is an optional parameter depending on the
configuration of supportsMultipleInstantiation
attribute.
data
The input data <data> for primitive data types without string
types is passed by value. The <DataType> is the type, specified
at the data element prototype in the SWC description.
*data
The input data <data> for string types and composite data types
is passed by reference. The <DataType> is the type, specified
at the data element prototype in the SWC description.
Return code
RTE_E_OK
Data passed to communication services successfully.
RTE_E_COM_STOPPED
An infrastructure communication error was detected by the RTE.
RTE_E_SOFT_TRANSFORMER_ERROR An error during transformation occurred which shall be notified
to the SWC but still produces valid data as output.
RTE_E_HARD_TRANSFORMER_ERROR An error during transformation occurred which produces invalid
data as output.
Existence
This API exists, if the runnable entity of a SWC has configured direct (explicit) access to the data element in
the DaVinci configuration and the referenced data element prototype is configured without queued
communication (isQueued=false).
Functional Description
The function Rte_Write__<d>() can be used for explicit transmission of S/R data with
isQueued=false.
Call Context
This function can be used inside a runnable entity of an AUTOSAR software component (SWC).

2015, Vector Informatik GmbH
Version: 4.8.0
72 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.6.4
Rte_Receive

Prototype
Std_ReturnType Rte_Receive__<d> ( [IN Rte_Instance instance,] OUT <DataType> *data, [OUT uint16
*length] )
Parameter
instance
Instance handle, used to distinguish between the different
instances in case of multiple instantiation.
Note: This is an optional parameter depending on the
configuration of supportsMultipleInstantiation
attribute.
*data
The output <data> is passed by reference. The <DataType> is
the type, specified at the data element prototype in the SWC
description.
*length
In case of an array with variable number of elements, the
dynamic length <length> is returned.
Return code
RTE_E_OK
Data read successfully.
RTE_E_UNCONNECTED
Indicates that the receiver port is not connected.
RTE_E_NO_DATA
A non-blocking call returned no data due to an empty receive
queue. No other error occurred.
RTE_E_TIMEOUT
Returned by a blocking call after the timeout has expired. No
data returned and no other error occurred. The argument buffer
is not changed.
RTE_E_LOST_DATA
Indicates that some incoming data has been lost due to an
overflow of the receive queue. This is not an error of the data
returned in the out parameter.
RTE_E_SOFT_TRANSFORMER_ERROR An error during transformation occurred which shall be notified
to the SWC but still produces valid data as output.
RTE_E_HARD_TRANSFORMER_ERROR An error during transformation occurred which produces invalid
data as output.
Existence
This API exists, if the runnable entity of a SWC has configured polling or waiting access to the data element
in the DaVinci configuration and the referenced data element prototype is configured with queued
communication (isQueued=true).
Functional Description
The function Rte_Receive__<d>() supplies the oldest value stored in the reception queue of the data
element. This API can be used for explicit read of S/R data with isQueued=true.
Call Context
This function can be used inside a runnable entity of an AUTOSAR software component (SWC).

2015, Vector Informatik GmbH
Version: 4.8.0
73 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.6.5
Rte_Send

Prototype
Std_ReturnType Rte_Send__<d> ( [IN Rte_Instance instance,] IN <DataType> data )
Std_ReturnType Rte_Send__<d> ( [IN Rte_Instance instance,] IN <DataType> *data, [IN uint16
length] )
Parameter
instance
Instance handle, used to distinguish between the different
instances in case of multiple instantiation.
Note: This is an optional parameter depending on the
configuration of supportsMultipleInstantiation
attribute.
data
The input data <data> for primitive data types without string
types is passed by value. The <DataType> is the type, specified
at the data element prototype in the SWC description.
*data
The input data <data> for string types and composite data types
is passed by reference. The <DataType> is the type, specified
at the data element prototype in the SWC description.
length
In case of an array with variable number of elements, the input
data <length> specifies the dynamic array length.
Return code
RTE_E_OK
Data passed to communication services successfully.
RTE_E_COM_STOPPED
An infrastructure communication error was detected by the RTE.
RTE_E_LIMIT
The submitted data has been discarded because the receiver
queue is full. Relevant only to intra ECU communication.
RTE_E_SOFT_TRANSFORMER_ERROR An error during transformation occurred which shall be notified
to the SWC but still produces valid data as output.
RTE_E_HARD_TRANSFORMER_ERROR An error during transformation occurred which produces invalid
data as output.
Existence
This API exists, if the runnable entity of a SWC has configured access to the data element in the DaVinci
configuration and the referenced data element prototype is configured with queued communication
(isQueued=true).
Functional Description
The function Rte_Send__<d>() can be used for explicit transmission of S/R data with
isQueued=true.
Call Context
This function can be used inside a runnable entity of an AUTOSAR software component (SWC).

2015, Vector Informatik GmbH
Version: 4.8.0
74 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.6.6
Rte_IRead

Prototype
<DataType> Rte_IRead_<r>__<d> ( [IN Rte_Instance instance] )
<DataType> *Rte_IRead_<r>__<d> ( [IN Rte_Instance instance] )
Parameter
Instance
Instance handle, used to distinguish between the different instances in
case of multiple instantiation.
Note: This is an optional parameter depending on the configuration of
supportsMultipleInstantiation attribute.
Return code
<DataType>
The return value contains the buffered data for primitive data types.
<DataType> is the type, specified at the data element prototype in the
SWC description
<DataType> *
The return value contains a reference to the buffered data for string
types and composite data types. <DataType> is the type, specified at
the data element prototype in the SWC description
Existence
This API exists, if the runnable entity of a SWC has configured buffered (implicit) access to the data
element in the DaVinci configuration.
Functional Description
The function Rte_IRead_<r>__<d>() supplies the value of the data element, stored in a
buffer before starting of the runnable entity. This API can be used for buffered (implicit) read of S/R
data with isQueued=false. After startup Rte_IRead provides the initial value.
Call Context
This function can be used inside the runnable <r> of an AUTOSAR software component (SWC).
Usage in other runnables of the same SWC is forbidden!

2015, Vector Informatik GmbH
Version: 4.8.0
75 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.6.7
Rte_IWrite

Prototype
void Rte_IWrite_<r>__<d> ( [IN Rte_Instance instance,] IN <DataType> data )
void Rte_IWrite_<r>__<d> ( [IN Rte_Instance instance,] IN <DataType> *data )
Parameter
instance
Instance handle, used to distinguish between the different instances in
case of multiple instantiation.
Note: This is an optional parameter depending on the configuration of
supportsMultipleInstantiation attribute.
data
The input data <data> for primitive data types without string types is
passed by value. The <DataType> is the type, specified at the data
element prototype in the SWC description.
*data
The input data <data> for string types and composite data types is
passed by reference. The <DataType> is the type, specified at the
data element prototype in the SWC description.
Return code
-

Existence
This API exists, if the runnable entity of a SWC has configured buffered (implicit) access to the data
element in the DaVinci configuration.
Functional Description
The function Rte_IWrite_<r>__<d>() can be used for buffered transmission of S/R data
with isQueued=false. Note, that the actual transmission is performed and therefore visible for
other runnable entities after the runnable entity has been terminated.
Call Context
This function can be used inside the runnable <r> of an AUTOSAR software component (SWC).
Usage in other runnables of the same SWC is forbidden!

Caution
When implicit write access to a data element has been configured for a runnable, the
 runnable has to update the data element at least once during its execution time using
the Rte_IWrite API or writing to the location returned by the Rte_IWriteRef API.
Otherwise, the content of the data element is undefined upon return from the runnable.

2015, Vector Informatik GmbH
Version: 4.8.0
76 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.6.8
Rte_IWriteRef

Prototype
<DataType> *Rte_IWriteRef_<r>__<d> ( [IN Rte_Instance instance] )
Parameter
Instance
Instance handle, used to distinguish between the different instances in
case of multiple instantiation.
Note: This is an optional parameter depending on the configuration of
supportsMultipleInstantiation attribute.
Return code
<DataType> *
The return value contains a reference to the buffered data.
<DataType> is the type, specified at the data element prototype in the
SWC description
Existence
This API exists, if the runnable entity of a SWC has configured buffered (implicit) access to the data
element in the DaVinci configuration.
Functional Description
The function Rte_IWriteRef_<r>__<d>() can be used for buffered transmission of S/R
data with isQueued=false. Note, that the actual transmission is performed and therefore visible
for other runnable entities after the runnable entity has been terminated.
The returned reference can be used by the runnable entity to directly update the corresponding
data elements. This is especially useful for data elements of composite types.
Call Context
This function can be used inside the runnable <r> of an AUTOSAR software component (SWC).
Usage in other runnables of the same SWC is forbidden!

Caution
When implicit write access to a data element has been configured for a runnable, the
 runnable has to update the data element at least once during its execution time using
the Rte_IWrite API or writing to the location returned by the Rte_IWriteRef API.
Otherwise, the content of the data element is undefined upon return from the runnable.

2015, Vector Informatik GmbH
Version: 4.8.0
77 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.6.9
Rte_IStatus

Prototype
Std_ReturnType Rte_IStatus_<r>__<d> ( [IN Rte_Instance instance] )
Parameter
instance
Instance handle, used to distinguish between the different instances in
case of multiple instantiation.
Note: This is an optional parameter depending on the configuration of
supportsMultipleInstantiation attribute.
Return code
RTE_E_OK
Data read successfully.
RTE_E_UNCONNECTED
Indicates that the receiver port is not connected.
RTE_E_INVALID
An invalidated signal has been received by the RTE.
RTE_E_MAX_AGE_EXCEEDED Indicates a timeout, detected by the COM module in case of inter ECU
communication, if an aliveTimeout is specified.
RTE_E_NEVER_RECEIVED
No data received since system start.
Existence
This API exists, if the runnable entity of a SWC has configured buffered (implicit) access to the data
element in the DaVinci configuration and if either
 data element outdated notification (aliveTimeout > 0) or
 data element invalidation is activated for this data element or
 the attribute handleNeverReceived is configured.
Functional Description
The function Rte_IStatus_<r>__<d>() returns the status of the data element which can be read
with Rte_IRead.
Call Context
This function can be used inside the runnable <r> of an AUTOSAR software component (SWC). Usage in
other runnables of the same SWC is forbidden!
2015, Vector Informatik GmbH
Version: 4.8.0
78 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.6.10 Rte_Feedback

Prototype
Std_ReturnType Rte_Feedback__<d> ( [IN Rte_Instance instance] )
Parameter
instance
Instance handle, used to distinguish between the different instances in
case of multiple instantiation.
Note: This is an optional parameter depending on the configuration of
supportsMultipleInstantiation attribute.
Return code
RTE_E_NO_DATA
No data transmitted, when the feedback API was attempted (non-
blocking call only).
RTE_E_UNCONNECTED Indicates that the sender port is not connected.
RTE_E_TIMEOUT
A timeout notiﬁcation was received from COM before any error
notiﬁcation (Inter-ECU only).
RTE_E_COM_STOPPED The last transmission was rejected when either Rte_Send / Rte_Write
API was called and the COM was stopped or an error notiﬁcation from
COM was received before any timeout notiﬁcation (Inter-ECU only).
RTE_E_TRANSMIT_ACK A “transmission acknowledgement” has been received.
Existence
This API exists, if the runnable entity of a SWC has configured explicit access to the data element
in the DaVinci configuration of a runnable entity and in addition the transmission acknowledgement
is enabled at the communication specification. Furthermore, polling or waiting acknowledgment
mode has to be specified for the same data element. If a timeout is specified, timeout monitoring
for waiting acknowledgment access is enabled.
Functional Description
The function Rte_Feedback__<d>() can be used to read the transmission status for explicit
S/R communication. It indicated the status of data, transmitted by Rte_Write() and
Rte_Send() calls. Depending on the configuration, the API can be either blocking or non-blocking.
Call Context
This function can be used inside a runnable entity of an AUTOSAR software component (SWC).

2015, Vector Informatik GmbH
Version: 4.8.0
79 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.6.11 Rte_IsUpdated

Prototype
boolean Rte_IsUpdated__<d> ( [IN Rte_Instance instance] )
Parameter
instance
Instance handle, used to distinguish between the different instances in
case of multiple instantiation.
Note: This is an optional parameter depending on the configuration of
supportsMultipleInstantiation attribute.
Return code
TRUE
Data element has been updated since last read.
FALSE
Data element has not been updated since last read.
Existence
This API exists, if the runnable entity of a SWC has configured explicit access to the data element
in the DaVinci configuration of a runnable entity and in addition the EnableUpdate attribute is
enabled at the communication specification.
Functional Description
The function Rte_IsUpdated__<d>() returns if the data element has been updated since
the last read or not.
Call Context
This function can be used inside a runnable entity of an AUTOSAR software component (SWC).

2015, Vector Informatik GmbH
Version: 4.8.0
80 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.7
Data Element Invalidation
5.7.1
Rte_Invalidate

Prototype
Std_ReturnType Rte_Invalidate__<d> ( [IN Rte_Instance instance] )
Parameter
instance
Instance handle, used to distinguish between the different
instances in case of multiple instantiation.
Note: This is an optional parameter depending on the
configuration of supportsMultipleInstantiation
attribute.
Return code
RTE_E_OK
No error occurred.
RTE_E_COM_STOPPED
The RTE could not perform the operation because the COM
service is currently not available (inter ECU communication
only).
Existence
This API exists, if the runnable entity of a SWC has configured explicit and non-queued access to the data
element in the DaVinci configuration of a runnable entity and in addition the data element invalidation is
enabled at the communication specification (CanInvalidate=true).
Functional Description
The function Rte_Invalidate__<d>() can be used to set the transmission data invalid for explicit
non-queued S/R communication.
Call Context
This function can be used inside a runnable entity of an AUTOSAR software component (SWC).

2015, Vector Informatik GmbH
Version: 4.8.0
81 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.7.2
Rte_IInvalidate

Prototype
void Rte_IInvalidate_<r>__<d> ( [IN Rte_Instance instance] )
Parameter
instance
Instance handle, used to distinguish between the different instances in
case of multiple instantiation.
Note: This is an optional parameter depending on the configuration of
supportsMultipleInstantiation attribute.
Return code
-

Existence
This API exists, if the runnable entity of a SWC has configured buffered (implicit) access to the data
element in the DaVinci configuration of a runnable entity and in addition the data element
invalidation is enabled at the communication specification (CanInvalidate=true).
Functional Description
The function Rte_IInvalidate_<r>__<d>() can be used to set the transmission data
invalid for implicit (buffered) S/R communication.
Call Context
This function can be used inside the runnable <r> of an AUTOSAR software component (SWC).
Usage in other runnables of the same SWC is forbidden!

2015, Vector Informatik GmbH
Version: 4.8.0
82 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.8
Mode Management
5.8.1
Rte_Switch

Prototype
Std_ReturnType Rte_Switch__<m> ( [IN Rte_Instance instance,]
IN Rte_ModeType_<ModeDeclarationGroup> mode )
Parameter
instance
Instance handle, used to distinguish between the different instances in
case of multiple instantiation.
Note: This is an optional parameter depending on the configuration of
supportsMultipleInstantiation attribute.
mode
The next mode. It is of type Rte_ModeType_<m>, where <m> is the
name of the mode declaration group.
Return code
RTE_E_OK
Mode switch trigger passed to the RTE successfully.

RTE_E_LIMIT
The submitted mode switch has been discarded because the mode
queue is full.
Existence
This API exists, if the runnable entity of a SWC has configured access to the mode declaration
group prototype in the DaVinci configuration.
Functional Description
The function Rte_Switch__<m>() can be used to trigger a mode switch of the specified
mode declaration group prototype.
Call Context
This function can be used inside a runnable entity of an AUTOSAR software component (SWC).

2015, Vector Informatik GmbH
Version: 4.8.0
83 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.8.2
Rte_Mode

Prototype
Rte_ModeType_<ModeDeclarationGroup> Rte_Mode__<m> ( [IN Rte_Instance instance] )
Parameter
instance
Instance handle, used to distinguish between the different instances in
case of multiple instantiation.
Note: This is an optional parameter depending on the configuration of
supportsMultipleInstantiation attribute.
Return code
RTE_TRANSITION_<mg> This return code is returned if the mode machine is in a mode
transition.
RTE_MODE_<mg>_<m>
This value is returned if the mode machine is not in a transition.
<m> indicates the currently active mode.
Existence
This API exists, if the runnable entity of a SWC has configured access to the mode declaration
group prototype in the DaVinci configuration and the enhanced Mode API is not active.
Functional Description
The function Rte_Mode__<m>() provides the current mode of a mode declaration group
prototype.
Call Context
This function can be used inside a runnable entity of an AUTOSAR software component (SWC).

2015, Vector Informatik GmbH
Version: 4.8.0
84 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.8.3
Enhanced Rte_Mode

Prototype
Rte_ModeType_<ModeDeclarationGroup> Rte_Mode__<m> ( [IN Rte_Instance instance],
OUT Rte_ModeType_<ModeDeclarationGroup> previousMode,
OUT Rte_ModeType_<ModeDeclarationGroup> nextMode )
Parameter
instance
Instance handle, used to distinguish between the different instances in
case of multiple instantiation.
Note: This is an optional parameter depending on the configuration of
supportsMultipleInstantiation attribute.
previousMode
The previous mode is returned if the mode machine is in a transition.
nextMode
The next mode is returned if the mode machine is in a transition.
Return code
RTE_TRANSITION_<mg> This return code is returned if the mode machine is in a mode
transition.
RTE_MODE_<mg>_<m>
This value is returned if the mode machine is not in a transition.
<m> indicates the currently active mode.
Existence
This API exists, if the runnable entity of a SWC has configured access to the mode declaration
group prototype in the DaVinci configuration and the enhanced Mode API is active.
Functional Description
The function Rte_Mode__<m>() provides the current mode of a mode declaration group
prototype. In addition it provodes the previous mode and the next mode if the mode machine is in
transition.
Call Context
This function can be used inside a runnable entity of an AUTOSAR software component (SWC).

2015, Vector Informatik GmbH
Version: 4.8.0
85 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.8.4
Rte_SwitchAck

Prototype
Std_ReturnType Rte_SwitchAck__<m> ( [IN Rte_Instance instance] )
Parameter
instance
Instance handle, used to distinguish between the different instances in
case of multiple instantiation.
Note: This is an optional parameter depending on the configuration of
supportsMultipleInstantiation attribute.
Return code
RTE_E_NO_DATA
No mode switch triggered, when the switch ack API was attempted
(non-blocking call only).
RTE_E_TIMEOUT
No mode switch processed within the specified timeout time, when the
switch ack API was attempted (blocking call only).
RTE_E_TRANSMIT_ACK The mode switch acknowledgement has been received.
RTE_E_UNCONNECTED Indicates that the mode provide port is not connected.
Existence
This API exists, if the runnable entity of a SWC has configured access to the mode declaration
group prototype in the DaVinci configuration of a runnable entity and in addition the mode switch
acknowledgement is enabled at the mode switch communication specification. Furthermore, polling
or waiting acknowledgment mode has to be specified for the same mode declaration group
prototype. If a timeout is specified, timeout monitoring for waiting acknowledgment access is
enabled.
Functional Description
The function Rte_SwitchAck__<m>() can be used to read the mode switch status of a
specific mode declaration group prototype. It indicated the status of a mode switch, triggered by an
Rte_Switch call. Depending on the configuration, the API can be either blocking or non-blocking.
Call Context
This function can be used inside a runnable entity of an AUTOSAR software component (SWC).

2015, Vector Informatik GmbH
Version: 4.8.0
86 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.9
Inter-Runnable Variables
5.9.1
Rte_IrvRead

Prototype
<DataType> Rte_IrvRead_<r>_<v> ( [IN Rte_Instance instance] )
void Rte_IrvRead_<r>_<v> ([IN Rte_Instance instance,] OUT <DataType> *data)
Parameter
Instance
Instance handle, used to distinguish between the different instances in
case of multiple instantiation.
Note: This is an optional parameter depending on the configuration of
supportsMultipleInstantiation attribute.
*data
The output <data> is passed by reference for composite data types.
The <DataType> is the type of the Inter-Runnable Variable specified in
the SWC description.
Return code
<DataType>
The return value contains the current content of the Inter-Runnable
Variable of primitive data types. The <DataType> is the type of the
Inter-Runnable Variable specified in the SWC description.
Existence
This API exists, if the runnable entity of a SWC has configured direct (explicit) read access to the
Inter-Runnable Variable in the SWC configuration.
Functional Description
The function Rte_IrvRead_<r>_<v>() supplies the current value of the Inter-Runnable Variable.
This API is used to read direct (explicit) Inter-Runnable Variables. After startup Rte_IrvRead
provides the configured initial value.
Call Context
This function can be used inside the runnable <r> of an AUTOSAR software component (SWC).
Usage in other runnables of the same SWC is forbidden!

2015, Vector Informatik GmbH
Version: 4.8.0
87 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.9.2
Rte_IrvWrite

Prototype
void Rte_IrvWrite_<r>_<v> ( [IN Rte_Instance instance,] IN <DataType> data )
void Rte_IrvWrite_<r>_<v> ( [IN Rte_Instance instance,] IN <DataType> *data )
Parameter
instance
Instance handle, used to distinguish between the different instances in
case of multiple instantiation.
Note: This is an optional parameter depending on the configuration of
supportsMultipleInstantiation attribute.
data
The input data <data> is passed by value for primitive data types. The
<DataType> is the type of the Inter-Runnable Variable specified in the
SWC description.
*data
The input data <data> for composite data types is passed by
reference. The <DataType> is the type of the Inter-Runnable Variable
specified in the SWC description.
Return code
-

Existence
This API exists, if the runnable entity of a SWC has configured direct (explicit) write access to the
Inter-Runnable Variable in the SWC configuration.
Functional Description
The function Rte_IrvIWrite_<r>_<v>() can be used for updating direct (explicit) access Inter-
Runnable Variables. The update is performed immediately.
Call Context
This function can be used inside the runnable <r> of an AUTOSAR software component (SWC).
Usage in other runnables of the same SWC is forbidden!

2015, Vector Informatik GmbH
Version: 4.8.0
88 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.9.3
Rte_IrvIRead

Prototype
<DataType> Rte_IrvIRead_<r>_<v> ( [IN Rte_Instance instance] )
<DataType> *Rte_IrvIRead_<r>_<v> ( [IN Rte_Instance instance] )
Parameter
instance
Instance handle, used to distinguish between the different instances in
case of multiple instantiation.
Note: This is an optional parameter depending on the configuration of
supportsMultipleInstantiation attribute.
Return code
<DataType>
The return value contains the buffered content of the Inter-Runnable
Variable for primitive data types. The <DataType> is the type of the
Inter-Runnable Variable specified in the SWC description.
<DataType> *
The return value contains a reference to the buffered content of the
Inter-Runnable Variable for composite data types. The <DataType> is
the type of the Inter-Runnable Variable specified in the SWC
description.
Existence
This API exists, if the runnable entity of a SWC has configured buffered (implicit) read access to the
Inter-Runnable Variable in the SWC configuration.
Functional Description
The function Rte_IrvIRead_<r>_<v>() supplies the value of the Inter-Runnable Variable,
stored in a buffer before the runnable entity is started. This API is used to read the buffered
(implicit) Inter-Runnable Variable. After startup Rte_IrvIRead provides the configured initial
value.
Call Context
This function can be used inside the runnable <r> of an AUTOSAR software component (SWC).
Usage in other runnables of the same SWC is forbidden!

2015, Vector Informatik GmbH
Version: 4.8.0
89 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.9.4
Rte_IrvIWrite

Prototype
void Rte_IrvIWrite_<r>_<v> ( [IN Rte_Instance instance,] IN <DataType> data )
void Rte_IrvIWrite_<r>_<v> ( [IN Rte_Instance instance,] IN <DataType> *data)
Parameter
instance
Instance handle, used to distinguish between the different instances in
case of multiple instantiation.
Note: This is an optional parameter depending on the configuration of
supportsMultipleInstantiation attribute.
data
The input data <data> is passed by value for primitive data types. The
<DataType> is the type of the Inter-Runnable Variable specified in the
SWC description.
*data
The input data <data> is passed by reference for composite data
types. The <DataType> is the type of the Inter-Runnable Variable
specified in the SWC description.
Return code
-

Existence
This API exists, if the runnable entity of a SWC has configured buffered (implicit) write access to
the Inter-Runnable Variable in the SWC configuration.
Functional Description
The function Rte_IrvIWrite_<r>_<v>() can be used for updating buffered (implicit) Inter-
Runnable Variables. Note, that the actual update is performed and therefore visible for other
runnable entities after the runnable entity has been terminated.
Call Context
This function can be used inside the runnable <r> of an AUTOSAR software component (SWC).
Usage in other runnables of the same SWC is forbidden!

Caution
When buffered (implicit) write access to an Inter-Runnable Variable has been
 configured for a runnable, the runnable has to update the Inter-Runnable variable at
least once during its execution time using the Rte_IrvIWrite API. Otherwise, the
content of the Inter-Runnable Variable may become undefined upon return from the
runnable.

2015, Vector Informatik GmbH
Version: 4.8.0
90 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.10 Per-Instance Memory
5.10.1 Rte_Pim

Prototype
<C-type> *Rte_Pim_<n> ( [IN Rte_Instance instance] )
<DataType> *Rte_Pim_<n> ( [IN Rte_Instance instance] )
Parameter
instance
Instance handle, used to distinguish between the different instances in
case of multiple instantiation.
Note: This is an optional parameter depending on the configuration of
supportsMultipleInstantiation attribute.
Return code
<C-Type> *
If the configured data type of the Per-Instance Memory is specified by
any C type string, a reference to the PIM of the C-type is returned.
<DataType> *
If the configured DataType of the Per-Instance Memory is an
AUTOSAR DataType, a reference to the PIM of this AUTOSAR type is
returned. If the data type is known and completely described, the RTE
generator knows the size of the PIM variable and is able to generate
the PIM variables in a specific optimized order.
Existence
This API exists for each specified Per-Instance Memory specified for an AUTOSAR application
SWC.
Functional Description
The function Rte_Pim_<n>() can be used to access Per-Instance Memory. Note: If several
runnable entities have concurrent access to the same Per-Instance Memory, the user has to
protect the accesses by using implicit or explicit exclusive areas.
Call Context
This function can be used inside all runnable entities of the AUTOSAR software component (SWC)
specifying the Per-Instance Memory.

Caution
When the Per–Instance Memory uses no AUTOSAR data type and is also not based
 on a standard data type like e.g. uint8 the RTE generator cannot create the type
definition for this type.
In this case the user has to provide a user header file Rte_UserTypes.h which
should contain the type definitions for the Per-Instance Memory allowing the RTE
generator to allocate the Per-Instance memory.

2015, Vector Informatik GmbH
Version: 4.8.0
91 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.11 Calibration Parameters
5.11.1 Rte_CData

Prototype
<DataType> Rte_CData_<cp> ( [IN Rte_Instance instance] )
<DataType> *Rte_CData_<cp> ( [IN Rte_Instance instance] )
Parameter
instance
Instance handle, used to distinguish between the different instances in
case of multiple instantiation.
Note: This is an optional parameter depending on the configuration of
supportsMultipleInstantiation attribute.
Return code
<DataType>
For primitive data types the return value contains the content of the
calibration parameter. The return value is of type <DataType>, which
is the type of the calibration element prototype.
<DataType> *
For composite data types and string types the return value contains
the reference to the calibration parameter. The return value is of type
<DataType>, which is the type of the calibration element prototype.
Existence
This API exists for each calibration element prototype specified for an AUTOSAR application SWC.
Functional Description
The function Rte_CData_<cp>() can be used to access SWC local calibration parameters.
Depending on the configuration the Rte_CData API returns a SWC type specific (shared) or SWC
instance specific (perInstance) calibration parameter.
Call Context
This function can be used inside all runnable entities of the AUTOSAR software component (SWC)
specifying the calibration parameters.

2015, Vector Informatik GmbH
Version: 4.8.0
92 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.11.2 Rte_Prm

Prototype
<DataType> Rte_Prm__<cp> ( [IN Rte_Instance instance] )
<DataType> *Rte_Prm__<cp> ( [IN Rte_Instance instance] )
Parameter
instance
Instance handle, used to distinguish between the different instances in
case of multiple instantiation.
Note: This is an optional parameter depending on the configuration of
supportsMultipleInstantiation attribute.
Return code
<DataType>
For primitive data types the return value contains the content of the
calibration parameter. The return value is of type <DataType>, which
is the type of the calibration element prototype.
<DataType> *
For composite data types and string types the return value contains
the reference to the calibration parameter. The return value is of type
<DataType>, which is the type of the calibration element prototype.
Existence
This API exists for each calibration element prototype specified for a calibration software
component.
Functional Description
The function Rte_Prm__<cp>() can be used to access the instance specific calibration
element prototypes of a calibration component.
Call Context
This function can be used inside all runnable entities of the AUTOSAR software component (SWC)
specifying access to calibration element prototypes of calibration components via calibration ports.

2015, Vector Informatik GmbH
Version: 4.8.0
93 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.12 Client-Server Communication
5.12.1 Rte_Call

Prototype
Std_ReturnType Rte_Call__<o> ( [IN Rte_Instance instance,] {IN type
[*]inputparam,}* {OUT type *outputparam,}* {INOUT type *inoutputparam,}* )
Parameter
instance
Instance handle, used to distinguish between the different
instances in case of multiple instantiation.
Note: This is an optional parameter depending on the
configuration of supportsMultipleInstantiation
attribute.
[*]inputparam, *outputparam,
The number and type of parameters is determined by the
*inoutputparam,
operation prototype. Input (IN) parameters are passed by value
(primitive types) or reference (composite and string types),
output (OUT) and input-output (INOUT) parameters are always
passed by reference.
Return code
RTE_E_OK
Operation executed successfully.
RTE_E_UNCONNECTED
Indicates that the client port is not connected.
RTE_E_LIMIT
The operation is invoked while a previous invocation has not yet
terminated. Relevant only for asynchronous calls.
RTE_E_COM_STOPPED
An infrastructure communication error was detected by the RTE.
Relevant only to external communication.
RTE_E_TIMEOUT
Returned by a synchronous call after the timeout has expired
and no other error occurred. The arguments are not changed.
RTE_E_<interf>_<error>
Server runnables may return an application error if the operation
execution was not successful. Application errors are defined at
the client/server port interface and are references by the
operation prototype.
RTE_E_SOFT_TRANSFORMER_ERROR An error during transformation occurred which shall be notified
to the SWC but still produces valid data as output.
RTE_E_HARD_TRANSFORMER_ERROR An error during transformation occurred which produces invalid
data as output.
Existence
This API exists, if the runnable entity of a SWC has configured access to the operation prototype in the
DaVinci configuration.
Functional Description
The function Rte_Call__<o>() invokes the server operation <o> with the specified parameters. If
Rte_Call returns with an error, the INOUT and OUT parameters are unchanged.
Call Context
This function can be used inside a runnable entity of an AUTOSAR software component (SWC).

2015, Vector Informatik GmbH
Version: 4.8.0
94 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.12.2 Rte_Result

Prototype
Std_ReturnType Rte_Result__<o> ( [IN Rte_Instance instance,]
{OUT type *outputparam,}* )
Parameter
instance
Instance handle, used to distinguish between the different instances in
case of multiple instantiation.
Note: This is an optional parameter depending on the configuration of
supportsMultipleInstantiation attribute.
*outputparam
The number and type of parameters is determined by the operation
prototype. The output (OUT) parameters are always passed by
reference.
Return code
RTE_E_OK
Operation executed successfully.
RTE_E_UNCONNECTED Indicates that the client port is not connected.
RTE_E_NO_DATA
The result of the asynchronous operation invocation is not available.
Relevant only for non-blocking call.
RTE_E_COM_STOPPED An infrastructure communication error was detected by the RTE.
Relevant only to external communication.
RTE_E_TIMEOUT
The result of the asynchronous operation invocation is not available in
the specified time. Relevant only for blocking call.
RTE_E_<interf>_<error>
Server runnables may return an application error if the operation
execution was not successful. Application errors are defined at the
client/server port interface and are references by the operation
prototype.
Existence
This API exists, if the runnable entity of a SWC has configured polling or waiting access to an
asynchronous invoked operation of a C/S port interface.
Functional Description
The function Rte_Result__<o>() provides the result of asynchronous C/S calls. In case of
a polling call, the API returns the OUT parameters if the result is already available while for
asynchronous calls the API waits until the server runnable has finished the execution or a timeout
occurs.
Call Context
This function can be used inside a runnable entity of an AUTOSAR software component (SWC).

2015, Vector Informatik GmbH
Version: 4.8.0
95 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.13 Indirect API
5.13.1 Rte_Ports

Prototype
Rte_PortHandle__<R/P> Rte_Ports__<P/R> ( [IN Rte_Instance instance] )
Parameter
instance
Instance handle, used to distinguish between the different instances in
case of multiple instantiation.
Note: This is an optional parameter depending on the configuration of
supportsMultipleInstantiation attribute.
Return code
Rte_PortHandle__<R/P> The API returns a pointer to the first port data structure of the port
data structure array.
Existence
This API exists, if the indirect API is configured at the Component Type.
Functional Description
The function Rte_Ports__<R/P> returns an array containing the port data structures of all
require ports indicated by the API extension <R> or provide ports indicated by of the port
interface specified by in order to allow indirect access of the port APIs via the port handle (e.g.
iteration over all ports of the same interface).
Call Context
This function can be used inside a runnable entity of an AUTOSAR software component (SWC).

2015, Vector Informatik GmbH
Version: 4.8.0
96 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.13.2 Rte_NPorts

Prototype
uint8 Rte_NPorts__<P/R> ( [IN Rte_Instance instance] )
Parameter
instance
Instance handle, used to distinguish between the different instances in
case of multiple instantiation.
Note: This is an optional parameter depending on the configuration of
supportsMultipleInstantiation attribute.
Return code
uint8
The API returns the size of the port data structure array provided by
Rte_Ports.
Existence
This API exists, if the indirect API is configured at the component type.
Functional Description
The function Rte_NPorts__<R/P> returns the number of array entries (port data structures)
of all require ports indicated by the API extension <R> or provide ports indicated by of the port
interface specified by .
Call Context
This function can be used inside a runnable entity of an AUTOSAR software component (SWC).
2015, Vector Informatik GmbH
Version: 4.8.0
97 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.13.3 Rte_Port

Prototype
Rte_PortHandle__<R/P> Rte_Port_ ( [IN Rte_Instance instance] )
Parameter
instance
Instance handle, used to distinguish between the different instances in
case of multiple instantiation.
Note: This is an optional parameter depending on the configuration of
supportsMultipleInstantiation attribute.
Return code
Rte_PortHandle__<R/P> The API returns a pointer to a port data structure.
Existence
This API exists, if the indirect API is configured at the component type.
Functional Description
The function Rte_Port_ returns the port data structure of the port specified by . It allows
indirect API access via the port handle.
Call Context
This function can be used inside a runnable entity of an AUTOSAR software component (SWC).

2015, Vector Informatik GmbH
Version: 4.8.0
98 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.14  RTE Lifecycle API
The lifecycle API functions are declared in the RTE lifecycle header file Rte_Main.h
5.14.1  Rte_Start

Prototype
Std_ReturnType Rte_Start ( void )
Parameter
-

Return code
RTE_E_OK
RTE initialized successfully.
RTE_E_LIMIT
An internal limit has been exceeded.
Functional Description
The RTE lifecycle API function Rte_Start allocates and initializes system resources and
communication resources used by the RTE.
Call Context
This function has to be called by the ECU state manager after basic software modules have been
initialized especially OS and COM. It has to be called on every core that is used by the RTE. The
call on the core that contains the BSW will start the triggering of all cyclic runnables. Therefore
Rte_Start on the other cores has to be executed first.

5.14.2  Rte_Stop

Prototype
Std_ReturnType Rte_Stop ( void )
Parameter
-

Return code
RTE_E_OK
RTE initialized successfully.
RTE_E_LIMIT
A resource could not be released.
Functional Description
The RTE lifecycle API function Rte_Stop releases system resources and communication
resources used by the RTE and shutdowns the RTE. After Rte_Stop is called no runnable entity
must be processed.
Call Context
This function has to be called by the ECU state manager on every core that is used by the RTE.
The call on the core that contains the BSW will stop the triggering of the cyclic runnables.

2015, Vector Informatik GmbH
Version: 4.8.0
99 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.14.3  Rte_InitMemory

Prototype
void Rte_InitMemory ( void )
Parameter
-

Return code
-

Functional Description
The API function Rte_InitMemory is a MICROSAR RTE specific extension and should be used
to initialize RTE internal state variables if the compiler does not support initialized variables.
Call Context
This function has to be called before the ECU state manager calls the initialization functions of
other BSW modules especially the AUTOSAR COM module.  It has to be called on all cores that
are used by the RTE.

Caution
Rte_InitMemory API is a Vector extension to the AUTOSAR standard and may not be
  supported by other RTE generators.

2015, Vector Informatik GmbH
Version: 4.8.0
100 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.15 SchM Lifecycle API
The lifecycle API functions are declared in the RTE lifecycle header file Rte_Main.h
5.15.1 SchM_Init

Prototype
void SchM_Init ( [IN SchM_ConfigType ConfigPtr] )
Parameter
ConfigPtr
Pointer to the Rte_Config_<VariantName> data structure that shall be
used for the RTE initialization of the active variant in case of a
postbuild selectable configuration. The parameter is omitted in case
the project contains no postbuild selectable variance.
Return code
-

Functional Description
This function initializes the BSW Scheduler and resets the timers for all cyclic triggered schedulable
entities (main functions). Note that all main functions calls are activated upon return from this
function.
Call Context
This function has to be called by the ECU state manager from task context. The OS has to be
initialized before as well as those BSW modules for which the SchM provides triggering of
schedulable entities (main functions). The API has to be called on all cores that are used by the
RTE.

5.15.2 SchM_Deinit

Prototype
void SchM_Deinit ( void )
Parameter
-

Return code
-

Functional Description
This function finalizes the BSW Scheduler and stops the timer which triggers the main functions.
Call Context
This function has to be called by the ECU state manager from task context. It has to be called on
all cores that are used by the RTE.

2015, Vector Informatik GmbH
Version: 4.8.0
101 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.15.3 SchM_GetVersionInfo

Prototype
void SchM_GetVersionInfo (Std_VersionInfoType *versioninfo )
Parameter
versioninfo
Pointer to where to store the version information of this module.
Return code
-

Existence
This API exists if RteSchMVersionInfoApi is enabled.
Functional Description
SchM_GetVersionInfo() returns version information, vendor ID and AUTOSAR module ID of
the component.
The versions are decimal-coded.
Call Context
The function can be called on interrupt and task level.

2015, Vector Informatik GmbH
Version: 4.8.0
102 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.16 VFB Trace Hooks
The RTE’s “VFB tracing” mechanism allows to trace interactions of the AUTOSAR
software components with the VFB. The choice of events resides with the user and can
range from none to all. The “VFB tracing” functionality is designed to support multiple
clients for each event. If one or multiple clients are specified for an event, the trace
function without client prefix will be generated followed by the trace functions with client
prefixes in alphabetically ascending order.
5.16.1 Rte_[<client>_]<API>Hook_<cts>_<ap>_Start

Prototype
void Rte_[<client>_]<API>Hook_<cts>_<ap>_Start ( [IN const Rte_CDS_<cts>* inst,]
params )
Parameter
Rte_CDS_<cts>* inst
The instance specific pointer of type Rte_CDS_<cts> is used to
distinguish between the different instances in case of multiple
instantiation.
Note: This is an optional parameter depending on the configuration of
supportsMultipleInstantiation attribute.
params
The parameters are the same as the parameters of the <API>. See
the corresponding API description for details.
Return code
-

Existence
This VFB trace hook exists if the global and the hook specific configuration switches are enabled.
Functional Description
This VFB trace hook is called inside the RTE APIs directly after invocation of the API. The user has
to provide this hook function if it is enabled in the configuration. The placeholder <API> represents
one of the following APIs:
Enter, Exit, Write, Read, Send, Receive, Invalidate, SwitchAck, Switch, Call, Result, IrvWrite,
IrvRead
The <AccessPoint> is defined as follows:
 Enter, Exit: <ExclusiveArea>
 Write, Read, Send, Receive, Feedback, Invalidate:
<PortPrototype>_<DataElementPrototype>
 Switch, SwitchAck: <PortPrototype>_<ModeDeclarationGroupPrototype>
 Call, Result: <PortPrototype>_<OperationPrototype>
 IrvWrite, IrvRead: <InterRunnableVariable>
Call Context
This function is called inside the RTE API. The call context is the context of the API itself. Since
APIs can only be called in runnable context, the context of the trace hooks is also the runnable
entity of an AUTOSAR software component (SWC).
2015, Vector Informatik GmbH
Version: 4.8.0
103 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.16.2 Rte_[<client>_]<API>Hook_<cts>_<ap>_Return

Prototype
void Rte_[<client>_]<API>Hook_<cts>_<ap>_Return ( [IN const Rte_CDS_<cts> *inst,]
params )
Parameter
Rte_CDS_<cts>* inst
The instance specific pointer of type Rte_CDS_<cts> is used to
distinguish between the different instances in case of multiple
instantiation.
Note: This is an optional parameter depending on the configuration of
supportsMultipleInstantiation attribute.
params
The parameters are the same as the parameters of the API. See the
corresponding API description for details.
Return code
-

Existence
This VFB trace hook exists if the global and the hook specific configuration switches are enabled.
Functional Description
This VFB trace hook is called inside the RTE APIs directly before leaving the API. The user has to
provide this hook function if it is enabled in the configuration. The placeholder <API> represents
one of the following APIs:
Enter, Exit, Write, Read, Send, Receive, Invalidate, Feedback, Switch, SwitchAck, Call, Result,
IrvWrite, IrvRead
The <AccessPoint> is defined as follows:
 Enter, Exit: <ExclusiveArea>
 Write, Read, Send, Receive, Feedback, Invalidate:
<PortPrototype>_<DataElementPrototype>
 Switch, SwitchAck: <PortPrototype>_<ModeDeclarationGroupPrototype>
 Call, Result: <PortPrototype>_<OperationPrototype>
 IrvWrite, IrvRead: <InterRunnableVariable>
Call Context
This function is called inside the RTE API. The call context is the context of the API itself. Since
APIs can only be called in runnable context, the context of the trace hooks is also the runnable
entity of an AUTOSAR software component (SWC).

Caution
The RTE generator tries to prevent overhead by sometimes implementing the Rte_Call
 API as macro that does a direct runnable invocation. If VFB trace hooks are enabled
for such an Rte_Call API or for the called server runnable, these optimizations are no
longer possible.
Also macro optimizations for Rte_Read, Rte_DRead, Rte_Write, Rte_IrvRead and
Rte_IrvWrite APIs are disabled when VFB tracing for that APIs is enabled.

2015, Vector Informatik GmbH
Version: 4.8.0
104 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

Caution
The RTE does not call VFB trace hooks for the following APIs because they are
 intended to be implemented as macros.
 Implicit S/R APIs: Rte_IWrite, Rte_IWriteRef, Rte_IRead, Rte_IStatus,
Rte_IInvalidate
 Implicit Inter-Runnable Variables: Rte_IrvIWrite, Rte_IrvIRead
 Per-instance Memory and calibration parameter APIs: Rte_Pim, Rte_CData,
Rte_Prm
 Indirect APIs: Rte_Ports, Rte_Port, Rte_NPorts
 RTE Life-Cycle APIs: Rte_Start, Rte_Stop

5.16.3 SchM_[<client>_]<API>Hook_<Bsw>_<ap>_Start

Prototype
void SchM_[<client>_]<API>Hook_<bsw>_<ap>_Start ( params )
Parameter
params
The parameters are the same as the parameters of the <API>. See
the corresponding API description for details.
Return code
-

Existence
This VFB trace hook exists if the global and the hook specific configuration switches are enabled.
Functional Description
This VFB trace hook is called inside the RTE APIs directly after invocation of the API. The user has
to provide this hook function if it is enabled in the configuration. The placeholder <API> represents
one of the following APIs:
Enter, Exit
The <AccessPoint> is defined as follows:
 Enter, Exit: <ExclusiveArea>
Call Context
This function is called inside the RTE API. The call context is the context of the API itself. Since
APIs can be called from a BSW function, the context of the trace hooks depends on the context of
the BSW function.

Caution
The SchM Hook APIs are a Vector extension to the AUTOSAR standard and may not
 be supported by other RTE generators.
2015, Vector Informatik GmbH
Version: 4.8.0
105 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.16.4 SchM_[<client>_]<API>Hook_<Bsw>_<ap>_Return

Prototype
void SchM_[<client>_]<API>Hook_<bsw>_<ap>_Return ( params )
Parameter
params
The parameters are the same as the parameters of the <API>. See
the corresponding API description for details.
Return code
-

Existence
This VFB trace hook exists if the global and the hook specific configuration switches are enabled.
Functional Description
This VFB trace hook is called inside the RTE APIs directly before leaving the API. The user has to
provide this hook function if it is enabled in the configuration. The placeholder <API> represents
one of the following APIs:
Enter, Exit
The <AccessPoint> is defined as follows:
 Enter, Exit: <ExclusiveArea>
Call Context
This function is called inside the RTE API. The call context is the context of the API itself. Since
APIs can be called from a BSW function, the context of the trace hooks depends on the context of
the BSW function.

Caution
The SchM Hook APIs are a Vector extension to the AUTOSAR standard and may not
 be supported by other RTE generators.

2015, Vector Informatik GmbH
Version: 4.8.0
106 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.16.5 Rte_[<client>_]ComHook_<SignalName>_SigTx

Prototype
void Rte_[<client>_]ComHook_<SignalName>_SigTx ( <DataType> *data )
Parameter
<DataType>* data
Pointer to data to be transmitted via the COM API.
Note: <DataType> is the application specific data type of Rte_Send,
Rte_Write or Rte_IWrite.
Return code
-

Existence
This VFB trace hook exists, if at least one data element prototype of a port prototype has to be
transmitted over a network (Inter-Ecu) and the global and the hook specific configuration switches
are enabled.
Functional Description
This hook is called just before the RTE invokes Com_SendSignal or
Com_UpdateShadowSignal.
Call Context
This function is called inside the RTE APIs Rte_Send and Rte_Write. The call context is the
context of the API itself. Since APIs can only be called in runnable context, the context of the trace
hooks is also the runnable entity of an AUTOSAR software component.
If buffered communication (Rte_IWrite) is used, the call context is the task of the mapped
runnable.

2015, Vector Informatik GmbH
Version: 4.8.0
107 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.16.6 Rte_[<client>_]ComHook_<SignalName>_SigIv

Prototype
void Rte_[<client>_]ComHook_<SignalName>_SigIv ( void )
Parameter
-

Return code
-

Existence
This VFB trace hook exists, if at least one data element prototype of a port prototype has to be
transmitted over a network (Inter-Ecu) and the global and the hook specific configuration switches
are enabled. In addition the canInvalidate attribute at the UnqueuedSenderComSpec of the
data element prototype must be enabled.
Functional Description
This hook is called just before the RTE invokes Com_InvalidateSignal.
Call Context
This function is called inside the RTE APIs Rte_Invalidate. The call context is the context of the
API itself. Since APIs can only be called in runnable context, the context of the trace hooks is also
the runnable entity of an AUTOSAR software component.
If buffered communication (Rte_IInvalidate) is used, the call context is the task of the mapped
runnable.

2015, Vector Informatik GmbH
Version: 4.8.0
108 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.16.7 Rte_[<client>_]ComHook_<SignalName>_SigGroupIv

Prototype
void Rte_[<client>_]ComHook_<SignalGroupName>_SigGroupIv ( void )
Parameter
-

Return code
-

Existence
This VFB trace hook exists, if at least one data element prototype of a port prototype is composite
and has to be transmitted over a network (Inter-Ecu) and the global and the hook specific
configuration switches are enabled. In addition the canInvalidate attribute at the
UnqueuedSenderComSpec of the data element prototype must be enabled.
Functional Description
This hook is called just before the RTE invokes Com_InvalidateSignalGroup.
Call Context
This function is called inside the RTE APIs Rte_Invalidate. The call context is the context of the
API itself. Since APIs can only be called in runnable context, the context of the trace hooks is also
the runnable entity of an AUTOSAR software component.
If buffered communication (Rte_IInvalidate) is used, the call context is the task of the mapped
runnable.

2015, Vector Informatik GmbH
Version: 4.8.0
109 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.16.8 Rte_[<client>_]ComHook_<SignalName>_SigRx

Prototype
void Rte_[<client>_]ComHook_<SignalName>_SigRx ( <DataType> *data )
Parameter
<DataType>* data
Pointer to the data received via the COM API.
Note: <DataType> is the application specific data type of
Rte_Receive, Rte_Read, Rte_DRead or Rte_IRead.
Return code
-

Existence
This VFB trace hook exists, if at least one data element prototype of a port prototype has to be
received from a network and the global and hook specific configuration switches are enabled.
Functional Description
This VFB Trace Hook is called after the RTE invokes Com_ReceiveSignal or
Com_ReceiveShadowSignal.
Call Context
This function is called inside the RTE API Rte_Read or Rte_DRead. The call context is the
context of the API itself. Since this API can only be called in runnable context, the context of the
trace hooks is also the runnable entity of an AUTOSAR software component.
If buffered communication (Rte_IRead) is used, the call context is the task of the mapped
runnable.
If queued communication is configured (Rte_Receive), the call of the Com API is called inside the
COM callback after reception. In this case, the context of the trace hook is the context of the COM
callback.
Note: This could be the task context or the interrupt context!

2015, Vector Informatik GmbH
Version: 4.8.0
110 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.16.9 Rte_[<client>_]ComHook<Event>_<SignalName>

Prototype
void Rte_[<client>_]ComHook<Event>_<SignalName> ( void )
Parameter
-

Return code
-

Existence
This VFB trace hook is called inside the <Event> specific COM callback, directly after the
invocation by COM and if the global and the hook specific configuration switches are enabled.
Functional Description
This trace hook indicates the start of a COM callback. <Event> depends on the type of the
callback.
 empty string: Rte_COMCbk_<SignalName>
 TxTOut Rte_COMCbkTxTOut_<SignalName>
 RxTOut Rte_COMCbkRxTOut_<SignalName>
 TAck Rte_COMCbkTAck_<SignalName>
 TErr Rte_COMCbkTErr_<SignalName>
 Inv Rte_COMCbkInv_<SignalName>
Call Context
This function is called inside the context of the COM callback.
Note: This could be the task context or the interrupt context!

2015, Vector Informatik GmbH
Version: 4.8.0
111 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.16.10 Rte_[<client>_]Task_Activate

Prototype
void Rte_[<client>_]Task_Activate ( TaskType task )
Parameter
task
The same parameter is also used to call the OS API ActivateTask
Return code
-

Existence
This VFB trace hook is called by the RTE immediately before the invocation of the OS API
ActivateTask and if the global and the hook specific configuration switches are enabled.
Functional Description
This trace hook indicates the call of ActivateTask of the OS.
Call Context
This function is called inside Rte_Start and in the context RTE API functions which trigger the
execution of a runnable entity where the runnable is mapped to a basic task. For API functions, the
call context is the runnable context.

5.16.11 Rte_[<client>_]Task_Dispatch

Prototype
void Rte_[<client>_]Task_Dispatch ( TaskType task )
Parameter
task
The parameter indicates the task to which was started (dispatched) by
the OS
Return code
-

Existence
This VFB trace hook exists for each configured RTE task and is called directly after the start if the
global and the hook specific configuration switches are enabled.
Functional Description
This trace hook indicates the call activation of a task by the OS.
Call Context
The call context is the task.

2015, Vector Informatik GmbH
Version: 4.8.0
112 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.16.12 Rte_[<client>_]Task_SetEvent

Prototype
void Rte_[<client>_]Task_SetEvent ( TaskType task, EventMaskType event )
Parameter
task
The same parameter is also used to call the OS API SetEvent
event
The same parameter is also used to call the OS API SetEvent
Return code
-

Existence
This VFB trace hook is called by the RTE immediately before the invocation of the OS API
SetEvent and if the global and the hook specific configuration switches are enabled.
Functional Description
This trace hook indicates the call of SetEvent.
Call Context
This function is called inside RTE API functions and in COM callbacks. For API functions, the call
context is the runnable context.
Note: For COM callbacks the context could be the task context or the interrupt context!

5.16.13 Rte_[<client>_]Task_WaitEvent

Prototype
void Rte_[<client>_]Task_WaitEvent ( TaskType task, EventMaskType event )
Parameter
task
The same parameter is also used to call the OS API WaitEvent
event
The same parameter is also used to call the OS API WaitEvent
Return code
-

Existence
This VFB trace hook is called by the RTE immediately before the invocation of the OS API
WaitEvent and if the global and the hook specific configuration switches are enabled.
Functional Description
This trace hook indicates the call of WaitEvent.
Call Context
This function is called inside RTE API functions and in generated task bodies.

2015, Vector Informatik GmbH
Version: 4.8.0
113 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.16.14 Rte_[<client>_]Task_WaitEventRet

Prototype
void Rte_[<client>_]Task_WaitEventRet ( TaskType task, EventMaskType event )
Parameter
task
The same parameter is also used to call the OS API WaitEvent
event
The same parameter is also used to call the OS API WaitEvent
Return code
-

Existence
This VFB trace hook is called by the RTE immediately after returning from the OS API WaitEvent
and if the global and the hook specific configuration switches are enabled.
Functional Description
This trace hook indicates leaving the call of WaitEvent.
Call Context
This function is called inside RTE API functions and in generated task bodies.

5.16.15 Rte_[<client>_]Runnable_<cts>_<re>_Start

Prototype
void Rte_[<client>_]Runnable_<cts>_<re>_Start ( [IN const Rte_CDS_<cts> *inst] )
Parameter
Rte_CDS_<cts>* inst
The instance specific pointer of type Rte_CDS_<cts> is used to
distinguish between the different instances in case of multiple
instantiation.
Note: This is an optional parameter depending on the configuration of
supportsMultipleInstantiation attribute.
Return code
-

Existence
This VFB trace hook is called for all mapped runnable entities if the global and the hook specific
configuration switches are enabled.
Functional Description
This trace hook indicates invocation of the runnable entity. It is called just before the call of the
runnable entity and allows for example measurement of the execution time of a runnable together
with the counterpart Rte_[<client>_]Runnable_<cts>_<re>_Return.
Call Context
This function is called inside RTE generated task bodies.
2015, Vector Informatik GmbH
Version: 4.8.0
114 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.16.16 Rte_[<client>_]Runnable_<cts>_<re>_Return

Prototype
void Rte_[<client>_]Runnable_<cts>_<re>_Return ( [IN const Rte_CDS_<cts> *inst] )
Parameter
Rte_CDS_<cts>* inst
The instance specific pointer of type Rte_CDS_<cts> is used to
distinguish between the different instances in case of multiple
instantiation.
Note: This is an optional parameter depending on the configuration of
supportsMultipleInstantiation attribute.
Return code
-

Existence
This VFB trace hook is called for all mapped runnable entities if the global and the hook specific
configuration switches are enabled.
Functional Description
This trace hook indicates invocation of the runnable entity. It is called just after the call of the
runnable entity and allows for example measurement of the execution time of a runnable together
with the counterpart Rte_[<client>_]Runnable_<cts>_<re>_Start.
Call Context
This function is called inside RTE generated task bodies.

2015, Vector Informatik GmbH
Version: 4.8.0
115 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.17  RTE Interfaces to BSW
The RTE has standardized Interfaces to the following basic software modules
  COM / LDCOM
  NVM
  DET
  OS
  XCP
  SCHM
The actual used API’s of these BSW modules depend on the configuration of the RTE.
5.17.1  Interface to COM / LDCOM
Used COM API
Com_SendSignal
Com_SendDynSignal
Com_SendSignalGroup
Com_UpdateShadowSignal
Com_ReceiveSignal
Com_ReceiveDynSignal
Com_ReceiveSignalGroup
Com_ReceiveShadowSignal
Com_InvalidateSignal
Com_InvalidateSignalGroup

Used LDCOM API
LdCom_IfTransmit

The RTE generator provides COM / LDCOM callback functions for signal notifications. The
generated callbacks, which are called inside the COM layer, have to be configured in the
COM  /  LDCOM  configuration  accordingly.  The  necessary  callbacks  are  defined  in  the
Rte_Cbk.h header file.

Caution
The RTE generator assumes that the context of COM / LDCOM callbacks is either a
  task context or an interrupt context of category 2.
It is explicitly NOT allowed that the call context of a COM / LDCOM callback is an
interrupt of category 1.

In  order  to  access  the  COM  /  LDCOM  API  the  generated  RTE  includes  the
Com.h/LdCom.h header file if necessary.
During  export  of  the  ECU  configuration  description  the  necessary  COM  /  LDCOM
callbacks  are  exported  into  the  COM    /  LDCOM  section  of  the  ECU  configuration
description.
2015, Vector Informatik GmbH
Version: 4.8.0
116 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.17.2  Interface to OS
In  general,  the  RTE  may  use  all  available  OS  API  functions  to  provide  the  RTE
functionality  to  the  software  components. The  following  table  contains  a  list  of  used  OS
APIs of the current RTE implementation.
Used OS API
SetRelAlarm
CancelAlarm
StartScheduleTableRel
NextScheduleTable
StopScheduleTable
SetEvent
GetEvent
ClearEvent
WaitEvent
GetTaskID
GetCoreID
ActivateTask
Schedule
TerminateTask
ChainTask
GetResource
ReleaseResource
GetSpinlock
ReleaseSpinlock
DisableAllInterrupts
EnableAllInterrupts
SuspendAllInterrupts
ResumeAllInterrupts
SuspendOSInterrupts
ResumeOSInterrupts
CallTrustedFunction (MICROSAR OS specific)
IocWrite
IocRead
IocWriteGroup
IocReadGroup
IocSend
IocReceive

In order to access the OS API the generated RTE includes the Os.h header file.
2015, Vector Informatik GmbH
Version: 4.8.0
117 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

The OS configuration needed by the RTE is stored in the file  Rte_Needs.ecuc.arxml
which is created during the RTE Generation Phase.
For  legacy  systems  the  OS  configuration  is  also  stored  in  Rte.oil.  This  file  is  an
incomplete OIL file and contains only the RTE relevant configuration. It should be included
in an OIL file used for the OS configuration of the whole ECU.

Caution
The generated files Rte_Needs.ecuc.arxml and Rte.oil file must not be
  changed!

5.17.3  Interface to NVM
The RTE generator provides NvM callback functions for synchronous copying of the mirror
buffers  to  and  from  the  NvM.  The  generated  callbacks,  which  are  called  inside  the
NvM_MainFunction,  have  to  be  configured  in  the  NvM  configuration  accordingly.  The
necessary callbacks are defined in the Rte_Cbk.h header file.

Caution
The RTE generator assumes that the call context of NvM callbacks is the task which
  calls the NvM_MainFunction.

During  export  of  the  ECU  configuration  description  the  necessary  NVM  callbacks  are
exported into the NVM section of the ECU configuration description.
5.17.4  Interface to XCP
In addition to the usage of the Com and the OS module as described by AUTOSAR, the
MICROSAR  RTE  generator  optionally  can  also  take  advantage  of  the  MICROSAR  XCP
module.
This  makes  it  possible  to  configure  the  RTE  to  trigger  XCP  Events  when  certain
measurement points are reached.
This  for  example  also  allows  the  measurement  of  buffers  for  implicit  sender/receiver
communication when a runnable entity is terminated.
Measurement is described in detail in chapter 6.6 Measurement and Calibration.
When measurement with XCP Events is enabled, the RTE therefore includes the header
Xcp.h and calls the Xcp_Event API to trigger the events.
Used Xcp API
Xcp_Event

2015, Vector Informatik GmbH
Version: 4.8.0
118 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

5.17.5  Interface to SCHM
In
multicore
and
memory
protection
systems,
the
schedulable
entity
Rte_ComSendSignalProxyPeriodic is provided by the RTE and is used to access the
COM  from  OS  Applications  without  BSW.  This  schedulable  entity  needs  to  be  called
periodically by the SCHM.
See chapter 4.8.1 for details.
Provided Schedulable Entity
Rte_ComSendSignalProxyPeriodic

5.17.6  Interface to DET
The RTE generator reports development errors to the DET, if development error detection
is enabled.
See chapter 3.8.1 for details.
Used DET API
Det_ReportError

2015, Vector Informatik GmbH
Version: 4.8.0
119 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

6  RTE Configuration
The RTE specific configuration in DaVinci Configurator encompasses the following parts:
  assignment of runnables to OS tasks
  assignment of OS tasks to OS applications (memory protection/multicore support)
  assignment of Per-Instance Memory to NV memory blocks
  selection of the exclusive area implementation method
  configuration of the periodic triggers
  configuration of measurement and calibration
  selection of the optimization mode
  selection of required VFB tracing callback functions
  configuration of the built-in call to the RTE generator
  platform dependent resource calculation
6.1
Configuration Variants
The RTE supports the configuration variants
  VARIANT-PRE-COMPILE
  VARIANT-POST-BUILD-SELECTABLE
The configuration classes of the  RTE parameters depend on the supported configuration
variants. For their definitions please see the Rte_bswmd.arxml file.
6.2
Task Configuration
Runnable  Entities  triggered  by  any  kind  of  RTE  Event  e.g.  TimingEvent  have  to  be
mapped to tasks. Only server runnables (triggered by an OperationInvokedEvent) that
either  have  their  CanBeInvokedConcurrently  flag  enabled  or  that  are  called  from
tasks  that  cannot  interrupt  each  other  do  not  need  to  be  mapped.  For  optimization
purposes  they  can  be  called  directly  and  are  then  executed  in  the  context  of  the  calling
runnable (client).
The task configuration within DaVinci Configurator also contains some attributes which are
part of the OS configuration. The parameters are required to control RTE generation.

2015, Vector Informatik GmbH
Version: 4.8.0
120 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

The creation of tasks is done in OS Configuration Editor in the in the DaVinci Configurator.
The Task Mapping Assistant has to be used to assign the triggered functions (runnables
and schedulable entities) to the tasks.

Figure 6-1 Mapping of Runnables to Tasks

The  MICROSAR  RTE  supports  the  generation  of  both  BASIC  and  EXTENDED  tasks.  The
Task  Type  can  either  be  selected  or  the  selection  is  done  automatically  if  AUTO  is
configured.
While  extended  tasks  are  used  for  tasks  that  need  to  wait  for  different  RTE  trigger
conditions, basic tasks are used when all runnables of a task are triggered by one or more
identical triggers.
A typical example for this might be several cyclic triggered runnables that share the same
activation offset and cycle time.
Moreover another requirement for basic task usage is that the mapped runnables do not
use APIs that requires a waitpoint, like a blocking Rte_Feedback().
In addition to the Task Type the number of possible task activations can be configured in
the same dialog.

Caution
When RTE events that trigger a runnable are fired multiple times before the actual
  runnable invocation happens and when the runnable is mapped to an extended task,
the runnable is invoked only once.
However, if the runnable is mapped to a basic task, the same circumstances will cause
multiple task activations and runnable invocations. Therefore, for basic tasks, the task
attribute Activation in the OS configuration has to be set to the maximum number of
2015, Vector Informatik GmbH
Version: 4.8.0
121 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

queued task activations. If Activation is too small, additional task activations may result
in runtime OS errors. To avoid the runtime error the number of possible Task Activation
should be increased.

6.3
Memory Protection and Multicore Configuration
For  memory  protection  or  multicore  support  the  tasks  have  to  be  assigned  to  OS
applications.  The  following  figures  show  the  configuration  of  OS  applications  and  the
assignment of OS tasks. For multicore support also the Core ID has to configured for the
OS application.

Figure 6-2 Assignment of a Task to an OS Application

Caution
Make sure that the operating system is configured with scalability class SC3 or SC4.

2015, Vector Informatik GmbH
Version: 4.8.0
122 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

Figure 6-3 OS Application Configuration
2015, Vector Informatik GmbH
Version: 4.8.0
123 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

6.4
NV Memory Mapping
Each instance of a Per-Instance Memory, which has configured Needs memory mapping
can be mapped to an NV memory block of the NvM.
The Per-Instance Memory (PIM) is used as mirror buffer for the NV memory block. During
startup, the EcuM calls NvM_ReadAll, which initializes the configured PIM with the value
of  the  assigned  NV  memory  block.  During  shutdown,  NvM_WriteAll  stores  the  current
value of the PIM buffer in the corresponding NV memory block.
The  RTE  configurator  provides  support  for  manual  mapping  of  already  existing  NV
memory  blocks  or  automatically  generation  of  NV  memory  blocks  and  mapping  for  all
PIMs.
The  RTE  has  no  direct  Interface  to  the  NvM  in  the  source  code.  There  exists  only  an
Interface on configuration level. The RTE configurator has to configure the following parts
of the NvM configuration.
  Address of PIM representing the RAM mirror of the NV memory block.
  Optionally the address of calibration parameter for default values.
  Optionally the size of the PIM in bytes if available during configuration time.

The  following  figure  shows  the  Memory  Mapping  in  DaVinci  Configurator  where
assignment of Per-Instance Memory to NV memory blocks can be configured.

Figure 6-4 Mapping of Per-Instance Memory to NV Memory Blocks
2015, Vector Informatik GmbH
Version: 4.8.0
124 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

6.5
RTE Generator Settings
The following figure shows how the MICROSAR RTE Generator has to be enabled for
code generation within the DaVinci Configurator.

Figure 6-5 RTE Generator Settings

2015, Vector Informatik GmbH
Version: 4.8.0
125 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

6.6
Measurement and Calibration
The  MICROSAR  RTE  generator  supports  the  generation  of  an  ASAM  MCD-2MC
compatible  description  of  the  generated  RTE  that  can  be  used  for  measurement  and
calibration  purposes.  When  measurement  or  calibration  is  enabled  the  RTE  generator
generates  a  file  Rte.a2l  that  contains  measurement  objects  for  sender/receiver  ports,
per-instance  memories  and  inter-runnable  variables.  Calibration  parameters  are
represented as characteristic objects.

Figure 6-6 Measurement and Calibration Generation Parameters

The switch A2L Version controls the ASAM MCD-2MC standard to which the Rte.a2l file
is compliant. Version 1.6.0 is recommended as it supports a symbol link attribute that can
be used by the measurement and calibration tools to automatically obtain the address of a
characteristic or measurement object in the compiled and linked RTE code.
What  measurements  and  characteristics  are  listed  in  the  Rte.a2l  file  depends  on  the
measurement  and  calibration  settings  of  the  individual  port  interfaces,  per-instance
memories,  inter-runnable variables and calibration parameters and if the variable can be
measured  in  general.  For  example,  measurement  is  not  possible  for  queued
communication as described in the RTE specification. When “Calibration Access” is set to
“NotAccessible”, an object will not be listed in the Rte.a2l file.
2015, Vector Informatik GmbH
Version: 4.8.0
126 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

Within  the  Rte.a2l  file,  the  measurement  objects  are  grouped  by  SWCs.  When  inter-
ECU sender/receiver communication shall be measured, the groups will also contain links
to  measurement  objects  with  the  name  of  the  COM  signal  handle.  These  measurement
objects have to be provided by the COM.
Furthermore, the generated Rte.a2l is only a partial A2L file. It is meant to be included in
the MODULE block of a skeleton A2L file with the ASAM MCD-2MC /include command.
This  makes  it  possible  to  specify  additional  measurement  objects,  for  example  from  the
COM, and IF_DATA blocks directly in the surrounding A2L file.

In order to also allow the measurement of implicit buffers for inter-ECU communication, the
MICROSAR RTE generator supports measurement  with the help of XCP Events. This is
controlled  by  the  flag  “Use  XCPEvents”.  When  XCP  Events  are  enabled,  the  RTE
generator  triggers  an  XCP  Event  that  measures  the  implicit  buffer  after  a  runnable  with
implicit  inter-ECU  communication  is  terminated  and  before  the  data  is  sent.  “Use
XCPEvents” also enables the generation of one XCP Event at the end of every task that
can be used to trigger the measurement of other objects.

The  RTE  generator  automatically  adds  the  XCP  Events  to  the  configuration  of  the  XCP
module. The Event IDs are then automatically calculated by the XCP module.
The  definitions  for  the  Events  are  generated  by  the  XCP  module  into  the  file
XCP_events.a2l.  This  file  can  be  included  in  the  DAQ  section  of  the  IF_DATA  XCP
section in the skeleton A2L file.

The  MICROSAR  RTE  supports  three  different  online  calibration  methods,  which  can  be
selected globally for the whole ECU. They differ in their kind how the APIs Rte_CData and
Rte_Prm access the calibration parameter. By default the online calibration is switched off.
The following configuration values can be selected:
  None
  Single Pointered
  Double Pointered
  Initialized RAM

In  addition  to  the  ECU  global  selection  of  the  method  the  online  calibration  have  to  be
activated for each component individually by setting the Calibration Support switch.
2015, Vector Informatik GmbH
Version: 4.8.0
127 / 139
based on template version 3.5

Technical Reference MICROSAR RTE


Figure 6-7 SWC Calibration Support Parameters

For each component with activated Calibration Support memory segments are generated
into the file Rte_MemSeg.a2l. This file can be  included in the MOD_PAR section in the
skeleton A2L  file.  This  makes  it  possible  to  specify  additional  memory  segments  in  the
surrounding A2L file.
If  the  method  Initialized  RAM  is  selected,  segments  for  the  Flash  data  section  and  the
RAM  data  section  of  each  calibration  parameter  are  generated.  The  Flash  sections  are
mapped to the corresponding RAM sections.
If the Single Pointered or Double Pointered method is enabled, only memory segments for
the  Flash  data  sections  are  listed  in  the  Rte_MemSeg.a2l.  In  addition  a  segment  for  a
RAM  buffer  is  generated,  when  the  Single  Pointered  method  is  used  and  a
CalibrationBufferSize is set. This parameter specifies the size of the RAM buffer in
byte. If it is set to 0, no RAM buffer will be created.
2015, Vector Informatik GmbH
Version: 4.8.0
128 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

Figure 6-8  CalibrationBufferSize Parameter
The  following  figure  shows  a  possible  include  structure  of  an A2L  file.  In  addition  to  the
fragment A2L files that are generated by the RTE generator other parts (e.g. generated by
the BSW) can be included in the skeleton A2L file.

Figure 6-9  A2L Include Structure

For more details about the creation of a complete A2L file see [20].
2015, Vector Informatik GmbH
Version: 4.8.0
129 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

6.7
Optimization Mode Configuration
A  general  requirement  to  the  RTE  generator  is  production  of  optimized  RTE  code.  If
possible  the  MICROSAR  RTE  Generator  optimizes  in  different  optimization  directions  at
the same time. Nevertheless, sometimes it isn’t possible to do that. In that case the default
optimization direction is “Minimum RAM Consumption”. The user can change this behavior
by manually selection of the optimization mode.
  Minimum RAM Consumption (MEMORY)
  Minimum Execution Time (RUNTIME)

The  following  figure  shows  the  Optimization  Mode  Configuration  in  DaVinci  Configurator.

Figure 6-10 Optimization Mode Configuration
2015, Vector Informatik GmbH
Version: 4.8.0
130 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

6.8
VFB Tracing Configuration
The  VFB  Tracing  feature  of  the  MICROSAR  RTE  may  be  enabled  in  the  DaVinci
Configrator as shown in the following picture.

Figure 6-11  VFB Tracing Configuration

You may open an already generated Rte_Hook.h header file from within this dialog. This
header file contains the complete list of all available trace hook functions, which can be
activated independently. You can select and copy the names and insert these names into
the trace function list of this dialog manually or you can import a complete list from a file. If
you want to enable all trace functions you can import the trace functions from an already
generated Rte_Hook.h. The VFB Trace Client Prefix defines an additional prefix for all
VFB trace functions to be generated. With this approach it is for example possible to
enable additionally trace functions for debugging (Dbg) and diagnostic log and trace (Dlt)
at the same time.

Info
All enabled trace functions have to be provided by the user. Section 4.3.4 describes
  how a template for VFB trace hooks can be generated initially or updated after
configuration changes.
2015, Vector Informatik GmbH
Version: 4.8.0
131 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

6.9
Exclusive Area Implementation
The implementation method for exclusive areas can be set in the DaVinci Configurator as
shown in the following picture.

Figure 6-12 Exclusive Area Implementation Configuration

2015, Vector Informatik GmbH
Version: 4.8.0
132 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

6.10  Periodic Trigger Implementation
The  runnable  activation  offset  and  the  trigger  implementation  for  cyclic  runnable  entities
may be set in the ECU project editor as shown in the following picture.

Figure 6-13 Periodic Trigger Implementation Configuration

Caution
Currently it is not supported to define an activation offset and a trigger implementation
  per trigger. The settings can only be made for the complete runnable with potential
several cyclic triggers.

The activation offset specifies at what time relative to the start of the RTE the runnable /
main function is triggered for the first time.
Trigger  implementation  can  either  be  set  to  Auto  or  None.  When  it  is  set  to  the  default
setting  Auto,  the  RTE  generator  will  automatically  generate  and  set  OS  alarms  that  will
then trigger the runnables  /  main functions. When trigger implementation is set  to  None,
the RTE  generator only creates the tasks  and events  for triggering the runnables  / main
functions. It is then the responsibility of the user to periodically activate the basic task to
which a runnable / main function is mapped or to send an event when the runnable / main
function is mapped to an extended task.
2015, Vector Informatik GmbH
Version: 4.8.0
133 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

This  feature  can  also  be  used  to  trigger  cyclic  runnable  entities  /  main  functions  with  a
schedule table. This allows the synchronization with FlexRay.
To ease the creation of such a schedule table, the generated report Rte.html contains a
trigger listing. The listing contains the triggered runnables / main functions, their tasks and
the used events and alarms.

Figure 6-14 HTML Report

If  the  OS  alarm  column  for  a  trigger  is  empty,  the  runnable  /  main  function  needs  to  be
triggered  manually.  In  the  example  above,  this  is  the  case  for  all  runnables  except  for
RunnableCyclic.
The row for Runnable2 does not contain an event because this runnable is mapped to a
basic task.
To  manually  implement  the  cyclic  triggers,  one  could  for  example  create  a  repeating
schedule table in the OS configuration with duration 10 that uses a counter with a tick time
of  one  millisecond.  An  expiry  point  at  offset  0  would  then  need  to  contain  SETEVENT
actions  for  the  runnables  Runnable1  and  Runnable3  and  an  ACTIVATETASK  action  for
Runnable2.
Moreover further expiry points with the offsets 2, 4, 6, 8 are needed to activate Runnable1
and Runnable2 and another expiry point with offset 5 is needed to activate Runnable3.

Caution
When the trigger implementation is set to none, the settings for the cycle time and the
  activation offset are no longer taken into account by the RTE. It is then the
responsibility of the user to periodically trigger the runnables / main functions at the
configured times. Moreover the user also has to make sure that this triggering does not
happen before the RTE is completely started.

2015, Vector Informatik GmbH
Version: 4.8.0
134 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

6.11  Resource Calculation
The RTE generator generates the file Rte.html containing the RAM and CONST usage of
the generated RTE. The RTE generator makes the following assumptions.
  Size of a pointer: 2 bytes. The default value of the RTE generator can be changed with
the parameter Size Of RAM Pointer in the EcuC module.
  Size of the OS dependent data type TaskType: 1 byte
  Size of the OS dependent data type EventMaskType: 1 byte
  Padding bytes in structures and arrays are considered according to the configured
parameters Struct Alignment and Struct In Array Alignment in the EcuC
module for NvM blocks.
  Size of a boolean data type: 1 byte (defined in PlatformTypes.h)

The  pointer  size  and  the  alignment  parameters  can  be  found  in  the  container
EcuC/EcucGeneral in the Basic Editor of DaVinci Configurator.

Figure 6-15 Configuration of platform settings

2015, Vector Informatik GmbH
Version: 4.8.0
135 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

7  Glossary and Abbreviations
7.1
Glossary
Term
Description
DaVinci DEV
DaVinci Developer: The SWC Configuration Editor.
DaVinci CFG
DaVinci Configurator: The BSW and RTE Configuration Editor.
Table 7-1   Glossary
The AUTOSAR  Glossary  [14]  also  describes  a  lot  of  important  terms,  which  are  used  in
this document.
7.2
Abbreviations
Abbreviation
Description
API
Application Programming Interface
AUTOSAR
Automotive Open System Architecture
BSW
Basis Software
Com
Communication Layer
ComXf
Com based Transformer
C/S
Client-Server
E2E
End-to-End Communication Protection
E2EXf
End-to-End Transformer
EA
Exclusive Area
ECU
Electronic Control Unit
EcuM
ECU State Manager
FOSS
Free and Open Source Software
HIS
Hersteller Initiative Software
IOC
Inter OS-Application Communicator
ISR
Interrupt Service Routine
MICROSAR
Microcontroller Open System Architecture (Vector’s  AUTOSAR solution)
NvM
Non-volatile Memory Manager
PIM
Per-Instance Memory
OIL
OSEK Implementation Language
OSEK
Open Systems and their corresponding Interfaces for Electronics in
Automotive
RE
Runnable Entity
SE
Schedulable Entity
RTE
Runtime Environment
SchM
Schedule Manager
2015, Vector Informatik GmbH
Version: 4.8.0
136 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

SOME/IP
Scalable service-oriented middleware over IP
SomeIpXf
SOME/IP Transformer
S/R
Sender-Receiver
SWC
Software Component
SWS
Software Specification
VFB
Virtual Functional Bus
Table 7-2 Abbreviations
2015, Vector Informatik GmbH
Version: 4.8.0
137 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

8  Additional Copyrights
The MICROSAR RTE Generator  contains Free and Open Source Software (FOSS). The
following table lists the files which contain this software, the kind and version of the FOSS,
the  license  under  which  this  FOSS  is  distributed  and  a  reference  to  a  license  file  which
contains the original text of the license terms and conditions. The referenced license files
can be found in the directory of the RTE Generator.

File
FOSS
License
License Reference
MicrosarRteGen.exe  Perl 5.20.2
Artistic License
License_Artistic.txt
Newtonsoft.Json.dll
Json.NET 6.0.4  MIT License
License_JamesNewton-King.txt
Rte.jar
flexjson 2.1
Apache License V2.0  License_Apache-2.0.txt
Table 8-1   Free and Open Source Software Licenses
2015, Vector Informatik GmbH
Version: 4.8.0
138 / 139
based on template version 3.5

Technical Reference MICROSAR RTE

9  Contact
Visit our website for more information on

  News
  Products
  Demo software
  Support
  Training data
  Addresses

www.vector.com

2015, Vector Informatik GmbH
Version: 4.8.0
139 / 139
based on template version 3.5

Document Outline

8 -

MICROSAR RTE Release Notes

MICROSAR RTE 4.8.0 - DaVinci Developer Version 3.11.x

MICROSAR RTE 4.7.1 - DaVinci Developer Version 3.10.x

MICROSAR RTE 4.7.0 - DaVinci Developer Version 3.10.x

MICROSAR RTE 4.6.0 - DaVinci Developer Version 3.9.x

MICROSAR RTE 4.5.0 - DaVinci Developer Version 3.9.x

MICROSAR RTE 4.4.2 - DaVinci Developer Version 3.8.x

MICROSAR RTE 4.4.1 - DaVinci Developer Version 3.8.x

MICROSAR RTE 4.4.0 - DaVinci Developer Version 3.8.x

MICROSAR RTE 4.3.0 - DaVinci Developer Version 3.7.x

MICROSAR RTE 4.2.1 - DaVinci Developer Version 3.6.x

MICROSAR RTE 4.2.0 - DaVinci Developer Version 3.6.x

MICROSAR RTE 4.1.3 - DaVinci Developer Version 3.5.x

MICROSAR RTE 4.1.2 - DaVinci Developer Version 3.5.x

MICROSAR RTE 4.1.1 - DaVinci Developer Version 3.5.x

MICROSAR RTE 4.1.0 - DaVinci Developer Version 3.5.x

MICROSAR RTE 4.0.0 - DaVinci Developer Version 3.4.x

MICROSAR RTE 3.90.0 - DaVinci Developer Version 3.3.x

MICROSAR RTE 2.22.0 - DaVinci Developer Version 3.3.x

MICROSAR RTE 2.21.0 - DaVinci Developer Version 3.2.x

MICROSAR RTE 2.20.1 - DaVinci Developer Version 3.1.x

MICROSAR RTE 2.20.0 - DaVinci Developer Version 3.1.x

MICROSAR RTE 2.19.1 - DaVinci Developer Version 3.0 (SP5)

MICROSAR RTE 2.19.0 - DaVinci Developer Version 3.0 (SP5)

MICROSAR RTE 2.18.2 - DaVinci Developer Version 3.0 (SP4)

MICROSAR RTE 2.18.1 - DaVinci Developer Version 3.0 (SP4)

MICROSAR RTE 2.18.0 - DaVinci Developer Version 3.0 (SP4)

MICROSAR RTE 2.17.6 - DaVinci Developer Version 3.0 (SP3)

MICROSAR RTE 2.17.5 - DaVinci Developer Version 3.0 (SP3)

MICROSAR RTE 2.17.4 - DaVinci Developer Version 3.0 (SP3)

MICROSAR RTE 2.17.3 - DaVinci Developer Version 3.0 (SP3)

MICROSAR RTE 2.17.2 - DaVinci Developer Version 3.0 (SP3)

MICROSAR RTE 2.17.1 - DaVinci Developer Version 3.0 (SP3)

MICROSAR RTE 2.17.0 - DaVinci Developer Version 3.0 (SP3)

MICROSAR RTE 2.16.1 - DaVinci Developer Version 3.0 (SP2)

MICROSAR RTE 2.16.0 - DaVinci Developer Version 3.0 (SP2)

MICROSAR RTE 2.15.5 - DaVinci Developer Version 3.0 (SP1)

MICROSAR RTE 2.15.4 - DaVinci Developer Version 3.0 (SP1)

MICROSAR RTE 2.15.3 - DaVinci Developer Version 3.0 (SP1)

MICROSAR RTE 2.15.2 - DaVinci Developer Version 3.0 (SP1)

MICROSAR RTE 2.15.1 - DaVinci Developer Version 3.0 (SP1)

MICROSAR RTE 2.15.0 - DaVinci Developer Version 3.0 (SP1)

MICROSAR RTE 2.14.0 - DaVinci Developer Version 3.0 (SP1)

MICROSAR RTE 2.13.0 - DaVinci Developer Version 3.0

MICROSAR RTE 2.12.1 - DaVinci Tool Suite Version 2.3 (SP7)

MICROSAR RTE 2.12.0 - DaVinci Tool Suite Version 2.3 (SP7)

MICROSAR RTE 2.11.0 - DaVinci Tool Suite Version 2.3 (SP6)

MICROSAR RTE 2.10.3 - DaVinci Tool Suite Version 2.3 (SP5)

MICROSAR RTE 2.10.2 - DaVinci Tool Suite Version 2.3 (SP5)

MICROSAR RTE 2.10.1 - DaVinci Tool Suite Version 2.3 (SP5)

MICROSAR RTE 2.10.0 - DaVinci Tool Suite Version 2.3 (SP5)

MICROSAR RTE 2.9.4 - DaVinci Tool Suite Version 2.3 (SP4)

MICROSAR RTE 2.9.3 - DaVinci Tool Suite Version 2.3 (SP4)

MICROSAR RTE 2.9.2 - DaVinci Tool Suite Version 2.3 (SP4)

MICROSAR RTE 2.9.1 - DaVinci Tool Suite Version 2.3 (SP4)

MICROSAR RTE 2.9.0 - DaVinci Tool Suite Version 2.3 (SP4)

MICROSAR RTE 2.8.1 - DaVinci Tool Suite Version 2.3 (SP3)

MICROSAR RTE 2.8.0 - DaVinci Tool Suite Version 2.3 (SP3)

MICROSAR RTE 2.7.1 - DaVinci Tool Suite Version 2.3 (SP2)

MICROSAR RTE 2.7.0 - DaVinci Tool Suite Version 2.3 (SP2)

MICROSAR RTE 2.6.5 - DaVinci Tool Suite Version 2.3 (SP1)

MICROSAR RTE 2.6.4 - DaVinci Tool Suite Version 2.3 (SP1)

MICROSAR RTE 2.6.3 - DaVinci Tool Suite Version 2.3 (SP1)

MICROSAR RTE 2.6.2 - DaVinci Tool Suite Version 2.3 (SP1)

MICROSAR RTE 2.6.1 - DaVinci Tool Suite Version 2.3 (SP1)

MICROSAR RTE 2.6.0 - DaVinci Tool Suite Version 2.3 (SP1)

MICROSAR RTE 2.5.0 - DaVinci Tool Suite Version 2.3

MICROSAR RTE 2.4.2 Beta - DaVinci Tool Suite Version 2.3 Beta

MICROSAR RTE 2.4.1 Beta - DaVinci Tool Suite Version 2.3 Beta

MICROSAR RTE 2.4.0 Beta - DaVinci Tool Suite Version 2.3 Beta

MICROSAR RTE 2.3.0 - DaVinci Tool Suite Version 2.2 (SP3)

MICROSAR RTE 2.2.4 - DaVinci Tool Suite Version 2.2 (SP2)

MICROSAR RTE 2.2.2 - DaVinci Tool Suite Version 2.2 (SP1)

MICROSAR RTE 2.2.1 - DaVinci Tool Suite Version 2.2

Additional Information

MICROSAR RTE 4.8.0 - DaVinci Developer Version 3.11.x

RTE features

Support of COM based Transformer ComXf
Support of different strategies for writing NV data in Nv Block SWCs
Support of C/S Interfaces for Nv Block SWCs
SWC Template generation provides user sections for documentation of runnable entities
Wide character support in paths
Improved counter selection for operating systems with multiple OS applications
Support of optimized macro implementation for SchM_Enter and SchM_Exit
Enhanced OS Spinlock support
Enable optimizations in QM partitions
Improved command line handling regarding paths which spaces and '-' signs
MISRA improvements

Fixed issues

Generation error: GenAPI error for record elements with init values TRUE/FALSE (ESCAN00083111)
Use of uninitialized value in concatenation when a data constraint with [0,0] exists (ESCAN00083589)
Asynchronous Rte_Call API for inter-ECU C/S communication without timeout does not check LdCom_IfTransmit return value (ESCAN00083611)
Compiler error: access to missing task variable in Rte_Call API (ESCAN00083765)
Compiler error: Missing structure for .Rte_CallCompleted access (ESCAN00083779)
Compiler error: duplicate members in TxUpdateFlagsType (ESCAN00083791)
Receiver that is not mapped to the BSW partition reads invalid data (ESCAN00083832)
Mode Declaration Groups with EXPLICIT_ORDER do not work correctly (ESCAN00083841)
Compiler error: Unconnected IWriteRef accesses unknown UNDEFINED structure element (ESCAN00083854)
Generator reports invalid array access (ESCAN00083943)
Compiler error: Missing initializer for NV data element (ESCAN00084379)

Limitations of AUTOSAR 4.0 support

See TechnicalReference_Asr_Rte.pdf for details.

RTE

RTE

Component Documentation

1 - Rte Peer Review Checklists

Overview

Sheet 1: Summary Sheet

Sheet 2: Synergy Project

2 - SafetyGuide_Rte

3 - SafetyGuide_Rte_ind

4 - SafetyGuide_Rtes

Document Outline

5 - TechnicalReference_Rte

6 - TechnicalReference_Rte_ind

7 - TechnicalReference_Rtes

Document Outline

8 -

Table of contents

RTE features

Fixed issues

Limitations of AUTOSAR 4.0 support

RTE features

Fixed issues

Limitations of AUTOSAR 4.0 support

RTE features

Fixed issues

Limitations of AUTOSAR 4.0 support

RTE features

Fixed issues

Limitations of AUTOSAR 4.0 support

RTE features

Fixed issues

Limitations of AUTOSAR 4.0 support

Fixed issues

Limitations of AUTOSAR 4.0 support

RTE features

Fixed issues

Limitations of AUTOSAR 4.0 support

RTE features

Fixed issues

Limitations of AUTOSAR 4.x support

RTE features

Fixed issues

Limitations of AUTOSAR 4.x support

Fixed issues

Limitations of AUTOSAR 4.0 support

RTE features

Fixed issues

Limitations of AUTOSAR 4.0 support

Fixed issues

Limitations of AUTOSAR 4.0 support

Fixed issues

Limitations of AUTOSAR 4.0 support

RTE features

Fixed issues

Limitations of AUTOSAR 4.0 support

RTE features

Fixed issues

Limitations of AUTOSAR 4.0 support

RTE features

Fixed issues

Limitations of AUTOSAR 4.0 support

RTE features

Limitations of AUTOSAR 4.0 support

RTE features

Fixed issues

Limitations of AUTOSAR 3.2.2 support

RTE features

Fixed issues

Fixed issues

RTE features

Fixed issues

RTE features

Fixed issues

RTE features

Fixed issues

Limitations of AUTOSAR 3.x support

Fixed issues

RTE features

Fixed issues

RTE features