RTA RTE User Guide V6.3.0

User Manual: Pdf

Open the PDF directly: View PDF .
Page Count: 282

Download
Open PDF In Browser	View PDF

RTA-RTE V6.3.0
User Guide

Copyright
The data in this document may not be altered or amended without special notification
from ETAS GmbH. ETAS GmbH undertakes no further obligation in relation to this document. The software described in it can only be used if the customer is in possession
of a general license agreement or single license. Using and copying is only allowed in
concurrence with the specifications stipulated in the contract. Under no circumstances
may any part of this document be copied, reproduced, transmitted, stored in a retrieval
system or translated into another language without the express written permission of
ETAS GmbH.
©Copyright 2017 ETAS GmbH, Stuttgart.
The names and designations used in this document are trademarks or brands belonging
to the respective owners.
Document: 10666-UG-001 EN - 10-2017
Revision: 68240 [RTA-RTE 6.3.0]
This product described in this document includes software developed by the Apache
Software Foundation (http://www.apache.org/).

RTA-RTE V6.3.0
User Guide

Contents
1 About this Manual
1.1
Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . .
1.2
Acronyms and Abbreviations . . . . . . . . . . . . . . . . . . . . . .

Introduction and Overview

7
9
9

2 Introduction to the RTE
2.1
What is a Run-Time Environment (RTE)?
2.2
Software Components . . . . . . . . . .
2.3
Interfaces . . . . . . . . . . . . . . . . .
2.4
Software Component Behavior . . . . .
2.5
Services . . . . . . . . . . . . . . . . . .

.
.
.
.
.

12
13
14
18
21
25

3 Introduction to RTE Configuration
3.1
Understanding XML . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2
Understanding AUTOSAR XML . . . . . . . . . . . . . . . . . . . . .
3.3
ECU Configuration Description . . . . . . . . . . . . . . . . . . . . .

26
26
27
33

4 Working
4.1
4.2
4.3
4.4
4.5

36
37
39
41
42
42

with the RTE Generator
Contract Phase . . . . . .
RTE Phase . . . . . . . . .
Basic Software Phase . .
The Development Process
Samples . . . . . . . . . .

.
.
.
.
.

Developing Software Components

5 Type System
5.1
Application Data Types . . . . . . . . . . . . . . . . . . . . . . .
5.2
Base Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3
Implementation Data Types . . . . . . . . . . . . . . . . . . . . .
5.4
Type Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.5
Application Types And Numerical Representations . . . . . . . .
5.6
Expressing Values in Physical Units or Numerical Representation

.
.
.
.
.
.

46
46
50
51
60
61
66

6 Interfaces
6.1
Sender-Receiver
6.2
Nv-Data . . . . .
6.3
Mode-Switch . .
6.4
Client-Server . .
6.5
Calibration . . .
6.6
Trigger . . . . .

.
.
.
.
.
.

69
69
70
71
72
73
74

7 Software Component Types
7.1
Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2
Communication Specifications . . . . . . . . . . . . . . . . . . . . .

75
76
77

.
.
.
.
.
.

Contents

RTA-RTE V6.3.0
User Guide

8 Internal Behavior
8.1
RTE Events . . . . . . . . . . . . . . . . .
8.2
Runnable Entities . . . . . . . . . . . . .
8.3
Responding to Periodic Events . . . . . .
8.4
Sending to a Port . . . . . . . . . . . . . .
8.5
Receiving from a Port . . . . . . . . . . .
8.6
Responding to a Server Request on a Port
8.7
Making a Client Request on a Port . . . .
8.8
Direct Trigger of a Runnable Entity . . . .
8.9
Exclusive Areas . . . . . . . . . . . . . . .
8.10
Inter-Runnable Variables . . . . . . . . . .
8.11
Accessing Modes . . . . . . . . . . . . . .
8.12
Per-instance Memory . . . . . . . . . . .
8.13
Port Options . . . . . . . . . . . . . . . .
8.14
Supporting Multiple Instantiation . . . . .
8.15
Memory Allocation . . . . . . . . . . . . .
9 Modes
9.1
9.2
9.3
9.4
9.5
9.6
9.7

Defining Modes . . . . . . . . .
Mode Communication . . . . .
Using Modes . . . . . . . . . .
Understanding Mode Instances
Fast Init . . . . . . . . . . . . .
Synchronizing Modes . . . . .
Non-AUTOSAR Functionality . .

.
.
.
.
.
.
.

10 Implementing Software Components
10.1
Basic Concepts . . . . . . . . . . . . . . .
10.2
Application Source Code . . . . . . . . . .
10.3
Single and Multiple Instances . . . . . . .
10.4
Runnable Entities . . . . . . . . . . . . .
10.5
Sender-Receiver Communication . . . . .
10.6
Client-Server Communication . . . . . . .
10.7
Using Inter-Runnable Variables . . . . . .
10.8
Accessing Parameters . . . . . . . . . . .
10.9
Accessing Per Instance Memory . . . . .
10.10
Concurrency Control with Exclusive Areas
10.11
Starting and Stopping the RTE . . . . . .
11 NVRAM
11.1
11.2
11.3

III

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

83
84
86
87
88
90
94
95
100
102
106
107
107
108
109
110

.
.
.
.
.
.
.

111
111
111
115
118
119
120
120

.
.
.
.
.
.
.
.
.
.
.

122
122
124
125
126
132
135
136
136
137
137
139

140
NV-Block Software Component Types . . . . . . . . . . . . . . . . . 140
Interaction with Application SWC . . . . . . . . . . . . . . . . . . . . 143
Interaction with the NVRAM Manager . . . . . . . . . . . . . . . . . 143

Developing Basic Software

145

12 Basic Software
146
12.1
Basic Software Modules . . . . . . . . . . . . . . . . . . . . . . . . . 146

Contents

RTA-RTE V6.3.0
User Guide

12.2
12.3

Interaction with the RTE . . . . . . . . . . . . . . . . . . . . . . . . . 147
API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152

Composition

13 Composing Software Components
13.1
Composition Type Definition
13.2
Component Instances . . . .
13.3
Connector Prototypes . . . .
13.4
FlatMaps . . . . . . . . . . .
13.5
Data Conversion . . . . . . .

154

.
.
.
.
.

155
155
156
156
167
173

14 Composing Basic Software
180
14.1
Instantiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
14.2
BSW Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
14.3
Connections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
15 Synchronizing BSW and SWC
15.1
Configuration . . . . . . . . . . .
15.2
Synchronized Mode Groups . . .
15.3
Synchronized Triggers . . . . . .
15.4
Synchronized Runnable Entities

.
.
.
.

183
183
185
186
187

16 Accessing NVRAM
189
16.1
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
16.2
Access from Application SWCs . . . . . . . . . . . . . . . . . . . . . 191
16.3
Access from the NVRAM manager . . . . . . . . . . . . . . . . . . . 193

Deployment

196

17 Defining the ECUs and the Networks
197
17.1
ECU Type Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
17.2
ECU Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
18 Mapping
18.1
18.2
18.3
18.4
18.5

Software Components to ECUs
Mapping Component Prototypes . . . . . . .
SWC Implementation Selection . . . . . . . .
Configuring Service Components on an ECU
Mapping Runnable Entities to Tasks . . . . .
How Runnables get activated . . . . . . . . .

.
.
.
.
.

200
200
201
202
203
205

19 Inter-ECU Communication
210
19.1
System Communications . . . . . . . . . . . . . . . . . . . . . . . . 210
19.2
Inter-ECU Sender-Receiver Communication . . . . . . . . . . . . . . 215
19.3
Inter-ECU Client-Server Communication . . . . . . . . . . . . . . . . 218
20 Using the OS and COM Configurations
223
20.1
Operating System Configuration . . . . . . . . . . . . . . . . . . . . 224
20.2
Communication Stack Configuration . . . . . . . . . . . . . . . . . . 226

Contents

RTA-RTE V6.3.0
User Guide

21 Debugging Implementations with VFB Tracing
21.1
Enabling Tracing . . . . . . . . . . . . . .
21.2
Supported Trace Events . . . . . . . . . .
21.3
Configuration . . . . . . . . . . . . . . . .
21.4
Trace Event Header File . . . . . . . . . .
21.5
Implementing Hook Functions . . . . . .

.
.
.
.
.

228
228
228
231
231
231

22 Data Transformation
233
22.1
Extent of support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
22.2
Enabling data transformation in an input configuration . . . . . . . 236
22.3
Working with data transformation . . . . . . . . . . . . . . . . . . . 239

Advanced Concepts

23 RTE Generation
23.1
Identifier length

240
241
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

24 Operating System Considerations
24.1
OS Trigger Selection . . . .
24.2
Task Recurrence . . . . . .
24.3
Schedule Points . . . . . .
24.4
Basic and Extended Tasks .
24.5
Forced-basic semantics . .

.
.
.
.
.

242
242
242
243
244
245

25 Understanding Deployment Choices
25.1
Intra-task . . . . . . . . . . .
25.2
Inter-task . . . . . . . . . . .
25.3
Inter-task Client-Server . . .
25.4
Inter-ECU . . . . . . . . . . .

.
.
.
.

248
248
250
252
253

.
.
.
.
.
.
.
.

260
260
260
261
262
263
264
265
266

26 Optimization
26.1
Buffers for Inter-ECU Reception .
26.2
Direct invocation of the RTE API
26.3
Sender-Receiver Communication
26.4
Client-Server Communication . .
26.5
Function Elision . . . . . . . . . .
26.6
Init Runnables . . . . . . . . . .
26.7
Data Consistency . . . . . . . .
26.8
Tips . . . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.

27 RTE Architecture
267
27.1
Component Data Structure . . . . . . . . . . . . . . . . . . . . . . . 267
27.2
Component Instance Handle . . . . . . . . . . . . . . . . . . . . . . 268
27.3
The RTE API Implementation . . . . . . . . . . . . . . . . . . . . . . 269

VII

Support

28 Contact, Support and Problem Reporting

Contents

272
273

RTA-RTE V6.3.0
User Guide

About this Manual
The RTA-RTE User Guide describes how to install the ETAS AUTOSAR Run-Time Environment (RTE) generation tools and how to configure, build and deploy RTE-based software
components on electronic control units.
The RTA-RTE User Guide is structured along the lines of a top-down development using
the RTE, taking users from software component configuration and development with
the RTE, through system configuration and software component deployment to final
integration of an RTE-based ECU.

• Part I, Introduction and Overview
• Chapter 2 introduces the fundamental building blocks for applications designed
for the AUTOSAR software architecture. The chapter explains how the RTE provides the environment by which AUTOSAR applications run, interact and exchange data at runtime.

• Chapter 3 outlines the key aspects of the RTA-RTE configuration language.
• Chapter 4 explains the wider scope of an AUTOSAR development process and
how RTA-RTE supports the process.

• Part II, Developing Software Components presents a guide to the RTE for Software
Component Engineers.

• Chapter 5 explains the AUTOSAR type system and how implementation and
application types interact.

• Chapter 6 explains how to define sender-receiver and client-server interfaces
that use the data types and can be used by software components to communicate.

• Chapter 7 describes how to define the external view of a software component.
• Chapter 8 shows how to define the threads of control, called runnable entities,
that will be executed to trigger or respond to RTE communication.

• Chapter 9 explains how to use the RTA-RTE provided support for AUTOSAR
application modes and how software components can trigger activity when a
mode changes.

• Chapter 10 shows how to write code to interface with the RTE, use the RTE API
in application code to communicate with other applications, build in run-time
fault tolerance and protect critical data.

• Chapter 11 shows how to write code to create non-volatile data and to interface
with the AUTOSAR NVRAM manager module.

• Part III, Developing Basic Software presents a guide to the development of Basic
Software using RTA-RTE.

• Chapter 12 explains how to create Basic Software modules for use with the
RTA-RTE.

About this Manual

RTA-RTE V6.3.0
User Guide

• Part IV, Composition presents a guide to the RTE for Software System Integrators.
• Chapter 13, Composing Software Components explains how to create instances
of software components, configure instance attributes like the number of
queued data elements that can be received and compose the instances of software components to create a logical software system.

• Chapter 14, Composing Basic Software explains how to create basic software
module instances and how to configure their connections.

• Chapter 15, Synchronizing Basic Software explains how to synchronize
runnables, modes and triggers between basic software module instances and
SWC instances.

• Chapter 16, Accessing NVRAM explains how to access non-volatile data from
application software.

• Part V, Deployment presents a guide to the RTE for ECU and Vehicle Integrators.
• Chapter 17 shows how to define the types of ECU, protocol and communication
frames that will be present in your system.

• Chapter 18 describes how to map the software architecture created during
the composition stage onto the hardware architecture created in the previous chapter and how to map the runnables of a software component into tasks
provided by the AUTOSAR OS.

• Chapter 19 describe how to map sender-receiver and client-server communication between software components located on different ECUs onto the underlying AUTOSAR COM communication basic software module.

• Chapter 20 shows how to use the generated OS and COM configuration files in
your application.

• Chapter 21 explains how to use the hook calls embedded within a generated
RTE to trace RTE events and communication.

• Chapter 22 explains how to serialize and transform communication between
software components.

• Part VI, Advanced Concepts
• Chapter 23 explains additional configuration options for generation of RTEs using RTA-RTE.

• Chapter 24 explains Basic and Extended tasks, and how the RTE interacts with
these OS features.

• Chapter 25 explains how the RTE API calls work when software components are
mapped to the same task, the same ECU or different ECUs.

• Chapter 26 explains how the RTA-RTE optimizes the generated RTE and how
application mapping can affect the scope for optimization.

• Chapter 27 explains how the RTE application specific headers provide the abstractions that make the RTE work and how they encapsulate optimizations.

• Part VII, Support
8

About this Manual

RTA-RTE V6.3.0
User Guide

• Chapter 28 explains how to contact ETAS to obtain technical support for RTARTE.
1.0.1

Related Documents
The RTA-RTE Reference Manual provides a complete reference for the RTE including:

• The syntax of the RTE configuration language.
• The features and functionality of the RTE Generation tool.
• The RTE naming conventions.
• A complete RTE API call reference.
• Dependencies on AUTOSAR Basic Software Modules.
1.0.2

Who Should Read this Manual?
You should read the RTA-RTE User Guide if you need to configure, generate or use a runtime environment for an embedded electronic control unit (ECU). Basic familiarity with
the concepts of the AUTOSAR software architecture and knowledge of C programming
are assumed.
Readers of this document are assumed to be familiar with the RTA-RTE Getting Started
Guide.
First time users of the RTE should read this document for a detailed description of what
features and facilities the RTE provides to software components.

1.1

Document Conventions
Notes that appear like this contain important information that you need to
be aware of. Make sure that you read them carefully and that you follow any
instructions that you are given.
Notes that appear like this describe things that you will need to know if you
want to write code that will work on any target processor.
In this guide you’ll see that program code, header file names, C type names, C functions
and API call names all appear in the monospaced typeface. When the name of an object
is made available to the programmer the name also appears in the courier typeface,
suitably modified in accordance with the RTE naming conventions. So, for example, a
runnable called Runnable1 appears as a handle called Runnable1.

1.2

Acronyms and Abbreviations

About this Manual

RTA-RTE V6.3.0
User Guide

AUTOSAR

AUTomotive Open System ARchitecture - a standardized software architecture targeted at automotive applications aimed at fostering the reuse of application software over multiple vehicle platforms.
See
http://www.autosar.org.

BSW

AUTOSAR Basic Software, see Chapter 12.

C/S

Client-server communication, see Section 6.4.

ECUC

AUTOSAR ECU Configuration

IOC

Inter-OsApplication Communication

RTA-OS

An AUTOSAR SC1-SC4 and OSEK 2.2.3 compatible operating system from ETAS GmbH.

RTA-OSEK

An AUTOSAR SC1 and OSEK 2.2.3 compatible operating
system from ETAS GmbH.

RTE

AUTOSAR Run-Time Environment. See “Introduction to the
RTE” (Chapter 2) for further details.

RTA-RTE

The ETAS AUTOSAR RTE Generator Product. This includes
the AUTOSAR RTE Generator Tool responsible for reading
the AUTOSAR XML configuration and generating the RTE
and associated C header files. RTA-RTE distributions also
include the RTE library, all user documentation and an example application.

SchM

BSW Scheduler (a BSW module defined by AUTOSAR).

S/R

Sender-receiver communication, see Section 6.1.

SWC

An AUTOSAR Software component, see Chapter 7.

VFB

Virtual Function Bus. See “Introduction to the RTE” (Chapter 2) for further details.

XML

eXtensible Markup Language used to describe AUTOSAR
configurations. RTA-RTE processes the input configuration
to generate the required RTE

About this Manual

RTA-RTE V6.3.0
User Guide

Part I

Introduction and Overview

RTA-RTE V6.3.0
User Guide

Introduction to the RTE
The RTE forms part of a layered software architecture based on the AUTOSAR layered
software architecture shown in Figure 2.1.

AUTOSAR
Software
Component 1

AUTOSAR
Software
Component n

AUTOSAR
Sensor/Actuator
Component 1

AUTOSAR
Sensor/Actuator
Component n

RTE

System Services

Memory Services

Communication
Services
I/O Hardware
Abstraction

Onboard Device
Abstraction

Memory
Hardware
Abstraction

Communication
Hardware
Abstraction

Microcontroller
Drivers

Memory Drivers

Communication
Drivers

Complex Drivers

I/O Drivers

ECU Hardware

Figure 2.1: Overview of the AUTOSAR software architecture
Application software is the name given in AUTOSAR to vehicle functions, e.g. braking
system, window wiper, seat control etc. Each application is decomposed into one or
more software components that provide a cohesive part of the application.
Software components are the atomic unit of application distribution in AUTOSAR. When
an AUTOSAR system is built, all the constituent parts of a component (the code, data
etc.) must live on the same ECU.
AUTOSAR defines two principle types of application software components:

• AUTOSAR software component—generic application-level software components
that are designed to be both CPU and location neutral. An AUTOSAR application
software component can be mapped to any available ECU during system configuration, subject to constraints imposed by the system designer. The AUTOSAR soft-

Introduction to the RTE

RTA-RTE V6.3.0
User Guide

ware component is therefore the atomic unit of distribution in an AUTOSAR system.

• AUTOSAR Sensor/Actuator component—software components that are closely coupled to some aspect of ECU hardware and are therefore typically not re-locatable
(onto a different ECU) due to their high degree of dependence on features of a
specific ECU.
In an AUTOSAR system, software component interaction is designed against a Virtual
Function Bus (VFB). The VFB provides a design abstraction that allows interacting software components to be specified and built without detailed knowledge about which
ECU they will be allocated at integration time, how ECUs in the vehicle network communicate, the vehicle network topology etc.
In the VFB model, software components interact though ports which are typed by interfaces. The interface controls what can be communicated and the semantics of communication. The port provides the software component access to the interface. The
combination of port and interface is known as an AUTOSAR interface. Software components are characterized by component type attributes that define how the components
interact with a interface over a port. Attributes might allow you to specify things like:

• A software component waits for data to be provided on a port.
• A software component polls a port for new data periodically.
• Acknowledgment of receipt of a sent message is required.
The VFB provides sufficient information about the logical interaction of software components to allow software systems to be integrated and tested before system integrators
have decided on the allocation of software components to ECUs. This means that the
entire functional behavior of a system can be prototyped before the electrical architecture of a vehicle, in terms of ECUs on networks, is known.
The next stage in development is system integration where software components are
allocated to ECUs and the abstract notions of communication embedded in their VFB
design are mapped to signals sent over the vehicle network. Software components
must also be bound onto the computing platform, for example, integrated into tasks
for scheduling by an operating system.

2.1

What is a Run-Time Environment (RTE)?
The VFB provides the abstraction that allows components to be reusable. The RTE
encapsulates the mechanisms required to make the VFB abstraction work at runtime.
The RTE is therefore, in the simplest case, an implementation of the VFB. However,
the RTE must provide the necessary interfacing and infrastructure to allow software
components to:
1. be implemented without reference to an ECU (the VFB model); and

Introduction to the RTE

RTA-RTE V6.3.0
User Guide

2. be integrated with the ECU and the wider vehicle network once this is known (the
Systems Integration Model) without changing the application software itself.
More specifically, the RTE must:

• Provide a communication infrastructure for software components.
This includes both communication between software components on the same ECU
(intra-ECU ) and communication between software components located on different
ECUs (inter-ECU).

• Arrange for real-time scheduling of software components.
This typically means mapping software components onto tasks provided by an operating system according to timeliness constraints specified at design time.
Application software components have no direct access to the basic software below
the abstraction implemented by the RTE. This means that components cannot, for example, directly access operating system or communication services. So, the RTE must
present an abstraction over such services that remains consistent irrespective of where
the software components are located. All interaction between software components
therefore happens through standardized RTE interface calls.
The RTE also binds the software component architecture onto one or more ECUs. To
make the RTE efficient, this binding is done statically at build time. The standardized
RTE interfaces are automatically implemented by an RTE generation tool that makes
sure that interface behaves in the correct way for the specified component interaction
and the specified component allocation.
For example, if two software components reside on the same ECU they can use internal
ECU communication, but if one is moved to a different ECU, communication now needs
to occur across the vehicle network.
The generated RTE therefore encapsulates the variability in the software that arises
from different mappings of components to ECUs by:

• Presenting a consistent interface to the software components so they can be
reused—they can be designed and written once but used multiple times.

• Binding that interface onto the underlying AUTOSAR basic software implement the
VFB design abstraction.

2.2

Software Components
Within the two broad types outlined above, AUTOSAR defines multiple sub-types of
software component:

• Application software components.
14

Introduction to the RTE

RTA-RTE V6.3.0
User Guide

• Sensor/actuator software components.
• Service components.
• Complex device driver components.
• ECU abstraction components.
From the perspective of the RTE, however, the multiple types are largely identical and
hence, for reasons of brevity, the term “software component” is used to refer to all
types.
Software components interact through ports. There are two classes of Port:

• PPorts are used by a software component to provide data or services to other
software components. Provided ports implement senders and servers.

• RPorts are used by a software component to require data or services from other
software components. Required ports implement receivers and clients.
Figure 2.2 shows a software component with PPorts and RPorts.

Receiver

Sender

RPORT characterised by a SENDER-RECEIVER interface

PPORT characterised by a SENDER-RECEIVER interface

Atomic
[or Sensor/Actuator]

Software
Component
Type

Client
RPORT characterised by a CLIENT-SERVER interface

Server
PPORT characterised by a CLIENT-SERVER interface

Figure 2.2: Software Component with PPorts and RPorts
2.2.1

Types
All configuration items in AUTOSAR are typed. Before any particular object can be
created it is first necessary to define its type.
Each type defines the fixed characteristics of the object. In a simple case you might
define a numeric type called MyNumberType that has a range 0 to 10. This then allows
you to create a MyNumberType which can take the values in the underlying type.
The same concept applies to AUTOSAR software-components. Before you can create a
software component you must first define its component type that identifies the fixed
characteristics of a component, e.g. the port names and how ports are typed by interfaces, how the component behaves etc. The component type is named and the name
Introduction to the RTE

RTA-RTE V6.3.0
User Guide

must be unique within the system. Component type names are typically assigned when
you create components.
2.2.2

Component Types and Instances
To allow the same component to be used it needs to be instantiated at configuration
time. Furthermore, it is possible to configure a software component so that multiple instantiation is possible. For example, you might write a software component to calculate
a rolling average that is used many times by different applications but with different
data set sizes. Each application could use its own instance of the same core algorithm.
Figure 2.3 shows the relationship between a component type and its instance. Here the
type is ETASoffice. Multiple instances of the ETASoffice can be defined and each one
is an instance.

ETASoffice
Atomic Software
Component Type

Stuttgart
Software
Component Instance

York
Software
Component Instance

Figure 2.3: Component Types and Instances
The distinction between type and an instance is analogous to types and variables in
convention programming languages. You would define an application wide unique type
name (the component type) and you would declare one or more uniquely named variables of the type (one or more component prototypes). For example, where we would
have int x, in a programming language we have component type instance in the RTE.
When there are multiple instances of a software component all instances of a component type share the same code, but each instance may have private state that is not
16

Introduction to the RTE

RTA-RTE V6.3.0
User Guide

shared between different instances of the component. Consequently, each instance
you declare is given a “copy” of the private state to which it has exclusive access
through an instance handle that is generated by the RTE. Each time you call an RTE
service you must pass in the instance handle so that the component type code knows
which component instance data it should use as shown in Figure 2.4. The idea of common code and private state that is passed to functions in the RTE is analogous to the
concept of abstract data types provided by some programming languages.

RunnableA

User Code

Rte_APICall(Instance_Handle)

RTE

Figure 2.4: Passing a Component Instance handle to the RTE
All software component instances mapped to a given ECU share the same code, but
the presence of multiple runnable entities means that a software component is multithreaded and there exists the possibility for multiple runnable entities to be simultaneously executing within the same component.
For example, two software component prototypes mapped to different ECUs may both
attempt to invoke operations in the same server in a third software component instance. This implies some form of concurrency control.
The RTE controls potentially conflicting access to shared resources through two mechanisms:

• Serialization
• Exclusive areas
Serialization is implemented automatically within RTA-RTE generated code and provides
a coarse grained mechanism that prevents concurrent execution of certain runnable
entities, such as servers.

Introduction to the RTE

RTA-RTE V6.3.0
User Guide

Exclusive areas provide a mechanism that allows users to have fine control over concurrency. All exclusive areas must be defined at configuration time and are either:

• Explicitly entered and exited in user code using an RTE API; or,
• Implicitly entered and exited in RTA-RTE generated code.
The scope of exclusive areas is the component instance and they cannot therefore be
used to control concurrency between different instances of the same component type
or between instances of different component types. Consequently, exclusive areas
cannot be used to prevent concurrent access to a non-AUTOSAR resource on an ECU. If
such a mechanism is required, then a complex device driver should be implemented.

2.3

Interfaces
When an application consists of multiple software components, it may be necessary
for the software components to communicate, either to exchange data or to trigger
some function. Software components from different applications may also need to
communicate, for example a climate control system will need to communicate with
an engine management system to set the engine idle speed sufficiently high that the
engine does not stall when the air conditioning compressor is switched on.
Communication between AUTOSAR application software components is designed in
terms of ports and interfaces. The following interface types are available:
1. Sender-receiver (signal passing)
2. Client-Server (function invocation)
3. Calibration
4. Trigger
These communication models are known as interfaces in AUTOSAR. Each port on a
software component type must define the type of interface it provides or requires.
Software-component types can define individual attributes, for example the maximum
number of data elements buffered on a receiver interface, so the same interface may
have different behavior for each port in which it is used.
When a system is composed from component instances, the ports of component instances are connected with an assembly connector. The assembly connector must
connect a sender to a receiver and a client to a server. Each assembly connector can
also specify attributes for the behavior between two components.

2.3.1

Sender-Receiver
Sender-receiver communication involves the transmission and reception of signals consisting of atomic data elements sent by one component and received by one or more
components.
18

Introduction to the RTE

RTA-RTE V6.3.0
User Guide

An AUTOSAR configuration can define multiple sender-receiver interfaces and a software component can reference a different interface from each port.
Each sender-receiver interface can contain multiple data elements each of which can
be sent and received independently. Data items within the interface can be simple
types like integer, float, natural etc. or more complex types like records, arrays etc. to
support simultaneous transmission where atomic transmission of related data values
is required.
Figure 2.5 shows the sender side of a sender-receiver interface that includes three
simple data elements.

Element1: IntegerType
Element2: FloatingPointType
Sender
Software
Component

ElementN: RecordType

Figure 2.5: Sender-Receiver Interface Data Elements (Sender Side)
Sender-receiver communication is one way—any reply sent by the receiver must be
sent as a separate sender-receiver communication.
An RPort of a component that requires an AUTOSAR sender-receiver interface can read
the data elements described in the interface and a PPort that provides the interface
can write the data elements.
Sender-receiver communication can be “1:n” (single sender, multiple receivers) and
“n:1” (multiple senders, single-receiver) communication shown in Figure 2.6 and Figure 2.7 respectively.
Sender-receiver “1:n” communication provides a multicast mechanism in the RTE.
When the sender transmits a signal, it is available at each receiver.
When signals are sent by multiple senders to a single receiver (“N:1” communication),
as illustrated in Figure 2.7, there is no synchronization imposed on the senders.
Application Modes
An AUTOSAR system can be configured to operate in one or more application modes
and can configure runnable entities that are activated on either entry or exit from a
mode.
Introduction to the RTE

RTA-RTE V6.3.0
User Guide

Receiver A
R1

Sender
P1

Receiver B
R2

Figure 2.6: Sender-Receiver 1:N Communication
Modes are communicated using sender-receiver communication and are thus defined
within a SENDER-RECEIVER interface.
2.3.2

Client-Server
Client-server communication involves a component invoking a defined “server” function in another component which may or may not return a reply.
A component type can define multiple ports categorized by client-server interfaces.
Each client-server interface can contain multiple operations each of which can be invoked separately. A port of a component that requires an AUTOSAR client-server interface to the component can independently invoke any of the operations defined in
the interface, by making a client-server call to a port providing the service. A port that
provides the client-service interface provides implementations of the operations.
Figure 2.8 shows the server side of a client-server interface that serves trigonometric
functions to clients.
RTA-RTE supports multiple clients invoking the same server (i.e. “N:1” communication
where N > 0) illustrated in Figure 2.9.
Note that it is not possible for a client to invoke multiple servers with a single request
(i.e. “1:N” communication). A client can, or course, call more than one server by
making more than one request.

2.3.3

Calibration
Calibration interfaces are used for communication with Calibration components.

Introduction to the RTE

RTA-RTE V6.3.0
User Guide

Sender A
P1

Sender B

Receiver A
P2

Sender C
P3

Figure 2.7: Sender-Receiver N:1 Communication
Each calibration interface can contain multiple calibration parameters. A port of a
software-component that requires an AUTOSAR calibration interface to the component
can independently access any of the parameters defined in the interface, by using
the RTE API generated for that calibration parameter on the required port. Calibration
components provide the calibration interface and thus provide implementations of the
calibration parameters.

2.4

Software Component Behavior
The software component description we have looked at so far only describes the external interfaces—i.e. those required for component integration. It does not define
how the code that implements the component interacts with the ports. The description
of this is called the software component’s internal behavior and defines what triggering events the component responds to and how threads of execution (called Runnable
Entities) execute when events occur.
A runnable entity, or simply runnable, is a piece of code in a software component that
is triggered by the RTE at runtime1 .
Figure 2.10 shows the internal behaviour for a software component.
1

Note that a

A runnable is similar in concept to a task in an OSEK Operating System.

Introduction to the RTE

RTA-RTE V6.3.0
User Guide

Server
Software
Component

Sin(DegreeType D)
Cosine(DegreeType D)
Tangent(DegreeType D)

Figure 2.8: Client-Server Interface Operation (Server Side)
runnable may do multiple things, for example receive from one interface and send
on another, or act as a server but receive from an interface in order to complete server
processing.
A software component comprises one or more runnable entities and each runnable
entity must have a unique handle so that the RTE can access it at runtime
Runnable entities are triggered by three classes of events:

• Timing events represent some periodic scheduling event, e.g. a periodic timer
tick. The runnable entity provides the entry point for component execution for
things that need to be executed on a regular basis. For example, a component may
want to poll its port for incoming data and would use a runnable triggered by a
timing event to do this.

• Communication events provide a link between the external (port) view of the
software component and the runnable entities internal to the software component.
For example, when a software component needs to respond to a client request on
a server port it will use a runnable to perform the server operation. Similarly, if
a software component needs to perform processing every time a new data item is
received then it will use a runnable that responds to a data received communication
event.

• Mode switch events are the third class of events that trigger runnable entities.
When a mode switch is triggered at runtime, the RTE can invoke a runnable entity in
the software component to perform the function associated with the mode switch.
Runnable Categories
As well as knowing how a runnable entity is triggered, we must also know how the
runnable entity behaves once triggered. This is captured by the runnable entity cate22

Introduction to the RTE

RTA-RTE V6.3.0
User Guide

Client1
Software
Component

Server
Software
Component
Client2-N-1
Software
Component

ClientN
Software
Component

Figure 2.9: Client-Server N:1 Communication
gory. RTA-RTE supports two categories of runnable entity:

• Category 1 runnable entities must be non-blocking (start, execute, terminate) and
have a finite execution time. A Category 1 runnable entity has limited access to RTE
facilities – for example, it is not permitted to make RTE calls that can block such as
synchronous client-server calls to components located on other ECUs. A Category 1
runnable entity is similar in concept to a basic task in the OSEK Operating System.
The Category 1 runnable entities are further split into categories 1a and 1b. Only
category 1b runnable entities can use explicit communication.

• Category 2 entities are permitted to block (start, execute, wait for interaction and
(optionally) terminate) and need not have a finite execution time. A Category 2

Introduction to the RTE

RTA-RTE V6.3.0
User Guide

Software Component Type

Receiver

Sender

RunnableA
Send
Receive

RunnableB

RunnableC

Client

RunnableD

Server

Figure 2.10: Software Component Internal Behaviour
runnable entity is similar in concept to an extended task in the OSEK Operating
System.
Implementing Runnable Entities
You must implement the entry points (similar to task bodies in an OSEK operating
system) of all the runnable entities defined for your component. You must also map
runnable entities onto operating system tasks at ECU deployment time.
When a runnable entity is part of a software component that supports multiple instantiation, the runnable must know the component instance on which it operates at runtime.
The RTE does this by passing the component instance handle to the runnable entity at
runtime when it is activated by the RTE.
The instance handle that is passed to the runnable entity by the RTE is passed back
to the RTE through each API call made from the runnable entities thread of execution.
This mechanism is shown in Figure 2.11 where Instance_handle represents the same
handle in both communications between user code and the RTE.

Introduction to the RTE

RTA-RTE V6.3.0
User Guide

RunnableA(Instance_Handle)

RunnableA

User Code

RTE

Rte_APICall(Instance_Handle)

Figure 2.11: Instance handle flow

2.5

Services
Services provide standardized functionality to AUTOSAR applications through an AUTOSAR interface. A service can thus be seen as a hybrid between application software
components and the basic software modules that provide access to low-level ECU-wide
services.
An AUTOSAR application component makes use of services by connecting to them in
the same way that it does to other software-components within the application, i.e.
using ports characterized by interfaces. A service component may present provider or
requirer ports (or both), and may participate in either sender-receiver or client-server
communications. The interfaces that characterize the ports of a service component are
marked as “Service” Interfaces to indicate their standardized status.
In common with application components, service components have internal behaviors
and are triggered by RTE events. In fact, the RTE treats service components in much the
same way as application software components with the following important exceptions:

• There is at most only a single instance of each service component type on one ECU,
• Service components are not mapped to ECUs via the SYSTEM mapping.

Introduction to the RTE

RTA-RTE V6.3.0
User Guide

Introduction to RTE Configuration
The RTE generator generates the RTE from one or more XML files that define the entire
required behaviour. The structure of the XML files is standardized by AUTOSAR.
This chapter gives a short overview of XML in general and then a description of the key
concepts in AUTOSAR XML that you will need to understand to write RTE configuration
files.

3.1

Understanding XML
XML is a mark-up language for documents that uses a series of tags to convey structured information.
XML does not define either the name of the tags or the semantics of the data enclosed
by the tags. Instead, the names and structure of the tags is defined in by an XML
schema.
Each XML document you write needs to specify the schema that is used for processing
the remaining file content.
With schema definitions it is possible to define a namespace for the tags which allows
you to create a single XML file that references configuration from multiple schemas.
There are basically three types of mark-up that you need to understand to work with
AUTOSAR configuration:

• Elements
• Attributes
• Comments
3.1.1

Elements
An element is delimited using angle brackets and is the most common construct you will
see. For elements that contain content, including sub-elements, the general structure
is:

...

An element can be empty which means that it has no content, this is represented using
the following shorthand:

3.1.2

Attributes
An attribute is a name-value pair that occurs inside start-tags after the element name.
For example,
26

Introduction to RTE Configuration

RTA-RTE V6.3.0
User Guide

All attribute values must be quoted.
3.1.3

Comments
Sometimes you will need to add comments to your XML document. Comments begin
with and can contain any data except the literal string “––”.
You can place comments between mark-up anywhere in your document.

Comments are not part of the textual content of an XML document and are ignored by
the XML processor.

3.2

Understanding AUTOSAR XML
AUTOSAR defines the tags and their semantics using an XML schema definition.

3.2.1

Namespace declaration
AUTOSAR XML descriptions (XML files describing all or part of an AUTOSAR configuration) must declare the AUTOSAR namespace as the default namespace. A namespace
is declared using an xmlns attribute on the root element of an XML file.
The AUTOSAR namespace for all
http://autosar.org/schema/r4.0.

AUTOSAR

releases

the

4.x

series

RTA-RTE will reject a configuration if any of its input files do not declare the
AUTOSAR 4.x namespace.
3.2.2

Schema Validation
RTA-RTE validates each XML input file that declares the AUTOSAR 4.x namespace
against an AUTOSAR XML schema.
Each 4.x schema from AUTOSAR is a superset of all previous 4.x schemas, allowing all
instance documents to be validated against the latest schema. Due to the relaxation of
some constraints, configurations that would have been rejected when validated against
earlier AUTOSAR schema versions may be accepted when validated against a later
version.
The schema version used by RTA-RTE for input validation is AUTOSAR 4.3.0.
RTA-RTE will reject a configuration if any of its input files fail to validate
against the supplied AUTOSAR 4.3.0 schema.
Validating against a newer AUTOSAR revision than supported
If you are using a schema newer than RTA-RTE’s current supported schema, input files
may not validate against the supported AUTOSAR 4.3.0 schema. If you do not require
Introduction to RTE Configuration

RTA-RTE V6.3.0
User Guide

the use of RTE-relevant features from the new schema version, you can override the
schema RTA-RTE uses for validation, allowing these files to be accepted.
Overriding the schema used for validation may cause RTA-RTE to raise unexpected errors, or may cause errors in the generated RTE source code. The
schema must only be overridden during the development stage of a project.
The code produced using an overridden validation schema must never be
used in production.
To override the validation schema, you must edit the RTEGen.ini file to supply the
location of the new schema file. For more details see Overriding the validation schema
in the RTA-RTE Reference Manual.
3.2.3

Object Names
All objects are named using the tag:
ThisIsMyNamedObject

The names allocated in the configuration for software component prototypes, ports,
runnable entities, interfaces etc. are used by the RTE generator to generate object
handles and customized API calls for use at runtime. This means that names you give
objects in the RTE configuration must be valid C identifiers.
The AUTOSAR schema restricts the maximum permitted length of short
names to 127 characters. A short name may only begin with an alphabetic
character (a-z and A-Z).
3.2.4

Packages
The element is a container for exactly one top level packages
element. The top-level packages element represents the root of an
XML object tree from which all objects in all configuration files can be accessed.
The top-level packages itself then contains one or more packages each defined with the
element. Each defines a group of AUTOSAR elements.
A package definition is named using the element. Each package should
have a unique name so that the elements contained within the package can be referenced by other packages, for example:

MyPackage
This is one of my packages

...

MyOtherPackage
This is another

Introduction to RTE Configuration

RTA-RTE V6.3.0
User Guide

The element is used to define the package name as well as acting as a
container for the descriptions. is a container for the components of an AUTOSAR configuration including:

• The definition of atomic software component types
• The description of component internal behavior
• The composition descriptions including software component prototype instantiation

• The definition of ECU types
• The system description including ECU instantiation
The element permits a hierarchical arrangement of packages to be
formed:

MyPackage
This is one of my packages

SWCs
...

Interfaces
...

...

AUTOSAR does not permit an arbitrary split of XML definitions between files. Instead,
files can only be split at the top-level packages level. When you need to work with
multiple XML files you must therefore split them at the top-level packages level.
In the previous example, we might have decided to split this file into two different files,
in which case in File 1 we would have:

MyPackage
This is one of my packages
...

Introduction to RTE Configuration

RTA-RTE V6.3.0
User Guide

In File 2 we would have the second AR-PACKAGE:

MyOtherPackage
This is another
...

With the exception of Module and ECU configuration elements within the ECUC Description and some “splittable” elements, RTA-RTE will reject configurations that have the
elements with the same name at the same level in the package hierarchy.
3.2.5

Referencing Objects
The elements in AUTOSAR XML define a hierarchical structure that is rooted at the toplevel packages element. Each named object within this structure can be
referenced.
The AUTOSAR XML makes extensive use of this referencing concept – objects are created using a set of elements and then referenced from other objects. For example,
when defining the ports of a software component you will need to reference interface
descriptions.
All references are indicated by XML elements with a tag ending *REF.
AUTOSAR XML allows references to be made using either absolute or relative paths.
An absolute path references an object from top of the XML tree and must start with a
forward-slash. For example:
<*REF>/MySystem/MyComponent/MyObject

The following example shows the use of absolute referencing:

PackageA

X
...

...

Introduction to RTE Configuration

RTA-RTE V6.3.0
User Guide

PackageB

/PackageA/X
...

/PackageB/X
...

3.2.6

Relative References
A relative reference can be distinguished from an absolute reference since
the latter always start with the ’/’ character. See the RTA-RTE Reference
Manual for more details on the use of absolute references within RTA-RTE.
The relative reference mechanism defines optional reference bases for each AUTOSAR
package. Each reference base defines the prefix to be used for relative references that
are associated with the reference base. For example, assume a package defines the
following reference base:

types
false
/autosar_types

Subsequently, within the package, relative references can be used that are associated
with base “types”. For example, the relative reference within the package that defines
reference base “types” above:
my_type

Is equivalent to the absolute reference:
/autosar_types/my_type

At most one reference base can be marked as the default for the package. The default reference base is used when a relative reference does not explicitly define the
associated base, e.g.:
my_type

Introduction to RTE Configuration

RTA-RTE V6.3.0
User Guide

3.2.7

Instance References
There is a special type of reference in AUTOSAR called an instance reference that is
used whenever you need to refer to a particular instance of an element. Instance
references are indicated with tags of the form <*-IREF>.
An instance reference itself comprises multiple reference elements each of which defines one part of the instance reference. The composite references depend on context;
for example they might include a reference to a component prototype, a port prototype
and a data element prototype.
When resolving an instance reference, RTA-RTE indirects through each context reference in turn to complete the reference. For example, the following instance reference:

/system/SWC/InputPort

/interfaces/SR/InputValue

Is interpreted as “find the context InputPort in software component SWC in ARPACKAGE system then look for a called InputValue in
the interface categorizing the port”. An instance reference is important to the correct operation of RTA-RTE since it enables the RTE generator to extract multiple pieces
of information from a reference, e.g. in the above example both the port prototype and
data element prototype can be located.
3.2.8

AUTOSAR Elements
The element provides the encapsulating element used to assemble all AUTOSAR definitions within an definition.
The element is not named since it is merely a container for other, named,
elements. There are essentially six sets of definitions:
1. Those that define basic types for the system.
2. Those that define the software components.
3. Those that define a logical software architecture built from the components independently of any hardware.
4. Those that define the physical hardware including the types of ECUs and how they
are connected to busses.
5. Those that define the network communication frames and protocols on busses
between ECUs.

Introduction to RTE Configuration

RTA-RTE V6.3.0
User Guide

6. Those that define how software components from the logical software architecture are mapped to ECUs and how logical communication is mapped into network
communication.

MyPackage
My AUTOSAR Test

The definition of AUTOSAR primitive and complex types is considered in Chapter 5.
The and elements are
used to define AUTOSAR interface types—see Chapter 6.
The
application
SWC-type

and
elements describe software components and
are considered in detail in Chapter 7. The of the components,
which includes which runnable entities exist, how they are triggered with RTE events,
how they define exclusive areas etc., is discussed in Chapter 8. Application modes
for software components and their interaction use
discussed in Chapter 9.
The software component types defined using the SWC-type element are instantiated
when a element is defined – see Chapter 13.
The and combine to define the hardware components that are
used to build a vehicle network. These are discussed in Chapter 17.
The element maps the software component instances on the composition
onto the hardware topology instance. This is covered in Chapter 18. However, this
is not the final stage in configuration. When a mapping is such that communication
between software components occurs between ECUs (inter-ECU communication) you
need to provide additional configuration to tell the RTE how to achieve this using AUTOSAR COM. This is discussed in Chapters 19 and 20.

3.3

ECU Configuration Description
RTA-RTE makes use of AUTOSAR OS for executing threads of control, providing timeouts, signaling events etc., and AUTOSAR COM for communication between ECUs.
Introduction to RTE Configuration

RTA-RTE V6.3.0
User Guide

For the RTE to be generated, RTA-RTE needs to know a small set of configuration data
for these AUTOSAR basic software modules.
AUTOSAR basic software uses a different configuration concept from the rest of AUTOSAR that is held in the ECU configuration description file. This file is also an XML file,
but the use of XML is significantly different from the rest of AUTOSAR configuration.
Rather than define a dedicated configuration for each basic software module, the ECU
configuration description defines how to structure a ECUC module configuration with
containers that hold configuration data. An ECUC Container element can hold subcontainers and thus a hierarchy of configuration containers is formed.1

...

Each ECUC Module Configutation container contains a that defines
what containers there are and how many of each type are needed for the referenced
basic software module.
All definition references have the form /AUTOSAR/. For the RTE configuration you will use:

• /AUTOSAR/Com
• /AUTOSAR/Os
• /AUTOSAR/Rte
ECU configuration descriptions are verbose, so for clarity this user guide will describe ECU configuration description in terms of which parameters referenced by the
1

The ECU configuration description is basically a meta-language embedded within XML that is instantiated for each basic software module.

Introduction to RTE Configuration

RTA-RTE V6.3.0
User Guide

are needed, for example: “An /AUTOSAR/Os/OsTask must be created for each RTE task you require.” /AUTOSAR/Os tells you the module for which configuration is needed and OsTask tells you that an OS task needs to be created. This is
equivalent to the following configuration:

Os
/AUTOSAR/Os

...

RTE_Task1
/AUTOSAR/Os/OsTask

...

Introduction to RTE Configuration

RTA-RTE V6.3.0
User Guide

Working with the RTE Generator
The separation of the development and integration phases in AUTOSAR is reflected in
a two-phase software component development process:
1. Software Component Development: the specification, design and implementation
of software components; then
2. Software Component Deployment: the allocation of components to ECUs and the
integration of components with the basic software on the ECU.
The two phases of operation allow for initial software component configurations to be
made and integrated onto the VFB (through some auxiliary design and development
process) then the RTE interface to be generated so that the software components can
be implemented before the prototypes are defined and their particular allocation onto
an ECU are known.
AUTOSAR R4.0 also defines a third development phase for integration of basic software
into an ECU. The basic software phase enables the creation of a “Basic Software Scheduler” that invokes multiple basic software modules at the correct time and integrates
their execution with application software components.
The phased development process means that there can be some time between the
development of a component type and the allocation of its component prototypes to
an ECU. A component could be developed once and re-used multiple times over many
generations of vehicles. The component could also be supplied to an integrator in
binary form for integration in an ECU with other components that have not yet been
written.
The RTE generator supports the phased process by allowing the interface to the RTE
to be generated before the component prototype/ECU allocation has been decided.
Given a software component description, the RTE generator has enough information
to generate interface definition files, allowing engineers to start developing software
components. The interface defines the contract between the RTE and the component,
that is, what that component must provide if future integration work is to happen easily.
This is known as contract phase.
When the system is integrated, and the mapping of software components to ECUs is
known, the RTE itself can be generated. However, we now know how many instances
of a software component exist, where runnable entities are executing, which communication is local to an ECU and which must be routed across the network etc. The RTE
generator can use this information to re-generate the interface definition files to include
optimizations based on this additional context. This is known as “RTE phase”.
The following sections discuss the contract and RTE phases in more detail.

Working with the RTE Generator

RTA-RTE V6.3.0
User Guide

4.1

Contract Phase
In AUTOSAR, the interface to a software component is captured in a “software component description” written in XML.
The component description is a promise that a software component will have certain
properties, for example:

• It will provide a set of ports.
• The ports are typed by defined interfaces.
• It will provide a set of runnable entities.
• It will respond to certain RTE events.
The software component description also contains obligations for the ECU integrator,
that is, the person who will create instances of the software component prototype and
integrate those prototypes with the basic software on an ECU. For example:

• RTE events must be scheduled at the specified rates.
• Only ports that use the same, compatible, or convertible interfaces can be connected.
The software component description must contain enough information to generate an
RTE interface that encapsulates the functional aspects of the contract.
The component descriptions are generated early in the process and can be used with
the RTE generation tools to build a framework for developing the components. The
“Software Component Descriptions” form the input to the first part of the RTE generation process where the interface contracts, in the form of C header files, can be generated without reference to the final system or to the allocation of specific components
to ECUs.
In the contract phase, the RTE generator produces header files to be used in the components you write.
Type Definitions
(Rte_Type.h)

Configuration
(XML)

RTEGen
Application Header
File

Figure 4.1: Contract Phase

Working with the RTE Generator

RTA-RTE V6.3.0
User Guide

4.1.1

Generation
In contract phase, RTA-RTE generates software component-specific application header
files in their most general form. The header files define the contract between the component and the system as a whole, and are suitable for both binary-code and sourcecode components. When running in the contract phase, the RTE generator only needs
access to the software component description file(s). It is not necessary to have any
information about system deployment.
During contract phase, the RTE is generated for a named software component with the
following command line:
RTEGen -c [options] .arxml
Where must be an absolute reference to a software-component type defined in the input. For details on additional options please see the RTA-RTE Reference
Manual.
Each execution of the RTE generator in contract phase produces the application header
file for a single component.

4.1.2

Software Component-Specific Header Files
Access to the RTE API for each declared component type is provided by a component
type-specific “application header file”. This file will be generated twice during your
system development process:
1. During the contract phase where a generic version of the file is generated.
2. During the RTE phase where an optimized version is generated.
The name of the application header file is derived from the component type name
assigned by the vendor, rather than the name assigned by the system integrator to the
component prototype during deployment.
The header file names have the following format:
Rte_.h
The component type name is used for two reasons:
1. The same component code is used for all component prototypes.
2. Object-code software components may be compiled before the number, or
names, of all the component prototypes used in the ECU are known.
The definitions in the XML file are used to define the APIs, so only valid runnable entities
may be declared without an error occurring when the component is compiled.

Working with the RTE Generator

RTA-RTE V6.3.0
User Guide

The RTE generator also generates an “application types file” that defines types specific
to a particular SW-C type. The name of this file is
Rte__Type.h
Component Type & Instance Declarations
For each component type declaration, the RTE generator creates a component data
structure type. The definition of this type is unique for each component and is written
to the component type header file.
When the RTE generator is run in the RTE phase, the RTE implementation includes
optimizations that can reduce the run-time cost of the instance handle to zero. For
example, when only one prototype of a component is mapped to an ECU, the instance
handle is not needed and can be elided.
4.1.3

Object-code Support
The RTE supports both application software components where the source is available
(“source-code software components”) and application software components where
only the object code (“object-code software components”) is available.
The header files generated in contract phase contain sufficient detail to allow a component to be developed and shipped as object files to the ECU integrator.
The only effect of shipping components in object-code format is that they cannot make
use of the optimizations that the RTE generator may make when the allocation of component instances to ECU instances is known.

4.2

RTE Phase
Before using RTA-RTE in RTE phase, a significant amount of system engineering will be
needed. The AUTOSAR development process assumes that there are several inputs to
the system engineering process:

• “Software component descriptions” that define the software components, their
ports, internal behaviors, implementation characteristics, and the interfaces provided and required by their ports. These are the same descriptions as used in
contract phase.

• “ECU resource descriptions” that define the ECU hardware characteristics (e.g.
communication ports).

• A “System constraint description” that defines aspects of the system (e.g. communication protocols).
To build an AUTOSAR system (i.e. a set of software components mapped to ECUs that
communicate over a network) you must define:

• “ECU configuration description” that defines which software components are
mapped to which ECUs, the resources available on the ECU, and so on.
Working with the RTE Generator

RTA-RTE V6.3.0
User Guide

• “System configuration description” that defines the network topology, how interECU communication is mapped to the physical network, and so on.

• “ECU Configuration” that defines the mapping between elements; for example, the
mapping of runnable entities to AUTOSAR Operating System tasks and the mapping
of AUTOSAR signals to AUTOSAR COM signals.
Once you have configured your AUTOSAR system with an allocation of component prototypes to ECU instances the RTE generator is used in “RTE Generation” phase to create:
1. The implementation of the RTE itself, Rte.c, and the generated library Rte_lib.c.
2. Optimized component header files that exploit mapping knowledge provided by
your configuration.
3. Operating system tasks that package your runnable entities.
4. (optional) An operating system configuration file for the RTE- generated objects
and required behavior.
5. (optional) A communication stack configuration file for inter-ECU communication
configuration.
Figure 4.2 illustrates the basic process.
The AUTOSAR configuration process includes tools for the generation of
RTE and generation/configuration of the OS and the communication stack.
Within RTA-RTE all three steps are integrated into the single RTE generator.
4.2.1

Generation
In RTE phase, the RTA-RTE generator generates optimized application header files suitable for compiling source-code components and, optionally, configuration files for the
communication stack and operating system. When running in RTE phase, the RTE generator needs access to all system deployment information.
For RTE phase, the RTE is generated for a named ECU instance with the following command line:
RTEGen -r [options] .arxml
The RTE is generated for each software component and each ECU specified in the configuration file using the command-line RTE generator tool. Each execution of the RTE
generator in RTE phase produces the generated RTE for a single ECU instance.

4.2.2

RTE Implementation File
The RTE is generated as one or more C modules. Each module must be compiled according to the dependency information created by the RTE.
The module Rte.c contains the core of the generated RTE and, when the RTE generator
is operating in compatibility mode, the generated task bodies.
40

Working with the RTE Generator

RTA-RTE V6.3.0
User Guide

Type Definitions
(Rte_Type.h)

Application Header
Files

Configuration
(XML)

RTEGen

Generated RTE
(Rte.c)

Task bodies

OS and COM
configuration

Figure 4.2: RTE Phase
4.2.3

Task Bodies
During “RTE Generation” phase, the RTA-RTE RTE generator creates task bodies and
assigns runnable entities to them based on the mapping specified in the ECU configuration.
The names of the tasks are used verbatim from the configuration file. If a task called
MyTask is declared then a task called MyTask will be generated. All task names in an
ECU must be unique.
In compatibility mode, all RTE tasks are generated in the Rte.c source code
file. When using vendor mode Each task body is written to a separate file
named .c. You must ensure that the tasks generated by the RTE
generator are compiled and linked with the rest of your ECU code.
The generated task bodies are appropriate for the selected OS, e.g. for AUTOSAR OS
the task is declared using the TASK macro and the body includes the TerminateTask
API call.

4.3

Basic Software Phase
The primary inputs within this phase are the “Basic Software descriptions” that define
the basic software modules’ internal behavior and implementation characteristics, in-

Working with the RTE Generator

RTA-RTE V6.3.0
User Guide

cluding the interfaces provided and required by the module.
The Basic Software Phase generates the APIs and code to support BSW code only. If
the input XML contains Software Component configuration then the configuration is
rejected by RTEGen.

4.4

The Development Process
Figure 4.3 shows the five key stages in the generation of an RTE-based ECU:
1. The initial “contract” phase of RTE generation defines the interface (componentspecific “application header” files) for each software component based on information from the software component descriptions. A software component compiled with a contract phase application header can be delivered to the integrator
as object-code.
2. The “RTE” phase generates an RTE for a specific ECU, configured from the “ECU
Extract”. The ECU Extract is a slice of the System Configuration Description, containing only information related to a single ECU. This can be distributed to the
developers of the ECU without the risk of disseminating confidential information
about other ECUs.
A software component compiled with an RTE phase application header can be
delivered to the integrator as source-code.
3. The RTE generator (optionally) creates configuration files for the ECU, including
OS configuration and dependency information for the creation of “makefiles” or
build scripts for building the RTE.
4. The generated RTE is compiled along with application software components using
build information created by the RTE generator.
5. The RTE library file is compiled and linked with the other application code to form
the executable ECU image.

4.5

Samples
RTA-RTE can generate sample application source files using the --samples=swc
command-line option. The name of the generated sample file is Rte_.c where
swc is the software component’s short name.
The generated sample file contains an empty function for each runnable entity. For
example, given a software component swcA that supports multiple instantiation and
contains a single time triggered runnable with entry point swcA_re_te1, the generated
sample file would contain:
/** @file
*
* @brief
*/
42

Rte_swcA.c
RTE Sample SWC implementation skeleton file

Working with the RTE Generator

RTA-RTE V6.3.0
User Guide

#include "Rte_swcA.h"
FUNC(void, RTE_APPL_CODE) swcA_re_te1(CONSTP2CONST(Rte_CDS_swcA,
AUTOMATIC, RTE_CONST) self)
{
/* ... */
}
The --samples=swc option is most useful in contract phase before starting implementation of a software component.

Working with the RTE Generator

RTA-RTE V6.3.0
User Guide

SWC
description

ECU Extract

1
RTEGen
Contract Phase

2
RTEGen

Basic SW
configuration

RTE
Phase

Application
header file

Generated
RTE

3
OS Config

Application
header files

4
OS
Configuration
tool

Object-code
SWCs

OS
(library)

Basic SW

RTA-RTE
library

Source-code
SWCs

Build

5
ECU

Figure 4.3: AUTOSAR Design Flow—Supplier based RTE Development

Working with the RTE Generator

RTA-RTE V6.3.0
User Guide

Part II

Developing Software
Components

RTA-RTE V6.3.0
User Guide

Type System
AUTOSAR defines three layers of data type abstraction as illustrated in Figure 5.1.
Application Types
Implementation Types
Base Types

Figure 5.1: Abstraction Levels for Describing Data Types
ApplicationDataTypes are defined in physical terms, i.e. by reference to some
CompuMethod, Unit and PhysicalDimension. This allows Application authors to create Software Components without deciding the C data type too early in the lifecycle.
ApplicationDataTypes also support automatic conversion of values from one Unit to
another. (See section 5.5 and section 13.5 for more information.)
ImplementationDataTypes model C types in the generated code. AUTOSAR specifies
a set of common ImplementationDataTypes known as the Platform Types, to make
platform-independent modeling and design easier.
Finally, Base Types describe the hardware-specific aspect of the data type, e.g. the
width, the alignment and the encoding. In particular, the shortName of the SwBaseType
element does not appear in the generated code.
The following sections expand these topics.

5.1

Application Data Types
Application data types are defined in physical terms, i.e. by reference to some Unit
which, in turn, references some PhysicalDimension. It is recommended to model
VariableDataPrototypes by referencing ApplicationDataTypes:

• Using ApplicationDataTypes allows the System Integrator to choose the
ImplementationDataType later in the development cycle,

• RTE supports data conversion of values between different ApplicationDataTypes
(Section 5.5, section 13.5),

• ApplicationDataTypes contain the necessary information to support measurement and calibration tools.
The shortName of an ApplicationDataType is only used within the scope of a
SoftwareComponentType, so it is supported to have multiple ApplicationDataTypes
with the same name when integrating several SWCTs on a single ECU (but not within a
single SWCT).

Type System

RTA-RTE V6.3.0
User Guide

The shortName of an ApplicationDataType is not used in generated code. In particular, the RTE APIs are defined in terms of the mapped ImplementationDataTypes
(according to the DataTypeMapping—see Section 5.4).
The attributes of ApplicationDataTypes include the range of physical values, the relationship to physical space (i.e. references to CompuMethod and/or Unit) and, for complex types, the data structure. The definition of an ApplicationDataType does not
consider implementation details such as width in bits, endianness, etc.
For example, an ApplicationPrimitiveDataType might be declared as follows:

length_in_metres
1

metres
1
0
/package/
length_in_metres

cm_id_metres
IDENTICAL
/package/metres

MyMetresType
VALUE

NOT-ACCESSIBLE
/package/cm_id_metres

Starting at the top, we have a PhysicalDimension representing e.g. Length or luminosity or temperature or speed etc.
Below that we have a Unit. For this example, we show the SI unit for length, the metre.
Similarly we could model the kilometre by setting FactorSIToUnit at 1000.
The CompuMethod is of Category IDENTICAL which means that the value on the ECU at
runtime is the same as the value of the physical quantity.
Additionally, we might define another application type like below:

Type System

RTA-RTE V6.3.0
User Guide

cm_centimetres
LINEAR
/package/metres

0
1

100

MyCMType
VALUE

NOT-ACCESSIBLE
/package/cm_centimetres

Here the CompuMethod cm_centimetres contains a CompuDenominator of 100. Since
it also references Unit metres a VariableDataPrototype of type MyCMType, it can be
connected to a VariableDataPrototype of type MyMetresType and RTA-RTE will create
the necessary code so that, e.g. a transmission of 100cm will arrive on the receiver as
1m.
To support more complex data types, an ApplicationDataType can be composed of
other ApplicationDataTypes. This form of recursive definition permits records and
arrays to be defined.
When the RTE is generated, any used Application Data Types must be mapped to implementation types. See Section 5.3 and 5.4 for details.
5.1.1

Arrays
To configure an array type in the application domain,
create an
ApplicationArrayDataType
that
contains
a
reference
to
the
desired
ApplicationDataType of the elements and the ArraySize set to the number of
elements required.
48

Type System

RTA-RTE V6.3.0
User Guide

This release of RTA-RTE does not support dynamic-sized arrays. ArraySizeSemantics must therefore be set to FIXED-SIZE.
For example an array of four lengths in centimetres could be represented with the
following type:

MyCMArrayType
ARRAY

NOT-ACCESSIBLE

element
VALUE
/package/MyCMType
FIXED-SIZE
4

Arrays of complex types can also be created,
by referencing an
ApplicationArrayDataType or ApplicationRecordDataType as the element type
and setting the element Category to ARRAY or STRUCTURE respectively.
5.1.2

Structures (also known as Record types)
To configure a record type in the application domain, to be mapped to a struct in
the implementation domain, create an ApplicationRecordDataType that contains
an ApplicationRecordElement for each structure member, referencing the desired
ApplicationDataType.
For example, the coordinates, in centimetres, of a point on a surface could be represented with the following type:

MyPointType
STRUCTURE

NOT-ACCESSIBLE

Type System

RTA-RTE V6.3.0
User Guide

VALUE
/package/MyCMType

y
VALUE
/package/MyCMType

Record elements can themselves be complex types.
Simply reference
an
ApplicationArrayDataType
or
ApplicationRecordDataType
as
the
ApplicationRecordElement type and set the ApplicationRecordElement Category to ARRAY or STRUCTURE respectively.

5.2

Base Types
SwBaseTypes describe data types in hardware terms (size in bits, memory alignment,
encoding). They form the basis on which the Implementation Data Types are built. A
base type can be referenced by several Implementation Data Types. In this way, the
C declarations of Implementation Data Types can be adjusted for different hardware
platforms by changing only the attributes of the referenced Base Type.
For example, the semantics of two 8-bit integer base types might be modeled as follows:

my_sint8
8
2C
1
char

my_uint8
8
NONE
1
unsigned char

The base type’s shortName never appears in the generated code; it is
only used as a reference target within the input model. Only Implementation Data Types are present in the generated code along with the
nativeDeclaration of the referenced basetype.
The encoding attribute can be either NONE, for unsigned types, or 2C, 1C or SM for signed
types.
50

Type System

RTA-RTE V6.3.0
User Guide

The nativeDeclaration attribute is optional but strongly recommended. It is usually
an error to omit the nativeDeclaration, except as part of a deprecated scheme for
suppressing the generation of a typedef. (See 5.3).
If present, it contains a raw C type-expression necessary to produce a type of the same
width and signedness as the SwBaseType itself. This text will typically be written on the
left hand side of a typedef of a referencing ImplementationDataType, e.g.
typedef unsigned int myImplementationDataType;
It is not correct to write the name of a PlatformType in the
nativeDeclaration, only raw C like unsigned int, signed long,
etc.
If you really think you need to do this, consider defining an
ImplementationDataType of Category TYPE_REFERENCE instead (See 5.3.6)

5.3

Implementation Data Types
ImplementationDataTypes represent types in the generated C code. The shortName
of an ImplementationDataType defines the symbol used in C to access the type, e.g.
in APIs and in user code.
Typically, ImplementationDataTypes have their typeEmitter attribute set to RTE and
result in typedef declarations being written to the file Rte_Type.h.
Some ImplementationDataTypes need to be modeled in the input but it is not desirable
to generate corresponding typedefs in the RTE code, for example the Platform Types,
whose C declarations are present in a standard header file not generated by the RTE
Generator (see 5.3.1). To suppress the typedef, specify the typeEmitter attribute with
a value other than RTE.
For backward compatibility, RTA-RTE also includes a deprecated mechanism
for suppressing typedefs.
If there is no typeEmitter attribute on the
ImplementationDataType, the generation of the typedef depends on the
SwBaseType.nativeDeclaration. If the nativeDeclaration is absent or empty, and
there is no typeEmitter present on the corresponding ImplementationDataType, no
typedef is written.
It is an error to have a missing or empty SwBaseType.nativeDeclaration if
the ImplementationDataType.typeEmitter is set to RTE.
It is supported to define VariableDataTypes in SWCTs by reference to Application Data
Types or Implementation Data Types, and it is supported to mix them freely. However
it is recommended to use only Application Data Types in SWCTs for the reasons already
given:

• Avoid deciding the C type too early in the lifecycle,
• Allow data conversion between values that represent the same physical quantity,
• Support measurement and calibration tools.
Type System

RTA-RTE V6.3.0
User Guide

RTA-RTE always uses Implementation Data Types in generated APIs. If the corresponding VariableDataPrototype is defined by reference to an ApplicationDataType, the
mapped ImplementationDataType is used in the API signature.
AUTOSAR data types must be declared in the XML input configuration if they
are to be used in Interfaces, ARTypedPerInstanceMemorys, etc. In addition, all
PlatformTypes must be declared on the input regardless of whether they are used
in the input model. This is because RTA-RTE depends on PlatformTypes to create its
internal types.
It is supported that multiple ImplementationDataTypes in the input XML have the same
name, provided that the resulting definitions in the generated code are identical. This
makes it easier to integrate packages from different third parties, which may for example include (re)definitions of Platform Types.
This section explains how to configure RTA-RTE to make types available to the C program and to the rest of the configuration input.
5.3.1

Platform Types
AUTOSAR specifies a set of platform types for use in C code.
These are
ImplementationDataTypes whose purpose is to provide a set of types with the same
semantics across different target hardware. RTA-RTE uses PlatformTypes when it
needs to create types for internal variables.
Unlike most ImplementationDataTypes, the PlatformTypes are also defined in C language in the file PlatformTypes.h. To support this, they reference SwBaseTypes with
empty or missing nativeDeclaration attributes (See 5.2).
AUTOSAR (from R4.0.3) also specifies the correct definitions and package name of the Platform Types.
RTA-RTE expects to find the package
_
AUTOSAR Platform/ImplementationDataTypes on the input, and it will look in
that package for any Platform Types that it needs. RTA-RTE will reject the configuration
if it does not include such a package.
RTA-RTE ships with a suitable Platform Types package (in the file
External/AUTOSAR/AUTOSAR_MOD_PlatformTypes.arxml).
Note
that
the
corresponding
SwBaseTypes
are
defined
in
a
separate
file
_
_
External/AUTOSAR/AUTOSAR MOD PlatformBaseTypes.arxml.
The Platform Types defined in AUTOSAR Specification of Platform Types and in the standard header file Platform_Types.h are:

• sint8 – 8-bit signed integer.
• uint8 – 8-bit unsigned integer.
• sint16 – 16-bit signed integer.
• uint16 – 16-bit unsigned integer.
52

Type System

RTA-RTE V6.3.0
User Guide

• sint32 – 32-bit signed integer.
• uint32 – 32-bit unsigned integer.
• float32 – single precision floating point.
• float64 – double precision floating point.
• uint8_least – at least 8-bit unsigned integer.
• uint16_least – at least 16-bit unsigned integer.
• uint32_least – at least 32-bit unsigned integer.
• sint8_least – at least 7-bit signed integer (plus sign bit).
• sint16_least – at least 15-bit signed integer (plus sign bit).
• sint32_least – at least 31-bit signed integer (plus sign bit).
• boolean – for use with TRUE/FALSE.
When a platform type is used in the input model, e.g. in an Interface, it might be
referenced in the standard location (/AUTOSAR_Platform/ImplementationDataTypes)
or the definition of the platform type might be repeated in another
ImplementationDataType element with the same shortName.
Both styles are
supported, provided the ImplementationDataTypes do not give rise to conflicting
definitions. In particular, the SwBaseTypes should both have empty or missing
nativeDeclaration, they should have matching baseTypeWidth and matching
encoding.
The correct way to represent a platform type in the XML input is by using
an ImplementationDataType of Category VALUE with the ShortName equal
to the name of the AUTOSAR Platform Type, which refers to a SwBaseType
element that does not have a nativeDeclaration.

pkg

dcI_uint8

0
255

bt_null_uint8

Type System

RTA-RTE V6.3.0
User Guide

8
1

uint8
VALUE

/pkg/bt_null_uint8
/pkg/cm_id
/pkg/dcI_uint8

Note that the ShortName of the SwBaseType never appears in the generated code in
any circumstances. It is only ever used as a means of referencing the SwBaseType in
the XML.
5.3.2

Custom Primitive Implementation Data Types
It is supported to configure new ImplementationDataTypes, either by reference to existing platform types (recommended) or completely from scratch (not recommended).
Enumeration (text table) types can be modeled in this way. The configured types are
written to the file Rte_Type.h.
It is not always necessary to define a completely new type just to give a semantically significant name to a type. Instead, an ImplementationDataType can be created with Category TYPE_REFERENCE in order to emit a typedef from an existing
ImplementationDataType to the more useful name, and to provide a single point at
which the actual type of the chosen typename can be changed.
For example, the following definition of type MyCommandIdType:

MyCommandIdType
TYPE_REFERENCE

/AUTOSAR_Platform/
ImplementationDataTypes/uint8

Type System

RTA-RTE V6.3.0
User Guide

Results in the following typedef in Rte_type.h:
typedef uint8 MyCommandIdType;
The new TYPE_REFERENCE type can then be referenced
ARTypedPerInstanceMemorys, InterRunnableVariables, etc.

Interfaces,

It is possible (but not recommended) to define a new ImplementationDataType that
is not defined by reference to an existing ImplementationDataType but instead references a SwBaseType that has a nativeDeclaration.
To do that, set the Category to VALUE and use a BaseTypeRef pointing to the chosen SwBaseType. The emitted typedef in Rte_type.h uses the nativeDeclaration
of the SwBaseType as in the following example, where the nativeDeclaration is
unsigned int:
typedef unsigned int MyMaskType;

This method is not recommended because the type may become hardwareplatform dependent.
The reference within a new ImplementationDataType declaration
defines the constraints of the type. In particular, RTA-RTE needs to know the type limits:

myDataConstraint

0
6000

RTA-RTE does not validate that the range specified by the constraints is compatible with the specified native declaration.
5.3.3

Enumerated Types
To declare an enumerated type, create a new ImplementationDataType of category TYPE_REFERENCE and add an ImplementationDataTypeRef referencing a suitable
PlatformType to store the enumeration values.
Create a CompuMethod of category TEXTTABLE and reference the CompuMethod from the
new ImplementationDataType. The CompuMethod supplies the symbolic and numeric
values for the enumerated type, for example:

myEnum

Type System

RTA-RTE V6.3.0
User Guide

TYPE_REFERENCE

myEnumValues
/
AUTOSAR_Platform/ImplementationDataTypes/sint8

myEnumValues
TEXTTABLE

0
0
ZERO

1
1
ONE

2
2
TWO

3
3
THREE

RTA-RTE will reject invalid CompuMethods, for example, those with duplicate labels
and/or numeric values with different lower- and upper-limits.
Now when the type is used within a SWC-type RTA-RTE creates definitions for use by
the SWC implementation. In the Type Header File Rte_Type.h:
typedef uint8 myEnum;
And in the Application Type Header File Rte__Type.h:

Type System

RTA-RTE V6.3.0
User Guide

#define
#define
#define
#define
5.3.4

ZERO ((myEnum)0)
ONE ((myEnum)1)
TWO ((myEnum)2)
THREE ((myEnum)3)

Arrays
To configure a fixed-size array, create an ImplementationDataType of category ARRAY
that contains an ImplementationDataTypeElement having an ArraySizeSemantics of
FIXED-SIZE and an ArraySize set to the number of elements you wish to have in the
array. The shortName of the ImplementationDataTypeElement does not appear in the
generated C.
This release of RTA-RTE does not support dynamic-sized arrays.
The category and configuration of the ImplementationDataTypeElement dictates the
type of the array element.
Rather than use Category VALUE,
TYPE_REFERENCE. (See Section 5.3.6).

recommended

use

Arrays as Function Parameters
AUTOSAR specifies that arrays used in API calls shall be passed as “pointer to base
type”. This does not refer to SwBaseType but rather to the type information of the
ImplementationDataTypeElement. RTA-RTE creates a formal parameter of a pointer to
that type, for example:
typedef unsigned short myValueType;
typedef myValueType myArrayType[4];
...
// Write of the array type is by pointer to ’base type’
FUNC(Std_ReturnType, RTE_CODE) Rte_Write_myPort_myArrayData(P2CONST(
myValueType, AUTOMATIC, RTE_APPL_DATA) data);
If the array is defined using an ImplementationDataTypeElement of a category other
than TYPE_REFERENCE, there is no typedef for myValueType, which may cause the generated code to fail MISRA advisory rule 6.3:
typedef unsigned short myArrayType[4];
...
// Write of the array type is by pointer to ’base type’
FUNC(Std_ReturnType, RTE_CODE) Rte_Write_myPort_myData(P2CONST(
unsigned short, AUTOMATIC, RTE_APPL_DATA) data);
// MISRA advisory 6.3: unsigned used outside of a typedef
// MISRA advisory 6.3: short used outside of a typedef

Type System

RTA-RTE V6.3.0
User Guide

5.3.5

Structures (also known as Record types)
To configure a struct type, create an ImplementationDataType of category
STRUCTURE that contains an ImplementationDataTypeElement for each structure
member. The ShortName of the ImplementationDataTypeElement becomes the name
of the structure member.
For example, the declaration of structure MyStructType in the input configuration:

myuint8bt
8
1
unsigned char

MyStructType
STRUCTURE

member_a
TYPE_REFERENCE

/pkg/uint8

member_b
VALUE

/custom_types/myuint8bt
/compu_methods/cm_id
/data_constrs/dcI_uint8

Produces the following struct definition in Rte_Type.h:
typedef struct {
uint8 member_a; /* recommended */
58

Type System

RTA-RTE V6.3.0
User Guide

unsigned char member_b; /* Not so safe */
} MyStructType
The category and configuration of each ImplementationDataTypeElement dictates the
type of the corresponding member.
Rather than use Category VALUE,
TYPE_REFERENCE. (See Section 5.3.6).
5.3.6

recommended

use

Declaring the elements of Complex Types
The category of an ImplementationDataTypeElement can be any of TYPE_REFERENCE,
STRUCTURE, UNION or ARRAY. VALUE, HOST, DATA_REFERENCE and FUNCTION_REFERENCE
are also allowed according to the AUTOSAR specification, but are not recommended as
noted in the following subsections.
TYPE_REFERENCE This
is
the
recommended
category
for
ImplementationDataTypeElement instead of VALUE or HOST. By creating a
separate ImplementationDataType for the VALUE or HOST type, and referencing
it from the ImplementationDataTypeElement, you create a shortname that is
used in the declaration and therefore makes the definition clear.
typedef uint8 MyElementType;
typedef MyElementType MyArrayType[4];
STRUCTURE / UNION / ARRAY By declaring an ImplementationDataTypeElement
that is itself of a complex type, you can create nested complex types, e.g. an
array of structs, a struct containing an array and a union, etc. This nesting can
be continued without limitation, but remember that using a TYPE_REFERENCE can
help to keep the configuration clearer.
VALUE / HOST An ImplementationDataTypeElement of category VALUE or HOST creates the element anonymously, i.e.
there is no named type that characterizes the element. If the ImplementationDateTypeElement refers to a
SwBaseType with a nativeDeclaration, the native declaration is written to
the generated C. This approach is not recommended because it carries a
risk of becoming hardware-dependent. Instead it is recommended to use an
ImplementationDataTypeElement of category TYPE_REFERENCE and refer to a
named, platform-safe ImplementationDataType.
If an ImplementationDataTypeElement references a SwBaseType with no
nativeDeclaration, the configuration is rejected because there is not enough
information to create the declaration in C. (Remember that the ShortName of a
SwBaseType never appears in the C as the name of a type, only the short names
of ImplementationDataTypes or the native declarations of SwBaseTypes.)

Type System

RTA-RTE V6.3.0
User Guide

When an ImplementationDataTypeElement is of category
other than TYPE_REFERENCE, it causes the C declaration (e.g.
nativeDeclaration) to be written directly to the generated C
where the type is used, e.g. in struct declarations and in API parameters, leading to the use of keywords like unsigned or short appearing
outside of typedefs. This violates MISRA advisory rule 6.3.
DATA_REFERENCE / FUNCTION_REFERENCE These result in pointer types. It is generally dangerous and forbidden to use a pointer for any communication between
SWCs or Runnables within a SWC. It is not recommended to use DATA_REFERENCE
or FUNCTION_REFERENCE for communication.

5.4

Type Mappings

5.4.1

Data types
A SWC-specific data type mapping is used to map application types onto implementation types. The use of a separate mapping means that different SWC types can
use different implementations of the same application type and permits, for example, changing data type characteristics if a SWC is moved to a new hardware platform
without changing the SWC itself.
RTA-RTE requires a data type mapping for each application type that is used
in the model in order to be able to generate the RTE.
The data type mapping for a SWC is held within a data type mapping set element:

dts1

...

The data type mapping is associated with a SWC type via a reference to the mapping
set from the SWC’s internal behavior. If required, one type mapping could be reused
for multiple SWCs, or the mapping could be modified without modifying the SWC itself.
A data type mapping contains one or more data type maps. Each map references a
single application data type and a single implementation data type.

/pkg/ApplType1

/pkg/SInt16

Type System

RTA-RTE V6.3.0
User Guide

As well as mappings within an individual SWC-type, RTA-RTE also supports a data type
mapping for the root composition SWC-type. This means that mappings for a configuration can be specified, and changed, without modification of the individual SWCs.
5.4.2

Mode types
Mode type mappings are used to map mode declaration groups onto implementation
types.
RTA-RTE requires a mode type mapping for each used mode declaration
group in order to be able to generate the RTE.
As with data type mappings, a mode type mapping is contained within a data type
mapping set element:

dts1

...

The mode type mapping is associated with a SWC type via a reference to the mapping
set from the SWC’s internal behavior.
A mode type mapping contains one or more mode request type maps. Each map references a single implementation data type and a single mode declaration group.

/pkg/SInt16

/pkg/mdg1

Multiple mode type mapping elements can reference the same implementation data
type.

5.5

Application Types And Numerical Representations

5.5.1

Concepts
RTA-RTE Supports AUTOSAR Data Conversion (see 13.5), where a connection may be
made between data items (or the sub-elements of complex-typed data items) of different, but related, ApplicationPrimitiveDataTypes. This depends on the correct
modelling of ApplicationPrimitiveDataTypes and how their numerical values relate
to physical quantities.

Type System

RTA-RTE V6.3.0
User Guide

Linear Data Conversion
When
DataPrototypes
with
incompatible,
but
related,
ApplicationPrimitiveDataTypes
are
explicitly
connected
via
a
PortInterfaceMapping (see section 13.3.4), RTA-RTE seeks to generate a linear conversion (rescaling and offset) of values between them. It evaluates the
CompuMethods and Units for both DataPrototypes, or for the primitive sub-elements if
the DataPrototypes have complex type, to derive what data transformation is needed.
Linear data conversion is also attempted between the primitive sub-elements of
DataPrototypes with complex ApplicationDataTypes, provided that they are shapecompatible.
Conceptually, the data conversion function is a functional composition of the individual transformations from the transmitted value x, through the Physical representation,
to the SI representation, to the Physical representation in the receiver’s Unit, to the
internal received value y :

f = cmrx ◦ unitrx ◦ unittx ◦ cmtx
or

y = cmrx (unitrx (unittx (cmtx (x))))

output

Where cmtx , unittx , unitrx and cmrx represent each step of the conversion as a linear
function that maps the input value to an intermediate output value. Figure 5.2 illustrates a linear function.

rxval

txval
Figure 5.2: Linear data conversion

Type System

input

RTA-RTE V6.3.0
User Guide

Since each function is linear it can be expressed as a line of the form y = (m × x) + c
where m is the gradient and c the offset. RTA-RTE derives the values for m and c from
the transformations specified in the CompuMethods and in the Units:

cmrx is the function represented by the CompuMethod of the receiving type in the
“physical-to-internal” direction.
The cmrx function is “linear” and is derived from the
element’s numerators num0 and num1 within the element
and the denominator denom from the element. The cmrx
function can then be defined as:

cmrx (x) =

num0 + (num1 × x)
denom

unitrx is the function represented by the FactorSIToUnit and OffsetSIToUnit of the
receiving type in the “physical-to-internal” direction.
As with the cmrx function, the unitrx function is “linear” but the gradient,
m, and offset, c, are derived from the Unit’s and
elements. The unitrx function can then be defined as:

unitrx (x) = (m × x) + c
unittx is the function represented by the FactorSIToUnit and OffsetSIToUnit of the
transmitting type in the “internal-to-physical” direction.
The unittx function is “linear” and the gradient, m, and offset, c, are derived
from the Unit’s and elements. The
unittx function can then be defined as:

unittx (x) = (m × x) + c
The unittx function is the inverse of the unitrx function.

cmtx is the function represented by the CompuMethod of the transmitting type in the
“internal-to-physical” direction.
The cmtx function is “linear” and is derived from the
element’s numerators num0 and num1 within the element
and the denominator denom from the element. The cmtx
function can then be defined as:

cmtx (x) =

num0 + (num1 × x)
denom

Note that the above description of the conversion functions, e.g. cmrx etc., is expressed
in the same direction as data flow. This is not required: RTA-RTE will derive the inverse
function as and when necessary.

Type System

RTA-RTE V6.3.0
User Guide

5.5.2

Modelling Application Types
By correctly modelling Application Data Types with regard to PhysicalDimensions,
RTA-RTE can automatically derive any data conversion code needed to transmit values
between different numerical representations of the same physical dimension.
PhysicalDimension
A PhysicalDimension represents the notion of length, or speed, or temperature, etc.

length_in_metres
1

Unit
Units express their relationship to a PhysicalDimension by means of FactorSIToUnit
and OffsetSIToUnit. For example, a Unit representing the kilometre might have the
FactorSIToUnit of 0.001.
FactorSIToUnit and OffsetSIToUnit are specified as decimal literals:

centimetres
0.01
0
/package/length_in_metres

An ApplicationDataType may directly reference a Unit, or the Unit may instead be
referenced by a CompuMethod (below). If the CompuMethod and ApplicationDataType
reference conflicting Units, the configuration will be rejected.
CompuMethod
The CompuMethod container in the input configuration has a ShortName, a Category,
and optionally a reference to a Unit.
If the Category is IDENTICAL, there is nothing more to specify.
If the Category is LINEAR, you must supply the coefficients for a linear conversion
function, either a CompuInternalToPhys for the “internal-to-physical” direction, a
CompuPhysToInternal for the “physical-to-internal” direction, or both.
If both are specified, CompuInternalToPhys and CompuPhysToInternal
must be the inverse of one another.
If only one of CompuInternalToPhys and CompuPhysToInternal is supplied, RTA-RTE
calculates the inverse automatically. If both are provided, RTA-RTE honors them both
but does not check that one is truly the inverse of the other.
64

Type System

RTA-RTE V6.3.0
User Guide

When specified in a CompuMethod with category LINEAR, the
CompuInternalToPhys and CompuPhysToInternal must contain exactly
one CompuScale element containing exactly one CompuRationalCoeffs
element.
The CompuRationalCoeffs element contains a CompuNumerator element that specifies
two values, num0 and num1 , and a CompuDenominator with one value, denom. The
meaning of these values is as follows:

f (x) =

num0 + (num1 × x)
denom

where num0 is the first value in the CompuNumerator element, num1 is the second value
in the CompuNumerator element, and denom is the value in the CompuDenominator.
All numerators and denominators in CompuRationalCoeffs must be integers. For example, to represent (0.5 + x) use coefficients 1, 2, 2 which give the mathematicallyequivalent 1+2x
2 .
As an example, consider the conversion of centimetres to metres:

compuMethod_centimetres
LINEAR
/package/metres

0
1

100

The above XML expresses the relationship metres(cm) =
cm
metres(cm) = 100
.

0+(1×cm)
,
100

or more simply,

Alternatively, the relationship can be expressed in the “physical-to-internal” direction:

compuMethod_centimetres
LINEAR
/package/metres

Type System

RTA-RTE V6.3.0
User Guide

0
100

In this case RTA-RTE will generate an “identical” conversion. That is, no conversion will
take place.

5.6

Expressing Values in Physical Units or Numerical Representation
The initial values of DataPrototypes and the invalid values of DataTypes are expressed using various classes of ValueSpecification. Values for primitive types
may be specified directly in the numerical representation required by the implementation (i.e. the value that will appear in the initializer in the generated C code) or,
for ApplicationPrimitiveDataTypes, a physical value can be specified in a particular
unit and the corresponding numerical representation will be computed.
A NumericalValueSpecification is used for a primitive value already in the necessary numerical representation. If used for an ApplicationPrimitiveType, the value is
interpretted in the context of the mapped ImplementationType.
An ApplicationValueSpecification is used for a physical value in a particular unit
and can be used only for ApplicationPrimitiveTypes. Data conversion occurs at
generation time, from the given unit to the unit of the ApplicationPrimitiveType,
then to the numerical representation in the mapped ImplementationDataType. The
resulting value is used in the initializer in the generated C code.
For complex types, complex ValueSpecifications are used and aggregate further
ValueSpecifications for the elements. The layout of the ValueSpecifications must
match the layout of the DataType, with RecordValueSpecifications used for record
data types and ArrayValueSpecifications used for array data types. The leaves,
that are of primitive type, are given values using NumericalValueSpecifications or
ApplicationValueSpecifications as described above.
Suppose that the ApplicationPrimitiveDataType MyCMArrayType from the earlier example is mapped to an ImplementationDataType that is an array of four 16-bit unsigned integers. The following example shows an initializer for an array of four lengths,
some specified in metres and some in centimetres, stored as 16-bit unsigned integers
66

Type System

RTA-RTE V6.3.0
User Guide

giving the number of centimetres.

VALUE

/package/metres

VALUE

/package/centimetres

145

The first two array elements are initialized with the numerical representation and the
values given are used directly in the generated C code. The third element is given the
value 5 m which is converted to 500 cm and the numerical representation is 500. The
fourth element is given the value 145 cm with numerical representation 145.
5.6.1

Reusing Values
As well as specifying initial and invalid values directly where they are needed, it
is also possible to create free-standing ConstantSpecifications that can be referenced multiple times in the model, using a ConstantReference in place of a
ValueSpecification.
The following example shows a reusable value that could be used as the initial value
for several DataPrototypes of type MyPointType (from an earlier example) where the
point at two metres by three is the desired initial point:

MyInitialPoint

Type System

RTA-RTE V6.3.0
User Guide

VALUE

/package/metres

VALUE

/package/metres

This can be referenced as follows, either for a DataPrototype in its entirety or for an
element of a complex type by placing within a complex ValueSpecification:

/package/MyInitialPoint

Since ValueSpecifications are not directly tied to data types it is even possible to
reuse ConstantSpecifications for different types, provided they are compatible. For
example, a numerical value of 7 can be used to initialize a signed 8-bit integer type
and an unsigned 16-bit integer type, but a value of 1000 cannot be used to initialize
a signed 8-bit integer type. Similarly a RecordValueSpecification containing the
numerical values 1 and 2 can be used to initialize any record type with two elements
of some integer type, regardless of the names of the elements, but cannot be used to
initialize a record type with three elements, for example.

Type System

RTA-RTE V6.3.0
User Guide

Interfaces
All ports of a software component (whether a provided or a required port) are typed by
a specific interface. The definition of interfaces is considered in detail in this section.
Note that how the software component interacts with the interface is defined by the
element that references a software component. This is discussed in Chapter 8.

6.1

Sender-Receiver
The element is used to define a sender-receiver interface as follows:

SRInterface
...

...

The name of the sender-receiver interface definition is given by the .
The name is used within other elements that need to reference the interface type,
for example a software component may specify that it uses sender-receiver interface
SRInterface.
The short-name of a sender-receiver interface should be a valid C identifier.
A sender-receiver interface can be used to communicate data (using data element prototypes within the element) or modes (using mode declaration group
prototypes within the element).
6.1.1

Data Element Prototypes
Each sender-receiver interface can specify zero or more data elements that constitute
the AUTOSAR signals communicated over the interface. Each data item defines a prototype of a specific type and can be a primitive data type, a RECORD or an ARRAY type.
See Chapter 5 for details of defining data types.
The declaration of data elements within a sender-receiver interface definition has the
following structure:

Speed

QUEUED

/types/SInt16

Interfaces

RTA-RTE V6.3.0
User Guide

A data element is defined using either a or
element and all elements must be defined within
an encapsulating element.
Each data element must specify:

• The that you will use to refer to the item.
• A reference to the type of the data item.
• The is specified for queued communication and omitted for unqueued.
Unqueued communication means that a newly received value over-writes the previous value of the data item. If a value is sent multiple times before it is received
then the receiver can only access the last transmitted value.
Queued communication means that the sender-receiver interface queues arrivals
of the data item on the receiver side.

6.2

Nv-Data
elements are used to define an interface used by an Nv-block
software component type (see Chapter 11). Each interface contains one or more NvData elements as follows:

NVInterface
...

...

The name of the Nv-Data interface definition is given by the . The name
is used within other elements that need to reference the interface type, for example an
Nv-Block software component may specify that it uses Nv-Data interface NVInterface.
The short-name of a Nv-Data interface should be a valid C identifier.
6.2.1

Nv-Data Elements
Each Nv-Data interface can specify zero or more Nv-data elements that constitute the
AUTOSAR signals communicated over the interface. Each Nv-data item defines a prototype of a specific type and can be a primitive data type, a RECORD or an ARRAY type.
The declaration of data elements within a Nv-Data interface definition has the following
structure:

Interfaces

RTA-RTE V6.3.0
User Guide

DTC
/types/SInt16

An Nv-data element is defined using a element and all
elements must be defined within an encapsulating element.
Each Nv-data element must specify:

• The that you will use to refer to the item.
• A reference to the type of the data item.
6.3

Mode-Switch
The element is used to define a mode-switch interface in a
configuration as follows:

SRInterface
...

...

The name of the mode-switch interface definition is given by the . The
name is used within other elements that need to reference the interface type.
The short-name of a mode-switch interface should be a valid C identifier.

A mode-switch interface can contain exactly one mode group.
6.3.1

Mode Groups
Each mode-switch interface can specify exactly one mode group that defines application modes.
The declaration of each mode group prototype within a mode-switch interface definition
has the following structure:

Speed
/autosar/mg1

A mode group prototype is defined using the element. Each mode group
prototype must specify:

• the that you will use to refer to the item.
Interfaces

RTA-RTE V6.3.0
User Guide

• the reference to mode declaration group.
The declaration of mode group prototypes and the use of mode declaration prototypes
within interfaces is considered in detail in Chapter 9.

6.4

Client-Server
The element is used to define a client-server interface
as follows:

CSInterface

...

A client-server interface is named using the element. The name is used
within other elements that need to reference the interface type. The short-name of a
client-server interface should be a valid C identifier.
A client-server interface consists of one or more operations defined using the
container element.
6.4.1

Operations
The element encapsulates one or more
elements each of which defines a single operation in the client-server interface.

MaximumValue

...

Each operation is named using the element. The name you specify here
will form part of the name used by the RTE to refer to the operation in your code.
The element encapsulates one or more argument prototypes using
elements that define each argument (parameter) of the
operation.
Each argument prototype definition must define:

• the of the parameter.
• a reference to the type of the parameter. The referenced type must
correspond to a defined type – see Chapter 5.
72

Interfaces

RTA-RTE V6.3.0
User Guide

• the of the parameter as “IN” (read only), “OUT” (write only) or “INOUT” readable and writable by the component.
The following XML definition shows the arguments for our MaximumValue operation that
we assume takes two parameters of type SInt16 and returns the maximum of the two
parameters in an out parameter called result:

InputA
/types/SInt16
IN

InputB
/types/SInt16
IN

OutputMaximum
/types/SInt16
OUT

6.5

Calibration
The element is used to define a calibration interface as follows:

if1

...

The name of the calibration interface definition is given by the . The
name is used within other elements that need to reference the interface type.
The short-name of a calibration interface should be a valid C identifier.
6.5.1

Calibration Prototypes
Each calibration interface can specify zero or more calibration prototypes that constitute the AUTOSAR parameters communicated over the interface. Each calibration
prototype defines a prototype of a specific type.
The declaration of calibration prototypes within a calibration interface definition has
the following structure:

Interfaces

RTA-RTE V6.3.0
User Guide

Speed
VALUE
/types/SInt16

6.6

Trigger
A trigger interface is defined with the element as follows:

ifSingle

...

Each trigger interface can specify one or more triggers. The declaration of triggers
within a trigger interface definition has the following structure:

Name

A trigger is defined using only its name; no other information is necessary.

Interfaces

RTA-RTE V6.3.0
User Guide

Software Component Types
Each software component you want to use must have its component type declared in
the RTE generator’s configuration. The component type makes the component available for composition into a larger software system
An
atomic
software
component
type
element:

defined

using

the

<*-TYPE>
AtomicSoftwareComponent

...

Additional component types are also possible. For example, a sensor-actuator component types uses the element:

SensorActuatorComponent

...

Whatever the component type it must be named using the element. The
name must be system-wide unique and is used within other elements to reference the
software component type.
The short-name of a software-component should be a valid C identifier.
7.0.1

Service Components
In order for a service to be used by application components, “service component” types
must also be declared.
Service components are defined using the element:

ServiceComponent

...

7.0.2

NVRAM
AUTOSAR makes NVRAM blocks visible to to application components and to the AUTOSAR NVRAM manager through instances of “NV Block software component” types.
NV Block components are defined using the :

Software Component Types

RTA-RTE V6.3.0
User Guide

nv1

...

Each Nv-Block software component declares one or more Nv-blocks. See Chapter 11
for more details.

7.1

Ports
The ports of a software component are defined within the element, for example:

<*-PORT-PROTOTYPE>
...

Within the element, the and the
elements are used to define provided and required ports respectively.
7.1.1

Provided Ports
A provided port within a software component type definition is named using the
element. The name is used within other elements to reference the software component type.
The short-name of a provided port should be a valid C identifier.
Each provided port definition must specify the interface type over which it will communicate with other ports using the :

Sender
/interfaces/SRInterface

This element must identify the required interface – see
Chapter 6.
7.1.2

Required Ports
The definition of a required port takes the same form as that of a provided port with
the exception that the element is used.
A required port within a software component type definition must be named using the
element. The name is used within other elements to reference the software component type.

Software Component Types

RTA-RTE V6.3.0
User Guide

The short-name of a required port should be a valid C identifier.
The required port definition must reference an interface definition defined using the
element:

Receiver

/interfaces/SRInterface

In the simplest scenario, the provided and required ports at the endpoints of a connection reference the same interface definition – this guarantees that they are compatible. However, it is also possible to connect a require port to a provide port
whose Interface is a superset of the require port Interface, or to connect ports with
Interfaces that are compatible except for differing names for the interface elements
using PortInterfaceMappings (see section 13.3.4) to explicitly specify the connections and furthermore to connect data items that are not directly compatible via Data
Conversion – see Section 13.5.
7.1.3

Service Components
All the ports of a service component must be characterized by interfaces with the service flag set:

ServiceReceiver

/interfaces/ServiceSRInterface

...

ServiceSRInterface
...
true

7.2

Communication Specifications
When a port prototype is created it can optionally define attributes that control how the
port will behave. Provided port prototypes define attributes in
element whereas required ports use a element.

name

...

name

...

7.2.1

Sender-Receiver
Acknowledgment Request
A sender (the provider of a sender-receiver interface) can optionally request that receivers acknowledge the transmission for one or more of the data elements communicated on the interface. The configuration depends on whether the data element is
queued or not.

0.5

Acknowledgment is enabled if the timeout is greater than zero.
For a sender, the only acknowledgment that can be requested is on transmission. It is
not possible to request acknowledgement on reception by the receiver since there may
be multiple receivers of the data item and it would be impossible to determine what
the semantics of successful reception were (would it be one receiver has received, all
receivers have received, some receivers have received etc.)
When a software component sends data over a port and acknowledgment requests are
defined then your application code can request transmission acknowledgment. This is
done by requesting feedback from the RTE with the following API call:
Rte_StatusType
Rte_Feedback__(Rte_Instance Self)

Software Component Types

RTA-RTE V6.3.0
User Guide

The call can be made irrespective of whether the receiving software component is located locally on the same ECU as the sender or on a remote ECU.
The call will block for seconds if a in the calling runnable
entity references a , otherwise it will not block.
The following code shows how to request feedback for a transmission assuming that a
blocking variant is configured:
FUNC(void, RTE_APPL_CODE)
Runnable(Rte_Instance self)
{
Rte_StatusType status;
status = Rte_Send_Port_Value(self, 42);
if (status != RTE_E_OK)
{
// Handle error
}
else
{
status = Rte_Feedback_Port_Value(self);
// Call blocks for up to TIMEOUT seconds
switch (status) {
case RTE_E_TRANSMIT_ACK:
// COM service transmitted data...
case RTE_E_TIMEOUT:
// Transmission request timedout
}
}
}
Rte_Feedback applies only to writes/sends that use the “explicit” form of the
sender-receiver communication API. Furthermore, when multiple transmissions are made then it is not possible to determine which is acknowledged
first. You should serialize calls and check each individually if you need this
behavior.
There is also an additional form of the feedback API, Rte_IFeedback, that applies to
the “implicit” form of sender-receiver communication. This API will never block.
Initial Values
Non-queued data elements can optionally specify whether they have an initial value
that is used when a receiver attempts a receive operation on a software component
that has not yet made its first send or when the sender has invalidated the signal.

Software Component Types

RTA-RTE V6.3.0
User Guide

...

/pkg/constant_857

Invalidation
Non-queued data elements can optionally enable invalidation so that a sender can send
a data item that has an invalidated value.
Invalidation is enabled through the interface’s invalidation policy element. This ensures
that all uses of the interface have the same invalidation state.

/pkg/if/element
KEEP

...

Invalidation is used to indicate whether a data item is invalid on transmission. When
the attribute is set at a sender, RTE API calls generated for that can be used by the
sender to set a signal value as invalid. There are two types of invalidation:

• Implicit communication invalidation using the Rte_IInvalidate API.
• Explicit Communication Invalidation using the Rte_Invalidate API.
Setting invalidity can only be made at the point of transmission – once the data item is
sent, the invalidate attribute cannot be modified. The receiver of an invalidated value
receives the specified initial value.
Queued Data Buffering
Recall that the RTE allows data to be queued and this is specified on the interface. Data
is always queued on the receiver software component. To avoid unnecessary use of
buffer space, the number of elements queued can be configured.

Software Component Types

RTA-RTE V6.3.0
User Guide

...
3

Only data elements that are specified as can be buffered.
Alive Timeout
When communication is between ECUs it can be useful to know whether a sender is
still alive and sending data. This is configured using an alive timeout that specifies the
maximum time between receives that the receiver considers to indicate the sender is
not alive.
If the alive timeout is exceeded then the receiver is informed through a
. Therefore, the internal behavior of a software component that wishes to use the alive timeout must ensure that a runnable entity that
responds to a is configured.
The alive timeout is specified in seconds.

...
1.5

Filter
In some cases a receiver may only want to receive a value when the sent data
has a specific property, for example the value has changed. This is especially
useful for reducing the load in systems where runnable entities are triggered by
since filtering can reduce the number of events that get
passed to the receiver and therefore the amount of time consumed processing signals
that are not deemed useful.

...
...

The valid filter specifications are described in the RTA-RTE Reference Manual.
7.2.2

Client-Server
Buffering for the server side of client-server communication is configured using the
element.

Software Component Types

RTA-RTE V6.3.0
User Guide

Server

...
2

7.2.3

Client Component Instance Attributes
This release of RTA-RTE does not use the .

Software Component Types

RTA-RTE V6.3.0
User Guide

Internal Behavior
In Chapter 6 you saw how to define the external interface of a software component. In
this chapter you will see how to configure the internal behavior of the component.
Internal behavior elements are used to define how the software component will interact
with the RTE at runtime.
The internal behavior of a software component specifies many aspects of how it behaves, including:

• The runnable entities that belong to the software component and how they interact
(if at all) with the ports of the software component

• The events that cause runnable entities to be activated at runtime.
• The exclusive areas that exist so runnable entities can execute all or part of their
code in mutual exclusion from other runnable entities.

• Variables that belong to the software component that are accessed by multiple
runnable entities.

• Port argument lists for accessing AUTOSAR Basic Software Modules.
The following example illustrates the internal behavior description for software component “SoftwareComponent”:

behavior
SoftwareComponent

...

Internal Behavior

RTA-RTE V6.3.0
User Guide

...

An internal behavior must be named using the element. The name is
used within other elements to reference the behavior.
The short-name of an internal behavior does not need to be a valid C identifier (but it
must pass the syntactic checks enforced by the XML Schema).
The way in which the configuration of RTE events within the element and
runnable entities defines the receive mode communication attributes is shown in Section 8.5. The following sections first outline the basic framework for RTE events and
runnable entities before showing how to configure the RTE to achieve different types of
runnable entity/interface interaction.

8.1

RTE Events
Events control how runnable entities are triggered by the generated RTE at runtime.
These events are termed RTE Events to distinguish them from OS events.
RTA-RTE supports the following RTE Event types:

• TIMING-EVENT – activate a runnable entity periodically. The TIMING-EVENT allows
you to execute a runnable entity to poll an RPort to check if data has been received,
periodically call a server (ie be a client), periodically send data on a PPort or simply
to execute some internal software component functionality. Runnable entities that
are activated in response to a timing event are said to be “time-triggered”.

• DATA-RECEIVED-EVENT – activate a runnable entity when data is received on a
RPort/data element. Runnable entities that are activated in response to a data
received event are “event-triggered”.

• DATA-RECEIVE-ERROR-EVENT – activate a runnable entity when either invalidated
data is received or an “alive timeout” has failed.

• ASYNCHRONOUS-SERVER-CALL-RETURNS-EVENT – activate a runnable entity when
the result from an earlier call to a server is available.

Internal Behavior

RTA-RTE V6.3.0
User Guide

• OPERATION-INVOKED-EVENT – activate a runnable entity to handle a server call for
an operation on a provided port characterized by a client-server interface.

• DATA-SEND-COMPLETED-EVENT – activate a runnable entity when a transmission acknowledgement is available (explicit communication).

• DATA-WRITE-COMPLETED-EVENT – activate a runnable entity when a transmission
acknowledgement is available (implicit communication).

• MODE-SWITCH-EVENT – activate a runnable entity on either entry to, or exit from an
application mode. AUTOSAR also permits mode switch events to be triggered on
the transition between two application modes.

• MODE-SWITCHED-ACK-EVENT – activate a runnable when a mode switch transition is
complete.

• BACKGROUND-EVENT – activate a runnable within the “idle” task.
• INTERNAL-TRIGGER-OCCURRED-EVENT – activate a runnable within the SW-C, possibly by direct function call, without passing data.

• EXTERNAL-TRIGGER-OCCURRED-EVENT – activate a runnable within the SW-C by an
external entity without passing data.
A is used to indicate that a runnable entity will be activated periodically by the Operating System. The RTE generator will use this information to generate
an appropriate schedule table that must be ticked from application code.
The and elements implicitly provide the XML configuration of the RECEIVE_MODE VFB communication attribute.
The structure for specifying RTE events is:

<*-EVENT>

The element can encapsulate any number of RTE events. RTE events can be
listed in any order.
An RTE event can be used to activate a runnable entity when the event occurs. The ,
and can also be waited upon by a runnable entity.
An RTE event references the runnable entity that is to be activated when the event
occurs. Similarly, when a runnable entity waits on one of the RTE events, the runnable
entity must reference the event(s) upon which it waits. Each of the RTE events can be
used in both ways and by more than one runnable entity but it is not possible for the
same event to simultaneously activate a runnable entity and to be waited upon.
Internal Behavior

RTA-RTE V6.3.0
User Guide

8.2

Runnable Entities
Each software component will require at least one runnable entity. All runnable entities
must be defined within the runnable entities definition in a
element.

RunnableEntity

CFunctionName

A must be named using the element. The name is
used within other elements to reference the runnable entity.
The denotes the name of the runnable entity in the XML namespace,
but it does not tell the RTE what the associated function body you will provide in your
code is called. This information is provided by the declaration that links
the runnable entity to the C function name you will use in your implementation. The
element defines the name of the function that implements the runnable entity. The name must be a valid C identifier.
This declaration is sufficient if your runnable entity does not need to interact with the
software component’s ports. However, if a runnable entity needs to interact then you
will need to specify additional information that allows the RTE generator to generate
APIs to allow interaction to take place, for example:
1. What data items the runnable entity can send.
2. What data items the runnable entity can receive.
3. What mode instances the runnable entity can switch.
4. What RTE events the runnable entity waits upon.
5. Which servers the runnable entity calls and how it expects the result to be returned.
You can use the same runnable entity to receive data on one interface and send data
on another interface, or to receive data on a port and then call a server port to process
the received data. For example, you may create a runnable entity that reads an integer
value from an RPort, multiplies it by two and sends it out on a PPort.
8.2.1

Specifying Maximum Arrival Rate
AUTOSAR permits the specification of the minimum time between executions by specifing a minimum start interval to place a limit on the rate at which activations can occur.
RTA-RTE manages runnable activation to ensure that the minimum start interval is not
violated.
86

Internal Behavior

RTA-RTE V6.3.0
User Guide

A minimum start interval cannot be specified for a runnable entity that is invoked by
an OperationInvokedEvent.
The RTE API function Rte_MainFunction must be invoked when minimum
start intervals are used. The period at which the function will be invoked is
specified by a command-line option.

8.3

Responding to Periodic Events
If your software component includes runnable entities that are not triggered by communication through the ports of the component you need to make sure that the
runnable entities are executed at runtime. This is achieved by associating them with a
or that specifies how the runnable entity should
execute.

8.3.1

Timing events
Each element specifies the of occurrence in seconds and
must reference a runnable entity defined in the component’s internal behavior using a
element. A period of zero is illegal.
The runnable entity declaration itself needs only to declare a name for the runnable
entity.
The following example shows how to configure the RTE to activate a runnable entity
every second.

EverySecond

/pkg/ib/RunnableEntity

1.0

RunnableEntity
MyFunctionName

A timing event must be named using the element. The name is used
within other elements to reference the timing event. The short-name of a timing event
does not need to be a valid C identifier.
8.3.2

Background events
RTA-RTE also supports Background events. These events are similar to TimingEvents
in that they are recurring but unlike timing events have no fixed period.

Internal Behavior

RTA-RTE V6.3.0
User Guide

RTA-RTE supports two mechanisms for activating background events:

• Via invocation from an “idle” task.
• Via an external OsAlarm or schedule table (see Section 24.1).
When all events mapped to a task are background events and no event has an externally declared OsAlarm or OsScheduleTable reference then RTA-RTE generates a task
body that uses ChainTask instead of TerminateTask.
In accordance with AUTOSAR requirements, RTA-RTE rejects configurations where a background triggered event is not triggerend by an external
OsAlarm or schedule table and is not mapped to the lowest priority task in
the system (the “idle” task).

8.4

Sending to a Port
If your software component provides a sender-receiver interface then you should define
at least one runnable entity that sends data over the interface.
The runnable can send data in two ways:
Explicitly – The RTE generates an explicit API call (that may be optimized to a macro).
The sent data item may be either queued or unqueued by the receiver.
Implicitly – The RTE generates an implicit API call that will be optimized to a macro.
The sent data item must not be queued.

8.4.1

Explicit Communication
Runnable entities that send data must define a that each of which
specifies the data item that will be sent for a given interface.
The

specifies
the
port
and
data
element
and elements:

Sender

SendPoint

Internal Behavior

using

RTA-RTE V6.3.0
User Guide

The specifies access to an AUTOSAR variable – the access
declaration includes the port and data element using and
elements:

Sender

dsp_p1_di1

For senders, it does not matter how the runnable entity is triggered, so any EVENT can
be used to activate the runnable entity.
A must be named using the element. The name is
used within other elements to reference the data send point. The short-name does not
need to be a valid C identifier.
8.4.2

Implicit Communication
Runnable entities can also communicate using implicit data read/write access. Such
configuration is guaranteed to be implemented as a simple macro that accesses global
storage defined in the RTE rather than through a C function call. Configuration is almost
identical to the .
The specifies access to an AUTOSAR variable – the access
declaration includes the port and data element using and
elements:

Sender

dwa_p1_di1

Internal Behavior

RTA-RTE V6.3.0
User Guide

For senders, it does not matter how the runnable entity is triggered, so any EVENT can
be used to activate the runnable entity.

8.5

Receiving from a Port
Similarly, if your software component requires a sender-receiver interface then you
must define at least one runnable entity that receives data over the interface. Data
can be received in three ways:
Implicit data read acces — your runnable is activated by some RTE event, e.g. a
TimingEvent, and makes an RTE API call to read data
Explicit Data read access — your runnable entity is activated by an event and
makes an RTE API call to read/receive the data. The receiver uses a non-blocking
API to poll for the data.
Prior to R4.0 data was read via an OUT parameter of the generated API call. R4.0
introduced an additional form that performs the read using the generated APIs
return value.
Activation of Runnable Entity — your runnable entity is activated when data is received on the software component’s port and makes a non-blocking RTE API call
to read/receive the data.
Wake up of Wake Point — your runnable entity makes a call to the RTE API to receive data. If the data has not yet been received the call will block and your
runnable entity will continue to execute only after the event occurs or a configured timeout occurs, whichever happens first. When using this receive mode the
invoking runnable entity may block and therefore must be a Category 2 runnable
entity.
These receive modes are configured by defining specific combinations of runnable entity elements and RTE events. The required configurations for each receive mode are
shown in the sections below.

8.5.1

Explicit Data Read Access
Runnable entities that are required to receive data with the “data read access” receive mode must define a element that specifies
the data item they will receive.
The element specifies access to an AUTOSAR variable – the access declaration includes the port and data element using
and elements:

Receiver_DataReadAccess

drp_r1_di1

Internal Behavior

RTA-RTE V6.3.0
User Guide

Using data read access implies that the runnable entity is polling the RPort for the
specified data item. It is common, therefore, that a runnable entity which defines a
data receive point will be activated by a that specifies the required
polling period.
A data receive point element must be named using the element. The
name is used within other elements to reference the data receive point. The shortname does not need to be a valid C identifier.
Direct Read
AUTOSAR also supports reading data via the generated API’s return value rather than
via arguments. In this case an is used instead of
the element.
As
with
the

element
the
element specifies access to an AUTOSAR
variables – the access declaration includes the port and data element using
and elements:

drv_R1_di2

8.5.2

Implicit Data Read Access
Receivers may also use “implicit” data read access to access a receive port using implicit communication. The APIs generated for “implicit” access are guaranteed to be
resolved to macros.
The element specifies access to one or more AUTOSAR
variables – the access declaration includes the port and data element using
and elements:

Internal Behavior

RTA-RTE V6.3.0
User Guide

Receiver_DataReadAccess

dra_r1_di1

8.5.3

Activation of Runnable Entity
If you require the receive mode to be “activation of runnable entity” then you must define a as the RTE event that will activate the runnable entity
when the data is received.
The following XML fragment shows how the “data read access” example above is converted to “activation of runnable entity”:

ActivationOfRunnableEntity

/pkg/internal/ReceivePort_DataItem

...

ReceivePort_DataItem

With this receive mode, the runnable entity still needs to define a data receive point
(as above) to ensure that an API is created to read the data once the runnable entity
has been activated by the RTE.
No should be specified since the combination of activated runnable entity and blocking API is forbidden by AUTOSAR.

Internal Behavior

RTA-RTE V6.3.0
User Guide

8.5.4

Wake up of Wait Point
If you need to receive with receive mode of “wake up of wait point” then your runnable
entity must define the at configuration time. Any runnable entity that
defines one or more wait points automatically becomes a Category2 runnable entity.
Before the runnable entity can wait you will need to make sure that the runnable entity
is triggered initially. This can be done by defining another RTE event.
For example, if you want the runnable entity to run periodically but to wait during
execution for data then you would use a to trigger the periodic execution. Alternatively, you might want the runnable entity to be triggered by one
data item and then wait for another data item to arrive. In this case you would use
a that includes a reference to the runnable entity to trigger
the initial execution.
A must be named using the element. The name is used
within other elements to reference the wait point. The short-name does not need to be
a valid C identifier.
Each must specify the RTE events by which it can be triggered. This is
done with the element. For a receiver, this reference must be to the
EVENT called .
Each must also specify a which is the maximum time that
the receiver will wait for wake-up.
The following XML fragment shows how the “activation of runnable entity” example
above is converted to “wake up of wait point”:

WakeUpOfWaitPoint

ReceivePort_DataItem

... as above ...

WaitPoint

/pkg/internal/WakeUpOfWaitPoint

Internal Behavior

RTA-RTE V6.3.0
User Guide

0.5

...

8.5.5

Accessing Calibration Parameters
When an RPort is categorized by a calibration interface (see Section 6.5) RTA-RTE can
create APIs to access the calibration prototypes.
Prior to R4.0 an Rte_CalPrm API was created for each parameter in the RPort. This could
lead to many unused, and undesired, APIs and therefore AUTOSAR R4.0 introduced the
concept of a ParameterAccess point to control when and how runnable entities access
a mode using the Rte_Prm API.

...

pap_rCal1_cp_value1

...

The element references the required calibration prototype using
the and elements. The referenced port should be declared within the context of the runnable entity’s SWC-type.
A ParameterAccess point must be declared for each required Rte_Prm API.

8.6

Responding to a Server Request on a Port
If your software component provides a client-server interface then you must define a
runnable entity for each operation in the interface. These runnable entities are the
servers for the client-server PPorts on your software component.
Each PPort that is characterized by a client-server interface must provide a runnable
entity for each operation defined by the interface.
For the runnable entity to be regarded by the RTE as a server it must be tied to an
. This RTE event allows the RTE to call the runnable entity at runtime in response to client requests. The must
specify what operation request on the server interface will result in the runnable entity
being activated. The following example shows how to configure runnable “ServerOper94

Internal Behavior

RTA-RTE V6.3.0
User Guide

ation”:

ActivateServerRunnable

/pkg/internal/ServerOperation

...

ServerOperation
...

An must be named using the element.
The name is used within other elements to reference the event. The short-name does
not need to be a valid C identifier.
8.6.1

Concurrent Invocation of Servers
When a runnable acting as a server is written to be re-entrant then the RTE can optimize
invocation by clients on the same ECU to a direct function call. This means that no
queuing is required (or possible) and therefore multiple invocations of the server can
occur concurrently.
The RTE generator needs to know which runnable entities can be called in this way.
Concurrent invocation is defined within the server’s runnable entity definition as follows:

true

The runnable must be written to be re-entrant. If this is not the case then
data consistency is not guaranteed when there is more than one client simultaneously requesting the server.

8.7

Making a Client Request on a Port
Similarly, if your software component requires a client-server interface then you must
define at least one runnable entity that acts as the client.
Clients can access servers either synchronously or asynchronously.
Synchronous —the client will be blocked while the server processes the request.
When the server has processed the request the result is passed back to the client
and the client continues to execute.
Internal Behavior

RTA-RTE V6.3.0
User Guide

A synchronous client is specified using a SynchronousServerCallPoint.
Asynchronous —the client makes the request then continues to execute. When the
server has serviced the request, the client can collect the result. The mechanism
by which the result is collected by the client is configured statically at configuration time by configuring a VFB RECEIVE_MODE. When using asynchronous communication, a client may have at most one outstanding request of any one server
(but may make multiple simultaneous requests to different servers).
An asynchronous client is specified using an AsynchronousServerCallPoint.
In the case of synchronous access, the client will block until the server completes and
the result of the operation will be returned by the API call. In the case of asynchronous
access, the client does not block and simply continues to execute. The client can then
receive the server result in one of three receive modes:
Data read access —the client uses a non-blocking read API to poll for the server’s
result. If the receive mode attribute is not specified, RTA-RTE assumes data read
access by default. This mode is only valid for asynchronous client-server communication.
If only an AsynchronousServerCallPoint is specified then RTA-RTE assumes data
read access by default.
Activation of runnable entity —the client runnable entity is activated by RTA-RTE
whenever new data is available. RTA-RTE creates a non-blocking read API to access the result. This mode is only valid for asynchronous client-server communication.
This receive mode is specified using a combination of an AsynchronousServerCallPoint an AsynchronousServerCallReturnsEvent.
Wake up of wait point —the client suspends execution via a blocking read API call
until either a timeout occurs or the server’s result is available. The client uses a
blocking read API to read data. When using this receive mode the runnable entity
may block and therefore must be a Category 2 runnable entity.
A client that communicates synchronously implies that the receive mode is “wake
up of wake up point”.
This receive mode is specified using a combination of an AsynchronousServerCallPoint, an AsynchronousServerCallReturnsEvent and a WaitPoint.
These receive modes are configured by defining specific combinations of runnable
entity elements and EVENTS. The required configurations for each receive mode are
shown in the sections below.
You can use the same runnable entity as a server on one interface and client on another
interface. For example, you may create a runnable entity that handles a server request
for sorting on a PPort and uses an auxiliary operation on an RPort.
96

Internal Behavior

RTA-RTE V6.3.0
User Guide

8.7.1

Synchronous Clients
Runnable entities that need to call a server synchronously (i.e.
block when
handling an RPort characterized by a client-server interface) must define a
.
The defines which operations the client can call
and specifies a global value for all the called operations. The
specified the maximum time that the client will wait for any of the servers providing an
operation.
A must be named using the SHORT-NAME element. The name is used within other elements to reference the call point. The shortname does not need to be a valid C identifier but must pass the syntactic checks imposed by the AUTOSAR schema.

SynchronousClient

SyncCallPoint

...

0.500
...

...
>

When a client has a client mode of synchronous, this means that the client will be
blocked until the server call returns. Implicitly this means the client is using a receive
mode of “wake up of wait point”.
You will have to ensure that the client is triggered by an RTE event.
8.7.2

Asynchronous Clients
Runnable entities that need to call a server asynchronously (i.e.
handle an
RPort characterized by a client-server interface without blocking) must define an
.
When a client is synchronous, it will be blocked while the server executes. However,
when a client is asynchronous the client is not blocked while the server executes. Once
the server has completed it is the client’s responsibility to get the result of the operation
back from the server.
Server results are collected by clients using one of the same three receive modes used

Internal Behavior

RTA-RTE V6.3.0
User Guide

for receivers in sender-receiver communication:

• data read access
• activation of runnable entity
• wake up of wait point
In all cases, the framework for the client request is the same and is shown in the following example where a runnable entity called Client is configured to make an asynchronous call on “CSInterface” to “Operation”:

AsynchronousClient

AsyncCallPoint

...

An must be named using the element. The name is used within other elements to reference the call point. The shortname does not need to be a valid C identifier but must pass the syntactic checks imposed by the AUTOSAR schema.
Collecting the Result by Data Read Access
If the client does not specify any that reference an
then the receive mode for the
server results defaults to “data read access” and the RTE generator will provide a
non-blocking Rte_Result API call for accessing the server result.
Collecting the Result by Activation of Runnable Entity
When you want the server result to be communicated back to the client software component through receive mode “activation of runnable entity” then, in addition to defining an in the client runnable entity, the following
elements are required:

• a runnable entity to capture the result (this may or may not be the same runnable
entity that makes the client request);

• an RTE event to trigger this runnable entity when the server completes.
98

Internal Behavior

RTA-RTE V6.3.0
User Guide

The
trigger
is
configured
using
the
RTE
event
called
that references both the client’s
server call point and the runnable entity to activate when the call returns:

ServerCallReturnsEvent

/pkg/internal/CollectResult

/pkg/internal/RE1/AsyncCallPoint

CollectResult
...

Like data read access, a non-blocking Rte_Result API call is generated to enable the
activated runnable entity to collect the server result.
Collecting the Result by Wake up of Wake Point
When you want the server result to be communicated through receive mode “wake up
of wait point” then, in addition to defining an ASYNCHRONOUS-SERVER-CALL-POINT in
the client runnable entity the following additional configuration is needed:

• declaration of an that specifies for
which call the RTE event will occur.

• a

in the client runnable
.

entity

that

waits

the

The following example shows the declaration of the RTE event and the additional configuration required by the client:

ServerCallReturns

/pkg/internal/Client/AsyncCallPoint

Client

Internal Behavior

RTA-RTE V6.3.0
User Guide

AsyncCallPoint

...

WaitForServerResult

/pkg/internal/ServerCallReturns

0.5

As with waiting on events in sender-receiver interface interaction, the
must specify a with the maximum allowed amount of time in seconds for
which wait can occur.
A timeout of 0 will cause an infinite wait.
A must be named using the element. The name is used
within other elements to reference the wait point. The short-name does not need to be
a valid C identifier.

8.8

Direct Trigger of a Runnable Entity
As we have seen, port based communication provides an effective mechanism for
transmitting an “event” that combines both data and the notification that the event
has occurred. However such a mechanism may be more than is required; a software
component may want to transmit just the fact that the event has occurred and have
no associated data. AUTOSAR R4.0 introduced the concept of Trigger Events to handle
this situation.
Internal Trigger
An Internal Trigger Occurred Event is used within a SW-C instance to activate one or
more runnables when the event occurs. Since the event is internal to a component no
ports are required and hence no connections are necessary during integration.
An internal trigger requires a Triggering Point to be declared within the runnable that
will make the Rte_IrTrigger API call.

100

Internal Behavior

RTA-RTE V6.3.0
User Guide

re_te1
...

itp3

...

Then RTA-RTE will create Rte_IrTrigger_re1_itp3 API based on the short name of the
triggering point. The short name is also used to identify the internal trigger point as
the event source within an Internal Trigger Occurred Event element:

itp3
/pkg/swc/ib/re_te1/itp3

Multiple Internal Trigger Occurred events can reference the same triggering point and
thus one internal trigger API can start multiple runnables. The runnables to be started
are specified by in response to an internal triggering event are specified using one or
more Internal Trigger Occurred Event elements.
When a SW-C indicates the event has occurred by invoking the Rte_IrTrigger API
created for the internal triggering point RTA-RTE activates all runnables specified by
Internal Trigger Occurred events that reference the triggering point. For runnables
without a minimum start inteval and without a task referenced in the event’s
RteEventMapping this activation is by a direct function call.
External Trigger
In contrast to internal triggering, External Trigger Occurred Event is used by entities
external to a SW-C instance to activate runnables. Since the event is external to a
component ports categorized by a trigger interface are used hence must be connected
during integration.
An external trigger requires a port categorized by a Trigger Interface (see Section 6.6)
to be declared within the SW-C. For SW-Cs that indicate the event has occurred by
invoking the Rte_Trigger API call a provided port is necessary whereas SW-Cs that
respond to the event use a required port.

r2
/pkg/itf

Where itf is a trigger interface, for example:

itf

Internal Behavior

101

RTA-RTE V6.3.0
User Guide

trig1

trig2

The short name of the port and the short name of the trigger within the interface are
used to form the name of the Rte_Trigger API. Within a SW-C, multiple External Trigger
Occurred Events can reference the same port/trigger and thus one external trigger API
can start multiple runnables. The provided port can be connected to multiple ports in
different SW-Cs.

etp2
/pkg/swc/IB/re

/pkg/swc/rPort
/pkg/itf/trig1

When a SW-C with a provide trigger port indicates the event has occurred by invoking
the Rte_Trigger API created for the external trigger RTA-RTE activates all runnables
specified by connected External Trigger Occurred events that reference the triggering
port/trigger. For runnables without a minimum start inteval and without a task referenced in the event’s RteEventMapping this activation is by a direct function call.

8.9

Exclusive Areas
Software components that need to provide mutual exclusion over data shared by two
(or more) of their runnable entities do so by configuring exclusive areas
The RTE generator uses exclusive area configuration to create operating system configuration files and to optimize exclusive areas. For example, if the only components
that access a region are mapped to the same task then the entire region can be elided.
Exclusive areas are defined in the XML configuration and are associated with the
runnable entities that use them.

8.9.1

Configuration
Each element must name the it uses.
Note that this means that the scope of any exclusive areas that you define is the software component instance. It is not possible to define exclusive areas that cross software component boundaries1 .
1
Data that is shared between multiple software-component instances which can potentially be accessed
concurrently should be encapsulated in its own component and then normal Sender-Receiver or Client-

102

Internal Behavior

RTA-RTE V6.3.0
User Guide

Each exclusive-area defined within an internal behavior definition must be named using
the element. The name is used within other elements to reference the
software component type and to form the “handle” by which the exclusive area is accessed at run-time. The short-name of an exclusive area should be a valid C identifier.

ExclusiveArea

...

RTA-RTE can be informed how to implement the exclusive area
RteExclusiveAreaImplementation element within the ECUC description.

with

You should create an exclusive area implementation element for each exclusive area. If omitted RTA-RTE defaults to “OS resource” implementation
strategy.
A different exclusive area implementation method can be set for each exclusive area
and SWC instance.
The InterruptBlocking method will cause all OS interrupts to be blocked
in the worst case for the longest execution time of the protected critical
section.
8.9.2

Usage
Each runnable entity in your section can declare if it uses one
of your named exclusive areas and how it uses the area at runtime with the following
elements:

• Explicit access—a element
defines exclusive areas accessed using an explicit API. The area’s name forms part
of the generated API (explicit access is similar to a standard resource in OSEK OS).

• Implicit access—a element defines an exclusive area that is locked automatically before the runnable entity executes and is released when the runnable entity terminates or waits for an RTE event
(similar to an internal resource in OSEK OS). In this case there is no user accessible
way of explicitly entering and leaving the defined exclusive area.
The configuration of both types of the exclusive area is shown below:

NeedsExclusiveAreas

Server communication used to access the data.

Internal Behavior

103

RTA-RTE V6.3.0
User Guide

/pkg/internal/ExclusiveArea

/pkg/internal/AnotherExclusiveArea

8.9.3

Implementation Methods
RTA-RTE supports the following implementation mechanisms for exclusive areas:

• OS resource locking.
• OS interrupt blocking.
• All interrupt blocking.
• Cooperative Runnable Placement.
OS Resource
When the OS resource implementation method is selected for an exclusive area instance RTA-RTE will attempt to use an OS resource is used to implement the exclusive
area.
If an exclusive area implementation element explicitly references an OsResource in the
input then RTA-RTE will use that resource unless access can be optimized. However if no
OsResource is selected then RTA-RTE will create a suitable standard/internal resource.
The naming of this resource is described in the RTA-RTE Reference Manual.
When using OS resources RTA-RTE will attempt to optimize the implementation of
Rte_Enter and Rte_Exit APIs to try and eliminate use of the resource entirely. This
optimization is possible when RTA-RTE observes that data consistency is guaranteed by
other means, namely:

• All accessors are located in the same task, or
• All accessing tasks are non-preemptive, or
• All accessing tasks have the same priority, or
• All accessing tasks are declared in the input as accessing the same internal resource.
104

Internal Behavior

RTA-RTE V6.3.0
User Guide

When an accessing runnable is declared as having implicit (“run inside”) access to
the exclusive area RTA-RTE will insert resource access around runnable calls in the
generated task body or use an internal resource if all accessors use implicit access and
no other runnables are mapped to the relevant tasks.
OS Interrupt Blocking
When the OS interrupt implementation method is selected for an exclusive area instance RTA-RTE will use suspend/resume of OS interrupts to implement the exclusive
area.
When using OS interrupt blocking RTA-RTE optimizes the APIs to null access if data
inconsistency cannot occur.
Avoid using any RTE APIs when OS interrupts are blocked. Failure to adhere
to this restriction may result in context switches not being recognized by the
OS when interrupt handling is resumed.
All Interrupt Blocking
AUTOSAR allows an exclusive area to block all interrupts, not just OS interrupts, When
the All interrupt implementation method is selected for an exclusive area instance.
When using all interrupt blocking RTA-RTE will optimize API calls to null access if data
inconsistency cannot occur.
Avoid using any RTE APIs when OS interrupts are blocked. Failure to adhere
to this restriction may result in context switches not being recognized by the
OS when interrupt handling is resumed.
Non-preemptive Tasks
When the non-preemptive task implementation method is selected for an exclusive
area instance RTA-RTE assumes that data consistency is guaranteed by external means
and that therefore all access to the exclusive area can be optimized to null access.
Cooperative Runnable Placement
When the cooperative runnable placement implementation method is selected for an
exclusive area instance RTA-RTE ensures that tasks containing runnables accessing an
exclusive area with implementation method cooperative runnable placement cannot
preempt other tasks with runnables accessing the same exclusive area instance when
a runnable is active. Unlike the non-preemptive tasks implementation method preemption is allowed when runnables are not running, e.g. between runnables.
If required to implement data consistency and no OsResource is explicit selected within
an EA implementation element in the ECUC then RTA-RTE will create a suitable standard/internal resource. The naming of this resource is described in the RTA-RTE Reference Manual.

Internal Behavior

105

RTA-RTE V6.3.0
User Guide

When using cooperative runnable placement RTA-RTE will optimize the implementation,
e.g. when all accessors are located in the same task or all accessing tasks are nonpreemptive, to null access since data consistency is then assured by external means.
The decision on whether to optimize is the same as for the OS resource implementation
method.
The cooperative runnable placement is best used when the accessing runnables are
declared as having implicit (“run inside”) access the exclusive area since RTA-RTE will
then insert resource access around runnable calls in the generated task body or use
internal resources as appropriate. If accessing runnables are declared as explicit access
(“can enter”) the exclusive area, i.e. will use the Rte_Enter API, then RTA-RTE cannot
use an internal resource to implement cooperative runnable placement since this would
block access for the entire runnable.

8.10

Inter-Runnable Variables
The RTE allows the configuration of inter-runnable variables that provide a way for
runnable entities to communicate between themselves. While this is possible through
user code and shared variable access (protected by exclusive areas - see Section 8.9)
this can be inefficient when handling primitive data types since the exclusive area API
calls are typically mapped onto the underlying Operating System’s resource control
mechanism.
Therefore, the RTE provides lightweight mechanisms for inter-runnable communication
that is equivalent in semantics to implicit/explicit sender-receiver communication but
within the scope of the software component instance.

8.10.1

Defining Variables
Each software component can define a number of variables at the scope of the component and how access is provided to the variable at runtime, either using explicit or
implicit communication:

8.10.2

Declaring Read and Write Access
Each runnable must explicitly specify whether it reads or writes a variable at runtime.
Access is declared using and
elements that reference an inter-runnable variable defined within the SWC-type, for
example:

/pkg/swc/IB/irvex1

106

Internal Behavior

RTA-RTE V6.3.0
User Guide

8.11

Accessing Modes
A mode user/manager can query the current application mode for a mode instabce
using the Rte_Mode API as well as have runnable entities activated as a result of a
mode switch event.
Prior to R4.0 a Rte_Mode API was created by RTA-RTE for all possible mode accesses.
This could lead to many unused, and undesired, APIs and therefore in R4.0 AUTOSAR introduced the concept of a ModeAccessPoint to control when and how runnable entities
access a mode using the Rte_Mode API.
A ModeAccessPoint is declared using the element within the
context of the runnable that will invoke the API:

/pkg/swc/r1
/pkg/if/mdgp1

A ModeAccessPoint must be declared for each required Rte_Mode API. The access point
can reference either required or provided mode groups.

8.12

Per-instance Memory
Software component instances may have state that has a lifetime that is longer than
the execution of any of its constituent runnable entities. Global variables cannot be
used for maintaining state because more than one instance of a software component
may be integrated onto the same ECU and there is no concurrency control mechanism
between instances of software components.
Per-instance memory allows software components to define one or more typed regions
of memory that can be accessed by the runnable entities at runtime.
The configuration of a per-instance memory section is shown below:

...

VAL
dataType
uint8

...

Internal Behavior

107

RTA-RTE V6.3.0
User Guide

Each per-instance memory must be named using the element. The
name allocated at configuration is the same name you will use to access the perinstance memory in your code. The short-name of a per-instance memory should be a
valid C identifier.
The and elements are used to, respectively, name and
define the data type created by RTA-RTE for the per-instance memory. The short-name
of a per-instance memory should be a valid C identifier. The type definition must be a
valid C type definition suitable for direct inclusion in a type definition as follows:
typedef ...TYPE-DEFINITION... ...TYPE...;
The example per-instance memory definition results on the following type definition:
typedef uint8 dataType;
Within the generated RTE, RTA-RTE allocates RAM for each per-instance memory. If the
ECUC specifies an NVRamAllocation container that references a per-instance memory then the name is the RamBlockLocationSymbol. Otherwise, RTA-RTE constructs a
unique name.

8.13

Port Options
The port options element permits:

• Enable/disable indirect API for a port.
• Port-defined arguments to be specified for client-server communication.
• Enabling application code to take the “address” of RTE API functions generated for
a port.
8.13.1

Indirect API
If the indirect API generated is not required for a port it can be disabled through “port
options” within the internal behavior:

false
/pkg/component/port

Disabling the indirect API can reduce the size of the component data structure (and
hence save ROM) when a SWC does not support multiple instances.
8.13.2

Port-defined Arguments
When the same runnable is used as the server for multiple ports it is necessary to be
able to identify which is the port that has caused the server invocation. Port-defined
108

Internal Behavior

RTA-RTE V6.3.0
User Guide

arguments permit a server to be supplied with default arguments based on the port
through which it is invoked.

pdav_1
/pkg/SInt16
1

...

/pkg/component/pport

...

8.13.3

Enable “Take Address”
A port option can be used to ensure that RTE APIs are generated in a way that their
address can be taken at run-time:

true
/pkg/component/port

If not specified, RTA-RTE assumes that is false.

8.14

Supporting Multiple Instantiation
By default, software components will only support the creation of a single software
component instance. If you want to support multiple instantiation then this must be
declared in the clause:

true

The element takes the values of “true” indicating that multiple instantiation is supported or “false” indicting that multiple instantiation is not supported.
If the element is omitted, RTA-RTE assumes
that the software-component does not support multiple instantiation.
The AUTOSAR 4.x feature of STATIC-MEMORYS is only available in InternalBehaviors that are single-instantated. See errors 2469 and 2470 for more
information.

Internal Behavior

109

RTA-RTE V6.3.0
User Guide

8.15

Memory Allocation
RTA-RTE uses the AUTOSAR memory abstraction scheme when declaring
RunnableEntitys.
A Memory Allocation Keyword is chosen according to the
SwAddrMethod for the RunnableEntity. If the RunnableEntity on the input references a swAddrMethod then its shortName is used for the Memory Allocation
Keyword; otherwise RTA-RTE uses the AUTOSAR specified SwAddrMethod CODE.
For example:

re2
/pkg/METHOD1
swcA_re1
...

The resultant definition of the runnable generated by RTA-RTE in the SWC type’s application header file then uses the appropriate section start/stop definitions:
#define swcA_START_SEC_METHOD1
#include "swcA_MemMap.h"
FUNC(void, swcA_METHOD1) swcA_re1(void);
#define swcA_STOP_SEC_METHOD1
#include "swcA_MemMap.h"

This applies to ASW only; this behaviour is not specified for BSW.

110

Internal Behavior

RTA-RTE V6.3.0
User Guide

Modes
The previous chapters have explored how an AUTOSAR software-component type can
be defined and configured. In this chapter you will learn how to define application
modes that can be used by software-components to control the execution of runnable
entities.

9.1

Defining Modes
Modes are declared within a contained within an
element.

MyModes

...

The element is used to declare one or more modes that
are subsequently used by interface declarations.

Modes
/pkg/Modes/iMode

iMode

runMode

One mode within a element is marked as the group’s initial mode through the . Mode switch events that are attached to
the ENTRY of an initial mode are triggered by RTA-RTE when the RTE is started using
Rte_Start.
A can be used (referenced) by multiple sender-receiver
interfaces and therefore inherently used by multiple software-components.

9.2

Mode Communication
Modes are communicated using mode-switch interfaces. Each mode-switch interface
can specify exactly one mode declaration group prototype that defines the AUTOSAR
modes communicated over the interface.

ModeInterface

Modes

111

RTA-RTE V6.3.0
User Guide

mdg1
/MyModes/Modes

...

A mode-switch interface can contain exactly one mode declaration group prototype
defined using the element.
Each or element must specify:

• the that you will use to refer to the item within references from other
elements.

• a reference to the mode declaration group.
9.2.1

Mode Managers and Mode Users
A software-component can be either1 a mode manager responsible for requesting a
switch to a new mode or a mode user activated in response to a mode switch.
A software-component declares itself as a mode manager by providing a port categorized by a sender-receiver interface containing a mode declaration group prototype and
declaring a mode switch point. The software-component can then use the Rte_Switch
API to request that a mode switch occurs as well as have runnable entities activated as
a result of a mode switch event.
A software-component declares itself as a mode user by requiring a port categorized
by a sender-receiver interface containing a mode declaration group prototype.
A mode manager is connected, using assembly connectors, to the mode users.

9.2.2

Mode Queues
When a mode manager initiates a mode switch RTA-RTE will being processing the request immediately as long as no mode switch is currently in progress for the mode
instance. However if the switch cannot begin then is is placed in a queue of mode
switch requests and handled when the current switch is complete.
RTA-RTE eliminates queues when they are not required; for example if no
ModeSwitchEvents are defined for the mode instance.
The length of the queue can be defined for each mode manager. For SWCs the length
is defined by the provided port’s com-spec element, for example to specify a queue
length of three entries:

It possible for the same software-component to be simultaneously a mode manager and a mode user
if it contains both provided and required ports.

112

Modes

RTA-RTE V6.3.0
User Guide

/pkg/if/mdgp1
3

The queue length can be specified for a BSW module by a
element within the module’s element.

/pkg/module/group
3

The Rte_Switch API returns RTE_E_LIMIT error if the mode queue overflows. The equivalent BSW API returns SCHM_E_LIMIT in the same circumstances.
9.2.3

Accessing Modes
A mode user/manager can query the current mode using the Rte_Mode API as well as
have runnable entities activated as a result of a mode switch event.
ModeAccessPoints are used to control when and how runnable entities access
a mode using the Rte_Mode API. A ModeAccessPoint is declared using the
element within the context of the runnable that will invoke the
API:

/pkg/swc/r1
/pkg/if/mdgp1

A ModeAccessPoint must be declared for each required Rte_Mode API. The access point
can reference either required or provided mode groups.
9.2.4

Interface Compatibility
For a provider to be successfully connected to a receiver the interfaces categorizing the
ports must have compatible interfaces – for modes this means that each Mode Declaration Group Prototype in the required interface must have the same name2 as a Mode
Declaration Group Prototype in the provided reference (this is analogous to the requirement for matching name and data-type for connecting interfaces containing Data
Element Prototypes). The Mode Declaration Group Prototypes must have compatible
modes.
2

Port interface mapping can be used to map mode declaration prototypes with dissimilar names.

Modes

113

RTA-RTE V6.3.0
User Guide

It is permitted for a provider to provide more Mode Declaration Group Prototypes than
are required.
9.2.5

Synchronous and Asynchronous Mode Switch
The Rte_Switch API supports both synchronous and asynchronous mode switches.
RTA-RTE uses the synchronous mode unless all mode users explicitly enable support
for asynchronous mode switches.
Synchronous Mode Switch
When synchronous mode switches are used the Rte_Switch API activates the task containing triggered mode switch runnables (all such runnables for a given mode instance
must be mapped to the same task). The execution of mode switch runnables is synchronized with the termination of any executing runnables with mode disabling dependencies and thus is is guaranteed that such runnables will have terminated when the
mode switch runnables are invoked.
Asynchronous Mode Switch
Support for asynchronous mode switches is enabled or disabled using a
ModeSwitchReceiverComSpec element within the requiring port prototype or a
BswModeReceiverPolicy within the BSW’s internal behaviour.

true

...

true

All mode users must explicitly enable asynchronous mode switch for it to
take effect. No warning is issued if a subset of mode users enable asynchronous mode switch.
When asynchronous mode switches are used the Rte_Switch or SchM_Switch API can
directly invokes the mode switch runnables (unless the runnable has a minimum start
interval or is in a different OS Application) and thus these run in the context of the caller.
The execution of mode switch runnables is thus not synchronized with the termination
of any executing runnables with mode disabling dependencies and such runnables may
not have terminated when the mode switch runnables are invoked.
RTA-RTE supports direct invocation of the mode switch runnable if the relevant RTE
event mappings does not specify a task. If the mode switch runnable entry point function is to be directly invoked then the input configuration must still provided an RTE
114

Modes

RTA-RTE V6.3.0
User Guide

event mapping for the associated event. The mapping must specify the position in the
task (for ordering purposes within the Switch API) but must not specify a task.
9.2.6

Mode Switch Management
RTA-RTE provides APIs for requesting a mode switch within a mode instance graph and
for reading the current mode. All mode switch management occurs either within the
generated switch API itself or within the task containing the mode switch event triggered runnable entities.

9.3

Using Modes

9.3.1

Software Component Initialization & Finalization
AUTOSAR modes can be used to execute code when the RTE is started, e.g. to initialize internal data structures etc. Similarly, when a system is shut down your software
component may need to store data, log operational details etc.
Each mode declaration group describes an initial mode—to activate a
runnable when the system is started created by a or
element for entry to the initial mode.
A runnable entity within a software-component can be started when the RTE is started
by declaring a mode-switch event for entry to an initial mode.
Within the mode switch event definition the particular mode instance is selected using , ,
and elements:

Behaviour

mse1

/pkg/internal/init

ON-ENTRY

...

init
InitializationFunction

Modes

115

RTA-RTE V6.3.0
User Guide

Once the mode switch event has been configured an initialization runnable entity must
be written that has the following structure:
FUNC(void, RTE_APPL_CODE)
InitalizeFunction(Rte_Instance Self)
{
/* user code */
}
The initialization runnable entity must be a Category 1 runnable entity and hence must
not make any (blocking) RTE calls nor access other application components.
Similarly, when a system is shut down your software component may need to store
data, log termination etc. The principle is the same as initialization, except that finalization is simply a transition to a new mode that is simply associated with shutdown.
9.3.2

Triggering a Runnable Entity on a Mode Switch
A runnable entity can be activated on either entry, transition or exit from a mode using
a Mode Switch Event configured, like all other events, in the
element of a software-component.
The selects the mode by the ,
and elements:

mse1
/pkg/IB/initialize
ENTRY

Finally, the declaration of the can reference one or two
modes within its element. One referenced mode is required for enter/exit mode switch events and two referenced modes for transition events.

mse1

/pkg/internal/init

ON-ENTRY

116

Modes

RTA-RTE V6.3.0
User Guide

A mode-switch event element defines three things:
1. The element defines the runnable entity to activate. The
reference must be to a runnable entity within the same software-component type.
2. The element defines the activation for the mode switch event, i.e.
when the runnable entity is triggered. A Mode Switch Event can apply to one
activation condition. If multiple activation conditions are required for a runnable
then more than one Mode Switch Event should be defined.
RTA-RTE supports “ENTRY”, “EXIT” or “ON-TRANSITION” activation conditions. A
mode switch event with one of these activation conditions is triggered whenever
the referenced mode is entered or exited.
Mode switch events using “ON-TRANSITION” activation are triggered by RTA-RTE
when the mode instance moves from the first referenced mode to the second
referenced mode.
3. The defines the mode associated with the mode switch event. The
element must contain three references (the port prototype, the
mode declaration group prototype and the mode declaration group that types
the declaration group prototype).
A mode switch event with an “ON-TRANSITION” activation condition requires two
modes to be referenced from the mode switch event’s element.
Both referenced modes must be within the same mode instance.
One mode within a element is marked as the group’s initial mode. Any mode switch events that are attached to the “ENTRY” of an initial mode
within any group are triggered by RTA-RTE when the RTE is started using Rte_Start.
The order of execution of runnable entities when more than one runnable
entity is triggered by the same mode entry (or exit) is not defined by the
SWC-type. For portability, therefore, a system should not rely on a particular
execution order since it may be redefined in the runnable to task mapping
(see Section 18.4.4).
9.3.3

Disabling RTE Events
A permits the behavior of an RTE event to be different in different modes. This allows such use-cases as the activation of a runnable entity to be
suppressed when a certain mode is active.
Modes

117

RTA-RTE V6.3.0
User Guide

A mode dependency declaration can be added to any RTE event (other than OperationInvokedEvents). A single RTE event can contain multiple mode dependency declarations in which case it is disabled in all the specified modes.
The

element
selects
the
mode
using
,
elements:

the
and

When the mode specified within the dependency is active, RTA-RTE will not activate
the runnable (the activation is discarded — it is not queued).
When a runnable activation triggered by, for example a DataReceivedEvent
with queued communication, is suppressed, RTA-RTE also suppresses the
write to the runnable entity’s queue – this prevents the queue filling up without corresponding runnable activations to process the events.

9.4

Understanding Mode Instances
A unique ’current mode’ is maintained by RTA-RTE for each connected graph of compatible Mode Declaration Group Prototypes. If an interface contains multiple prototypes
that reference different Mode Declaration Groups then the RTE defines a unique ’current mode’ value for each prototype. If the Mode Declaration Group Prototypes reference the same Mode Declaration Group then each ’current mode’ can take one of the
same set of modes but their state remains independent.
As an example, assume we have SW-C swcA with provided port P1 and swcB with required port R1 both categorized by the same interface. An Assembly Connector that
connects instances of swcA and swcB (e.g. A1.P1 to B1.R1) will result in a unique ’current mode’ maintained by RTA-RTE.

Mode 1

swcA

swcB

Figure 9.1: Single mode manager and mode user
Furthermore, another Assembly Connector that connects different instances of swcA
and swcB (e.g. A2.P1 to B2.R1) will result in RTA-RTE maintaining two independent
’current modes’ since the graphs formed by the connections do not intersect.

118

Modes

RTA-RTE V6.3.0
User Guide

Mode 1

swcA

Mode 2

swcA

swcB

Figure 9.2: Multiple distinct mode managers and mode users
However if the additional Assembly Connector connects the same instance of swcA to
a new instance of swcB (e.g. A1.P1 to B2.R1) then a new ’current mode’ is not created
by RTA-RTE but instead an additional mode user can access the same mode.

Mode 1

swcB

swcA

swcB

Figure 9.3: Single mode manager and multiple mode users
Multiple mode managers for the same mode instance are not supported by
AUTOSAR.

9.5

Fast Init
RTA-RTE supports a “fast init” activation method for Mode Switch Events that bypasses
the normal AUTOSAR activation method for events that are triggered only once at system startup. This mechanism is useful for a runnable that only runs once at system
start where the infrastructure code created by RTA-RTE to support the mode changes
Modes

119

RTA-RTE V6.3.0
User Guide

at run-time is superfluous.
The “fast init” activation method is unique to RTA-RTE and therefore nonportable.
An individual ModeSwitchEvent is made subject to “fast init” activation through a
command-line option (see RTA-RTE Reference Manual). It is also possible to make all
ModeSwitchEvents for a SWC subject to “fast init” through the same command-line
option.
When a ModeSwitchEvent is “fast init” then the implementation created by RTA-RTE
within the task is a simple function call — the use of a FastInit task both simplifies
the activation code necessary for the runnable associated with the event as well as
removing the normal infrastructure code created by RTA-RTE to support the AUTOSAR
mode mechanism.
It is the user’s responsibility to ensure that all FastInit tasks are activated at the appropropriate time.
An event that is specified as FastInit will not be activated by RTA-RTE during
a user-triggered mode switch. Instead the FastInit task must be activated
by user code at the appriopriate time.

9.6

Synchronizing Modes
RTA-RTE supports the synchronization of modes between SWC components and BSW
modules. Synchronizing mode groups permits both events in both AUTOSAR software
components and basic software modules to be triggered by a single mode manager.
RTA-RTE supports synchronization where the referenced BSW provides or releases (requires) the mode group.
The synchronization of mode groups is covered in detail in Chapter 15.

9.7

Non-AUTOSAR Functionality

9.7.1

Shared Mode Queues
When enabled with the --deviate-shared-mode-queue command-line option a shared
mode queue means that all mode instances mapped to a task share a single (common)
queue.
Shared mode queues do not support timeouts for ModeSwitchAck events
nor can they be mixed with distributed mode users.
A Shared Mode Queue results in a more predicable mode transition than is possible
with AUTOSAR compliant mechanisms since for mode instances assigned to the task it
is guaranteed that the transition for one mode instance will be complete before another
is started.

120

Modes

RTA-RTE V6.3.0
User Guide

9.7.2

Distributed Mode Users
When enabled with the --mode-policy command-line option different mode switch
events for a mode instance can be mapped to different tasks.
Dequeue Synchronization
When multiple mode switch tasks exist for a single mode instance then any task
can be responsible for performing the dequeue.
RTA-RTE provides a callback,
_
_
Rte ModeDequeueCbk , for each mode instance that controls within which task
the dequeue occurs.
The callback is called from each mode switch task after the mode switch has completed
for the calling task. When it returns TRUE the generated code dequeues the mode
switch.

The callback is only invoked when a mode switch instance is in a transition.
During each transition the callback must return TRUE for exactly one of the mode switch
tasks but which task is selected may vary between transitions. For example the callback might return TRUE for the last task to finish the mode switch and enter the callback, which could be timing-dependent, especially if the tasks run on different cores.
The name of the callback includes the mode instance index “”. RTA-RTE makes
this index available within the Rte_Const.h generated header file for each provide
mode port (i.e. mode manager) using the RTE_DMU macro:
#define RTE_DMU___ ...
Where “” is the SWC instance name (which can be set using a flatmap, see
Section 13.4), “” is the name of the provided mode port and “” is
the name of the mode declaration prototype within the mode interface categorizing the
port.
The “RTE_DMU_...” macro can be used with the C-preprocessor to construct the name
of the callback function.

Modes

121

RTA-RTE V6.3.0
User Guide

Implementing Software Components
This section shows how to write software components so that the objects required by
the RTE are declared and how to use the RTE API generated by the RTE generator.

10.1

Basic Concepts

10.1.1

Namespace
All RTE symbols (e.g. function names, global variables etc.) that are visible in the global
namespace use either the prefix Rte_ or the prefix RTE_.
You must not create symbols that use either the prefix Rte_ or the prefix
RTE_ to remove the possibility of namespace clashes.

10.1.2

Runnable Naming Convention
RTE generator generates code that activates your runnable entities. To do this, the
RTE’s internal mechanisms need to be able to access your code through defined interfaces.
Each of the named runnable entities defined in your runnable entity declarations must be implemented. Failure to define all runnable entities will be detected at
compile time when your application is linked to form the ECU’s executable image. The
linker error message will reference the missing runnable entity entry point.
Runnable entities are executed by RTE generated code when required. The function
providing an entry point for a runnable entity should not be invoked directly by an
application software-component.

10.1.3

API Naming Convention
The RTE API calls are generated for each software component using names derived
from the the RTE generator’s input. The RTE API provides a consistent interface to each
software component but allows the RTE generator to provide different implementations
of the API functionality.
Each API call name is formed from:

• An AUTOSAR defined prefix. For RTE API functions this is “Rte_” and, for BSW
functions, “SchM_”.

• The call functionality (Read, Write, etc.).
• Either
• The port name and data item name (sender-receiver) or operation name (clientserver) through which the API operates.

• The name of the object (e.g. trigger, exclusive area, per-instance memory etc)
upon which the API operates.

122

Implementing Software Components

RTA-RTE V6.3.0
User Guide

Thus RTE API calls involving communication through ports have the format:
Rte_StatusType
Rte___
Whereas other RTE APIs have the format:
Rte_StatusType
Rte__

RTA RTE User Guide V6.3.0

Navigation menu

Versions of this User Manual:

Views

Navigation