AUTOSAR TPS ECUConfiguration

Specification of ECU Configuration
AUTOSAR CP R22-11
Specification of ECU
Document Title Configuration
Document Owner AUTOSAR
Document Responsibility AUTOSAR
Document Identification No 87
Document Status published

Part of AUTOSAR Standard Classic Platform
Part of Standard Release R22-11
Document Change History

Date Release Changed by Description
• Clarified usage of apiServicePrefix
for Xfrm module defintions
• Added origin flag to
EcucContainerDef
AUTOSAR • Improved description how optionality
2022-11-24 R22-11 Release of containers, parameters and
Management references in the Ecuc Parameter
Definition UML model is expressed
• Clarified semantic of multiple
aggregated container trees that
include references
• Extend EcucParameterDefs with
AUTOSAR symbolicNameValue to support
2021-11-25 R21-11 Release PublishedInformation.
Management • Added withAuto support to
EcucAbstractReferenceDef.
• Introduced CddModuleId parameter
• Removed “Rules for Configuration
Editors” chapter
• Changed all lower multiplicities in the
AUTOSAR
Ecuc meta-model to 0 and
2020-11-30 R20-11 Release
introduced constraints that define at
Management
which time which model elements
need to be available. For details
please refer to the
ChangeDocumentation.
1 of 311 Document ID 87: AUTOSAR_TPS_ECUConfiguration

AUTOSAR CP R22-11
• Updated specification to avoid usage

of term MUST.
• Specification of the format of the
AUTOSAR destinationType of an
2019-11-28 R19-11 Release EcucForeignReferenceDef
Management • Added support for Bsw Multicore
Distribution in Ecuc module
• Changed Document Status from
Final to published
• Removed EcucSymbolic-
NameReferenceDef
• Introduced postBuildVariantsUsed
AUTOSAR
flag to improve the configuration of
2018-10-31 4.4.0 Release
postBuild variants
Management
• Minor corrections / clarifications /
editorial changes; For details please
refer to the ChangeDocumentation
AUTOSAR • Minor corrections / clarifications /
2017-12-08 4.3.1 Release editorial changes; For details please
Management refer to the ChangeDocumentation
• Improved description of Post-build
variants
• Improved Post-build loadable
AUTOSAR
approach
2014-10-31 4.2.1 Release
• Introduction of Uri References
Management
• Minor corrections / clarifications /
editorial changes; For details please
refer to the BWCStatement
AUTOSAR
2014-03-31 4.1.3 Release • Various fixes and clarifications
Management

AUTOSAR CP R22-11
• Support unidirectional CDD

communication
• Adapted range of parameter
MetaDataLength
• Harmonization with TR_Methodology
• Added "origin" attribute to the
EcucContainerDef
AUTOSAR • Adapted CDD configuration to allow
2013-10-31 4.1.2 Release the configuration of the CDD
Management interface type (IF/TP)
• Adapted the upper limit of PduLength
parameter
• Stereotyped EcucChoiceRefer-
enceDef.destination and
EcucSymbolicNameRefer-
enceDef.destination with
atpUriDef
• Description of the variant handling
approach to cope with PreCompile,
Link and Post-Build Configuration
parameters as alternative to the
usage of multiple configuration
containers
• Made the CDD configuration
postBuildConfigurable
AUTOSAR • Updated sorting criteria for
2013-03-15 4.1.1
Administration EcucContainerValues
• Extended CDD configuration with
SoAd interaction
• Clarified the production error
configuration
• The destination of
EcucReferenceDef and
EcucChoiceReferenceDef is
changed to EcucContainerDef

AUTOSAR CP R22-11
• Extended the Ecu Query Language

to describe configuration validity
rules
• Added apiServicePrefix attribute to
EcucModuleDef
• Added
EcucPartitionBswModuleExecution
and EcucPartitionBswModuleDistin-
guishedPartition
• Updated section about the
conversion of time parameters of
main functions to ticks
• Added EcucCoreDefinition to Ecuc
module
• ecuc_sws_5001 removed.
• Clarified modeling of destinationType
and destinationContext.
• Clarified scope of parameters.
• Clarified postBuildChangeable and
multipleConfigurationContainer.
• Added annotation to
EcucAbstractReferenceValue.
• Updated semantics of definitionRef
and introduced the term "pure
VSMD"
AUTOSAR
2011-12-22 4.0.3 • Clarification of PostBuildSelectable,
Administration
PostBuildLoadable in VSMD
• Set configuration class affection
support to deprecated
• Support for ordering of
EcucParameters and
EcucReferences
• Reworked CDD configuration to
reflect the direction of the
communication
• Clarified usage of symbolic name
references

AUTOSAR CP R22-11
• Updated "refvalue" function

requirements
• Added requirement sws6045
• Changed specification of PduLength
parameter from bits to bytes
• Added attribute "origin" to
EcucEnumerationParamDef
• Added "Template Glossary" to
Appendix
• Added "Rules for navigating in Ecu
Configuration Artifacts" chapter
• Removed restriction on
AUTOSAR hex-representation of integers
2011-04-15 4.0.2
Administration • Updated description of
refinedModuleDef within class
ModuleDef
• Changed calculation language key
words to lower case
• Changed structure of EcucQuery
and EcucQueryExpression
• Added section on Communication
Channel ID
• Removed section on
EcucMemoryMappingCollection
• Removed "annotation" from
"EcucContainerValue"
• Implemented Variant Handling
concept
• Implemented Calculation Formula
concept
• Reworked Parameter Value
representation
• Reworked Service Component
Methodology chapter
AUTOSAR • Updated rules for deriving VSMD
2009-12-18 4.0.1
Administration from StMD
• Implemented Documentation support
concept
• Implemented support for existence
dependence of ECUC Parameter
Definition elements
• Added "Clock Tree Configuration"
chapter
• Added "CDD module" chapter

AUTOSAR CP R22-11
AUTOSAR • Fixed foreign reference to

2009-02-04 3.1.2
Administration PduToFrameMapping
• Added reference from Container to
AUTOSAR ContainerDef.
2008-08-13 3.1.1
Administration • Removed reference from Container
to ParamConfContainerDef.
• Changed representation of a
ChoiceContainerDef in an ECU
Configuration Description
• Moved sections from "ECU
Configuration Parameter Definition"
into the "Specification of ECU
Configuration" (COM-Stack
Configuration Patterns)
• Updated interaction of ECU
Configuration with BSW Module
Description
• Added specification items which
AUTOSAR define what is allowed when creating
2007-12-21 3.0.1
Administration a Vendor Specific Module Definition
(VSMD)
• Correction of "InstanceParamRef"
definition in ECU Configuration
Specification
• Refined the available character set of
calculationFormula
• Added clarification about the usage
of ADMIN-DATA to track version
information
• Document meta information
extended
• Small layout adaptations made
AUTOSAR • “Advice for users” revised
2007-01-24 2.1.15
Administration • Legal disclaimer revised
• Methodology chapter revised (incl.
introduction of support for AUTOSAR
Services)
• Added EcucElement,
AUTOSAR EcuSwComposition, configuration
2006-11-28 2.1
Administration class affection, LinkerSymbolDef and
LinkerSymbolValue to the metamodel
• Support for multiple configuration
sets added
• Legal disclaimer revised

AUTOSAR CP R22-11
AUTOSAR
2006-05-16 2.0 Initial Release
Administration

AUTOSAR CP R22-11
Disclaimer
This work (specification and/or software implementation) and the material contained in
it, as released by AUTOSAR, is for the purpose of information only. AUTOSAR and the
companies that have contributed to it shall not be liable for any use of the work.
The material contained in this work is protected by copyright and other types of intel-
lectual property rights. The commercial exploitation of the material contained in this
work requires a license to such intellectual property rights.
This work may be utilized or reproduced without any modification, in any form or by
any means, for informational purposes only. For any other purpose, no part of the work
may be utilized or reproduced, in any form or by any means, without permission in
writing from the publisher.
The work has been developed for automotive applications only. It has neither been
developed, nor tested for non-automotive applications.
The word AUTOSAR and the AUTOSAR logo are registered trademarks.

AUTOSAR CP R22-11
Contents
1 Introduction 15
1.1 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.2 Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3 Binding Times of Constraints . . . . . . . . . . . . . . . . . . . . . . . 20
1.4 Requirements Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2 Configuration Metamodel 23
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2 ECU Configuration Template Structure . . . . . . . . . . . . . . . . . . 23
2.3 ECU Configuration Parameter Definition Metamodel . . . . . . . . . . 27
2.3.1 ECU Configuration Parameter Definition top-level structure . 27
2.3.1.1 Usage of the Admin Data . . . . . . . . . . . . . . . 29
2.3.1.2 Life Cycle definition . . . . . . . . . . . . . . . . . . . 30
2.3.1.3 Documentation Support . . . . . . . . . . . . . . . . 32
2.3.2 ECU Configuration Module Definition . . . . . . . . . . . . . 34
2.3.3 Container Definition . . . . . . . . . . . . . . . . . . . . . . . 38
2.3.3.1 Choice Container Definition . . . . . . . . . . . . . . 43
2.3.4 Common Configuration Elements . . . . . . . . . . . . . . . 46
2.3.4.1 Variant Handling . . . . . . . . . . . . . . . . . . . . 46
2.3.4.2 Configuration Multiplicity . . . . . . . . . . . . . . . . 46
2.3.4.3 Common Configuration Attributes . . . . . . . . . . . 50
2.3.5 Parameter Definition . . . . . . . . . . . . . . . . . . . . . . . 57
2.3.5.1 Boolean Type . . . . . . . . . . . . . . . . . . . . . . 60
2.3.5.2 Integer Type . . . . . . . . . . . . . . . . . . . . . . . 62
2.3.5.3 Float Type . . . . . . . . . . . . . . . . . . . . . . . . 63
2.3.5.4 String Parameter . . . . . . . . . . . . . . . . . . . . 65
2.3.5.5 Linker Symbol Parameter . . . . . . . . . . . . . . . 66
2.3.5.6 Function Name Parameter . . . . . . . . . . . . . . . 68
2.3.5.7 Enumeration Parameter . . . . . . . . . . . . . . . . 68
2.3.5.8 Enumeration Literal Definition . . . . . . . . . . . . . 69
2.3.5.9 AddInfo . . . . . . . . . . . . . . . . . . . . . . . . . 71
2.3.6 References in Parameter Definition . . . . . . . . . . . . . . 71
2.3.6.1 Reference . . . . . . . . . . . . . . . . . . . . . . . . 74
2.3.6.2 Choice Reference . . . . . . . . . . . . . . . . . . . 76
2.3.6.3 Foreign Reference . . . . . . . . . . . . . . . . . . . 77
2.3.6.4 Instance Reference . . . . . . . . . . . . . . . . . . . 78
2.3.6.5 Symbolic Name Reference . . . . . . . . . . . . . . 81
2.3.6.6 Uri Reference . . . . . . . . . . . . . . . . . . . . . . 83
2.3.7 Derived Parameter Specification . . . . . . . . . . . . . . . . 89
2.3.7.1 Derived Parameter Calculation Formula . . . . . . . 90
2.3.7.2 Restrictions on Configuration Class of Derived Pa-
rameters . . . . . . . . . . . . . . . . . . . . . . . . . 101
2.3.8 Existence dependence of ECUC Parameter Definition elements101
2.3.9 Validation conditions . . . . . . . . . . . . . . . . . . . . . . . 105

AUTOSAR CP R22-11
2.3.10 Multiple aggregation of full container trees that include refer-

ences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
2.4 ECU Configuration Value Metamodel . . . . . . . . . . . . . . . . . . . 110
2.4.1 ECU Configuration Value Top-Level Structure . . . . . . . . . 110
2.4.2 Module Configurations . . . . . . . . . . . . . . . . . . . . . 112
2.4.2.1 Splitable ModuleConfiguration . . . . . . . . . . . . 118
2.4.3 Parameter Container Description . . . . . . . . . . . . . . . . 122
2.4.3.1 Choice Containers . . . . . . . . . . . . . . . . . . . 126
2.4.4 Parameter Values . . . . . . . . . . . . . . . . . . . . . . . . 128
2.4.4.1 Textual Parameter Value . . . . . . . . . . . . . . . . 131
2.4.4.2 Numerical Parameter Value . . . . . . . . . . . . . . 133
2.4.4.3 AddInfo Parameter Value . . . . . . . . . . . . . . . 134
2.4.5 References in the ECU Configuration Metamodel . . . . . . 135
2.4.5.1 Instance Reference Values . . . . . . . . . . . . . . 139
2.4.5.2 Representation of Symbolic Names . . . . . . . . . . 141
2.4.5.3 Rules for references in the ECUC Parameter Value
description . . . . . . . . . . . . . . . . . . . . . . . 148
2.4.6 Derived Parameters in an ECU Configuration Description . . 149
2.4.7 Using Variant Handling to Cope with Several Binding
Times in the ECU Configuration Value Description 150
2.4.7.1 Example of ECU configuration using Variant
Handling . . . . . . . . . . . . . . . . . . . . . . . . 151
3 ECU Configuration Parameter Definition SWS implications 159
3.1 Formalization aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
3.1.1 ECU Configuration Parameter Definition table . . . . . . . . 160
3.2 AUTOSAR Stack Overview . . . . . . . . . . . . . . . . . . . . . . . . . 162
3.3 Virtual Module EcuC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
3.3.1 Hardware description . . . . . . . . . . . . . . . . . . . . . . 168
3.3.2 Definition of Partitions . . . . . . . . . . . . . . . . . . . . . . 170
3.3.3 PostBuild Variants . . . . . . . . . . . . . . . . . . . . . . . . 175
3.3.4 Variation Resolver Description . . . . . . . . . . . . . . . . . 176
3.3.5 UnitGroup Assignment . . . . . . . . . . . . . . . . . . . . . 178
3.3.6 Definition of Pdus . . . . . . . . . . . . . . . . . . . . . . . . 179
3.3.7 Pdu Meta-Data . . . . . . . . . . . . . . . . . . . . . . . . . . 185
3.4 COM-Stack configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 188
3.4.1 Handle IDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
3.4.1.1 Handle ID concept . . . . . . . . . . . . . . . . . . . 189
3.4.1.2 Definition of Handle IDs . . . . . . . . . . . . . . . . 190
3.4.1.3 Agreement on Handle IDs . . . . . . . . . . . . . . . 192
3.4.1.4 Handle IDs with symbolic names . . . . . . . . . . . 193
3.4.2 Configuration examples for the Pdu Router . . . . . . . . . . 194
3.4.2.1 Tx from Com to CanIf . . . . . . . . . . . . . . . . . 194
3.4.2.2 Rx from CanIf to Com . . . . . . . . . . . . . . . . . 196
3.4.2.3 Gateway from CanIf to FrIf . . . . . . . . . . . . . . . 197
3.4.3 Communication Channel IDs . . . . . . . . . . . . . . . . . . 197

AUTOSAR CP R22-11
3.5 CDD module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

3.5.1 Pdu Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
3.5.2 COM Interface modules . . . . . . . . . . . . . . . . . . . . . 209
3.5.3 Communication Manager . . . . . . . . . . . . . . . . . . . . 211
3.5.4 Generic Network Management . . . . . . . . . . . . . . . . . 212
3.5.5 Socket Adaptor . . . . . . . . . . . . . . . . . . . . . . . . . . 213
3.5.6 J1939Rm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
3.5.7 Global Time Synchronization . . . . . . . . . . . . . . . . . . 218
3.6 EcuM configuration to initialize post-build capable BSW Modules . . . 221
3.7 Optional reporting of Production Errors and Extended Production Errors 222
3.8 Converting time parameters of main functions to ticks . . . . . . . . . . 222
3.9 Clock Tree Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . 223
4 Rules to follow in different configuration activities 226
4.1 Deriving vendor specific module definitions from standardized module
definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
4.2 Rules for building the Base ECU configuration . . . . . . . . . . . . . . 239
4.3 Rules for navigating in Ecu Configuration Artifacts . . . . . . . . . . . . 241
4.4 Post-build Time Consistency . . . . . . . . . . . . . . . . . . . . . . . . 242
A Possible Implementations for the Configuration Steps 243
A.1 Alternative Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
A.1.1 Alternative Configuration Editor Approaches . . . . . . . . . 243
A.1.1.1 Custom Editors (Informative) . . . . . . . . . . . . . 244
A.1.1.2 Generic Tools (Informative) . . . . . . . . . . . . . . 245
A.1.1.3 Tools Framework (Informative) . . . . . . . . . . . . 246
A.1.2 Alternative Generation Approaches . . . . . . . . . . . . . . 246
B AUTOSAR Service Components 248
C Glossary 250
D Change History 254

D.1 Change History between AUTOSAR R4.0.1 against R3.1.5 . . . . . . . 254
D.1.1 Renamed Meta-Model Elements for AUTOSAR Release 4.0 254
D.1.2 Deleted SWS Items . . . . . . . . . . . . . . . . . . . . . . . 254
D.1.3 Changed SWS Items . . . . . . . . . . . . . . . . . . . . . . 255
D.1.4 Added SWS Items . . . . . . . . . . . . . . . . . . . . . . . . 255
D.2.2 Added SWS Items . . . . . . . . . . . . . . . . . . . . . . . . 257
D.3.3 Added SWS Items . . . . . . . . . . . . . . . . . . . . . . . . 258
D.3.4 Added Constraints . . . . . . . . . . . . . . . . . . . . . . . . 259

AUTOSAR CP R22-11

D.4.3 Added SWS Items . . . . . . . . . . . . . . . . . . . . . . . . 260
D.5.3 Added SWS Items . . . . . . . . . . . . . . . . . . . . . . . . 261
D.6.3 Added SWS Items . . . . . . . . . . . . . . . . . . . . . . . . 262
D.7.1 Added Traceables in 4.2.1 . . . . . . . . . . . . . . . . . . . . 262
D.7.2 Changed Traceables in 4.2.1 . . . . . . . . . . . . . . . . . . 264
D.7.3 Deleted Traceables in 4.2.1 . . . . . . . . . . . . . . . . . . . 265
D.7.4 Added Constraints in 4.2.1 . . . . . . . . . . . . . . . . . . . 266
D.7.5 Changed Constraints in 4.2.1 . . . . . . . . . . . . . . . . . . 266
D.7.6 Deleted Constraints in 4.2.1 . . . . . . . . . . . . . . . . . . 266

AUTOSAR CP R22-11

D.12 Change History between AUTOSAR R4.4.0 against R19-11 . . . . . . 272
D.12.1 Added Traceables in 19-11 . . . . . . . . . . . . . . . . . . . 272
D.12.2 Changed Traceables in 19-11 . . . . . . . . . . . . . . . . . . 272
D.12.3 Deleted Traceables in 19-11 . . . . . . . . . . . . . . . . . . 273
D.12.4 Added Constraints in 19-11 . . . . . . . . . . . . . . . . . . . 273
D.12.5 Changed Constraints in 19-11 . . . . . . . . . . . . . . . . . 273
D.12.6 Deleted Constraints in 19-11 . . . . . . . . . . . . . . . . . . 273
D.13 Change History between AUTOSAR R19-11 against R20-11 . . . . . . 273
D.13.1 Added Traceables in R20-11 . . . . . . . . . . . . . . . . . . 273
D.13.2 Changed Traceables in R20-11 . . . . . . . . . . . . . . . . . 273
D.13.3 Deleted Traceables in R20-11 . . . . . . . . . . . . . . . . . 274
D.13.4 Added Constraints in R20-11 . . . . . . . . . . . . . . . . . . 274
D.13.5 Changed Constraints in R20-11 . . . . . . . . . . . . . . . . 275
D.13.6 Deleted Constraints in R20-11 . . . . . . . . . . . . . . . . . 275
E Mentioned Class Tables 279
F Splitable Elements in the Scope of this Document 310
G Variation Points in the Scope of this Document 311

AUTOSAR CP R22-11
References
[1] Methodology for Classic Platform
AUTOSAR_TR_Methodology
[2] System Template
AUTOSAR_TPS_SystemTemplate
[3] Glossary
AUTOSAR_TR_Glossary
[4] Standardization Template
AUTOSAR_TPS_StandardizationTemplate
[5] Requirements on ECU Configuration
AUTOSAR_RS_ECUConfiguration
[6] Generic Structure Template
AUTOSAR_TPS_GenericStructureTemplate
[7] AUTOSAR XML Schema Production Rules
AUTOSAR_TPS_XMLSchemaProductionRules
[8] Specification of ECU Configuration Parameters (XML)
AUTOSAR_MOD_ECUConfigurationParameters
[9] Meta Model
AUTOSAR_MMOD_MetaModel
[10] IEEE standard for radix-independent floating-point arithmetic
(ANSI/IEEE Std 854-1987)
[11] Meta Model-generated XML Schema
AUTOSAR_MMOD_XMLSchema
[12] Software Component Template
AUTOSAR_TPS_SoftwareComponentTemplate
[13] List of Basic Software Modules
AUTOSAR_TR_BSWModuleList
[14] Layered Software Architecture
AUTOSAR_EXP_LayeredSoftwareArchitecture
[15] Software Process Engineering Meta-Model Specification
http://www.omg.org/spec/SPEM/2.0/

AUTOSAR CP R22-11
1 Introduction
According to the AUTOSAR Methodology (see figure 1.1) the configuration process is
a major part of the ECU software integration that is represented by the activity Inter-
grate Software for ECU.

AUTOSAR CP R22-11

Develop an Abstract
BSW Standard Package System Description
«input» VFB AUTOSAR

Standard Package
1..*
1 1..*
«output»
«input» «input»
0..1 1..*
«input» Develop a
VFB System
0..* Description
0..*
System 0..1 Abstract System
Constraint Description
Description
«input» «input» «output»
Develop System «input»

«input» 0..1

«output» Overall VFB 1
System
«output»
0..*
0..*
«input»
0..* Transformer Design

Bundle
System Extract 1
«input»
«input»
«output»
Develop Basic Software Develop Application

Develop Sub- Software
System
«output»
«output»
«output»
1..* 1..* 1..* 1..*
ECU Extract
1..* Delivered
BSW Module 1..* 1
Delivered Bundle Atomic
«input» Software
«input» «input» Components
Integrate Software
for ECU
«output»
ECU Software Delivered

Figure 1.1: AUTOSAR Methodology Overview (from [1])
The configuration process of an ECU starts with the splitting of the System Description
into several descriptions, whereas each contains all information about one single ECU.
In figure 1.1 the artifact System Description is hidden in the activity Develop

AUTOSAR CP R22-11
System. The creation of an Ecu Extract is described in detail in the System Tem-
plate specification [2].
The Ecu Extract and the BSW Module Delivered Bundle are the inputs for the
ECU configuration step. This is also visible in figure 1.2 where the ECU configuration
is described by the activities Prepare ECU Configuration and Configure BSW
and RTE.
A detailed description about this activities is given in the AUTOSAR Methodology [1],
chapter 2.7.
«input»
1
1
ECU BSW Module
ECU Extract Prepare ECU Configuration «output»
Configuration Data
Configuration Values Source Code
«input» «output»
1..* 1 «input»
«output»
1
1
Generate BSW and

BSW Module
1 RTE
Delivered Bundle BSW Module
Configuration
«inoutput» «output» Header File
Configure BSW and RTE

RTE Source
Code
Figure 1.2: Ecu Configuration Overview (from [1])
Within the ECU Configuration process each single module of the AUTOSAR Architec-
ture can be configured for the special needs of this ECU. Because of a quite complex
AUTOSAR Architecture, modules and interdependencies between the modules, tool-
support is required: AUTOSAR ECU Configuration Editor(s).
The tool strategy and tooling details for the ECU Configuration are out of scope of this
specification. Nevertheless tools need the knowledge about ECU Configuration Pa-
rameters and their constraints such as configuration class, value range, multiplicities
etc. This description is the input for the tools. The description of configuration param-
eters is called ECU Configuration Parameter Definition and described in detail in this
specification (chapter 2.3).
To make sure, that all tools are using the same output-format within the configured
values of the parameters, the ECU Configuration Value description is also part of this
specification and described in detail later on (chapter 2.4). The ECU Configuration
Value description may be on one hand the input format for other configuration tools
(within a tool-chain of several configuration editors) and on the other hand it is the basis
of generators. The configured parameters are generated into ECU executables. This
is the last step of the configuration process and again out of scope of this specification.

AUTOSAR CP R22-11
1.1 Abbreviations
This section describes abbreviations that are specific to the ECU Configuration Speci-
fication and that are not part of the official AUTOSAR Glossary [3].
Following abbreviations are mentioned that are specifically used in this specification:
Abbreviation meaning
ECUC ECU Configuration
ECUC Value descrip- ECU Configuration Value Description
tion
ECUC ParamDef ECU Configuration Parameter Definition
ECUC Value ECU Configuration Value
StMD Standardized Module Definition
VSMD Vendor Specific Module Definition
Table 1.1: Abbreviations used in the scope of this Document

AUTOSAR CP R22-11
1.2 Document Conventions

Technical terms are typeset in mono spaced font, e.g. PortPrototype. As a general
rule, plural forms of technical terms are created by adding "s" to the singular form, e.g.
PortPrototypes. By this means the document resembles terminology used in the
AUTOSAR XML Schema.
This document contains constraints in textual form that are distinguished from the rest
of the text by a unique numerical constraint ID, a headline, and the actual constraint
text starting after the d character and terminated by the c character.
The purpose of these constraints is to literally constrain the interpretation of the
AUTOSAR meta-model such that it is possible to detect violations of the standardized
behavior implemented in an instance of the meta-model (i.e. on M1 level).
Makers of AUTOSAR tools are encouraged to add the numerical ID of a constraint that
corresponds to an M1 modeling issue as part of the diagnostic message issued by the
tool.
The attributes of the classes introduced in this document are listed in form of class
tables. They have the form shown in the example of the top-level element AUTOSAR:
Please note that constraints are not supposed to be enforceable at any given time in an
AUTOSAR workflow. During the development of a model, constraints may legitimately
be violated because an incomplete model will obviously show inconsistencies.
However, at specific points in the workflow, constraints shall be enforced as a safeguard
against misconfiguration.
The points in the workflow where constraints shall be enforced, sometimes also known
as the "binding time" of the constraint, are different for each model category, e.g. on the
classic platform, the constraints defined for software-components are typically enforced
prior to the generation of the RTE while the constraints against the definition of an Ecu
extract shall be applied when the Ecu configuration for the Com stack is created.
For each document, possible binding times of constraints are defined and the binding
times are typically mentioned in the constraint themselves to give a proper orientation
for implementers of AUTOSAR authoring tools.
Let AUTOSAR be an example of a typical class table. The first rows in the table have
the following meaning:
Class: The name of the class as defined in the UML model.
Package: The UML package the class is defined in. This is only listed to help locating
the class in the overall meta model.
Note: The comment the modeler gave for the class (class note). Stereotypes and UML
tags of the class are also denoted here.
Base Classes: If applicable, the list of direct base classes.

AUTOSAR CP R22-11
The headers in the table have the following meaning:

Attribute: The name of an attribute of the class. Note that AUTOSAR does not distin-
guish between class attributes and owned association ends.
Type: The type of an attribute of the class.
Mul.: The assigned multiplicity of the attribute, i.e. how many instances of the given
data type are associated with the attribute.
Kind: Specifies, whether the attribute is aggregated in the class (aggr aggregation),
an UML attribute in the class (attr primitive attribute), or just referenced by it (ref
reference). Instance references are also indicated (iref instance reference) in this
field.
Note: The comment the modeler gave for the class attribute (role note). Stereotypes
and UML tags of the class are also denoted here.
Please note that the chapters that start with a letter instead of a numerical value rep-
resent the appendix of the document. The purpose of the appendix is to support the
explanation of certain aspects of the document and does not represent binding con-
ventions of the standard.
The verbal forms for the expression of obligation specified in [TPS_STDT_00053] shall
be used to indicate requirements, see Standardization Template, chapter Support for
Traceability ([4]).
The representation of requirements in AUTOSAR documents follows the table specified
in [TPS_STDT_00078], see Standardization Template, chapter Support for Traceability
([4]).
1.3 Binding Times of Constraints

Constraints in this document have different actual binding times. Some
parts of the document are considered when defining a ECU Configuration Pa-
rameter Definition (either a STANDARDIZED_MODULE_DEFINITION or a VEN-
DOR_SPECIFIC_MODULE_DEFINITION). In such cases the binding time is described
as "when the ECU Configuration Parameter definition is complete".
Another binding time considers the time when the ECU Configuration Values are used
to generate code. In such cases the binding time is described as "at code generation
time".

AUTOSAR CP R22-11
1.4 Requirements Tracing

The following table references the requirements specified in [5] and links to the fulfill-
ment of these.
Requirement Description Satisfied by
[RS_ECUC_00002] Support of vendor-specific ECU [TPS_ECUC_01001] [TPS_ECUC_01011]
Configuration Parameters [TPS_ECUC_01013] [TPS_ECUC_01014]
[TPS_ECUC_01015] [TPS_ECUC_05002]
[TPS_ECUC_05003] [TPS_ECUC_06007]
[RS_ECUC_00008] Post-build time configuration of [TPS_ECUC_02019]
BSW
[RS_ECUC_00012] One description mechanism for [TPS_ECUC_02016]
different configuration classes
[RS_ECUC_00015] Configuration of multiple instances [TPS_ECUC_02008] [TPS_ECUC_02059]
of BSW modules
[RS_ECUC_00032] ECU Configuration Description [TPS_ECUC_02003]
shall be the root for the whole
configuration information of an
ECU
[RS_ECUC_00043] Duplication free description [TPS_ECUC_02124]
[RS_ECUC_00046] Support definition of configuration [TPS_ECUC_02016]
class
[RS_ECUC_00047] Pre-compile time configuration of [TPS_ECUC_02017]
BSW
[RS_ECUC_00048] Link time configuration of BSW [TPS_ECUC_02018]
[RS_ECUC_00049] ECU Configuration description [TPS_ECUC_02001]
shall be tool process-able
[RS_ECUC_00050] Specify ECU Configuration [TPS_ECUC_02065] [TPS_ECUC_06087]
Parameter Definition
[RS_ECUC_00055] Support standardization of [TPS_ECUC_02008] [TPS_ECUC_02009]
mandatory and optional [TPS_ECUC_03010] [TPS_ECUC_03011]
configuration parameters [TPS_ECUC_03030] [TPS_ECUC_06007]
[RS_ECUC_00065] Development according to the [TPS_ECUC_02000]
AUTOSAR Generic Structure
Template document
[RS_ECUC_00066] Transformation of ECUC model [TPS_ECUC_02001]
according to the AUTOSAR XML
Schema Production Rules
[RS_ECUC_00070] Support mandatory and optional [TPS_ECUC_02008] [TPS_ECUC_02009]
containers [TPS_ECUC_06007]
[RS_ECUC_00071] Support for Generic Configuration [TPS_ECUC_02124]
Editor
[RS_ECUC_00072] Support for referencing from [TPS_ECUC_02039] [TPS_ECUC_03027]
dependent containers [TPS_ECUC_03033]
[RS_ECUC_00073] Support Service Configuration of [TPS_ECUC_02087]
AUTOSAR SW Components
[RS_ECUC_00074] Support Sequential ECU [TPS_ECUC_02124]
Configuration
[RS_ECUC_00076] Support the configuration of which [TPS_ECUC_06014]
AUTOSAR Services are available
on a specific ECU
[RS_ECUC_00078] Variable existence of container on [TPS_ECUC_02119] [TPS_ECUC_02120]
value side
[RS_ECUC_00079] Variable existence of value [TPS_ECUC_02121] [TPS_ECUC_02122]
[TPS_ECUC_02141]
5

AUTOSAR CP R22-11
4
Requirement Description Satisfied by
[RS_ECUC_00080] Variable value [TPS_ECUC_02142]
[RS_ECUC_00082] Variable lower and upper [TPS_ECUC_02110] [TPS_ECUC_06009]
multiplicity in ECU Configuration [TPS_ECUC_06010] [TPS_ECUC_06013]
Parameter definition [TPS_ECUC_06016]
[RS_ECUC_00083] Variable default value in ECU [TPS_ECUC_02111] [TPS_ECUC_02112]
Configuration Parameter definition [TPS_ECUC_02114] [TPS_ECUC_02115]
[RS_ECUC_00084] Variable min and max ranges in [TPS_ECUC_02116] [TPS_ECUC_02117]
ECU Configuration Parameter
definition
[RS_ECUC_00086] The TPS_ECUConfiguration shall [TPS_ECUC_06001] [TPS_ECUC_08011]
provide naming conventions for
public symbols.
Table 1.2: RequirementsTracing

AUTOSAR CP R22-11
2 Configuration Metamodel
2.1 Introduction
AUTOSAR exchange formats are specified using a metamodel based approach. The
metamodel for the configuration of ECU artifacts uses an universal description lan-
guage so that it is possible to specify different kinds of configuration aspects. This
is important as it is possible to describe AUTOSAR-standardized and vendor-specific
ECU Configuration Parameters with the same set of language elements. This eases
the development of tools and introduces the possibility to standardize vendor-specific
ECU Configuration Parameters at a later point in time.
In general the configuration language uses containers and actual parameters. Contain-
ers are used to group corresponding parameters. Parameters hold the relevant values
that configure the specific parts of an ECU. Due to the flexibility that has to be achieved
by the configuration language the configuration description is divided into two parts:
• ECU Configuration Parameter Definition
• ECU Configuration Values
A detailed description of these two parts and their relationships is presented in the
following sections.
2.2 ECU Configuration Template Structure

In this section the relationships between the different AUTOSAR templates involved
in the ECU Configuration are introduced. A template is defining the structure and
possible content of an actual description. The concept is open to be implemented in
several possible ways, in AUTOSAR XML files have been chosen to be used for the
exchange formats. If XML files are used there is no conceptual limit in the number of
files making up the description. All the contributing files are virtually merged to build
the actual description.
The goal of the ECU Configuration Value Template is to specify an exchange format
for the ECU Configuration Values of one ECU. The actual output of ECU Configuration
editors is stored in the ECU Configuration Value description, which might be one or
several XML files. But the ECU Configuration editors need to know how the content
of an ECU Configuration Values should be structured (which parameters are available
in which container) and what kind of restrictions are to be respected (e.g. the ECU
Configuration Parameter is an integer value in the range between 0 and 255). This is
specified in the ECU Configuration Parameter Definition which is also an XML file. The
relationship between the two file types is shown in figure 2.1.

Relationship between Models, Schema and XML-Files

AUTOSAR CP R22-11
XML XML
ECU Configuration ECU
Parameter Configuration
Definition Value description
ECU
Configuration
Editor(s)
Figure 2.1: Parameter Definition and ECU Configuration Value files
For the ECU Configuration editors there are basically two possible approaches how to
implement these definitions. Either the ECU Configuration Parameter Definition is read
and interpreted directly from the XML file or the defined structures are hard-coded into
the tool1 .
For the development of the ECU Configuration Parameter Definition and the ECU Con-
figuration Value description a model-based approach has been chosen which already
has been used during the development of other AUTOSAR template formats.
The main approach is to use a subset of UML to graphically model the desired enti-
ties and their relationships. Then, in a generation step, the actual XML formats are
automatically generated out of the model.
[TPS_ECUC_02000] Modeling of ECU Configuration Value and ECU Configura-
tion Parameter Definition metamodels d The modeling of the ECU Configuration
Value and ECU Configuration Parameter Definition metamodels is done according to
the Generic Structure Template [6].c(RS_ECUC_00065)
Please note that the Generic Structure Template [6] contains some fundamental infras-
tructure meta-classes and common patterns and provides details about:
• Autosar Top level structure,
• Commonly used metaclasses and primitives
• Variant Handling
• Documentation
[TPS_ECUC_02001] Transformation of the ECU Configuration Value and ECU
Configuration Parameter Definition metamodels to schema definitions d The
transformation of the ECU Configuration Value and ECU Configuration Parameter Def-
inition metamodels to schema definitions is done according to the XML Schema Pro-
duction Rules [7].c(RS_ECUC_00049, RS_ECUC_00066)
Because of these transformation rules there is a given discrepancy between the UML
model and the generated XML-Schema names. This also affects this document. The
1
The advantage of using the interpreter is that changes on the ECU Configuration Parameter Defini-
tion are directly available in the tool. But the hard-coded approach allows for more custom user support
in the tool

AUTOSAR CP R22-11
major descriptions will be based on the UML model notations (figures and tables),
although the corresponding XML notation might be given for reference purposes.
In this section the application of the modeling approach for the ECU Configuration is
described.
AUTOSAR uses the UML metamodel (M2-level) to describe the classes and objects
that may be used in an AUTOSAR-compliant system. These metamodel elements
may be used in an application model (M1-level) to describe the content of a real vehi-
cle. ECU Configuration is a part of the AUTOSAR standard so the elements of ECU
Configuration Description shall be described in the UML metamodel at M2-level. The
(M2) metamodel has therefore been populated with UML descriptions from which ECU
Configuration Parameter models may be built.
With M2 definitions in place, it is possible to create AUTOSAR-conforming models
of real application ECU Configuration Parameters (an ECU Configuration Parameter
Definition Model) at M1-level. Certain aspects of real application configurations are
already defined: BSW Modules have standard interfaces and configuration require-
ments. These ’real’ configuration parameters have therefore already been modeled
at M1-level for each defined BSW Module. These are described in detail in the SWS
documents.
XML has been chosen as the technology that will be used by AUTOSAR-compliant
tools in order to define and share information during an AUTOSAR-compliant system
development. It shall therefore be possible to transform the UML Configuration Pa-
rameter Definition Model (M1-level) into an XML Configuration Parameter Definition so
that it may be used by ECU Configuration tools. This is the way that the tool gets a
definition of exactly which ECU Configuration Parameters are available and how they
may be configured. The XML Schema Production Rules [7] describes how the UML
metamodel (M2-level) may be transformed into a schema that describes the format of
XML to contain model elements.
This same formalization is also true for the ECU Configuration Parameter Definition
Metamodel elements on M2-level: the XML Schema Production Rules dictate how
ECU Configuration Parameter Definition elements will generate a schema to hold ECU
Configuration Parameter Model (M1-level) elements in an XML ECU Configuration Pa-
rameter Definition, that can then be interpreted by ECU Configuration tools.
ECU Configuration editors allow a system designer to set ECU Configuration Parame-
ter Values for their particular application. The actual values are then stored in an ECU
Configuration Value description that conforms to the template described in the UML.
An ECU Configuration Value description is an XML file that conforms to an AUTOSAR
schema called an ECU Configuration Value Template. The template in turn is an
AUTOSAR standard defined by placing ECU Configuration Value Template elements
into the UML Meta-Model (M2-level) such that the schema (the ECU Configuration
Value Template) can be generated (using the Formalization Guide rules).
There are three different parts involved in the development of the ECU Configuration:
UML models, Schema and XML content files. The overview is shown in figure 2.2.

Internal
Relationship between Models, Schema and XML-Files
AUTOSAR CP R22-11
UML classes Schema

Schema UML classes
ECU Configuration gen. ECU Configuration gen.
ECU Configuration ECU Configuration
Parameter Definition Parameter Definition
Value Template Value Metamodel
Metamodel Template
conforms to conforms to conforms to
UML objects XML XML

ECU Configuration gen. ECU Configuration ECU
Parameter Definition Parameter Configuration
Model Definition Value description
ECU
Configuration
Editor(s)
Figure 2.2: Relationship between UML models and XML files
The following section describes one way to define ECU Configuration Parameter defi-
nitions. Other ways of defining and maintaining of ECU Configuration Parameter defi-
nitions are also possible.
The ECU Configuration Parameter Definition Model is used to specify the ECU Con-
figuration Parameter Definition. This is done using object diagrams (this is the M1
level of metamodeling) with special semantics defined in section 2.3. What kind of
UML elements are allowed in the ECU Configuration Parameter Definition Model is de-
fined in the ECU Configuration Parameter Definition Metamodel which is conforming to
the Generic Structure Template [6]. The definition is done using UML class diagrams
(which is done on M2 level of metamodeling).
Out of the ECU Configuration Parameter Definition Metamodel a schema 2 is generated
and the generated ECU Configuration Parameter Definition XML file has to conform to
this schema. Vendor-specific ECU Configuration Parameter Definitions need to con-
form to this schema as well.
The ECU Configuration Value XML file needs to conform to the ECU Configuration
Value Template schema which itself is generated out of the ECU Configuration Value
Metamodel specified in UML class diagrams as well.
In the next section the ECU Configuration Parameter Definition Metamodel and its
application toward the ECU Configuration Parameter Definition Model is described.
In the following figures and tables the names from the UML model are shown. In the
generated XML-Schema the names may differ based on the XML Schema Production
Rules [7]. For instance, the attribute shortName will become SHORT-NAME in the
XML-Schema.
2
Whether a DTD or an XML-Schema is used is not relevant for this explanation and is left to the
formalization strategy defined in [7].

AUTOSAR CP R22-11
2.3 ECU Configuration Parameter Definition Metamodel

The two major building blocks for the specification of ECU Configuration Parameter
Definitions are containers and parameters/references. With the ability to establish re-
lationships between containers and parameters and the means to specify references,
the definition of parameters has enough power for the needs of the ECU Configuration.
2.3.1 ECU Configuration Parameter Definition top-level structure
The definition of each Software Module’s3 configuration has at the top level the struc-
ture shown in figure 2.3. For an overview of the complete ECU Configuration top level
structure please refer to chapter 2.4.1.
PackageableElement
ARElement
AtpBlueprint AtpBlueprint
AtpBlueprintable +module AtpBlueprintable
EcucDefinitionCollection EcucDefinitionElement
0..*
EcucModuleDef
+ apiServicePrefix: CIdentifier [0..1]

+ postBuildVariantSupport: Boolean [0..1]
+ supportedConfigVariant: EcucConfigurationVariantEnum [0..*]
+refinedModuleDef 0..1
«atpUriDef»
«atpSplitable»
+container 0..*
EcucDefinitionElement
EcucContainerDef
+ origin: String [0..1]

+ postBuildVariantMultiplicity: Boolean [0..1]
+ requiresIndex: Boolean [0..1]
Figure 2.3: ECU Configuration Parameter Definition top-level structure
[TPS_ECUC_02002] Generic structure of all AUTOSAR templates d The generic

structure of all AUTOSAR templates is described in detail in the AUTOSAR Generic
Structure Template [6].c()
[TPS_ECUC_02130] Standardized Module Definition package structure d The
Standardized Module Definition (StMD) as delivered by AUTOSAR [8] shall be pro-
vided inside the package structure /AUTOSAR/EcucDefs/.c()
[TPS_ECUC_06070] Sorting of Ecu Configuration Parameter Definitions d Ecu
Configuration Parameter Definitions shall be sorted alphabetically.c()
3
A Software Module might be Basic Software, RTE, Application Software Component or Complex
Driver; see AUTOSAR Glossary [3]. The approach of Ecu configuration may be applied to non-
standardized AUTOSAR Software modules (Application Software Component or Complex Driver) using
the Vendor Specific Module Definition.

AUTOSAR CP R22-11
[TPS_ECUC_02003] EcucDefinitionCollection class d First ECU Configura-

tion specific class is the EcucDefinitionCollection which inherits from AREle-
ment. Through this inheritance the EcucDefinitionCollection can be part of
an AUTOSAR ARPackage and thus part of an AUTOSAR description.c(RS_ECUC_-
00032)
[TPS_ECUC_02149] Existence of EcucDefinitionCollection.module d An
EcucDefinitionCollection without any references to EcucModuleDef has no
effect on the Ecu configuration and should not occur when the ECU Configuration
Parameter definition is complete.c()
[TPS_ECUC_02065] EcucModuleDef class d The ECU Configuration Parameter
Definition of one module is called EcucModuleDef and inherits from ARElement.c
(RS_ECUC_00050)
ARElement itself inherits from PackageableElement, Identifiable and Re-
ferrable which has two consequences: First, each Referrable has to have a ma-
chine readable shortName. Second, the Identifiable introduces the concept of a
namespace for the contained Identifiable objects, so those objects need to have
unique shortNames in the scope of that namespace. For additional information about
the consequences of being a Referrable and Identifiable and the additional
attributes please refer to the AUTOSAR Generic Structure Template [6].
[TPS_ECUC_02004] EcucDefinitionCollection collects all references to indi-
vidual module configuration definitions d The use-case of the EcucDefinition-
Collection class is to collect all references to individual module configuration defini-
tions of the AUTOSAR ECU Configuration. Therefore the EcucDefinitionCollec-
tion specifies a reference relationship to the definition of several Software Modules in
the module attribute.c()
Please note that it is allowed to have several EcucDefinitionCollections to col-
lect the EcucModuleDefs based on various criteria e.g. modules from different ven-
dors.
Class EcucDefinitionCollection
Package M2::AUTOSARTemplates::ECUCParameterDefTemplate
Note This represents the anchor point of an ECU Configuration Parameter Definition within the AUTOSAR
templates structure.
Tags:atp.recommendedPackage=EcucDefinitionCollections
Base ARElement, ARObject, AtpBlueprint, AtpBlueprintable, CollectableElement, Identifiable, Multilanguage
Referrable, PackageableElement, Referrable
Aggregated by ARPackage.element
Attribute Type Mult. Kind Note
module EcucModuleDef * ref References to the module definitions of individual
software modules.
Table 2.1: EcucDefinitionCollection

AUTOSAR CP R22-11
2.3.1.1 Usage of the Admin Data
AdminData is an attribute of Identifiable [6] and can be used to set administrative

information for an element (e.g. version information). Such administrative information
can be set for the whole ECU Configuration Parameter Definition XML file and for each
module definition.
[TPS_ECUC_06004] AdminData field in ECU Configuration Parameter Definition
XML file d An AdminData field is required at the beginning of every ECU Configuration
Parameter Definition XML file (regardless whether it is the StMD or the VSMD file) to
allow the setting of AdminData for the whole XML File.c()
Example 2.1 shows how AdminData can be used for the whole ECU Configuration
Parameter Definition file. For the files provided by AUTOSAR the AdminData shall be
filled out with the AUTOSAR release information (Release and Revision number). For
the files provided by Vendor the AdminData shall be filled out with the Vendor release
information.
Example 2.1
<ADMIN-DATA>
<DOC-REVISIONS>
<DOC-REVISION>
<REVISION-LABEL>optional_file_revision</REVISION-LABEL>
<ISSUED-BY>AUTOSAR_or_VendorShortName</ISSUED-BY>
<DATE>optional_file_date</DATE>
</DOC-REVISION>
</DOC-REVISIONS>
</ADMIN-DATA>
[TPS_ECUC_06005] Usage of AdminData on EcucModuleDef is mandatory dFor

each module definition, the revision of the StMD shall be provided. For the VSMD the
AUTOSAR release version and the vendor’s own version information shall be provided.
The usage of AdminData on EcucModuleDef is mandatory.c()
[TPS_ECUC_08053] AUTOSAR release version in VSMD dIn the VSMD the
AUTOSAR release version shall be provided in following format:
• DocRevision.revisionLabel shall be set to the AUTOSAR release number.
• DocRevision.issuedBy shall be set to AUTOSAR.
c()
Example 2.2 shows that there are possibilities to specify several elements for the
AdminData. The initial one would be provided by AUTOSAR, the additional one is the
vendor’s information which is based on the AUTOSAR one.
Example 2.2
<ECUC-MODULE-DEF>
<SHORT-NAME>Rte</SHORT-NAME>

AUTOSAR CP R22-11
<DESC>
<L-2 L="EN">Configuration Parameter Definition of the RTE</L-2>
</DESC>
<ADMIN-DATA>
<DOC-REVISIONS>
<DOC-REVISION>
<REVISION-LABEL>4.2.1</REVISION-LABEL>
<ISSUED-BY>AUTOSAR</ISSUED-BY>
<DATE>2014-10-31</DATE>
</DOC-REVISION>
<DOC-REVISION>
<REVISION-LABEL>15.3.0</REVISION-LABEL>

<REVISION-LABEL-P-1>2.1.1</REVISION-LABEL-P-1>
<ISSUED-BY>VendorX</ISSUED-BY>
<DATE>2007-06-21T09:30:00+01:00</DATE>
</DOC-REVISION>
</DOC-REVISIONS>
</ADMIN-DATA>
<LOWER-MULTIPLICITY>0</LOWER-MULTIPLICITY>
<UPPER-MULTIPLICITY>1</UPPER-MULTIPLICITY>
<CONTAINERS>

</CONTAINERS>
</ECUC-MODULE-DEF>
2.3.1.2 Life Cycle definition
AUTOSAR provides support for life cycle handling, defined in the Generic Structure
Template [6]. A standardized usage of this approach is defined in the Standardization
Template [4].
For the definition of ECU Configuration Parameters there is support in the MetaModel
to annotate the life cycle state of each EcucDefinitionElement. For the annotation
the following tagged value pairs can be used (see example 2.3):
• atp.Status
• atp.StatusComment
• atp.StatusRevisionBegin
Example 2.3
<LIFE-CYCLE-INFO-SET>
<SHORT-NAME>AUTOSARParameterDefinition</SHORT-NAME>
<DEFAULT-LC-STATE-REF DEST="LIFE-CYCLE-STATE">/AUTOSAR/GeneralDefinitions
/LifeCycleStateDefinitionGroups/AutosarLifeCycleStates/valid</DEFAULT-
LC-STATE-REF>
<DEFAULT-PERIOD-BEGIN>
<AR-RELEASE-VERSION>4.1.1</AR-RELEASE-VERSION>
</DEFAULT-PERIOD-BEGIN>

AUTOSAR CP R22-11
<LIFE-CYCLE-INFOS>
<LIFE-CYCLE-INFO>
<LC-OBJECT-REF DEST="ECUC-DEFINITION-ELEMENT">/AUTOSAR/EcucDefs/EcuC/
EcucConfigSet/EcucPduCollection/Pdu/SysTPduToFrameMappingRef</LC-
OBJECT-REF>
<LC-STATE-REF DEST="LIFE-CYCLE-STATE">/AUTOSAR/GeneralDefinitions/
LifeCycleStateDefinitionGroups/AutosarLifeCycleStates/obsolete</LC
-STATE-REF>
<PERIOD-BEGIN>
<AR-RELEASE-VERSION>4.1.1</AR-RELEASE-VERSION>
</PERIOD-BEGIN>
<REMARK>
<P>
<L-1 L="EN">obsolete since R4.1.1</L-1>
</P>
</REMARK>
<USE-INSTEAD-REFS>
<USE-INSTEAD-REF DEST="ECUC-DEFINITION-ELEMENT">/AUTOSAR/EcucDefs/
EcuC/EcucConfigSet/EcucPduCollection/Pdu/
SysTPduToFrameTriggeringRef</USE-INSTEAD-REF>
<USE-INSTEAD-REF DEST="ECUC-DEFINITION-ELEMENT">/AUTOSAR/EcucDefs/
EcuC/EcucConfigSet/EcucPduCollection/Pdu/
SysTPduToPduTriggeringRef</USE-INSTEAD-REF>
</USE-INSTEAD-REFS>
</LIFE-CYCLE-INFO>
</LIFE-CYCLE-INFOS>
<USED-LIFE-CYCLE-STATE-DEFINITION-GROUP-REF DEST="LIFE-CYCLE-STATE-
DEFINITION-GROUP">/AUTOSAR/GeneralDefinitions/
LifeCycleStateDefinitionGroups/AutosarLifeCycleStates</USED-LIFE-CYCLE
-STATE-DEFINITION-GROUP-REF>
</LIFE-CYCLE-INFO-SET>
If a EcucParamConfContainerDef in the StMD has the atp.Status set to a value

then the included aggregation of parameters, references and subContainers
are allowed to have the atp.Status set according to Table 2.2.
There “1” means allowed and “0” means not allowed combination. Please note that the
Table 2.2 is only valid for the StMD and not for the VSMD.
Status of included aggregation
Status of EcucParamConfContainerDef draft valid obsolete removed
draft 1 0 1 1
valid 1 1 1 1
obsolete 0 0 1 1
removed 0 0 0 1
Table 2.2: Matrix of allowed status value combinations of EcucParamConfCon-

tainerDef and aggregations of EcucParameterDef/EcucAbstractReferenceDef/E-
cucContainerDef in the StMD
If a EcucAbstractReferenceDef in the StMD has the atp.Status set to a value then

the target of this reference is allowed to have the atp.Status set according to Table 2.3.

AUTOSAR CP R22-11
Status of reference target

Status of EcucAbstractReferenceDef draft valid obsolete removed
draft 1 1 0 0
valid 0 1 0 0
obsolete 1 1 1 0
removed 1 1 1 1
Table 2.3: Matrix of allowed status value combinations of referenced targets of a

EcucAbstractReferenceDef
Please note that in the current StMD only the atp.Status values “valid”, “obsolete” and
“draft” are used.
2.3.1.3 Documentation Support
AUTOSAR provides support for integrated and well-structured documentation. More

details about the AUTOSAR Documentation Support concept can be found in the
AUTOSAR Generic Structure Template [6].
The documentation can be specified within in the following levels:
• a single paragraph can be inserted in any Identifiable element using the
desc element.
• a documentation block is available in any Identifiable element as intro-
duction. This type of documentation is typically used to capture a short intro-
duction about the role of an element or respectively how it is built.
• a standalone documentation structured into multiple chapters is also offered in
AUTOSAR. It is provided as Documentation which is an ARElement of its own
rights allowing for a reference to the documents context.
With the introduction of this concept the container and parameter notes in the ECU
Configuration Parameter Definition XML file are split into a desc and an introduc-
tion field. The desc field contains a brief description about the element and the
introduction field contains the documentation about how the element is built and
used.
In the ECU Configuration Parameter Definition XML file of the current AUTOSAR Re-
lease the proper usage of the desc and the introduction fields is not guaranteed.
Therefore the content of the desc and introduction shall be read as one cohesive
note.
Example 2.4 shows the split of the desc and introduction.
Example 2.4
<ECUC-MODULE-DEF>
<SHORT-NAME>Adc</SHORT-NAME>
<CONTAINERS>

AUTOSAR CP R22-11
<ECUC-PARAM-CONF-CONTAINER-DEF>
<SHORT-NAME>AdcHwUnit</SHORT-NAME>
<DESC>
<L-2 L="EN">This container contains the Driver configuration (
parameters) depending on grouping of channels</L-2>
</DESC>
<INTRODUCTION>
<P>
<L-1 L="EN">This container could contain HW specific parameters
which are not defined in the Standardized Module Definition.
They shall be added in the Vendor Specific Module Definition.<
/L-1>
</P>
</INTRODUCTION>
<UPPER-MULTIPLICITY-INFINITE>true</UPPER-MULTIPLICITY-INFINITE>
</ECUC-PARAM-CONF-CONTAINER-DEF>
</CONTAINERS>
</ECUC-MODULE-DEF>
Example 2.5 shows the usage of the Documentation element to describe elements
like chapters, lists, tables and figures. For details on this description means please
refer to the AUTOSAR Generic Structure Template [6].
Example 2.5
<DOCUMENTATION>
<SHORT-NAME>Adc_AddInfo</SHORT-NAME>
<CONTEXTS>
<DOCUMENTATION-CONTEXT>
<SHORT-NAME>AUTOSAR_Adc</SHORT-NAME>
<IDENTIFIABLE-REF DEST="ECUC-MODULE-DEF">/AUTOSAR/EcucDefs/Adc</
IDENTIFIABLE-REF>
</DOCUMENTATION-CONTEXT>
</CONTEXTS>
<DOCUMENTATION-CONTENT>
<CHAPTER>
<SHORT-NAME>Introduction</SHORT-NAME>
<P><L-1 L="EN">The ADC module initializes and controls the internal
Analogue Digital Converter Unit(s) of the microcontroller. It
provides services to start and stop a conversion respectively to
enable and disable the trigger source for a conversion.</L-1></P>
<P><L-1 L="EN">The consistency of the group channel results can be
obtained with the following methods on the application side:</L-1>
</P>
<LIST>
<ITEM>
<P><L-1 L="EN">Using group notification mechanism</L-1></P>
</ITEM>
<ITEM>
<P><L-1 L="EN">Polling via API function Adc_GetGroupStatus</L-1><
/P>
</ITEM>
</LIST>

AUTOSAR CP R22-11
<TABLE>
<TGROUP COLS="2">
<THEAD>
<ROW>
<ENTRY>
<P><L-1 L="EN">column1</L-1></P>
</ENTRY>
<ENTRY>
<P><L-1 L="EN">column2</L-1></P>
</ENTRY>
</ROW>
</THEAD>
<TBODY>
<ROW>
<ENTRY>
<P><L-1 L="EN">element11</L-1></P>
</ENTRY>
<ENTRY>
</ENTRY>
</ROW>
<ROW>
<ENTRY>
</ENTRY>
<ENTRY>
</ENTRY>
</ROW>
</TBODY>
</TGROUP>
</TABLE>
</CHAPTER>
</DOCUMENTATION-CONTENT>
</DOCUMENTATION>
2.3.2 ECU Configuration Module Definition
[TPS_ECUC_02005] EcucModuleDef class d The class EcucModuleDef is defining

the ECU Configuration Parameters of one Software Module4 . It is inheriting from
ARElement, so each individual EcucModuleDef needs to have a unique name within
its enclosing ARPackage.c()
[TPS_ECUC_02059] Number of instances of a BSW module in the ECU Configura-
tion Value description d The EcucModuleDef is using the EcucDefinitionEle-
ment attributes to specify how many instances of that specific module are allowed in
the ECU Configuration Value description (see [TPS_ECUC_02008] for more details).c
(RS_ECUC_00015)
4
A Software Module is not restricted to the BSW Modules but also includes the RTE, Application
Software Components and generic ECU Configuration.

AUTOSAR CP R22-11
Class EcucModuleDef
Note Used as the top-level element for configuration definition for Software Modules, including BSW and RTE
as well as ECU Infrastructure.
Tags:atp.recommendedPackage=EcucModuleDefs
Base ARElement, ARObject, AtpBlueprint, AtpBlueprintable, AtpDefinition, CollectableElement, Ecuc
DefinitionElement, Identifiable, MultilanguageReferrable, PackageableElement, Referrable
apiServicePrefix CIdentifier 0..1 attr For modules where several instances of the VSMD can
be defined the apiServicePrefix defines the API
namespace of the derived instances, e.g. Cdd, Xfrm
(ComXf, SomeIpXf, E2EXf).
container EcucContainerDef * aggr Aggregates the top-level container definitions of this
specific module definition.
Stereotypes: atpSplitable
Tags:
atp.Splitkey=container.shortName
xml.sequenceOffset=11
postBuildVariant Boolean 0..1 attr Indicates if a module supports different post-build variants
Support (previously known as post-build selectable configuration
sets). TRUE means yes, FALSE means no.
refinedModule EcucModuleDef 0..1 ref Optional reference from the Vendor Specific Module
Def Definition to the Standardized Module Definition it refines.
In case this EcucModuleDef has the category
STANDARDIZED_MODULE_DEFINITION this reference
shall not be provided. In case this EcucModuleDef has
the category VENDOR_SPECIFIC_MODULE_
DEFINITION this reference is mandatory.
Stereotypes: atpUriDef
supported EcucConfiguration * attr Specifies which ConfigurationVariants are supported by
ConfigVariant VariantEnum this software module. This attribute is optional if the Ecuc
ModuleDef has the category STANDARDIZED_
MODULE_DEFINITION. If the category attribute of the
EcucModuleDef is set to VENDOR_SPECIFIC_
MODULE_DEFINITION then this attribute is mandatory.
Table 2.4: EcucModuleDef
[TPS_ECUC_02094] EcucModuleDef is able to aggregate container definitions

d The EcucModuleDef aggregates container definitions (EcucModuleDef) with the
role name container which may hold other container definitions, parameter defini-
tions and reference definitions.c()
[TPS_ECUC_02150] Existence of EcucModuleDef.container d An EcucMod-
uleDef without any EcucContainerDef has no effect on the Ecu configuration and
should not occur when the ECU Configuration Parameter definition is complete.c
()
[TPS_ECUC_08012] Module support for post-build variants dThe postBuild-
VariantSupport attribute of the EcucModuleDef specifies if this EcucModuleDef
supports different variation points bound at post-build time (post-build variants)5 . true
means yes, false means no.c()
5
Note that post-build variants were previously known as post-build selectable configuration sets.

AUTOSAR CP R22-11
[constr_5507] Value of EcucContainerDef.postBuildVariantMultiplicity

if postBuildVariantSupport is set to false dIf postBuildVariantSupport
is set to false, every EcucContainerDef in this EcucModuleDef with upperMul-
tiplicity greater than lowerMultiplicity shall have its postBuildVariant-
Multiplicity attribute set to false.c()
[constr_5509] Value of postBuildVariantMultiplicity if postBuildVari-
antSupport is set to false dIf postBuildVariantSupport is set to false, ev-
ery EcucCommonAttributes in this EcucModuleDef with upperMultiplicity
greater than lowerMultiplicity shall have its postBuildVariantMultiplic-
ity attribute set to false.c()
[constr_5510] Value of postBuildVariantValue if postBuildVariantSup-
port is set to false dIf postBuildVariantSupport is set to false, every Ecuc-
CommonAttributes in this EcucModuleDef shall have its postBuildVariant-
Value attribute set to false.c()
[TPS_ECUC_02095] VSMD refines the StMD d The reference re-
finedModuleDef from an EcucModuleDef with the category VEN-
DOR_SPECIFIC_MODULE_DEFINITION to an EcucModuleDef with the category
STANDARDIZED_MODULE_DEFINITION specifies that the source EcucModuleDef
is the Vendor Specific Module Definition which refines the referenced Standardized
EcucModuleDef.c()
[TPS_ECUC_06076] Use cases where the reference refinedModuleDef
is mandatory dThe refinedModuleDef reference is mandatory if the Ecuc-
ModuleDef with the category VENDOR_SPECIFIC_MODULE_DEFINITION
actually refines the EcucModuleDef with the category STANDARD-
IZED_MODULE_DEFINITION (e.g. Vendor Specific Module Definition of Com
BSW module refines Standardized Module Definition of Com BSW module).c()
[TPS_ECUC_06077] Use cases where the reference refinedModuleDef is
optional dThe refinedModuleDef reference is not necessary if the Ecuc-
ModuleDef with the category VENDOR_SPECIFIC_MODULE_DEFINITION does
not actually refines any EcucModuleDefs with the category STANDARD-
IZED_MODULE_DEFINITION (e.g. Vendor Specific Module Definition of CDD which
does not contribute to the ComStack configuration).c()
[TPS_ECUC_06044] refinedModuleDef reference in the StMD d The refer-
ence refinedModuleDef from an EcucModuleDef with the category STANDARD-
IZED_MODULE_DEFINITION shall not be used.c()
[TPS_ECUC_06043] EcucModuleDef categories d The category attribute shall be
used to clearly distinguish between the different roles of the EcucModuleDef class.c
()
category Meaning
STANDARDIZED_ The EcucModuleDef class is used to describe the Standardized Module
MODULE_DEFINITION Definition (StMD)

AUTOSAR CP R22-11
category Meaning
VENDOR_SPECIFIC_ The EcucModuleDef class is used to describe Vendor Specific Module
MODULE_DEFINITION Definition
Table 2.5: EcucModuleDef class categories
[constr_3022] EcucModuleDef category restriction dThe category definition shall

be restricted to exactly the two defined ones:
• VENDOR_SPECIFIC_MODULE_DEFINITION
• STANDARDIZED_MODULE_DEFINITION
c()
[TPS_ECUC_02096] Supported configuration variants in a BSW module d The
EcucModuleDef specifies which configuration variants are supported by this software
modules configuration using the element supportedConfigVariant. For each con-
figuration variant that is supported one entry shall be provided.c()
For a detailed description how the configuration variants are related to the configuration
classes please refer to section 2.3.4.3.2.
In figure 2.4 an example of the top-level structure is provided and in the example 2.6
the corresponding ECU Configuration Parameter Definition XML file extract is shown.
In the example XML also the overall XML structure of AUTOSAR descriptions is shown.
The corresponding ECU Configuration Value description XML file extract is shown in
example 2.28.
AUTOSARParameterDefinition:
EcucDefinitionCollection
Figure 2.4: ECU Configuration Definition example
Example 2.6
<AR-PACKAGE>
<SHORT-NAME>EcucDefs</SHORT-NAME>
<ELEMENTS>
<ECUC-DEFINITION-COLLECTION>
<SHORT-NAME>AUTOSARParameterDefinition</SHORT-NAME>
<MODULE-REFS>
<MODULE-REF DEST="ECUC-MODULE-DEF">/AUTOSAR/EcucDefs/Rte</
MODULE-REF>

</MODULE-REFS>
</ECUC-DEFINITION-COLLECTION>
<ECUC-MODULE-DEF>
<DESC>
<L-2 L="EN">Configuration Parameter Definition of the RTE</L-2>
</DESC>

AUTOSAR CP R22-11
<POST-BUILD-VARIANT-SUPPORT>false</POST-BUILD-VARIANT-SUPPORT>
<SUPPORTED-CONFIG-VARIANTS>
<SUPPORTED-CONFIG-VARIANT>VARIANT-PRE-COMPILE</SUPPORTED-CONFIG
-VARIANT>
</SUPPORTED-CONFIG-VARIANTS>
<CONTAINERS>

</CONTAINERS>
</ECUC-MODULE-DEF>
</ELEMENTS>
</AR-PACKAGE>
In the next sections the structure of containers, individual parameters and references
is introduced.
2.3.3 Container Definition
There are two specializations of a container definition. The abstract class EcucCon-
tainerDef is used to gather the common features (see figure 2.5).
AtpDefinition +trace 0..*

Identifiable
MultilanguageReferrable
EcucDefinitionElement +relatedTraceItem Traceable
+ scope: EcucScopeEnum [0..1] «atpUriDef» 0..1
«enumeration»
EcucConfigurationClassEnum «atpVariation»
+ lowerMultiplicity: PositiveInteger [0..1]
PublishedInformation + upperMultiplicity: PositiveInteger [0..1]
PreCompile + upperMultiplicityInfinite: Boolean [0..1]
Link
PostBuild EcucAbstractConfigurationClass
+ configClass: EcucConfigurationClassEnum [0..1]

+ configVariant: EcucConfigurationVariantEnum [0..1]
«enumeration»
EcucConfigurationVariantEnum
PreconfiguredConfiguration
RecommendedConfiguration
VariantPreCompile EcucContainerDef
EcucMultiplicityConfigurationClass
VariantLinkTime +multiplicityConfigClass
VariantPostBuild
+ postBuildVariantMultiplicity: Boolean [0..1] 0..*
+subContainer 0..*
EcucCommonAttributes
«atpSplitable» EcucParameterDef
+parameter + symbolicNameValue: Boolean [0..1]

+ withAuto: Boolean [0..1]
EcucChoiceContainerDef EcucParamConfContainerDef 0..*
+choice «atpSplitable»
«atpSplitable» 0..* +reference EcucCommonAttributes

«atpSplitable» 0..*
Figure 2.5: Class diagram for parameter container definition

AUTOSAR CP R22-11
Class EcucContainerDef (abstract)

Note Base class used to gather common attributes of configuration container definitions.
Base ARObject, AtpDefinition, EcucDefinitionElement, Identifiable, MultilanguageReferrable, Referrable
Subclasses EcucChoiceContainerDef, EcucParamConfContainerDef
Aggregated by EcucDestinationUriPolicy.container, EcucModuleDef.container, EcucParamConfContainerDef.sub
Container
destinationUri EcucDestinationUriDef * ref Several destinationUris can be defined for an Ecuc
ContainerDef. With such destinationUris an Ecuc
ContainerDef is applicable for several EcucUriReference
Defs.
multiplicity EcucMultiplicity * aggr Specifies which MultiplicityConfigurationClass this
ConfigClass ConfigurationClass container is available for which ConfigurationVariant. This
aggregation is optional if the surrounding EcucModuleDef
has the Category STANDARDIZED_MODULE_
DEFINITION. If the category attribute of the EcucModule
Def is set to VENDOR_SPECIFIC_MODULE_
DEFINITION and if the upperMultiplicity is greater than
the lowerMultiplicity then this aggregation is mandatory.
Tags:xml.name
Plural=MULTIPLICITY-CONFIG-CLASSES
origin String 0..1 attr This attribute specifies whether this configuration
container is an AUTOSAR standardized container or
whether it is vendor-specific.
postBuildVariant Boolean 0..1 attr Indicates if a container may have different number of
Multiplicity instances in different post-build variants (previously
known as post-build selectable configuration sets). TRUE
means yes, FALSE means no.
requiresIndex Boolean 0..1 attr Used to define whether the value element for this
definition shall be provided with an index.
Table 2.6: EcucContainerDef
[TPS_ECUC_02044] Number of instances of a EcucContainerDef in the ECU

Configuration Value description d Each EcucContainerDef also has the features
of EcucDefinitionElement which enables to specify for each EcucContain-
erDef how often it is allowed to occur in the ECU Configuration Value description
later on (see [TPS_ECUC_02008] for more details).c()
[TPS_ECUC_08000] Different number of EcucContainerDef instances in dif-
ferent configuration times dThe assignment of configClasses to configVari-
ants of the EcucContainerDef.multiplicityConfigClass specifies when (i.e.
PreCompile time, Link time, PostBuild time) the number of instances of this
EcucContainerDef at latest may change for each implementation variant of the
EcucModuleDef (i.e. VariantPreCompile, VariantLinkTime, VariantPost-
Build).c()
For example if a multiplicityConfigClass.configClass of one container
equals PostBuild for multiplicityConfigClass.configVariant Variant-
PostBuild, this means that the number of instances of this container at latest may
change at post-build time (i.e. updated post-build configurations may contain different
number of instances of this container, e.g. ComIPdu).

AUTOSAR CP R22-11
The assignment of configClasses to configVariants is described in Section

2.3.4.3.2.
[constr_5500] Applicability of the multiplicityConfigClass attribute dThe
multiplicityConfigClass attribute is applicable only to EcucContainerDefs
which have upperMultiplicity greater than lowerMultiplicity.c()
[constr_5504] Removing an instance of the EcucContainerDef at post-build
time dOnly instances of EcucContainerDefs with multiplicityConfigClass.
configClass set to PostBuild in the multiplicityConfigClass.config-
Variant VariantPostBuild which are not referenced or are exclusively referenced
by EcucAbstractReferenceDefs with valueConfigClass.configClass set to
PostBuild in the valueConfigClass.configVariant VariantPostBuild and
have been introduced at post-build time (not part of the initial configuration before post-
build updates) can be removed at post-build time.c()
[TPS_ECUC_08003] Usage of multiplicityConfigClass.configClass at-
tribute is independent of its aggregated subContainers dAn EcucContain-
erDef may have the attribute multiplicityConfigClass.configClass set to
PostBuild in the multiplicityConfigClass.configVariant VariantPost-
Build even if one or more of its aggregated EcucContainerDefs in the role sub-
Container have the attribute multiplicityConfigClass.configClass set to
PreCompile or Link in the valueConfigClass.configVariant VariantPost-
Build.c()
If a container "A" has the attribute multiplicityConfigClass.configClass set
to PostBuild and its sub-container "B" set to Link, it is not possible to add a new
instance "b2" of sub-container "B" to the existing container instance "a1" of "A" in post-
build time. However, it is allowed to add a new instance "a2" of the container "A"
together with a new instance "b2" of its sub-container "B".
[TPS_ECUC_08013] Different number of EcucContainerDef instances in differ-
ent post-build variants dThe postBuildVariantMultiplicity attribute of the
EcucContainerDef specifies if a different number of instances of this EcucCon-
tainerDef may exist in different post-build variants6 . true means yes, false means
no.c()
[constr_5506] Applicability of postBuildVariantMultiplicity attribute dThe
postBuildVariantMultiplicity attribute of EcucContainerDef is applicable
only to EcucContainerDefs which have upperMultiplicity greater than low-
erMultiplicity.c()
[TPS_ECUC_08014] Usage of postBuildVariantMultiplicity attribute is in-
dependent of aggregated subContainers dAn EcucContainerDef may have the
attribute postBuildVariantMultiplicity set to true even if one or more of
its aggregated EcucContainerDefs in the role subContainer have the attribute
postBuildVariantMultiplicity set to false.c()
6

AUTOSAR CP R22-11
If container "A" has postBuildVariantMultiplicity attribute set to true and its

sub-container "B" set to false, it is not possible to have a different number of instances
of "B" in the same instance of "A" in different post-build variants. However it is allowed
to have a different number of instances of container "A" where new instances may have
arbitrary number of instances of container "B".
[constr_3235] EcucModuleDef that relies on EcucContainerDefs with mul-
tiplicityConfigClass set to Link/PostBuild of another EcucModuleDef dIf
one EcucModuleDef relies on the EcucContainerDefs with multiplicityCon-
figClass.configClass set to Link/PostBuild of another EcucModuleDef, the
number of instances of these EcucContainerDefs can only be changed at Link/
PostBuild time if the corresponding EcucModuleConfigurationValues of the
using EcucModuleDef has the implementationConfigVariant set to Vari-
antLinkTime/VariantPostBuild, respectively.c()
Note: [constr_3235] shall be checked by the using module, i.e., the module that is not
post-build capable shall assure that the number of the post-build container instances
used from other modules is not changed.
[constr_3238] EcucModuleDef that relies on EcucContainerDef with post-
BuildVariantMultiplicity set to true of another EcucModuleDef dIf one
EcucModuleDef relies on the EcucContainerDefs with postBuildVariantMul-
tiplicity set to true of another EcucModuleDef, the number of instances of these
EcucContainerDefs can can only differ in different post-build variants if the imple-
mentation of the using EcucModuleDef supports post-build variations.c()
Note: [constr_3238] shall be checked by the using module, i.e., the module that does
not support post-build variation shall assure that the number of post-build variable con-
tainer instances used from other modules is the same in all variants.
[TPS_ECUC_02007] EcucParamConfContainerDef class d A EcucParamConf-
ContainerDef is the main container class definition and can contain other containers,
configuration parameters and references.c()
Class EcucParamConfContainerDef
Note Used to define configuration containers that can hierarchically contain other containers and/or parameter
definitions.
Base ARObject, AtpDefinition, EcucContainerDef , EcucDefinitionElement, Identifiable, Multilanguage
Referrable, Referrable
Aggregated by EcucChoiceContainerDef.choice, EcucDestinationUriPolicy.container, EcucModuleDef.container, Ecuc
ParamConfContainerDef.subContainer
parameter EcucParameterDef * aggr The parameters defined within the EcucParamConf
ContainerDef.
Tags:atp.Splitkey=parameter.shortName
5

AUTOSAR CP R22-11
4
Class EcucParamConfContainerDef
reference EcucAbstractReference * aggr The references defined within the EcucParamConf
Def ContainerDef.
Tags:atp.Splitkey=reference.shortName
subContainer EcucContainerDef * aggr The containers defined within the EcucParamConf
ContainerDef.
Tags:atp.Splitkey=subContainer.shortName
Table 2.7: EcucParamConfContainerDef
One example of a EcucContainerDef and its embedding in the ECU Configuration

Parameter Definition is shown in figure 2.6. One EcucModuleDef Rte is specified be-
ing part of the EcucDefinitionCollection. Two containers of type EcucParam-
ConfContainerDef are specified as part of the module definition.
When specifying the containment relationship between the EcucModuleDef and con-
tainers the role name container is used. When specifying the containment relation-
ship between two containers an aggregation with the role name subContainer at the
contained container is used.
AUTOSARParameterDefinition:
Figure 2.6: Example of an object diagram for container definition
In the XML outtake in example 2.7 only the relevant part from figure 2.6 is shown, not
including the EcucDefinitionCollection7 . The corresponding ECU Configuration
Value description XML file extract is shown in example 2.32.
Example 2.7
<ECUC-MODULE-DEF>
<POST-BUILD-VARIANT-SUPPORT>false</POST-BUILD-VARIANT-SUPPORT>
<CONTAINERS>
<SHORT-NAME>RteGeneration</SHORT-NAME>
<SHORT-NAME>SwComponentInstance</SHORT-NAME>
<MULTIPLICITY-CONFIG-CLASSES>
7
Note that in the figures of ECU Configuration Parameter Definition modeled in UML the in-
finite upper multiplicity is shown as upperMultiplicity = * resulting in <UPPER-MULTIPLICITY-
INFINITE>true</UPPER-MULTIPLICITY-INFINITE>

AUTOSAR CP R22-11
<ECUC-MULTIPLICITY-CONFIGURATION-CLASS>
<CONFIG-CLASS>PRE-COMPILE</CONFIG-CLASS>
<CONFIG-VARIANT>VARIANT-LINK-TIME</CONFIG-VARIANT>
</ECUC-MULTIPLICITY-CONFIGURATION-CLASS>
<CONFIG-VARIANT>VARIANT-POST-BUILD</CONFIG-VARIANT>
<CONFIG-VARIANT>VARIANT-PRE-COMPILE</CONFIG-VARIANT>
</MULTIPLICITY-CONFIG-CLASSES>
<POST-BUILD-VARIANT-MULTIPLICITY>false</POST-BUILD-VARIANT-
MULTIPLICITY>
</CONTAINERS>
</ECUC-MODULE-DEF>
2.3.3.1 Choice Container Definition
[TPS_ECUC_02011] EcucChoiceContainerDef class d The EcucChoiceCon-

tainerDef can be used to specify that certain containers might occur exclusively in
the ECU Configuration Value description. In the ECU Configuration Parameter Defini-
tion the potential containers are specified as part of the EcucChoiceContainerDef
and the constraint is that in the actual ECU Configuration Value description only some
of those specified containers will actually be present.c()
Class EcucChoiceContainerDef
Note Used to define configuration containers that provide a choice between several EcucParamConfContainer
Def. But in the actual ECU Configuration Values only one instance from the choice list will be present.
Base ARObject, AtpDefinition, EcucContainerDef , EcucDefinitionElement, Identifiable, Multilanguage
Aggregated by EcucDestinationUriPolicy.container, EcucModuleDef.container, EcucParamConfContainerDef.sub
Container
choice EcucParamConf * aggr The choices available in a EcucChoiceContainerDef.
ContainerDef
Tags:atp.Splitkey=choice.shortName
Table 2.8: EcucChoiceContainerDef
[TPS_ECUC_02067] Multiplicity of the to be chosen containers d The multiplicity of

the to be chosen containers shall always be 0..1, indicating that each time a choice
is performed you can only choose exactly one of these to be chosen containers at a
time.c()

AUTOSAR CP R22-11
[TPS_ECUC_02012] Allowed choice of available to be chosen containers in the

ECU Configuration Value description d Each time a choice can be performed, the
user is free to choose one of the available to be chosen containers. The upperMul-
tiplicity of the EcucChoiceContainerDef specifies how many instances on the
values side shall be allowed.c()
An example of the usage of a EcucChoiceContainerDef is shown in figure 2.7 and
the XML definition is shown in example 2.8. The corresponding ECU Configuration
Value description is shown in example 2.33.
ComGwMapping: EcucParamConfContainerDef
lowerMultiplicity = 0
upperMultiplicity = *
+subContainer +subContainer
ComGwSource: ComGwDestination:
EcucChoiceContainerDef EcucChoiceContainerDef
+choice +choice
ComGwSignal:
EcucParamConfContainerDef
upperMultiplicity = 1
+choice +choice
ComGwSourceDescription: ComGwDestinationDescription:
EcucParamConfContainerDef EcucParamConfContainerDef
upperMultiplicity = 1 upperMultiplicity = 1
lowerMultiplicity = 0 lowerMultiplicity = 0
Figure 2.7: Example of an object diagram for two choice container definitions
The example shows two use-cases of EcucChoiceContainerDef with different mul-

tiplicities of the EcucChoiceContainerDef.
The EcucChoiceContainerDef ComGwSource is defined to be able to hold one of
the two given containers later in the ECU Configuration Value description. Since the
upperMultiplicity of ComGwSource = 1 there can only be one choice taken.
The EcucChoiceContainerDef ComGwDestination is defined to be able to hold
one of the two given containers later in the ECU Configuration Value description.
Since the upperMultiplicity of ComGwDestination = * several choices can
be taken.
Example 2.8
<ECUC-MODULE-DEF>
<SHORT-NAME>Com</SHORT-NAME>
<POST-BUILD-VARIANT-SUPPORT>true</POST-BUILD-VARIANT-SUPPORT>
<CONTAINERS>
<SHORT-NAME>ComGwMapping</SHORT-NAME>

AUTOSAR CP R22-11
<CONFIG-CLASS>LINK</CONFIG-CLASS>
<CONFIG-CLASS>POST-BUILD</CONFIG-CLASS>
<POST-BUILD-VARIANT-MULTIPLICITY>true</POST-BUILD-VARIANT-
MULTIPLICITY>
<SUB-CONTAINERS>
<ECUC-CHOICE-CONTAINER-DEF>
<SHORT-NAME>ComGwSource</SHORT-NAME>
<CHOICES>
<SHORT-NAME>ComGwSignal</SHORT-NAME>

<SHORT-NAME>ComGwSourceDescription</SHORT-NAME>

</CHOICES>
</ECUC-CHOICE-CONTAINER-DEF>
<ECUC-CHOICE-CONTAINER-DEF>
<SHORT-NAME>ComGwDestination</SHORT-NAME>
<CONFIG-CLASS>LINK</CONFIG-CLASS>
MULTIPLICITY>
<CHOICES>
<SHORT-NAME>ComGwSignal</SHORT-NAME>

AUTOSAR CP R22-11


<SHORT-NAME>ComGwDestinationDescription</SHORT-NAME>

</CHOICES>
</ECUC-CHOICE-CONTAINER-DEF>
</SUB-CONTAINERS>
</CONTAINERS>
</ECUC-MODULE-DEF>
The containers from the example, which the choice is from, will of course have to be
specified in more detail in an actual definition file.
2.3.4 Common Configuration Elements
Configuration Containers, Parameters and References have some common attributes

which are described in this section.
2.3.4.1 Variant Handling
Variant Handling has been introduced to AUTOSAR in a generic way. The major spec-
ification can be found in the AUTOSAR Generic Structure Template [6]. Every element
which is subject to variability shall have the stereotype <<atpVariation>> set.
Variant Handling is used in both areas of ECU Configuration, the ECU Configuration
Parameter Definition and ECU Configuration Value description. In this specification
the semantics of variant handling are specified at the actual location where they occur
individually.
2.3.4.2 Configuration Multiplicity
[TPS_ECUC_02008] Number of occurrences of containers, parameters and ref-

erences in the ECU Configuration Value description d To be able to specify how
often a specific configuration element (container, parameter or reference) may occur
in the ECU Configuration Value description the class EcucDefinitionElement is
introduced. With the two attributes lowerMultiplicity and upperMultiplic-
ity the minimum and maximum occurrence of the configuration element is specified.c
(RS_ECUC_00015, RS_ECUC_00055, RS_ECUC_00070)
[TPS_ECUC_06016] Countably infinite number of containers, parameters and
references in the ECU Configuration Value description dTo express a countable

AUTOSAR CP R22-11
infinite number of occurrences of this element the upperMultiplicityInfinite

element shall exist and shall be set to true. 8 c(RS_ECUC_00082)
[constr_5325] Existence of upperMultiplicityInfinite and upperMulti-
plicity is mutually exclusive dThe existence of the elements upperMultiplic-
ityInfinite and upperMultiplicity shall be mutually exclusive.c()
[TPS_ECUC_02110] Variable lower and upper multiplicity in ECU Configuration
Parameter definition d The attributes lowerMultiplicity, upperMultiplicity
and upperMultiplicityInfinite are subject to variant handling. The values can
be computed using the variant handling mechanism.c(RS_ECUC_00082)
In this specification the literals n and m are used to represent some natural number in
order to allow the definition of relations between the lowerMultiplicity and the
upperMultiplicity.
[TPS_ECUC_02009] Expression of optionality of containers, parameters and
references in the Ecuc Parameter Definition UML model dIf there is no multi-
plicity defined for an element in the Ecuc Parameter Definition UML model ([9] -
AUTOSAR_MMOD_MetaModel), then the element will be generated as mandatory in
the Ecu Parameter Definition ARXML file ([8] - Specification of ECU Configuration Pa-
rameters):
• lowerMultiplicity = 1
• upperMultiplicity = 1.
To express an optional element in the Ecuc Parameter Definiton model ([9] -
AUTOSAR_MMOD_MetaModel) the lowerMultiplicity has to be set explicitly to
’0’.c(RS_ECUC_00055, RS_ECUC_00070)
As Ecuc Parameter definition UML model figures can be quite large and consume
a lot of graphical space, some space can be saved by omitting the lowerMulti-
plicity and upperMultiplicity respectively upperMultiplicityInfinite.
In the generated Ecu Parameter Definition ARXML file these multiplicities are defined
as mandatory.
Configuration Parameter and Reference definitions with an upperMultiplicity >
1 have to be considered with care, since it is not possible to reference to individual
parameters. So such multiple occurrences of a parameter in the Value description will
just be mere collections, it is neither guaranteed that the order will be preserved nor
that individual elements do have a special semantics.
[TPS_ECUC_02010] Multiplicity attributes in ECU Configuration Parameter Model
diagrams d In the specification object diagrams (ECU Configuration Parameter Model)
the multiplicity attributes may be omitted if both values are equal to the default value of
’1’. Otherwise both attributes are shown.c()
8
Note that in the figures of ECU Configuration Parameter Definition modeled in UML the infinite upper
multiplicity is shown as upperMultiplicity = *

AUTOSAR CP R22-11
Class EcucDefinitionElement (abstract)

Note Common class used to express the commonalities of configuration parameters, references and
containers. If not stated otherwise the default multiplicity is exactly one mandatory occurrence of the
specified element.
Base ARObject, AtpDefinition, Identifiable, MultilanguageReferrable, Referrable
Subclasses EcucCommonAttributes, EcucContainerDef , EcucModuleDef
ecucCond EcucCondition 0..1 aggr If it evaluates to true the Ecu Parameter definition shall be
Specification processed as specified. Otherwise the parameter
definition shall be ignored.
Tags:xml.sequenceOffset=100
ecucValidation EcucValidation * aggr Collection of validation conditions which all need to
Cond Condition evaluate to true in order to indicate a valid validation
condition of the EcucDefinitionElement.
lowerMultiplicity PositiveInteger 0..1 attr The lower multiplicity of the specified element.
0: optional
1: at least one occurrence
n: at least n occurrences
atpVariation: [RS_ECUC_00082]
Stereotypes: atpVariation
Tags:
vh.latestBindingTime=codeGenerationTime
relatedTrace Traceable 0..1 ref This contains a sloppy reference to the Autosar
Item compatible identifier of the element (EcucId).
Tags:xml.sequenceOffset=-10
scope EcucScopeEnum 0..1 attr Specifies the scope of this configuration element.
upperMultiplicity PositiveInteger 0..1 attr The upper multiplicity of the specified element.
0: no occurrence (used for VSMD)
1: at most one occurrence
m: at most m occurrences
If upperMultiplicity is set than upperMultiplicityInfinite shall
not be used.
Tags:
5

AUTOSAR CP R22-11
4
Class EcucDefinitionElement (abstract)
upperMultiplicity Boolean 0..1 attr To express an infinite number of occurrences of this
Infinite element this attribute has to be set to true.
If upperMultiplicityInfinite is set than upperMultiplicity shall
not be used.
Tags:
Table 2.9: EcucDefinitionElement
Enumeration EcucScopeEnum
Note Possible scope settings for a configuration element.
Aggregated by EcucDefinitionElement.scope
Literal Description
ECU An element may be shared with other modules.
Tags:atp.EnumerationLiteralIndex=0
local An element is only be applicable for the module it is defined in.
Table 2.10: EcucScopeEnum
The reference EcucDefinitionElement.relatedTraceItem is used to provide

the Specification ID of the respective EcucDefinitionElement in the StMD. Please
note that the same Specification ID can occur several times in the StMD because the
same EcucDefinitionElement can be part of several EcucParamConfContain-
erDefs.
EcucDefinitionElement.relatedTraceItem can be used in the VSMD but the
value shall not conflict with the AUTOSAR defined namespace.
[constr_3200] Restriction on values of EcucDefinitionElement.related-
TraceItem in the VSMD dThe value of EcucDefinitionElement.relatedTra-
ceItem in the VSMD shall never start with ’ECUC_’.c()
The values of EcucDefinitionElement.relatedTraceItem starting with
’ECUC_’ are reserved for AUTOSAR standardization.
[constr_3509] Applicability of scope attribute dThe usage of the attribute scope
is prohibited for EcucModuleDef and for sub-classes of EcucContainerDef (i.e.
EcucChoiceContainerDef and EcucParamConfContainerDef).c()
For examples please refer to figure 2.6 and example 2.7

AUTOSAR CP R22-11
2.3.4.3 Common Configuration Attributes
Several attributes are available on both, parameters and references. These common
attributes are shown in figure 2.8.
«enumeration» AtpDefinition
Identifiable +trace 0..*
EcucConfigurationClassEnum
EcucDefinitionElement
PublishedInformation MultilanguageReferrable
PreCompile + scope: EcucScopeEnum [0..1] +relatedTraceItem Traceable
Link «atpVariation» «atpUriDef» 0..1
PostBuild + lowerMultiplicity: PositiveInteger [0..1]
+ upperMultiplicity: PositiveInteger [0..1]
+ upperMultiplicityInfinite: Boolean [0..1]
«enumeration»
EcucConfigurationVariantEnum
EcucMultiplicityConfigurationClass
PreconfiguredConfiguration
+multiplicityConfigClass
RecommendedConfiguration EcucCommonAttributes
VariantPreCompile 0..*
VariantLinkTime + origin: String [0..1]
VariantPostBuild + postBuildVariantMultiplicity: Boolean [0..1]
+ postBuildVariantValue: Boolean [0..1]
+ requiresIndex: Boolean [0..1] +valueConfigClass EcucValueConfigurationClass
0..*
EcucParameterDef
EcucAbstractReferenceDef EcucAbstractConfigurationClass
+ symbolicNameValue: Boolean [0..1]
+ withAuto: Boolean [0..1] + withAuto: Boolean [0..1] + configClass: EcucConfigurationClassEnum [0..1]
+ configVariant: EcucConfigurationVariantEnum [0..1]
Figure 2.8: Common Attributes for parameters and references
[constr_3570] EcucDefinitionElement.lowerMultiplicity always required

dThe attribute EcucDefinitionElement.lowerMultiplicity shall always be de-
fined when the ECU Configuration Parameter definition is complete.c()
[constr_5342] EcucDefinitionElement.upperMultiplicity or EcucDefini-
tionElement.upperMultiplicityInfinite always required dExactly one of
the attributes EcucDefinitionElement.upperMultiplicity or EcucDefini-
tionElement.upperMultiplicityInfinite shall always be defined when the
ECU Configuration Parameter definition is complete.c()
[constr_3571] EcucCommonAttributes.origin always required dThe attribute
EcucCommonAttributes.origin shall always be defined when the ECU Configu-
ration Parameter definition is complete.c()
[constr_3572] EcucParameterDef.symbolicNameValue always required dThe
attribute EcucParameterDef.symbolicNameValue shall always be defined when
the ECU Configuration Parameter definition is complete.c()
[constr_3573] EcucAbstractConfigurationClass.configClass always re-
quired dThe attribute EcucAbstractConfigurationClass.configClass shall al-
ways be defined when the ECU Configuration Parameter definition is complete.c
()
[constr_3574] EcucAbstractConfigurationClass.configVariant always re-
quired dThe attribute EcucAbstractConfigurationClass.configVariant shall

AUTOSAR CP R22-11
always be defined when the ECU Configuration Parameter definition is complete.c

()
Class EcucCommonAttributes (abstract)
Note Attributes used by Configuration Parameters as well as References.
Base ARObject, AtpDefinition, EcucDefinitionElement, Identifiable, MultilanguageReferrable, Referrable
Subclasses EcucAbstractReferenceDef , EcucParameterDef
multiplicity EcucMultiplicity * aggr Specifies in which MultiplicityConfigurationClass this
ConfigClass ConfigurationClass parameter or reference is available in a particular
ConfigurationVariant. This aggregation is optional if the
surrounding EcucModuleDef has the Category
STANDARDIZED_MODULE_DEFINITION. If the
category attribute of the EcucModuleDef is set to
VENDOR_SPECIFIC_MODULE_DEFINITION, then this
aggregation is mandatory.
Tags:xml.name
Plural=MULTIPLICITY-CONFIG-CLASSES
origin String 0..1 attr String specifying if this configuration parameter is an
AUTOSAR standardized configuration parameter or if the
parameter is hardware- or vendor-specific.
postBuildVariant Boolean 0..1 attr Indicates if a parameter or a reference may have different
Multiplicity number of instances in different post-build variants
(previously known as post-build selectable configuration
sets). TRUE means yes, FALSE means no.
postBuildVariant Boolean 0..1 attr Indicates if a parameter or a reference may have different
Value value in different post-build variants (previously known as
post-build selectable configuration sets). TRUE means
yes, FALSE means no.
requiresIndex Boolean 0..1 attr Used to define whether the value element for this
definition shall be provided with an index.
valueConfig EcucValueConfiguration * aggr Specifies in which ValueConfigurationClass this
Class Class parameter or reference is available in a particular
ConfigurationVariant. This aggregation is optional if the
surrounding EcucModuleDef has the Category
VENDOR_SPECIFIC_MODULE_DEFINITION, then this
Tags:xml.namePlural=VALUE-CONFIG-CLASSES
Table 2.11: EcucCommonAttributes
2.3.4.3.1 Parameter Origin
[TPS_ECUC_02015] Origin information in parameter and reference definitions d

Each parameter type has to provide information on its origin, which contains a string
describing if the parameter is defined in the AUTOSAR standard (’AUTOSAR_ECUC’)
or if the parameter is defined as a vendor specific parameter (e.g. ’VendorXYZ_v1.-
3’).c()
Example 2.9
<ECUC-INTEGER-PARAM-DEF>

AUTOSAR CP R22-11
<SHORT-NAME>ClockRate</SHORT-NAME>
<ORIGIN>AUTOSAR_ECUC</ORIGIN>
</ECUC-INTEGER-PARAM-DEF>
<ECUC-BOOLEAN-PARAM-DEF>
<SHORT-NAME>VendorExtensionEnabled</SHORT-NAME>
<ORIGIN>VendorXYZ_v1.3</ORIGIN>
</ECUC-BOOLEAN-PARAM-DEF>
In example 2.9 two parameters are defined, one which belongs to the AUTOSAR stan-
dard and one which is introduced by the module vendor in a specific version of his own
ECU Configuration tools.
2.3.4.3.2 Value and Multiplicity Configuration Classes
[TPS_ECUC_02016] Configuration class of parameter and reference definitions d

Supported configuration classes in the StMD and the VSMD are9 :c(RS_ECUC_00012,
RS_ECUC_00046)
• [TPS_ECUC_02070] Configuration class “PubilishedInformation” d Pub-
lishedInformationc()
• [TPS_ECUC_02017] Configuration class “PreCompile” d PreCompilec(RS_-
ECUC_00047)
• [TPS_ECUC_02018] Configuration class “Link” d Linkc(RS_ECUC_00048)
• [TPS_ECUC_02019] Configuration class “PostBuild” d PostBuild10 c(RS_-
ECUC_00008)
The element PublishedInformation is used to specify the fact that certain infor-
mation is fixed even before the pre-compile stage.
[TPS_ECUC_02071] Usage of PublishedInformation configuration class d If
PublishedInformation is selected as configuration class it has to be the same for
all configuration variants.c()
[TPS_ECUC_02097] Supported configuration variants in the StMD and the VSMD
d The supported configuration variants in the StMD and the VSMD are11 :c()
• [TPS_ECUC_02098] StMD Configuration variant "VariantPreCompile" d
VariantPreCompilec()
• [TPS_ECUC_02099] StMD Configuration variant "VariantLinkTime" d Vari-
antLinkTimec()
9
In the XML-Schema the values are represented as PUBLISHED-INFORMATION, PRE-COMPILE,
LINK, POST-BUILD.
10
The configuration classes PostBuildLoadable and PostBuildSelectable are no longer
used.
11
In the XML-Schema the values are represented as VARIANT-PRE-COMPILE, VARIANT-LINK-
TIME, VARIANT-POST-BUILD.

AUTOSAR CP R22-11
• [TPS_ECUC_02100] StMD Configuration variant "VariantPostBuild" d Vari-

antPostBuildc()
[TPS_ECUC_08034] Different values of EcucCommonAttributess instances in
different configuration times dThe assignment of configClasses to configVari-
ants of the valueConfigClass specifies when (i.e. PreCompile time, Link time,
PostBuild time) the value of this EcucCommonAttributes instances at latest may
change for each implementationConfigVariant of the EcucModuleDef (i.e.
VariantPreCompile, VariantLinkTime, VariantPostBuild).c()
[TPS_ECUC_08035] Different number of instances of EcucCommonAttributess
in different configuration times dThe assignment of configClasses to config-
Variants of the multiplicityConfigClass specifies when (i.e. PreCompile
time, Link time, PostBuild time) the number of instances of this EcucCommonAt-
tributes at latest may change for each implementationConfigVariant of the
EcucModuleDef (i.e. VariantPreCompile, VariantLinkTime, VariantPost-
Build).c()
For example if a multiplicityConfigClass.configClass of one parameter
equals PostBuild for the multiplicityConfigClass.configVariant Vari-
antPostBuild, this means that the number of instances of this parameter at latest
may change at post-build time (i.e. updated post-build configurations may contain dif-
ferent number of instances of this parameter, e.g. ComIPduHandleId).
[constr_5514] Applicability of the multiplicityConfigClass attribute dThe
multiplicityConfigClass attribute is applicable only to EcucCommonAt-
tributes which have upperMultiplicity greater than lowerMultiplicity.c
()
[constr_3091] Multiplicity of valueConfigClass dThe multiplicity of the attribute
EcucCommonAttributes.valueConfigClass shall not exceed 3.c()
[constr_5015] Multiplicity of multiplicityConfigClass dThe multiplicity of the
attribute EcucCommonAttributes.multiplicityConfigClass shall not exceed
3.c()
[constr_3091] and [constr_5015] mean that the implementer of the module does not
have complete freedom how the configuration classes are chosen for each individual
configuration parameter but needs to select one of the specified variants.
The mapping of the EcucConfigurationVariantEnum to the EcucConfigura-
tionClassEnum is done using the EcucValueConfigurationClass and Ecuc-
MultiplicityConfigurationClass inherited from the EcucAbstractConfig-
urationClass:

AUTOSAR CP R22-11
Class EcucAbstractConfigurationClass (abstract)

Note Specifies the ValueConfigurationClass of a parameter/reference or the MultiplicityConfigurationClass of a
parameter/reference or a container for each ConfigurationVariant of the EcucModuleDef.
Base ARObject
Subclasses EcucMultiplicityConfigurationClass, EcucValueConfigurationClass
configClass EcucConfigurationClass 0..1 attr Specifies the ConfigurationClass for the given
Enum ConfigurationVariant.
configVariant EcucConfiguration 0..1 attr Specifies the ConfigurationVariant the ConfigurationClass
VariantEnum is specified for.
Table 2.12: EcucAbstractConfigurationClass
Class EcucValueConfigurationClass
Note Specifies the ValueConfigurationClass of a parameter/reference for each ConfigurationVariant of the
EcucModuleDef.
Base ARObject, EcucAbstractConfigurationClass
Aggregated by EcucCommonAttributes.valueConfigClass
– – – – –
Table 2.13: EcucValueConfigurationClass
Class EcucMultiplicityConfigurationClass
Note Specifies the MultiplicityConfigurationClass of a parameter/reference or a container for each
ConfigurationVariant of the EcucModuleDef.
Base ARObject, EcucAbstractConfigurationClass
Aggregated by EcucCommonAttributes.multiplicityConfigClass, EcucContainerDef .multiplicityConfigClass
– – – – –
Table 2.14: EcucMultiplicityConfigurationClass
Enumeration EcucConfigurationClassEnum
Note Possible configuration classes for the AUTOSAR configuration parameters.
Aggregated by EcucAbstractConfigurationClass.configClass
Literal Description
Link Link Time: parts of configuration are delivered from another object code file
PostBuild PostBuildTime: after compilation a configuration parameter can be changed.
PreCompile PreCompile Time: after compilation a configuration parameter can not be changed any more.
5

AUTOSAR CP R22-11
4
Enumeration EcucConfigurationClassEnum
Published PublishedInformation is used to specify the fact that certain information is fixed even before the
Information pre-compile stage.
Table 2.15: EcucConfigurationClassEnum
Enumeration EcucConfigurationVariantEnum
Note Specifies the possible Configuration Variants used for AUTOSAR BSW Modules.
Aggregated by EcucAbstractConfigurationClass.configVariant, EcucModuleConfigurationValues.implementation
ConfigVariant, EcucModuleDef.supportedConfigVariant
Literal Description
Preconfigured Preconfigured (i.e. fixed) configuration which cannot be changed.
Configuration
Recommended Recommended configuration for a module.
Configuration
VariantLinkTime Specifies that the BSW Module implementation may use PreCompileTime and LinkTime configuration
parameters.
VariantPostBuild Specifies that the BSW Module implementation may use PreCompileTime, LinkTime and PostBuild
configuration parameters.
VariantPreCompile Specifies that the BSW Module implementation uses only PreCompileTime configuration parameters.
Table 2.16: EcucConfigurationVariantEnum
[TPS_ECUC_02101] EcucAbstractConfigurationClass usage d For each

EcucConfigurationVariantEnum the EcucModuleDef supports, there shall
be one EcucAbstractConfigurationClass element (EcucValueConfigura-
tionClass or EcucMultiplicityConfigurationClass depending on the con-
text).c()
The supported configuration variants of the module are described in section 2.3.2.
[constr_3092] Usage of configVariant and configClass attributes dconfig-
Variant and configClass shall always exist as a pair for each existing EcucAb-
stractConfigurationClass (EcucValueConfigurationClass or EcucMul-
tiplicityConfigurationClass depending on the context).c()
[constr_5523] Allowed configClasses for paired configVariants dPub-
lishedInformation configClass is supported by all configVariants where
[TPS_ECUC_02071] applies. Additionally, VariantPreCompile configVariant
supports PreCompile configClass, VariantLinkTime configVariant sup-
ports PreCompile and Link configClasses, and VariantPostBuild config-
Variant supports PreCompile, Link and PostBuild configClasses.c()

AUTOSAR CP R22-11
[TPS_ECUC_02102] Configuration class selection for parameters and refer-

ences for supported configuration variants d Every EcucAbstractConfigura-
tionClass specifies which EcucConfigurationClassEnum this parameter or ref-
erence shall be implemented for the EcucConfigurationVariantEnum the Ecuc-
ModuleDef supports.c()
The example 2.10 shows how the EcucValueConfigurationClass and the the
EcucMultiplicityConfigurationClass is provided in XML for three configura-
tion variants of one module. The integer configuration parameter SignalSize shall be
implemented as a PRE-COMPILE parameter for the configuration variants VARIANT-
PRE-COMPILE and VARIANT-LINK-TIME. It shall be POST-BUILD for the configura-
tion variant VARIANT-POST-BUILD.
Example 2.10
<SHORT-NAME>SignalSize</SHORT-NAME>
<POST-BUILD-VARIANT-MULTIPLICITY>true</POST-BUILD-VARIANT-MULTIPLICITY>
<POST-BUILD-VARIANT-VALUE>true</POST-BUILD-VARIANT-VALUE>
<VALUE-CONFIG-CLASSES>
<ECUC-VALUE-CONFIGURATION-CLASS>
</ECUC-VALUE-CONFIGURATION-CLASS>
</VALUE-CONFIG-CLASSES>
The configuration tools are now able to derive the configuration class of each configu-
ration parameter and reference from the ECU Configuration Parameter Definition XML
file [8].

AUTOSAR CP R22-11
2.3.4.3.3 Value and Multiplicity Variant Values in Different Post-Build Variants
[TPS_ECUC_08016] Different values of EcucCommonAttributess instances in

different post-build variants dThe postBuildVariantValue attribute of Ecuc-
CommonAttributes specifies if a different value of this EcucCommonAttributes
may exist in different post-build variants. true means yes, false means no.c()
[TPS_ECUC_08015] Different number of EcucCommonAttributess instances in
different post-build variants dThe postBuildVariantMultiplicity attribute of
EcucCommonAttributes specifies if a different number of instances of this Ecuc-
CommonAttributes may exist in different post-build variants12 . true means yes,
false means no.c()
[constr_5508] Applicability of postBuildVariantMultiplicity attribute dThe
postBuildVariantMultiplicity attribute is applicable only to EcucCommonAt-
tributes which have upperMultiplicity greater than lowerMultiplicity.c
()
The example 2.10 above shows how the postBuildVariantValue and the post-
BuildVariantMultiplicity is provided in the XML file. The integer configuration
parameter SignalSize shall be implemented with both values true.
[constr_3236] EcucModuleDef that relies on EcucCommonAttributes with
postBuildVariantValue set to true of another EcucModuleDef dIf one Ecuc-
ModuleDef relies on the EcucCommonAttributes (parameters and references) with
postBuildVariantValue set to true of another EcucModuleDef, the values of
these EcucCommonAttributes can only differ in different post-build variants if the
implementation of the using EcucModuleDef supports post-build variations.c()
[constr_3237] EcucModuleDef that relies on EcucCommonAttributes with
postBuildVariantMultiplicity set to true of another EcucModuleDef dIf
one EcucModuleDef relies on the EcucCommonAttributes (parameters and ref-
erences) with postBuildVariantMultiplicity set to true of another EcucMod-
uleDef, the number of instances of these EcucCommonAttributes can only differ
in different post-build variants if the implementation of the using EcucModuleDef sup-
ports post-build variations.c()
Note: [constr_3236] and [constr_3237] shall be checked by the using module, e.g.,
the module that does not support post-build variation shall assure that the value of the
post-build variable parameters used from other modules is the same in all variants.
2.3.5 Parameter Definition
[TPS_ECUC_02013] Definition of parameters within a EcucParamConfContain-

erDef d Parameters are defined within a EcucParamConfContainerDef using an
aggregation with the role name parameter at the parameter side.c()
12

AUTOSAR CP R22-11
[TPS_ECUC_02014] Parameter types d The possible parameter types are specified

using one of the specialized classes derived from EcucParameterDef. The Ecuc-
ParameterDef does inherit from Identifiable, EcucCommonAttributes and
EcucDefinitionElement.c()
The available parameter types are shown in figure 2.9.
[constr_3233] EcucModuleDef that relies on EcucCommonAttributes with val-
ueConfigClass set to Link/PostBuild of another EcucModuleDef dIf one
EcucModuleDef relies on the EcucCommonAttributes (parameters and refer-
ences) with valueConfigClass.configClass set to Link/PostBuild of another
EcucModuleDef, the values of these EcucCommonAttributes can only be changed
at Link/PostBuild time if the corresponding EcucModuleConfigurationVal-
ues of the using EcucModuleDef has the implementationConfigVariant set
to VariantLinkTime/VariantPostBuild, respectively.c()
[constr_3234] EcucModuleDef that relies on EcucCommonAttributes with mul-
tiplicityConfigClass set to Link/PostBuild of another EcucModuleDef dIf
one EcucModuleDef relies on the EcucCommonAttributes (parameters and ref-
erences) with multiplicityConfigClass.configClass set to Link/PostBuild
of another EcucModuleDef, the number of instances of these EcucCommonAt-
tributes can only be changed at Link/PostBuild time if the corresponding Ecuc-
ModuleConfigurationValues of the using EcucModuleDef has the implemen-
tationConfigVariant set to VariantLinkTime/VariantPostBuild, respec-
tively.c()
Note: [constr_3233] and [constr_3234] shall be checked by the using module, e.g.,
the module that is not post-build capable shall assure that the value of the post-build
parameters used from other modules is not changed.

AUTOSAR CP R22-11
EcucContainerDef +parameter EcucCommonAttributes

EcucParamConfContainerDef EcucParameterDef
0..*
«atpSplitable» + symbolicNameValue: Boolean [0..1]
+ withAuto: Boolean [0..1] «primitive»
Identifier
+ blueprintValue: String [0..1]

+ namePattern: String [0..1]
+defaultValue 0..1
EcucBooleanParamDef EcucFloatParamDef EcucAddInfoParamDef EcucEnumerationParamDef
«atpVariation» «atpVariation»
+ defaultValue: Boolean [0..1]A + defaultValue: Float [0..1] «atpSplitable»
+ max: Limit [0..1]
+ min: Limit [0..1]
+literal 0..*
Identifiable
EcucIntegerParamDef EcucEnumerationLiteralDef
«atpVariation»
«atpVariation» + origin: String [0..1]
EcucAbstractStringParamDef
+ defaultValue: UnlimitedInteger [0..1]
+ max: UnlimitedInteger [0..1] + defaultValue: VerbatimString [0..1]
+ min: UnlimitedInteger [0..1] + maxLength: PositiveInteger [0..1]
+ minLength: PositiveInteger [0..1]
+ regularExpression: RegularExpression [0..1]
«primitive»
VerbatimString
«primitive»
+ blueprintValue: String [0..1] RegularExpression
+ xmlSpace: XmlSpaceEnum [0..1]
tags
xml.xsd.customType = VERBATIM-STRING
xml.xsd.type = string
xml.xsd.whiteSpace = preserve EcucMultilineStringParamDef EcucLinkerSymbolDef
EcucStringParamDef EcucFunctionNameDef
Figure 2.9: Class diagram for parameter definition
[constr_3575] EcucEnumerationLiteralDef.origin always required dThe at-

tribute EcucEnumerationLiteralDef.origin shall always be defined when the
ECU Configuration Parameter definition is complete.c()
Class EcucParameterDef (abstract)
Note Abstract class used to define the similarities of all ECU Configuration Parameter types defined as
subclasses.
Base ARObject, AtpDefinition, EcucCommonAttributes, EcucDefinitionElement, Identifiable, Multilanguage
Subclasses EcucAbstractStringParamDef , EcucAddInfoParamDef, EcucBooleanParamDef, EcucEnumerationParam
Def, EcucFloatParamDef, EcucIntegerParamDef
Aggregated by EcucDestinationUriPolicy.parameter, EcucParamConfContainerDef.parameter
derivation EcucDerivation 0..1 aggr A derivation of a Configuration Parameter value can be
Specification specified by an informal Calculation Formula or by a
formal language that can be used to specify the
computational rules.
symbolicName Boolean 0..1 attr Specifies that this parameter’s value is used, together
Value with the aggregating container, to derive a symbolic name
definition. See chapter "Representation of Symbolic
Names" in Ecuc specification for more details.
5

AUTOSAR CP R22-11
4
Class EcucParameterDef (abstract)
withAuto Boolean 0..1 attr Specifies whether it shall be allowed on the value side to
specify this parameter value as "AUTO".
If withAuto is "true" it shall be possible to set the "isAuto
Value" attribute of the respective parameter to "true". This
means that the actual value will not be considered during
ECU Configuration but will be (re-)calculated by the code
generator and stored in the value attribute afterwards.
These implicit updated values might require a
re-generation of other modules which reference these
values.
If withAuto is "false" it shall not be possible to set the "is
AutoValue" attribute of the respective parameter to "true".
If withAuto is not present the default is "false".
Table 2.17: EcucParameterDef
The use-case for the attribute symbolicNameValue is described in section 2.3.6.5.

The use-case for the attribute withAuto is described in section 3.4.1.
In the next sections the different parameter types will be described in detail. The ex-
amples for the individual parameters are taken from figure 2.10.
RTE_DEV_ERROR_DETECT: PositionInTask: SchedulingPeriod: EepJobEndNotification: EcucFunctionNameDef
EcucBooleanParamDef EcucIntegerParamDef EcucFloatParamDef
defaultValue = Eep_JobEndNotification
defaultValue = false defaultValue = 0 defaultValue = 0.01
max = 255 max = 10
min = 0 min = 0
RtePimInitialisationSymbol: EcucLinkerSymbolDef
defaultValue = MyPimInitValuesLightMaster
RteGenerationMode:
EcucEnumerationParamDef
defaultValue = CompatibilityMode DiagnosticTesterMessage: EcucAddInfoParamDef
+literal +literal
CompatibilityMode: VendorMode:
EcucEnumerationLiteralDef EcucEnumerationLiteralDef
Figure 2.10: Example of parameter definitions using different types
2.3.5.1 Boolean Type
[TPS_ECUC_02026] EcucBooleanParamDef properties d With the EcucBoolean-

ParamDef parameter a ’true’ or ’false’ parameter can be specified. The only ad-
ditional attribute is the defaultValue which may be specified while defining the pa-
rameter.c()
[TPS_ECUC_02127] Possible values for EcucBooleanParamDef parameters d
The alternative representation of ’true’ and ’false’ are ’1’ and ’0’ which allows the
usage of a numerical representation of the value in order to be computed in the variant
handling.c()

AUTOSAR CP R22-11
This parameter can also be used for other ’boolean’-type configuration parameters with
the semantic of:
• ON / OFF
• ENABLE / DISABLE
• 1 / 0
even if the ECU Configuration Values are restricted as described in
[TPS_ECUC_02127].
Please note that the representation of an boolean parameter value or an attribute which
supports atpVariation as true / false already requires the processing of the
BooleanLiteral true /false by the formula processor.
On the ECU Configuration Value description side boolean parameter values are repre-
sented as EcucNumericalParamValues (see chapter 2.4.4.2). The attribute "value"
in the EcucNumericalParamValue supports atpVariation and therefore the
BooleanLiteral true /false is supported by the formula language as well. Please note
that true evaluates to 1 and false to 0 (see [6] for more details).
[TPS_ECUC_02111] Variable default value in EcucBooleanParamDef d The at-
tribute defaultValue of EcucBooleanParamDef is subject to variant handling. The
value can be computed using the variant handling mechanism.c(RS_ECUC_00083)
Class EcucBooleanParamDef
Note Configuration parameter type for Boolean. Allowed values are true and false.
Base ARObject, AtpDefinition, EcucCommonAttributes, EcucDefinitionElement, EcucParameterDef ,
Identifiable, MultilanguageReferrable, Referrable
defaultValue Boolean 0..1 attr Default value of the boolean configuration parameter.
Tags:vh.latestBindingTime=codeGenerationTime
Table 2.18: EcucBooleanParamDef
Example 2.11 shows the ECUC Parameter definition XML file. The corresponding
ECUC Value description XML file extract is shown in example 2.37.
Example 2.11
<SHORT-NAME>PositionInTask</SHORT-NAME>
<DEFAULT-VALUE>0</DEFAULT-VALUE>
<MAX>255</MAX>
<MIN>0</MIN>

AUTOSAR CP R22-11
2.3.5.2 Integer Type
[TPS_ECUC_02027] EcucIntegerParamDef properties d With the EcucInte-

gerParamDef parameter a signed/unsigned whole number can be specified. With
the additional attributes min and max the range of this parameters values in the ECU
Configuration Value description can be limited13 . Also the defaultValue can be
specified.c()
[TPS_ECUC_02114] Variable default value in EcucIntegerParamDef d The at-
tribute defaultValue of EcucIntegerParamDef is subject to variant handling. The
value can be computed using the variant handling mechanism.c(RS_ECUC_00083)
[TPS_ECUC_02116] Variable min, max values in EcucIntegerParamDef d The
attributes min and max of EcucIntegerParamDef are subject to variant handling.
The values can be computed using the variant handling mechanism.c(RS_ECUC_-
00084)
The value range of the EcucIntegerParamDef has two use-cases, signed and un-
signed, which both have to fit in a 64-bit number space.
[TPS_ECUC_02072] Signed EcucIntegerParamDef value range dIf a signed value
is represented the min value can be down to -9223372036854775808 and the max
value can be up to 9223372036854775807.c()
[TPS_ECUC_02073] Unsigned EcucIntegerParamDef value range d If an un-
signed value is represented the min value can be down to 0 and the max value can be
up to 18446744073709551615 (in hex 0xFFFFFFFFFFFFFFFF).c()
[TPS_ECUC_06032] Min and max values in EcucIntegerParamDef d The max
value shall be equal or bigger than the min value and the min value shall be equal or
less than the max value.c()
[TPS_ECUC_02074] +/- sign in the EcucNumericalParamValue is optional dIf the
optional +/- sign in the EcucNumericalParamValue is omitted, "+" is assumed.c()
[TPS_ECUC_03040] The value of an EcucNumericalParamValue shall be unam-
biguously an integer value dThe value of an EcucNumericalParamValue shall be
specified such that it is unambiguously an integer value. In particular the result of the
NumericalValueVariationPoint shall yield an integer, not a float.c()
Class EcucIntegerParamDef
Note Configuration parameter type for Integer.
5
13
The min and max values are defined optional, however in the ’Vendor Specific Module Definition’
these values are mandatory.

AUTOSAR CP R22-11
4
Class EcucIntegerParamDef
defaultValue UnlimitedInteger 0..1 attr Default value of the integer configuration parameter.
max UnlimitedInteger 0..1 attr Max value allowed for the parameter defined.
min UnlimitedInteger 0..1 attr Min value allowed for the parameter defined.
Table 2.19: EcucIntegerParamDef
Example 2.12
<SHORT-NAME>PositionInTask</SHORT-NAME>
<DEFAULT-VALUE>0</DEFAULT-VALUE>
<MAX>255</MAX>
<MIN>0</MIN>
2.3.5.3 Float Type
[TPS_ECUC_02028] EcucFloatParamDef properties d To be able to specify pa-

rameters with floating number values the EcucFloatParamDef can be used. The
additional attributes min, max and defaultValue can be specified as well14 .c()
[TPS_ECUC_02115] Variable default value in EcucFloatParamDef d The attribute
defaultValue of EcucFloatParamDef is subject to variant handling. The value
can be computed using the variant handling mechanism.c(RS_ECUC_00083)
[TPS_ECUC_02117] Variable min, max values in EcucFloatParamDef d The at-
tributes min and max of EcucFloatParamDef are subject to variant handling. The
values can be computed using the variant handling mechanism.c(RS_ECUC_00084)
14
The min and max values are defined optional, however in the ’Vendor Specific Module Definition’
these values are mandatory.

AUTOSAR CP R22-11
[TPS_ECUC_06033] Min and max values in EcucFloatParamDef d The max value

shall be equal or bigger than the min value and the min value shall be equal or less
than the max value.c()
[TPS_ECUC_06034] Special float values d The notation of the special float values
"Not a Number" and positive/negative "infinity" shall be:
• NaN
• INF
• -INF
c()
[TPS_ECUC_06087] INF and -INF allowed as defaultValue in EcucFloatParamDef
dThe special float values INF and -INF are allowed to be specified as defaultValue
of EcucFloatParamDefc(RS_ECUC_00050)
[TPS_ECUC_02075] Representation of EcucFloatParamDefs d For the represen-
tation the IEEE double-precision 64-bit floating point of the IEEE 754-
1985 standard [10] is used.c()
Float values that exist on a target ECU which does not support 64 bit have to be con-
verted to the nearest approximation of the value in float 32 for the target. In AUTOSAR
XML the value shall be kept in 64 bit representation.
Class EcucFloatParamDef
Note Configuration parameter type for Float.
defaultValue Float 0..1 attr Default value of the float configuration parameter.
max Limit 0..1 attr Max value allowed for the parameter defined.
min Limit 0..1 attr Min value allowed for the parameter defined.
Table 2.20: EcucFloatParamDef
[TPS_ECUC_06082] Definition of interval type for EcucFloatParamDef.min

and EcucFloatParamDef.max dThe attributes EcucFloatParamDef.min and

AUTOSAR CP R22-11
EcucFloatParamDef.max are used to define the usable interval of the respective

EcucFloatParamDef. The interval itself may on both ends be defined as either
• closed: the provided value is included in the interval. This is expressed by set-
ting the attribute min.intervalType resp. max.intervalType to Interval-
TypeEnum.closed.
• open: the provided value in not included in the interval. This is expressed by
setting the attribute min.intervalType resp. max.intervalType to Inter-
valTypeEnum.open.
c()
[TPS_ECUC_06083] Attribute EcucFloatParamDef.min.intervalType is not
defined dIf the attribute min.intervalType is not defined then a closed interval is
implicitly assumed for EcucFloatParamDef.min.c()
[TPS_ECUC_06084] Attribute EcucFloatParamDef.max.intervalType is not
defined dIf the attribute max.intervalType is not defined then a closed interval is
implicitly assumed for EcucFloatParamDef.max.c()
Example 2.13
<ECUC-FLOAT-PARAM-DEF>
<SHORT-NAME>SchedulingPeriod</SHORT-NAME>
<DEFAULT-VALUE>NaN</DEFAULT-VALUE>
<MAX INTERVAL-TYPE="CLOSED">80</MAX>
<MIN INTERVAL-TYPE="OPEN">0</MIN>
</ECUC-FLOAT-PARAM-DEF>
2.3.5.4 String Parameter
[TPS_ECUC_02029] Subclasses of EcucAbstractStringParamDef d The sub-

classes of the class EcucAbstractStringParamDef provide means to specify
strings in the ECUC Value description. Additionally an optional defaultValue can
be provided.c()
[TPS_ECUC_02112] Variable default value in EcucAbstractStringParamDef
d The attribute defaultValue of EcucAbstractStringParamDef and its sub-
classes is subject to variant handling. The value can be computed using the variant
handling mechanism.c(RS_ECUC_00083)
[TPS_ECUC_06035] Regular expression d The regular expression is provided ac-
cording to the Generic Structure Template [6].c()

AUTOSAR CP R22-11
Class <<atpVariation>> EcucAbstractStringParamDef (abstract)

Note Abstract class that is used to collect the common properties for StringParamDefs, LinkerSymbolDef,
FunctionNameDef and MultilineStringParamDefs.
Subclasses EcucFunctionNameDef, EcucLinkerSymbolDef, EcucMultilineStringParamDef, EcucStringParamDef
defaultValue VerbatimString 0..1 attr Default value of the string configuration parameter.
maxLength PositiveInteger 0..1 attr Max length allowed for this string.
minLength PositiveInteger 0..1 attr Min length allowed for this string.
regular RegularExpression 0..1 attr This represents the regular expression which shall be
Expression used to validate the string parameter value.
Table 2.21: EcucAbstractStringParamDef
Class <<atpVariation>> EcucStringParamDef

Note Configuration parameter type for String.
Base ARObject, AtpDefinition, EcucAbstractStringParamDef , EcucCommonAttributes, EcucDefinitionElement,
EcucParameterDef , Identifiable, MultilanguageReferrable, Referrable
– – – – –
Table 2.22: EcucStringParamDef
Class <<atpVariation>> EcucMultilineStringParamDef

Note Configuration parameter type for multiline Strings (including "carriage return").
– – – – –
Table 2.23: EcucMultilineStringParamDef
2.3.5.5 Linker Symbol Parameter
[TPS_ECUC_06006] EcucLinkerSymbolDef properties d When a parameter rep-

resents a linker symbol in the configured software the EcucLinkerSymbolDef shall
be used. The actual values of the symbol defined will be specified by the implementing
software and are not subject to configuration.c()

AUTOSAR CP R22-11
[TPS_ECUC_02030] Programming language identifier limitations d The restriction

on the defaultValue and the value of a EcucLinkerSymbolDef and its subclass
are the common programming language identifier limitations: start with a letter or a
special character (sc) followed by upper- and lower-case letters, digits and special
characters:
identifier := (letter | sc) ( letter | digit | sc )*
where letter is [a-z] or [A-Z], sc is ( _ | . | $ | % ) and digit is [0-9].c()

[TPS_ECUC_02031] Restriction on the length of EcucLinkerSymbolDef values
and defaultValue d The restriction on the length of the default value and the value of
a EcucLinkerSymbolDef is set to 255 characters.c()
The class EcucLinkerSymbolDef does not introduce any additional attributes.
The EcucLinkerSymbolDef in fact represents the C-compiler symbol which later is
translated into a linker symbol. With this element the usage of the external declara-
tion of symbols (e.g. variables, constants) is possible.
Class <<atpVariation>> EcucLinkerSymbolDef
Note Configuration parameter type for Linker Symbol Names like those used to specify memory locations of
variables and constants.
– – – – –
Table 2.24: EcucLinkerSymbolDef
Example 2.14
<ECUC-LINKER-SYMBOL-DEF>
<SHORT-NAME>RtePimInitializationSymbol</SHORT-NAME>
<ECUC-LINKER-SYMBOL-DEF-VARIANTS>
<ECUC-LINKER-SYMBOL-DEF-CONDITIONAL>
<DEFAULT-VALUE>MyPimInitValuesLightMaster</DEFAULT-VALUE>
</ECUC-LINKER-SYMBOL-DEF-CONDITIONAL>
</ECUC-LINKER-SYMBOL-DEF-VARIANTS>
</ECUC-LINKER-SYMBOL-DEF>

AUTOSAR CP R22-11
2.3.5.6 Function Name Parameter
[TPS_ECUC_02033] EcucFunctionNameDef properties d When a parameter rep-

resents a function name in the configured software the EcucFunctionNameDef shall
be used. With this feature functions (like callbacks) can be specified. The class Ecuc-
FunctionNameDef does not introduce any additional attributes.c()
Class <<atpVariation>> EcucFunctionNameDef
Note Configuration parameter type for Function Names like those used to specify callback functions.
– – – – –
Table 2.25: EcucFunctionNameDef
Example 2.15
<ECUC-FUNCTION-NAME-DEF>
<SHORT-NAME>EepJobEndNotification</SHORT-NAME>
<ECUC-FUNCTION-NAME-DEF-VARIANTS>
<ECUC-FUNCTION-NAME-DEF-CONDITIONAL>
<DEFAULT-VALUE>Eep_JobEndNotification</DEFAULT-VALUE>
</ECUC-FUNCTION-NAME-DEF-CONDITIONAL>
</ECUC-FUNCTION-NAME-DEF-VARIANTS>
</ECUC-FUNCTION-NAME-DEF>
[TPS_ECUC_06075] EcucFunctionNameDef shall represent a valid C Identifier

dThe defaultValue and the value of a EcucFunctionNameDef shall follow the pattern
[a-zA-Z_][a-zA-Z0-9_]* defined in the context of the CIdentifier.c()
2.3.5.7 Enumeration Parameter
[TPS_ECUC_02034] EcucEnumerationParamDef properties d When the parame-

ter can be one choice of several possibilities the EcucEnumerationParamDef shall
be used. It defines the parameter that will hold the actual value and may also define
the defaultValue for the enumeration.c()
The specification of variable default value for the enumeration is currently not sup-
ported.

AUTOSAR CP R22-11
Class EcucEnumerationParamDef
Note Configuration parameter type for Enumeration.
defaultValue Identifier 0..1 attr Default value of the enumeration configuration parameter.
This string needs to be one of the literals specified for this
enumeration.
literal EcucEnumerationLiteral * aggr Aggregation on the literals used to define this
Def enumeration parameter. This aggregation is optional if the
surrounding EcucModuleDef has the category
VENDOR_SPECIFIC_MODULE_DEFINITION then this
Tags:atp.Splitkey=literal.shortName
Table 2.26: EcucEnumerationParamDef
2.3.5.8 Enumeration Literal Definition
[TPS_ECUC_02035] Available choices of EcucEnumerationParamDefs are de-

fined by aggregated literals d To provide the available choices for the EcucEnu-
merationParamDef the EcucEnumerationLiteralDef is used. For each avail-
able choice there needs to be one literal defined.c()
[TPS_ECUC_02036] The shortName of an EcucEnumerationLiteralDef is
used to define the literal d For the text used to define the EcucEnumerationLit-
eralDef no additional attribute is needed because the shortName inherited from
Identifiable is used to define the literals.c()
[TPS_ECUC_02054] Allowed literal strings d For the allowed string in shortName
the restrictions apply as defined in the Generic Structure Template [6], in the primitive
Identifier.c()
This basically restricts the shortName to only containing the characters [a-zA-
Z][a-zA-Z0-9_] and have a maximum length of 128 characters. If a more human
readable text shall be provided the longName can be used which has much more free-
dom. This requires that configuration tools will show the optional longName to the
users.
The relationship between the EcucEnumerationParamDef and the available Ecu-
cEnumerationLiteralDef is established using aggregations with the role name
literal at the side of the EcucEnumerationLiteralDef.
[TPS_ECUC_02131] Origin information in literal definitions d Each EcucEnumer-
ationLiteralDef has to provide information on its origin, which contains a string
describing if the parameter is defined in the AUTOSAR standard (’AUTOSAR_ECUC’)

AUTOSAR CP R22-11
or if the parameter is defined as a vendor specific parameter (e.g. ’VendorXYZ_v1.-

3’).c()
Class EcucEnumerationLiteralDef
Note Configuration parameter type for enumeration literals definition.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Aggregated by EcucEnumerationParamDef.literal
ecucCond EcucCondition 0..1 aggr If it evaluates to true the literal definition shall be
Specification processed as specified. Otherwise the literal definition
shall be ignored.
origin String 0..1 attr String specifying if this literal is an AUTOSAR
standardized literal or if the literal is vendor-specific.
Table 2.27: EcucEnumerationLiteralDef
Example 2.16
<ECUC-ENUMERATION-PARAM-DEF>
<SHORT-NAME>RteGenerationMode</SHORT-NAME>
<LITERALS>
<ECUC-ENUMERATION-LITERAL-DEF>
<SHORT-NAME>CompatibilityMode</SHORT-NAME>
<LONG-NAME>
<L-4 L="EN">Generate in Compatibility Mode</L-4>
</LONG-NAME>
</ECUC-ENUMERATION-LITERAL-DEF>
<ECUC-ENUMERATION-LITERAL-DEF>
<SHORT-NAME>VendorMode</SHORT-NAME>
<LONG-NAME>
<L-4 L="EN">Generate in Vendor Mode</L-4>
</LONG-NAME>
</ECUC-ENUMERATION-LITERAL-DEF>
</LITERALS>
</ECUC-ENUMERATION-PARAM-DEF>

AUTOSAR CP R22-11
2.3.5.9 AddInfo
[TPS_ECUC_02118] EcucAddInfoParamDef properties d The parameter Ecu-

cAddInfoParamDef is used to specify the need for formated text in the ECU Con-
figuration Value description. The specification of the details on formated text can be
found in the AUTOSAR Generic Structure Template [6].c()
Class EcucAddInfoParamDef
Note Configuration Parameter Definition for the specification of formatted text in the ECU Configuration
Parameter Description.
– – – – –
Table 2.28: EcucAddInfoParamDef
Example 2.17
<ECUC-ADD-INFO-PARAM-DEF>
<SHORT-NAME>DiagnosticTesterMessage</SHORT-NAME>
</ECUC-ADD-INFO-PARAM-DEF>
2.3.6 References in Parameter Definition
There are five kinds of references available for the definition of configuration parame-
ters referring to other entities.
• Reference to other configuration containers within the ECU Configuration Value
description (see section 2.3.6.1).
• A choice in the referenced configuration container can be specified and the ECU
Configuration Value description has the freedom (with restrictions) to choose to
which target type the reference is pointing to (see section 2.3.6.2).
• Entities outside the ECU Configuration Value description can be referenced when
they have been specified in a different AUTOSAR Template (see section 2.3.6.3).
• Entities outside the ECU Configuration Value description can be referenced using
the instanceRef semantics defined in the Generic Structure Template [6] (see
section 2.3.6.4).
• Reference to a destination that is specified via destinationUri (see section
2.3.6.6).

AUTOSAR CP R22-11
The metamodel of those references is shown in figure 2.11.

+reference 0..*
EcucAbstractExternalReferenceDef
EcucAbstractInternalReferenceDef EcucInstanceReferenceDef EcucForeignReferenceDef
+ requiresSymbolicNameValue: Boolean [0..1] + destinationContext: String [0..1] + destinationType: String [0..1]

+ destinationType: String [0..1]
«atpSplitable»
EcucChoiceReferenceDef EcucReferenceDef EcucUriReferenceDef
«atpUriDef» «atpUriDef»
«atpUriDef»
+destination 0..* +destination 0..1
EcucDefinitionElement +destinationUri 0..1

EcucContainerDef
+destinationUri Identifiable
+ origin: String [0..1] EcucDestinationUriDef
+ postBuildVariantMultiplicity: Boolean [0..1] «atpUriDef» 0..*
+destinationUriDef 0..*
+subContainer 0..*
ARElement
EcucChoiceContainerDef AtpBlueprint
«atpSplitable»
AtpBlueprintable
EcucDestinationUriDefSet
«atpSplitable»
+choice 0..*
Figure 2.11: Class diagram for parameter references
[constr_3576] EcucInstanceReferenceDef.destinationContext always re-

quired dThe attribute EcucInstanceReferenceDef.destinationContext shall
always be defined when the ECU Configuration Parameter definition is complete.c
()
[constr_3577] EcucInstanceReferenceDef.destinationType always re-
quired dThe attribute EcucInstanceReferenceDef.destinationType shall al-
()
[constr_3578] EcucForeignReferenceDef.destinationType always required
dThe attribute EcucForeignReferenceDef.destinationType shall always be de-
fined when the ECU Configuration Parameter definition is complete.c()

AUTOSAR CP R22-11
[constr_3579] EcucReferenceDef.destination always required dThe attribute

EcucReferenceDef.destination shall always be defined when the ECU Config-
uration Parameter definition is complete.c()
[constr_3580] EcucUriReferenceDef.destinationUri always required dThe
attribute EcucUriReferenceDef.destinationUri shall always be defined when
the ECU Configuration Parameter definition is complete.c()
[constr_3581] EcucDestinationUriDefSet.destinationUriDef always re-
quired dThe attribute EcucDestinationUriDefSet.destinationUriDef shall al-
()
[TPS_ECUC_02037] EcucAbstractReferenceDef properties d The abstract class
EcucAbstractReferenceDef is used to specify the common parts of all reference
definitions. EcucAbstractReferenceDef is an Identifiable so it is mandatory
to give each reference definition a name. Also EcucAbstractReferenceDef is in-
heriting from EcucDefinitionElement so for each reference definition it can be
specified how many such references might be present in the same configuration con-
tainer later in the ECU Configuration Value description.c()
Class EcucAbstractReferenceDef (abstract)
Note Common class to gather the attributes for the definition of references.
Base ARObject, AtpDefinition, EcucCommonAttributes, EcucDefinitionElement, Identifiable, Multilanguage
Subclasses EcucAbstractExternalReferenceDef , EcucAbstractInternalReferenceDef
Aggregated by EcucDestinationUriPolicy.reference, EcucParamConfContainerDef.reference
withAuto Boolean 0..1 attr Specifies whether it shall be allowed on the value side to
specify this reference value as "AUTO".
If withAuto is "true" it shall be possible to set the "isAuto
Value" attribute of the respective reference to "true". This
means that the actual value will not be considered during
ECU Configuration but will be (re-)calculated by the code
values.
If withAuto is "false" it shall not be possible to set the "is
AutoValue" attribute of the respective reference to "true".
If withAuto is not present the default is "false".
Table 2.29: EcucAbstractReferenceDef
Class EcucAbstractInternalReferenceDef (abstract)

Note Common abstract class to gather attributes for internal references (where the destination is located in the
Ecu Configuration Description).
5

AUTOSAR CP R22-11
4
Class EcucAbstractInternalReferenceDef (abstract)
Base ARObject, AtpDefinition, EcucAbstractReferenceDef , EcucCommonAttributes, EcucDefinitionElement,
Subclasses EcucChoiceReferenceDef, EcucReferenceDef, EcucUriReferenceDef
requires Boolean 0..1 attr If this attribute is set to true the implementation of the
SymbolicName reference is done using a Symbolic Name defined by the
Value referenced container according to TPS_ECUC_02108.
Table 2.30: EcucAbstractInternalReferenceDef
Class EcucAbstractExternalReferenceDef (abstract)

Note Common abstract class to gather attributes for external references (where the destination is not located
in the ECU Configuration Description but in an another AUTOSAR Template).
Base ARObject, AtpDefinition, EcucAbstractReferenceDef , EcucCommonAttributes, EcucDefinitionElement,
Subclasses EcucForeignReferenceDef, EcucInstanceReferenceDef
– – – – –
Table 2.31: EcucAbstractExternalReferenceDef
2.3.6.1 Reference
[TPS_ECUC_02039] References between containers are established with the

EcucReferenceDef d The EcucReferenceDef is used to establish references
from one EcucParamConfContainerDef to one other specific EcucParamConf-
ContainerDef or EcucChoiceContainerDef within the same ECU Configuration
Value description. For this purpose an object representing the reference has to be
used.c(RS_ECUC_00072)
[TPS_ECUC_02038] Destination of EcucReferenceDef and EcucChoiceRefer-
enceDefs is the EcucContainerDef d The destination for the EcucRefer-
enceDef and the EcucChoiceReferenceDef is both the EcucContainerDef. So
it is not possible to reference to a specific EcucParameterDef, EcucReferenceDef
or EcucModuleDef.c()
The reason is that there is no use-case where a direct reference to a parameter would
be needed.

AUTOSAR CP R22-11
Class EcucReferenceDef
Note Specify references within the ECU Configuration Description between parameter containers.
Base ARObject, AtpDefinition, EcucAbstractInternalReferenceDef , EcucAbstractReferenceDef , EcucCommon
Attributes, EcucDefinitionElement, Identifiable, MultilanguageReferrable, Referrable
destination EcucContainerDef 0..1 ref Exactly one reference to a parameter container is allowed
as destination.
Table 2.32: EcucReferenceDef
The role name at the EcucReferenceDef has to be reference and the role name
at the referenced container has to be destination (see figure 2.12 for an example).
OsApplication: OsAppScheduleTableRef: OsScheduleTable:
EcucParamConfContainerDef +reference EcucReferenceDef +destination EcucParamConfContainerDef
upperMultiplicity = * upperMultiplicity = * upperMultiplicity = *

lowerMultiplicity = 0 lowerMultiplicity = 0 lowerMultiplicity = 0
Figure 2.12: Example of an object diagram for a reference
In the example in figure 2.12 the ’OsApplication’ is defined to contain references to the
’OsScheduleTable’. The references are called ’OsAppScheduleTableRef’ and there
can be several such references in the actual ECU Configuration Value description doc-
ument. For the multiplicity of references the multiplicity definition on the EcucRef-
erenceDef are relevant (in the example the lowerMultiplicity is ’0’ and the
upperMultiplicity is ’*’). The multiplicity of the referenced container is not con-
sidered for references.
In the ECU Configuration Parameter Definition XML file the destination has to be
identified unambiguously because the names of configuration parameters are not re-
quired to be unique throughout the whole ECU Configuration Parameter Definition. So
there might be a parameter defined in the CAN-Driver with the same name as one
parameter defined in the ADC-Driver. For this reason the containment hierarchy of
the referenced configuration parameter has to be denoted in the definition XML file,
as shown in example 2.18. In this example the referenced parameter will be found in
the definition of the Os module directly in the AUTOSARParameterDefinition. The
corresponding ECUC Value description XML file extract is shown in example 2.41.
Example 2.18
<ECUC-REFERENCE-DEF>
<SHORT-NAME>OsAppScheduleTableRef</SHORT-NAME>
<DESTINATION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">/AUTOSAR/
EcucDefs/Os/OsScheduleTable</DESTINATION-REF>
</ECUC-REFERENCE-DEF>

AUTOSAR CP R22-11
2.3.6.2 Choice Reference
[TPS_ECUC_02040] EcucChoiceReferenceDef properties d With the Ecuc-

ChoiceReferenceDef it is possible to define one reference where the destination
is specified to be one of several possible kinds. To be able to define such a choice an
object of the class EcucChoiceReferenceDef has to be aggregated in a container
with the role name reference at the EcucChoiceReferenceDef object. The des-
tinations of a EcucChoiceReferenceDef may be EcucParamConfContain-
erDef and EcucChoiceContainerDef.c()
Class EcucChoiceReferenceDef
Note Specify alternative references where in the ECU Configuration description only one of the specified
references will actually be used.
destination EcucContainerDef * ref All the possible parameter containers for the reference
are specified.
Table 2.33: EcucChoiceReferenceDef
All the available choices are connected via associations with the role name destina-
tion at the referenced object (see example in figure 2.13).
PortPin:
+reference
PortPinMode:
EcucChoiceReferenceDef
+destination +destination +destination
CanDrvCanController: AdcChannel: SpiCsDirect:

EcucParamConfContainerDef EcucParamConfContainerDef EcucParamConfContainerDef
upperMultiplicity = * upperMultiplicity = *
Figure 2.13: Example of an object diagram for a choice reference
In this example an actual instance of the ’PortPinMode’ container can reference one
of the three defined containers. Once again the multiplicity is defined by the Ecuc-
ChoiceReferenceDef (here the default ’1’ for lower and upper) and the multiplicities
of the referenced containers are not relevant for choice references.

AUTOSAR CP R22-11
Also the destination needs to be defined unambiguously in the ECU Configuration

Parameter Definition XML file like shown in example 2.19. The corresponding ECUC
Value description XML file extract is shown in example 2.42.
Example 2.19
<ECUC-CHOICE-REFERENCE-DEF>
<SHORT-NAME>PortPinMode</SHORT-NAME>
<DESTINATION-REFS>
<DESTINATION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">/AUTOSAR/EcucDefs
/Can/CanDrvCanController</DESTINATION-REF>
/Adc/AdcChannel</DESTINATION-REF>
/Spi/SpiCsDirect</DESTINATION-REF>
</DESTINATION-REFS>
</ECUC-CHOICE-REFERENCE-DEF>
In the ECU Configuration Value description the actual choice will be taken and there
will be only one reference destination left15 .
2.3.6.3 Foreign Reference
[TPS_ECUC_02041] EcucForeignReferenceDef properties d To be able to refer-

ence to descriptions of other AUTOSAR templates the parameter definition EcucFor-
eignReferenceDef is used. With the attribute destinationType the type of the
referenced entity has to be specified.c()
Class EcucForeignReferenceDef
Note Specify a reference to an XML description of an entity described in another AUTOSAR template.
Base ARObject, AtpDefinition, EcucAbstractExternalReferenceDef , EcucAbstractReferenceDef , Ecuc
CommonAttributes, EcucDefinitionElement, Identifiable, MultilanguageReferrable, Referrable
destinationType String 0..1 attr The type in the AUTOSAR Metamodel to which instance
this reference is allowed to point to.
Table 2.34: EcucForeignReferenceDef
[TPS_ECUC_02042] Specification of the destinationType in a EcucForeign-

ReferenceDef d Since the AUTOSAR Generic Structure Template [6] requires
the class names of all Identifiables to be unique within the AUTOSAR ’M2::
15
The EcucDefinitionElement is used to specify the possible occurrences of each reference later
in the ECU Configuration Description. The EcucChoiceReferenceDef specifies multiple possible
destinations for one reference but later in the ECU Configuration Value description there can only be
exactly one destination described. So the freedom of multiple destinations is only available on the
definition of references, if several containers need to be referenced the EcucDefinitionElement
has to be set to more than 1, even for the EcucChoiceReferenceDef.

AUTOSAR CP R22-11
AUTOSAR Templates’ metamodel, it is sufficient to provide only the actual class name
of the referenced class in the destinationType, as shown in example 2.20.c()
[TPS_ECUC_06088] Specification of the destinationType format in a Ecuc-
ForeignReferenceDef dThe string entered as destinationType shall have the
name of a M2 class defined in the metamodel [9] under ’M2:: AUTOSAR Templates’ as
it is represented in the XML-Schema [11] and the referenced class needs to be derived
(directly or indirectly) from Identifiable. In the generated Parameter Definition
XML file [8] the XML-Schema name shall be used.c()
System template
+reference FibexElement
FrameMapping: SystemFrame:
EcucParamConfContainerDef EcucForeignReferenceDef CoreCommunication::Frame
destinationType = FRAME + frameLength: Integer [0..1]
Figure 2.14: Example of an object diagram for a foreign reference
In the example in figure 2.14 the reference is defined to be pointing to a description of

a Frame. The Frame is defined in the System Template metamodel [2] and is derived
from Identifiable. The corresponding ECUC Value description XML file extract is
shown in example 2.43.
Example 2.20
<ECUC-FOREIGN-REFERENCE-DEF>
<SHORT-NAME>SystemFrame</SHORT-NAME>
<DESTINATION-TYPE>FRAME</DESTINATION-TYPE>
</ECUC-FOREIGN-REFERENCE-DEF>
2.3.6.4 Instance Reference
[TPS_ECUC_02060] EcucInstanceReferenceDef properties d To be able to refer-

ence to descriptions of other AUTOSAR templates with the instanceRef semantics16
the parameter definition EcucInstanceReferenceDef is used. With the attribute
destinationType the type of the referenced entity has to be specified. With the
attribute destinationContext the context expression has to be specified.c()
[TPS_ECUC_02082] Specification of the destinationType in a EcucIn-
stanceReferenceDef d The string entered as destinationType shall have the
name of a M2 class defined in the metamodel [9] under ’M2::AUTOSAR Templates’ as
it is represented in the XML-Schema [11] and the referenced class needs to be derived
(directly or indirectly) from Identifiable. In the generated Parameter Definition
XML file [8] the XML-Schema name shall be used.c()
16
For a detailed description of the instanceRef concept please refer to the Generic Structure Tem-
plate [6]

AUTOSAR CP R22-11
[TPS_ECUC_02083] Specification of the destinationContext in a EcucIn-

stanceReferenceDef d The string entered as destinationContext shall be an
ordered list of M2 class names defined in the metamodel [9] under ’M2::AUTOSAR
Templates’ as it is represented in the XML schema [11] separated by the SPACE char-
acter. Additionally the ’*’ character can be used to indicate none or multiple occurrence
of the M2 class BEFORE the ’*’ character.c()
Examples of destinationContext expressions are:
SW-COMPONENT-PROTOTYPE R-PORT-PROTOTYPE
ROOT-SW-COMPOSITION-PROTOTYPE SW-COMPONENT-PROTOTYPE PORT-PROTOTYPE
ROOT-SW-COMPOSITION-PROTOTYPE SW-COMPONENT-PROTOTYPE PORT-PROTOTYPE

DATA-PROTOTYPE*
Class EcucInstanceReferenceDef
Note Specify a reference to an XML description of an entity described in another AUTOSAR template using
the INSTANCE REFERENCE semantics.
Base ARObject, AtpDefinition, EcucAbstractExternalReferenceDef , EcucAbstractReferenceDef , Ecuc
CommonAttributes, EcucDefinitionElement, Identifiable, MultilanguageReferrable, Referrable
destination String 0..1 attr The context in the AUTOSAR Metamodel to which’ this
Context reference is allowed to point to.
destinationType String 0..1 attr The type in the AUTOSAR Metamodel to which’ instance
this reference is allowed to point to.
Table 2.35: EcucInstanceReferenceDef
[TPS_ECUC_02061] Specification of the destinationType in a EcucInstanceRef-

erenceDef d Since the AUTOSAR Generic Structure Template [6] requires the class
names of all Identifiables to be unique within the AUTOSAR ’M2:: AUTOSAR
Templates’ metamodel, it is sufficient to provide only the actual class name of the ref-
erenced class in the destinationType, as shown in example 2.21.c()

AUTOSAR CP R22-11
Software Component Template
AtpPrototype ARElement
SwComponentPrototype type AtpBlueprint
AtpBlueprintable
«isOfType» 0..1 AtpType
{redefines SwComponentType
atpType}
«atpVariation,atpSplitable»
port 0..*
AtpBlueprintable
AtpPrototype
PortPrototype
AbstractProvidedPortPrototype AbstractRequiredPortPrototype
PPortPrototype PRPortPrototype RPortPrototype
«isOfType» «isOfType»
0..1 «isOfType» 0..1
{redefines 0..1 {redefines
providedInterface providedRequiredInterface {redefines atpType} requiredInterface atpType}
atpType}
ARElement
AtpBlueprint
AtpBlueprintable
AtpType
PortInterface
serviceKind: ServiceProviderEnum [0..1]

«atpVariation»
isService: Boolean [0..1]
DataInterface
dataElement AutosarDataPrototype
SenderReceiverInterface
VariableDataPrototype
0..*
VariableDataPrototoypeRef: EcucInstanceReferenceDef
SenderReceiverMapping: reference
EcucParamConfContainerDef destinationType = VARIABLE-DATA-PROTOTYPE
destinationContext = SW-COMPONENT-PROTOTYPE* PORT-PROTOTYPE
Figure 2.15: Example of an object diagram for an instance reference
In the example in figure 2.15 the reference is defined to be pointing to a description

of a ’VARIABLE-DATA-PROTOTYPE’. The ’VARIABLE-DATA-PROTOTYPE’ is defined
in the Software Component Template metamodel [12] and is derived from Identi-
fiable. Via the destinationContext it is specified that each ’VARIABLE-DATA-
PROTOTYPE’ exists in the context of a ’PORT-PROTOTYPE’, which itself is in the
context of the ’SW-COMPONENT-PROTOTYPE’. The corresponding ECUC Value de-
scription XML file extract is shown in example 2.44.
Example 2.21

AUTOSAR CP R22-11
<ECUC-INSTANCE-REFERENCE-DEF>
<SHORT-NAME>VariableDataPrototypeRef</SHORT-NAME>
<DESTINATION-CONTEXT>SW-COMPONENT-PROTOTYPE* PORT-PROTOTYPE</DESTINATION-
CONTEXT>
<DESTINATION-TYPE>VARIABLE-DATA-PROTOTYPE</DESTINATION-TYPE>
</ECUC-INSTANCE-REFERENCE-DEF>
Although the ECU Configuration Parameter Definition of the EcucForeignRefer-

enceDef and EcucInstanceReferenceDef are similar there is a difference how
those references are represented in the ECU Configuration Value description (see sec-
tion 2.4.5).
2.3.6.5 Symbolic Name Reference
[TPS_ECUC_02146] Symbolic Name Reference properties dAn EcucAbstract-

InternalReferenceDef with the attribute requiresSymbolicNameValue set to
true is used to establish the relationship between the user of a symbolic name and
the provider of a symbolic name. The object defining the EcucAbstractInternal-
ReferenceDef is the user and the destination of the reference is the provider of the
symbolic name.c()
[TPS_ECUC_02063] Parameters with symbolicNameValue = true d If the attribute
symbolicNameValue of a configuration parameter (see [TPS_ECUC_02014]) is set
to true this configuration parameter contributes to the value of the symbolic name.
Only one configuration parameter within a container may have the attribute symbol-
icNameValue set to true.c()
If the attribute symbolicNameValue is not present it shall be assumed to be set to
false.
[constr_5520] valueConfigClass attribute of symbolicNameValue parame-
ters dThe values of EcucParameterDefs with symbolicNameValue attribute set
to true shall have their valueConfigClass.configClass set to PreCompile or
PublishedInformation for all valueConfigClass.configVariants.c()
[constr_5521] multiplicityConfigClass attribute of symbolicNameValue pa-
rameters dThe values of EcucParameterDefs with symbolicNameValue attribute
set to true shall have their multiplicityConfigClass.configClass set to Pre-
Compile for all multiplicityConfigClass.configVariants.c()
[constr_5512] postBuildVariantValue attribute of symbolicNameValue pa-
rameters dThe values of EcucParameterDefs with symbolicNameValue attribute
set to true shall have their postBuildVariantValue set to false.c()
[constr_5522] postBuildVariantMultiplicity attribute of symbolic-
NameValue parameters dThe values of EcucParameterDefs with symbolic-
NameValue attribute set to true shall have their postBuildVariantMultiplic-
ity set to false.c()

AUTOSAR CP R22-11
In the example definition shown in figure 2.16 the CorTst module can contain a CorT-
stDemEventParameterRefs. Those errors need to be defined in the Dem module.
And only the Dem module is able to define actual numbers associated with these errors
when all errors have been specified and collected in the Dem module. Those asso-
ciated values can be stored in the DemEventId parameter which belongs to each
DemEventParameter.
For an example how this is used in the ECU Configuration Value description refer to
section 2.4.5.2. The corresponding ECUC Value description XML file extract is shown
in example 2.45.
CorTst: EcucModuleDef CorTstDemEventParameterRefs: CORTST_E_CORE_FAILURE:
+container
EcucParamConfContainerDef +reference EcucReferenceDef
upperMultiplicity = 1 lowerMultiplicity = 0 lowerMultiplicity = 0
requiresSymbolicNameValue = true
Dem: EcucModuleDef
+container +destination
DemConfigSet: DemEventParameter: DemEventId:

+subContainer
EcucParamConfContainerDef EcucParamConfContainerDef +parameter EcucIntegerParamDef
upperMultiplicity = 65535 max = 65535

lowerMultiplicity = 1 min = 1
symbolicNameValue = true
Figure 2.16: Example of an object diagram for a Symbolic Name Reference
Example 2.22
<ECUC-MODULE-DEF>
<SHORT-NAME>CorTst</SHORT-NAME>
<CONTAINERS>
<SHORT-NAME>CorTstDemEventParameterRefs</SHORT-NAME>
<REFERENCES>
<SHORT-NAME>CORTST_E_CORE_FAILURE</SHORT-NAME>
<REQUIRES-SYMBOLIC-NAME-VALUE>true</REQUIRES-SYMBOLIC-NAME-VALUE>
<DESTINATION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">/AUTOSAR/
EcucDefs/Dem/DemEventParameter</DESTINATION-REF>
</REFERENCES>
</CONTAINERS>
</ECUC-MODULE-DEF>
<ECUC-MODULE-DEF>
<SHORT-NAME>Dem</SHORT-NAME>
<CONTAINERS>

AUTOSAR CP R22-11
<SHORT-NAME>DemEventParameter</SHORT-NAME>
<PARAMETERS>
<SHORT-NAME>DemEventId</SHORT-NAME>
<SYMBOLIC-NAME-VALUE>true</SYMBOLIC-NAME-VALUE>
</PARAMETERS>
</CONTAINERS>
</ECUC-MODULE-DEF>
2.3.6.6 Uri Reference
[TPS_ECUC_06078] EcucUriReferenceDef properties dWith the EcucUriRef-

erenceDef it is possible to define one reference where the destination is specified via
a destinationUri. Any EcucContainerDef with an identical destinationUri
defines a valid reference target. The destination of an EcucUriReferenceDef may
be a EcucParamConfContainerDef or a EcucChoiceContainerDef.c()
Please note that an EcucContainerDef can define several destinationUris and
therefore be applicable for several EcucUriReferenceDefs. With the EcucUriRef-
erenceDef it is possible to define a reference to containers in different modules inde-
pendent from the concrete definition of the target container.
Class EcucUriReferenceDef
Note Definition of reference with a destination that is specified via a destinationUri. With such a reference it is
possible to define a reference to a EcucContainerDef in a different module independent from the
concrete definition of the target container.
destinationUri EcucDestinationUriDef 0..1 ref Any EcucContainerDef with a destinationUri that is
identical to the destinationUri that is referenced here
defines a valid target.
Table 2.36: EcucUriReferenceDef

AUTOSAR CP R22-11
Class EcucDestinationUriDefSet
Note This class represents a list of EcucDestinationUriDefs.
Tags:atp.recommendedPackage=EcucDestinationUriDefSets
Base ARElement, ARObject, AtpBlueprint, AtpBlueprintable, CollectableElement, Identifiable, Multilanguage
Referrable, PackageableElement, Referrable
destinationUri EcucDestinationUriDef * aggr This is one particular EcucDestinationUriDef.
Def
Table 2.37: EcucDestinationUriDefSet
Class EcucDestinationUriDef
Note Description of an EcucDestinationUriDef that is used as target of EcucUriReferenceDefs.
Aggregated by EcucDestinationUriDefSet.destinationUriDef
destinationUri EcucDestinationUri 0..1 aggr Description of the targeted EcucContainerDef.
Policy Policy
Table 2.38: EcucDestinationUriDef
In order to define the expected content of the referenced EcucContainerDef the

EcucDestinationUriPolicy qualifies which containers, parameters and / or
references the referenced EcucContainerDef shall own.
Identifiable +destinationUri
EcucDestinationUriDef
0..* «atpUriDef»
+destinationUriPolicy
0..1
EcucDestinationUriPolicy EcucDefinitionElement
+ destinationUriNestingContract: EcucDestinationUriNestingContractEnum [0..1] EcucContainerDef
+container
0..* + postBuildVariantMultiplicity: Boolean [0..1]
+parameter EcucParameterDef
0..* + symbolicNameValue: Boolean [0..1]

+reference
0..*
«enumeration»
EcucDestinationUriNestingContractEnum
targetContainer
leafOfTargetContainer
vertexOfTargetContainer
Figure 2.17: EcucDestinationUriDef details

AUTOSAR CP R22-11
[constr_3582] EcucDestinationUriDef.destinationUriPolicy always re-

quired dThe attribute EcucDestinationUriDef.destinationUriPolicy shall al-
()
[constr_3583] EcucDestinationUriPolicy.destinationUriNestingCon-
tract always required dThe attribute EcucDestinationUriPolicy.destina-
tionUriNestingContract shall always be defined when the ECU Configuration
Parameter definition is complete.c()
Class EcucDestinationUriPolicy
Note The EcucDestinationUriPolicy describes the EcucContainerDef that will be targeted by EcucUriReference
Defs. The type of the description is dependent of the destinationUriNestingContract attribute.
Base ARObject
Aggregated by EcucDestinationUriDef.destinationUriPolicy
container EcucContainerDef * aggr Description of the targetContainer in case that the
destinationUriNestingPolicy is set to targetContainer. In
all other cases the subContainers of the target container
are defined here.
destinationUri EcucDestinationUri 0..1 attr This attribute defines how the referenced target Ecuc
NestingContract NestingContractEnum ContainerDef is described.
parameter EcucParameterDef * aggr Description of parameters that are contained in the target
container.
reference EcucAbstractReference * aggr Description of references that are contained in the target
Def container.
Table 2.39: EcucDestinationUriPolicy
Enumeration EcucDestinationUriNestingContractEnum
Note EcucDestinationUriNestingContractEnum is used to determine what is qualified by the Ecuc
DestinationUriPolicy.
Aggregated by EcucDestinationUriPolicy.destinationUriNestingContract
Literal Description
leafOfTarget EcucDestinationUriPolicy describes elements (subContainers, Parameters, References) that are
Container directly owned by the target container.
targetContainer EcucDestinationUriPolicy describes the target container of EcucUriReferenceDef.
vertexOfTarget EcucDestinationUriPolicy describes elements (subContainers, Parameters, References) of the target
Container container which can be defined in arbitrary nested subContainer structure.
Table 2.40: EcucDestinationUriNestingContractEnum
[constr_3119] Necessary content of EcucDestinationUriDefs that are refer-

enced by an EcucContainerDef dThe EcucDestinationUriDef that is refer-
enced by the EcucContainerDef in the role destinationUri shall define at least
the analogous set of containers, parameters and references defined by the

AUTOSAR CP R22-11
EcucDestinationUriPolicy of the EcucDestinationUriDef that is referenced

by the EcucUriReferenceDef that targets the EcucContainerDef.c()
Dependent from the attribute destinationUriNestingContract the EcucDes-
tinationUriPolicy can qualify either
• the referenced EcucContainerDef
• containers, parameters and references being leafs of the referenced
EcucContainerDef
• containers, parameters and references defined in an arbitrary nested sub-
Container structure below the referenced EcucContainerDef
[TPS_ECUC_06079] destinationUriNestingContract is set to targetCon-
tainer dWhen the destinationUriNestingContract is set to targetCon-
tainer the EcucContainerDef in the role container qualifies as the target con-
tainer of EcucUriReferenceDef. The according EcucContainerDef shall have
the identical shortName and at least the defined subContainers, references and pa-
rameters with the given attributes (e.g shortName, range and multiplicity).c()
[constr_3120] Applicable attributes when destinationUriNestingContract
is set to targetContainer dIf the destinationUriNestingContract is set to
targetContainer the attributes parameter and reference shall not exist.c()
[TPS_ECUC_06080] destinationUriNestingContract is set to leafOfTar-
getContainer dWhen the destinationUriNestingContract is set to leafOf-
TargetContainer the attributes containers, parameters and references qual-
ify directly owned elements of the target container. In this case the according Ecuc-
ContainerDef shall have at least the defined subContainers, references and param-
eters with the given attributes (e.g shortName, range and multiplicity).c()
This is in particular useful to define parameters or references owned by the target
container without further specification of the target container (e.g. type of container or
shortName)
[TPS_ECUC_06081] destinationUriNestingContract is set to vertexOf-
TargetContainer dWhen the destinationUriNestingContract is set to ver-
texOfTargetContainer the attributes containers, parameters and refer-
ences qualify elements of the target container which can be defined in arbitrary nested
subContainer structure. In this case the according EcucContainerDef or any sub-
Container shall have at least the defined subContainers, references and parameters
with the given attributes (e.g shortName, range and multiplicity).c()
The following example shows the definition of the destinationUri "/Example/UriSe-
tA/Uri1". The EcucDestinationUriPolicy qualifies the targetContainer with the
shortName "UriReferableContainer" and one parameter "InterestingParam1" of type
EcucIntegerParamDef. The module "UriTarget" defines a fitting container and the
module "UriRef" defines an according EcucUriReferenceDef.

AUTOSAR CP R22-11
Example 2.23
<AR-PACKAGES>
<AR-PACKAGE>
<SHORT-NAME>EcucModuleDefs</SHORT-NAME>
<ELEMENTS>
<ECUC-MODULE-DEF>
<SHORT-NAME>UriTarget</SHORT-NAME>
<CONTAINERS>
<SHORT-NAME>UriReferableContainer</SHORT-NAME>
<DESTINATION-URI-REFS>
<DESTINATION-URI-REF DEST="ECUC-DESTINATION-URI-DEF">/
Example/UriSetA/Uri1</DESTINATION-URI-REF>
</DESTINATION-URI-REFS>
<PARAMETERS>
<SHORT-NAME>InterestingParam1</SHORT-NAME>
<MAX>255</MAX>
<MIN>1</MIN>
</PARAMETERS>
</CONTAINERS>
</ECUC-MODULE-DEF>
<ECUC-MODULE-DEF>
<SHORT-NAME>UriRef</SHORT-NAME>
<CONTAINERS>
<SHORT-NAME>Container1</SHORT-NAME>
<REFERENCES>
<ECUC-URI-REFERENCE-DEF>
<SHORT-NAME>UriRef_Uri1</SHORT-NAME>
<DESTINATION-URI-REF DEST="ECUC-DESTINATION-URI-DEF">
/Example/UriSetA/Uri1</DESTINATION-URI-REF>
</ECUC-URI-REFERENCE-DEF>
</REFERENCES>
</CONTAINERS>
</ECUC-MODULE-DEF>
</ELEMENTS>
</AR-PACKAGE>
<AR-PACKAGE>
<SHORT-NAME>EcucDestinationUriDefSet</SHORT-NAME>
<ELEMENTS>
<ECUC-DESTINATION-URI-DEF-SET>
<SHORT-NAME>UriSetA</SHORT-NAME>
<DESTINATION-URI-DEFS>
<ECUC-DESTINATION-URI-DEF>
<SHORT-NAME>Uri1</SHORT-NAME>
<DESTINATION-URI-POLICY>
<CONTAINERS>
<SHORT-NAME>UriReferableContainer</SHORT-NAME>

AUTOSAR CP R22-11
<PARAMETERS>
<SHORT-NAME>InterestingParam1</SHORT-NAME>
<MAX>255</MAX>
<MIN>1</MIN>
</PARAMETERS>
</CONTAINERS>
<DESTINATION-URI-NESTING-CONTRACT>TARGET-CONTAINER</
DESTINATION-URI-NESTING-CONTRACT>
</DESTINATION-URI-POLICY>
</ECUC-DESTINATION-URI-DEF>
</DESTINATION-URI-DEFS>
</ECUC-DESTINATION-URI-DEF-SET>
</ELEMENTS>
</AR-PACKAGE>
</AR-PACKAGES>

AUTOSAR CP R22-11
2.3.7 Derived Parameter Specification
The parameter definitions introduced in the previous sections are meant to define con-
figuration parameter types regardless how the actual values will be captured. But since
the ECU Configuration is dependent on lots of other input information many values for
the configuration of the BSW and the RTE can be taken over or calculated from other
values already available in the description (e.g. the System Extract or the Software-
Component description) or other sections of the ECU Configuration. Such configura-
tion parameters are called Derived Configuration Parameters.
EcucContainerDef
«atpSplitable»
+parameter 0..*
EcucParameterDef

Paginateable
+derivation 0..1
+informalFormula MlFormula
EcucDerivationSpecification
0..1
+calculationFormula FormulaExpression
0..1 «atpMixedString»
EcucParameterDerivationFormula
+ecucQuery 0..*
+ecucQuery
Identifiable
0..1
EcucQuery
{subsets
atpReference}
0..1 +ecucQueryString
{subsets
+ecucQueryExpression 0..1 atpStringReference}
«atpMixedString»
EcucQueryExpression
AtpDefinition
+configElementDefGlobal
Identifiable
«atpUriDef» EcucDefinitionElement
0..1
+ scope: EcucScopeEnum [0..1]
«atpVariation»
+configElementDefLocal + lowerMultiplicity: PositiveInteger [0..1]
+ upperMultiplicity: PositiveInteger [0..1]
«atpUriDef» 0..1 + upperMultiplicityInfinite: Boolean [0..1]
Figure 2.18: Definition of Derived Parameters
[constr_3584] EcucQuery.ecucQueryExpression always required dThe attribute

EcucQuery.ecucQueryExpression shall always be defined when the ECU Con-
figuration Parameter definition is complete.c()

AUTOSAR CP R22-11
Class EcucDerivationSpecification
Note Allows to define configuration items that are calculated based on the value of
• other parameter values
• elements (attributes/classes) defined in other AUTOSAR templates such as System template
and SW component template
Base ARObject
Aggregated by EcucParameterDef .derivation
calculation EcucParameter 0..1 aggr Definition of the formula used to calculate the value of the
Formula DerivationFormula configuration element.
ecucQuery EcucQuery * aggr Query to the ECU Configuration Description.
informalFormula MlFormula 0..1 aggr Informal description of the derivation used to calculate the
value of the configuration element.
Table 2.41: EcucDerivationSpecification
[TPS_ECUC_02047] Derivation of parameter values d For each EcucParameter-

Def it can be specified how the parameter value will be computed. This is captured in
the element EcucDerivationSpecification.c()
[TPS_ECUC_02129] Informal description of the derivation d For all EcucParame-
terDef types an informal description of the derivation can be specified in the element
informalFormula.c()
[TPS_ECUC_02128] Formal description of the derivation d For the EcucParame-
terDef types
• EcucBooleanParamDef
• EcucIntegerParamDef
• EcucFloatParamDef
a formal calculationFormula can be specified in the element EcucParameter-
DerivationFormula.c()
Note: The application of the formal calculation formula to the above mentioned types
is due to the fact that the result of the calculation formula is numerical.
2.3.7.1 Derived Parameter Calculation Formula
A derivation of a Configuration Parameter value can be specified by an informal Calcu-

lation Formula or by a formal language that can be used to specify the computational
rules (see figure 2.18). The formal language is defined in the Generic Structure Tem-
plate [6]. With this formal language it is possible to express dependencies between
parameters and e.g. to calculate a value of one parameter based on other parameter
values.

AUTOSAR CP R22-11
Class <<atpMixedString>> EcucParameterDerivationFormula

Note This formula is intended to specify how an ecu parameter can be derived from other information in the
Autosar Templates.
Base ARObject, FormulaExpression
Aggregated by EcucDerivationSpecification.calculationFormula
ecucQuery EcucQuery 0..1 ref This is one particular EcucQuery used in the calculation
formula.
ecucQuery EcucQuery 0..1 ref This indicates that the referenced query shall return a
String string.
Table 2.42: EcucParameterDerivationFormula
The informal Calculation Formula (MlFormula) can be used for the same purpose.
But here, the rules how the derived values are computed are not defined. Different
representations can be used to specify such an informal computational rule. More
details can be found in MSRSW. Although the MlFormula is informal there can be
some programming language syntax and semantics interpreted.
To derive Configuration Parameter values with the formal calculation formula one or
several EcucQuerys can be defined. An EcucQuery is Identifiable and aggre-
gates one EcucQueryExpression. The EcucQueryExpression defines a query
to the ECU Configuration Value description and outputs the result as a numerical value.
Four functions are currently supported by the EcucQueryExpression: count, value,
deref and refvalue. Due the atpMixedString nature of the EcucQueryExpres-
sion several function keywords mixed with several local and global references17 can
be defined within an EcucQueryExpression.
Class EcucQuery
Note Defines a query to the ECUC Description.
Aggregated by EcucConditionSpecification.ecucQuery, EcucDerivationSpecification.ecucQuery, EcucValidation
Condition.ecucQuery
ecucQuery EcucQueryExpression 0..1 aggr This is the EcucQuery used in the calculation formula or
Expression the condition formula.
Table 2.43: EcucQuery
Class <<atpMixedString>> EcucQueryExpression

Note Defines a query expression to the ECUC Description and output the result as an numerical value. Due to
the "mixedString" nature of the formula there can be several EcuQueryExpressions used.
Base ARObject
5
17
configElementDefLocal, configElementDefGlobal

AUTOSAR CP R22-11
4
Class <<atpMixedString>> EcucQueryExpression
Aggregated by EcucQuery.ecucQueryExpression
configElement EcucDefinitionElement 0..1 ref The EcucQueryExpression points to an EcucDefinition
DefGlobal Element that is used to find an element in the Ecuc
Description. In order to find the right element in the Ecuc
Description a search is necessary. If the complete Ecuc
Description needs to be searched this global reference
shall be used. Due to the "mixedString" nature of the
EcucQueryExpression several references to Ecuc
DefintionElements can be used in one EcucQuery
Expression.
configElement EcucDefinitionElement 0..1 ref The EcucQueryExpression points to an EcucDefinition
DefLocal Element that is used to find an element in the Ecuc
Description. In order to find the right element in the Ecuc
Description a search is necessary. If the search is
executed inside of the same module that contains the
EcucQuery this local reference shall be used. Due to the
"mixedString" nature of the EcucQueryExpression several
references to EcucDefintionElements can be used in one
EcucQueryExpression.
Table 2.44: EcucQueryExpression
[constr_5505] Configuration class of the elements of the EcucQueryExpression

dThe elements of the EcucQueryExpression involved in one calculation formula
shall have lower or equal configuration class (where PreCompile configuration class
is considered to be the lowest and PostBuild the highest) with respect to the context
element in which the calculation is performed (e.g. a Link configuration parameter
can not calculate its value based on a PostBuild parameters value).c()
[TPS_ECUC_06018] Input and Output of the refvalue function dThe refvalue func-
tion is provided with a EcucDefinitionElement and delivers a set of elements from
the ECU Configuration Value description which share the definition role of the pro-
vided EcucDefinitionElement.c()
[TPS_ECUC_06019] Output of the refvalue function if the EcucDefinitionElement
points to a not existing element in the ECU Configuration Parameter Definition
dThe refvalue function shall result in an error if the EcucDefinitionElement points
to a not existing element in the ECU Configuration Parameter Definition.c()
[TPS_ECUC_06020] Output of the refvalue function if no element in the ECU Con-
figuration Value description is found dThe refvalue function shall return an empty
set if the EcucDefinitionElement points to an existing element in the ECU Config-
uration Parameter Definition but no element in the ECU Configuration Value description
has been found.c()
[TPS_ECUC_06021] Input and Output of the deref function dThe deref function
takes two parameters
1. result of another deref function or refvalue function, which is an element set

AUTOSAR CP R22-11
2. reference to a member of the first parameter

and returns the member of the first parameter that is denoted by the second parame-
ter.c()
[TPS_ECUC_06022] Output of the deref function in case the first input parameter
is a reference dIn case the member of the first parameter is a reference the deref
function returns the referenced element as a set.c()
[TPS_ECUC_06023] Cases where the deref function reports an error dThe deref
function shall result in an error if
• the first parameter is an empty set
• the first parameter is a set with more than 1 elements18
• the first parameter contains one element which is a value (e.g. 5)
• second parameter points to a not existing element in the ECU Configuration Pa-
rameter Definition or to the AUTOSAR Schema.
c()
[TPS_ECUC_06024] Input of the value function dThe value function takes the result
of a deref function or refvalue function, which is an element set.c()
[TPS_ECUC_06025] Output of the value function dThe value function returns the
parameter’s value as numerical value.c()
[TPS_ECUC_06026] Cases where the value function reports an error dThe value
function shall result in an error if
• the parameter is an empty set
• the parameter is a set with more than 1 elements19
• the parameter’s single element does not have a value (e.g. is a container)
c()
[TPS_ECUC_06057] Input of the strValue function dThe strValue function takes the
result of a deref function or refvalue function, which is an element set.c()
[TPS_ECUC_06058] Output of the strValue function dThe strValue function returns
the parameter’s value as string.c()
[TPS_ECUC_06059] Cases where the strValue function reports an error dThe str-
Value function shall result in an error if
18
The deref function shall only be applied to element sets which are guaranteed to contain only up to
1 element.
19
The value function shall only be applied to element sets which are guaranteed to contain only up to
1 element.

AUTOSAR CP R22-11
• the parameter is a set with more than 1 elements20

c()
[TPS_ECUC_06060] Input of the valueAt function dThe valueAt function takes the
result of a deref function or refvalue function, which is an element set and a zero-based
position argument.c()
[TPS_ECUC_06061] Output of the valueAt function dThe valueAt function returns
the value of the parameter as numerical value at the position according to the sorting
criteria defined in section xxxc()
[TPS_ECUC_06062] Cases where the valueAt function reports an error dThe val-
ueAt function function shall result in an error if
• the parameter is a set with more than 1 elements
• the position is larger than the count-1
c()
[TPS_ECUC_06063] Input of the strValueAt function dThe strValueAt function takes
the result of a deref function or refvalue function, which is an element set and a zero-
based position argument.c()
[TPS_ECUC_06064] Output of the strValueAt function dThe strValueAt function
returns the value of the parameter as string at the position according to the sorting
criteria defined in section x.x.x.c()
[TPS_ECUC_06065] Cases where the strValueAt function reports an error dThe
strValueAt function function shall result in an error if
• the parameter is a set with more than 1 elements
• the position is larger than the count-1
c()
[TPS_ECUC_06027] Input of the count function dThe count function gets the result
of the deref or refvalue function as input parameter.c()
[TPS_ECUC_06028] Output of the count function dThe count function returns the
number of elements in the input parameter set.c()
20
The strValue function shall only be applied to element sets which are guaranteed to contain only up
to 1 element.

AUTOSAR CP R22-11
[TPS_ECUC_06029] Output of the count function in case the input parameter set
is empty dThe count function returns zero if the input parameter set is empty.c()
In order to find the referenced element in the ECUC Value description the reference
to the EcucDefinitionElement needs to be traced. If the complete ECUC Value
description needs to be searched a global reference (configElementDefGlobal)
shall be used. If the search is executed inside of the same module a local reference (
configElementDefLocal) is sufficient.
The following section shows the EcucQueryExpression syntax:
ecuQueryExpr : (valueExpr|stringValueExpr|valueAtExpr|stringValueAtExpr|countExpr);
valueExpr : ’value(’(derefExpr | refValueExpr) ’)’;
stringValueExpr : ’strValue(’(derefExpr | refValueExpr) ’)’;
valueAtExpr : ’valueAt(’(derefExpr | refValueExpr) ’,’ index ’)’
stringValueAtExpr : ’strValueAt(’(derefExpr | refValueExpr) ’,’ index ’)’
countExpr : ’count(’(derefExpr | refValueExpr) ’)’;
refValueExpr : ’refvalue(’ refExpr ’)’;
derefExpr : ’deref(’(derefExpr| refValueExpr) ’,’ refString ’)’;
refExpr : (localRef | globalRef);
localRef : ’<CONFIG-ELEMENT-DEF-LOCAL-REF DEST="’ NCName* ’">’
refString ’</CONFIG-ELEMENT-DEF-LOCAL-REF>’;
globalRef : ’<CONFIG-ELEMENT-DEF-GLOBAL-REF DEST="’ NCName* ’">’
refString ’</CONFIG-ELEMENT-DEF-GLOBAL-REF>’;
refString : ’/’NCName(’/’NCName)*;
index: ’0’ | (’1’..’9’)(’0’..’9’)*;
NCName : (Letter) (Letter | (’0’..’9’) | ’_’)*;
Figure 2.19 shows a COM Gateway example where the CheckConsistency boolean
parameter is calculated. This parameter checks the length of the Source Signal and
compares it with the length of the Destination Signal. If the length of both signals is
equal this parameter is set to true, otherwise to false. An XML extract from an ECUC
Parameter Definition file is is shown in example 2.24.

AUTOSAR CP R22-11
ComConfig: EcucParamConfContainerDef
+subContainer
ComGwMapping: EcucParamConfContainerDef checkConsistency:

EcucBooleanParamDef
ComGwSource: ComGwDestination:
EcucChoiceContainerDef EcucChoiceContainerDef
+choice +choice
ComGwSignal: EcucParamConfContainerDef ComBitSize:

EcucIntegerParamDef
+parameter
+reference
ComGwSignalRef: +destination ComSignal: EcucParamConfContainerDef

EcucReferenceDef
Figure 2.19: Calculation Formula Example
To determine the parameter value the EcucDerivationSpecification within the

CheckConsistency parameter aggregates two EcucQueries.
The first EcucQuery "getSourceSignalLength" contains a EcucQueryExpression
with a local reference to the ComGwSignalRef element. To get the signal length from
the referenced ComGwSignal two deref functions are used. The first deref function
takes the reference to the ComGwSignalRef element as input and returns the ComG-
wSignal that is searched by the second input parameter. The second deref function
takes the ComGwSignal as the first input parameter and the reference to the searched
ECUC parameter within the ComGwSignal as the second input parameter and returns
the ComBitSize parameter. The value of the ComBitSize parameter is provided by
the value function.
To find the right source signal in the ECUC Value description the biggest common prefix
from the local reference and from the CheckConsistency parameter path is used as
entry point to the ECUC Value description. In this example the biggest common prefix
is the following path: /AUTOSAR/EcucDefs/Com/ComConfig/ComGwMapping/.
The second EcucQuery "getDestinationSignalLength" provides the ComBitSize Pa-
rameter Value of the destination Signal accordingly.

AUTOSAR CP R22-11
The CalculationFormula compares both values and determines the value for the
CheckConsistency parameter. The corresponding ECUC Value description XML file
extract is shown in example 2.24.
Example 2.24
<ECUC-MODULE-DEF>
<CONTAINERS>
<SHORT-NAME>ComConfig</SHORT-NAME>
<SUB-CONTAINERS>
<PARAMETERS>
<SHORT-NAME>CheckConsistency</SHORT-NAME>
<DERIVATION>
<CALCULATION-FORMULA>
(<ECUC-QUERY-REF DEST="ECUC-QUERY">getSourceSignalLength</ECUC-QUERY-REF>
==
<ECUC-QUERY-REF DEST="ECUC-QUERY">
getDestinationSignalLength</ECUC-QUERY-REF>)
</CALCULATION-FORMULA>
<ECUC-QUERYS>
<ECUC-QUERY>
<SHORT-NAME>getSourceSignalLength</SHORT-NAME>
<ECUC-QUERY-EXPRESSION>
value(
deref(
deref(
refvalue(<CONFIG-ELEMENT-DEF-LOCAL-REF DEST="ECUC-REFERENCE-DEF">/AUTOSAR/
EcucDefs/Com/ComConfig/ComGwMapping/ComGwSource/ComGwSignal/
ComGwSignalRef</CONFIG-ELEMENT-DEF-LOCAL-REF>),
/AUTOSAR/EcucDefs/Com/ComConfig/ComGwMapping/ComGwSource/ComGwSignal/
ComGwSignalRef),
/ComBitSize)
)
</ECUC-QUERY-EXPRESSION>
</ECUC-QUERY>
<ECUC-QUERY>
<SHORT-NAME>getDestinationSignalLength</SHORT-NAME>
value(
deref(
deref(
EcucDefs/Com/ComConfig/ComGwMapping/ComGwDestination/ComGwSignal/
/AUTOSAR/EcucDefs/Com/ComConfig/ComGwMapping/ComGwDestination/ComGwSignal/
ComGwSignalRef),
/ComBitSize)
)
</ECUC-QUERY>
</ECUC-QUERYS>

AUTOSAR CP R22-11
</DERIVATION>
</PARAMETERS>
</SUB-CONTAINERS>
</CONTAINERS>
</ECUC-MODULE-DEF>
The next example 2.25 shows the usage of the count operation. Within the COM mod-
ule an Integer Parameter countNoOfCanDrv is introduced which counts the available
CanDrv modules. To cover all CanDrv modules a global reference is used.
Example 2.25
<ECUC-MODULE-DEF>
<CONTAINERS>
<PARAMETERS>
<SHORT-NAME>numberOfCanDrivers</SHORT-NAME>
<DERIVATION>
<ECUC-QUERY-REF DEST="ECUC-QUERY">countNoOfCanDrv</ECUC-QUERY
-REF>
<ECUC-QUERYS>
<ECUC-QUERY>
<SHORT-NAME>countNoOfCanDrv</SHORT-NAME>
count(
refvalue(<CONFIG-ELEMENT-DEF-GLOBAL-REF DEST="ECUC-MODULE-DEF">/AUTOSAR/
EcucDefs/Can</CONFIG-ELEMENT-DEF-GLOBAL-REF>)
)
</ECUC-QUERY>
</ECUC-QUERYS>
</DERIVATION>
</PARAMETERS>
</CONTAINERS>
</ECUC-MODULE-DEF>
A third example 2.20 shows a reference into the System Description. The referenced
ComSignal contains a ForeignReference into the System Template (SystemTem-
plateSystemSignalRef). The searched startPosition attribute is defined in the Sys-
tem Template and describes a bitposition of a SystemSignal within a PDU.

AUTOSAR CP R22-11
To get the value of this attribute three deref functions are used. The first deref func-
tion provides the ComSignal. The second deref function provides the ISignalToP-
duMapping element of the System Description and the third deref function returns
the startPosition attribute of the ISignalToPduMapping element. The attribute
value is provided by the value function and is used in the calculation formula.
ComConfig: EcucParamConfContainerDef
+subContainer
ComGwMapping: EcucParamConfContainerDef
ComSignal: +reference SystemTemplateSystemSignalRef:

ComGwSource: ComGwDestination: EcucForeignReferenceDef
EcucChoiceContainerDef EcucParamConfContainerDef
EcucChoiceContainerDef
destinationType = I-SIGNAL-TO-I-PDU-MAPPING
lowerMultiplicity = 1 +destination
+choice +choice
System Description Template
ComGwSignal: EcucParamConfContainerDef +reference ComGwSignalRef:
EcucReferenceDef
Identifiable
ISignalToIPduMapping
+ packingByteOrder: ByteOrderEnum [0..1]

+ startPosition: UnlimitedInteger [0..1]
+ transferProperty: TransferPropertyEnum [0..1]
+ updateIndicationBitPosition: UnlimitedInteger [0..1]
Figure 2.20: Calculation Formula Example
Example 2.26
<ECUC-MODULE-DEF>
<CONTAINERS>
<SUB-CONTAINERS>
<PARAMETERS>
<SHORT-NAME>startPositionBits</SHORT-NAME>
<DERIVATION>
<ECUC-QUERY-REF DEST="ECUC-QUERY">
getSourceSignalStartPosition</ECUC-QUERY-REF>* 8
<ECUC-QUERYS>
<ECUC-QUERY>
<SHORT-NAME>getSourceSignalStartPosition</SHORT-NAME>
value(

AUTOSAR CP R22-11
deref(
deref(
deref(
EcucDefs/Com/ComConfig/ComGwMapping/ComGwSource/ComGwSignal/
/AUTOSAR/EcucDefs/Com/ComConfig/ComGwMapping/ComGwSource/ComGwSignal/
ComGwSignalRef),
/SystemTemplateSystemSignalRef),
/SystemTemplateSystemSignalRef),
/startPosition)
)
</ECUC-QUERY>
</ECUC-QUERYS>
</DERIVATION>
</PARAMETERS>
</SUB-CONTAINERS>
</CONTAINERS>
</ECUC-MODULE-DEF>

AUTOSAR CP R22-11
2.3.7.2 Restrictions on Configuration Class of Derived Parameters
Derived Parameters have to be defined similar to plain configuration parameters which

means that also the configuration class has to be specified in the actual implementation
of the configuration. But since derived parameters do depend on other information
there are certain restrictions applicable which reduce the degree of freedom what kind
of configuration class a derived parameter might be.
If the derived parameter is derived from other Configuration Parameters in the ECU
Configuration Value description then certain rules have to be applied:
• [TPS_ECUC_02058] Derivation of information from PreCompile parameters
d If the derived parameter uses information from parameters defined as PreCom-
pile, then the derived parameter can be of any configuration class.c()
• [TPS_ECUC_02056] Derivation of information from Link parameters d If the
derived parameter uses information from parameters defined as Link, then the
derived parameter shall be of either Link or PostBuild configuration class.c()
• [TPS_ECUC_02057] Derivation of information from PostBuild parameters
d If the derived parameter uses information from parameters defined as Post-
Build, then the derived parameter shall be of PostBuild configuration class.c
()
• [TPS_ECUC_08017] Derivation of information from parameter values bound
at PreCompile time d If the derived parameter uses information from parameter
values which are bound at PreCompile time, then the derived parameter value
can be bound at any time.c()
at Link time d If the derived parameter uses information from parameter values
which are bound at Link time, then the derived parameter value shall be bound
at either Link or PostBuild time.c()
at PostBuild time d If the derived parameter uses information from parameter
values which are bound at PostBuild time, then the derived parameter value
shall be bound at PostBuild time.c()
2.3.8 Existence dependence of ECUC Parameter Definition elements
ECUC Parameter Values can be calculated from other parameter values that are avail-
able in other sections of the ECU Configuration. Such derived configuration parameters
are described in detail in chapter 2.3.7. But also the existence of a ECUC Container,
Parameter and Reference definition elements can depend on the setting of ECUC Pa-
rameter Values. Such it is for example possible to define parameters that are only
considered if a specific switch parameter is set to a certain value. Otherwise these
parameters are ignored.

AUTOSAR CP R22-11
Identifiable AtpDefinition
EcucEnumerationLiteralDef Identifiable +configElementDefLocal
EcucDefinitionElement «atpMixedString»
+ origin: String [0..1] 0..1 «atpUriDef» EcucQueryExpression
+ scope: EcucScopeEnum [0..1]
«atpVariation» +configElementDefGlobal
+ lowerMultiplicity: PositiveInteger [0..1] «atpUriDef»
0..1
+ upperMultiplicity: PositiveInteger [0..1] +ecucQueryExpression 0..1
+ upperMultiplicityInfinite: Boolean [0..1]
+ecucCond 0..1
+ecucCond 0..1
Identifiable
EcucConditionSpecification
+ecucQuery EcucQuery
0..*
+ecucQuery 0..1 +ecucQueryString 0..1

{subsets {subsets
atpReference} atpStringReference}
+informalFormula 0..1 +conditionFormula 0..1

Paginateable FormulaExpression
MlFormula EcucConditionFormula
Figure 2.21: Existence dependence of parameter definitions and literal definitions
[constr_3585] EcucConditionFormula.ecucQuery always required dThe at-

tribute EcucConditionFormula.ecucQuery shall always be defined when the ECU
Configuration Parameter definition is complete.c()
[constr_3586] EcucConditionFormula.ecucQueryString always required
dThe attribute EcucConditionFormula.ecucQueryString shall always be defined
when the ECU Configuration Parameter definition is complete.c()
To allow the description of such existence dependencies the EcucDefinitionEle-
ment and the EcucEnumerationLiteralDef aggregate the EcucCondition-
Specification. The EcucConditionSpecification aggregates an Ecuc-
ConditionFormula or a informal Calculation Formula (MlFormula). If the Ecuc-
ConditionFormula evaluates to true the parameter definition/literal definition shall
be processed as specified. Otherwise the parameter definition/literal definition shall be
ignored. The informal Calculation Formula (MlFormula) can be used for the same
purpose. But here, the rules how the condition is evaluated are not defined.
An EcucQuery to the ECU Configuration Value Description serves as an argument
for the EcucConditionFormula. Due the atpMixedString nature of the Ecuc-
ConditionFormula several EcucQueries can be defined within an EcucCondi-
tionFormula.
An EcucQuery is Identifiable and aggregates one EcucQueryExpression.
The EcucQueryExpression outputs the result as a numerical value. The Ecuc-
QueryExpression syntax is described in chapter 2.3.7.1.

AUTOSAR CP R22-11
Class EcucConditionSpecification
Note Allows to define existence dependencies based on the value of parameter values.
Base ARObject
Aggregated by EcucDefinitionElement.ecucCond, EcucEnumerationLiteralDef.ecucCond
condition EcucConditionFormula 0..1 aggr Definition of the formula used to define existence
Formula dependencies.
informalFormula MlFormula 0..1 aggr Informal description of the condition used to to define
existence dependencies.
Table 2.45: EcucConditionSpecification
Class <<atpMixedString>> EcucConditionFormula

Note This formula shall yield a boolean expression depending on ecuc queries. Note that the EcucCondition
Formula is a mixed string. Therefore, the properties have the upper multiplicity 1.
Base ARObject, FormulaExpression
Aggregated by EcucConditionSpecification.conditionFormula, EcucValidationCondition.validationFormula
ecucQuery EcucQuery 0..1 ref The EcucQuery serves as a argument for the formula.
ecucQuery EcucQuery 0..1 ref This indicates that the referenced query shall return a
String string.
Table 2.46: EcucConditionFormula
In the following example in figure 2.22 – taken from the Can Interface module – a
possible usage of the condition formula is shown.
CanIf: EcucModuleDef
+container
CanIfPrivateCfg: +parameter CanIfPrivateDataLengthCheck:

EcucParamConfContainerDef EcucBooleanParamDef
defaultValue = True
+parameter CanIfSupportTTCAN:
EcucBooleanParamDef
defaultValue = FALSE
CanIfTTGeneral:
+subContainer
Figure 2.22: Example for condition formula
The container CanIfPrivateCfg contains 2 parameters and one sub container. The
use case is to make the existance of the container CanIfTTGeneral dependent on
the value configured in the parameter CanIfSupportTTCAN. If the value of CanIf-
SupportTTCAN is set to true the container CanIfTTGeneral and its content shall

AUTOSAR CP R22-11
be available for configuration. If the value of CanIfSupportTTCAN is set to false

the container CanIfTTGeneral shall not be considered for configuration.
Example 2.27
<ECUC-MODULE-DEF>
<SHORT-NAME>CanIf</SHORT-NAME>
<CONTAINERS>
<SHORT-NAME>CanIfPrivateCfg</SHORT-NAME>
<PARAMETERS>
<SHORT-NAME>CanIfPrivateDlcCheck</SHORT-NAME>

<SHORT-NAME>CanIfSupportTTCAN</SHORT-NAME>
<DEFAULT-VALUE>false</DEFAULT-VALUE>
</PARAMETERS>
<SUB-CONTAINERS>
<SHORT-NAME>CanIfTTGeneral</SHORT-NAME>
<ECUC-COND>
<CONDITION-FORMULA>
<ECUC-QUERY-REF DEST="ECUC-QUERY">GetTTCanEnabled</ECUC-QUERY
-REF>
</CONDITION-FORMULA>
<ECUC-QUERYS>
<ECUC-QUERY>
<SHORT-NAME>GetTTCanEnabled</SHORT-NAME>
value(
refvalue(<CONFIG-ELEMENT-DEF-LOCAL-REF DEST="ECUC-BOOLEAN-PARAM-DEF">/
AUTOSAR/EcucDefs/CanIf/CanIfPrivateCfg/CanIfSupportTTCAN</CONFIG-
ELEMENT-DEF-LOCAL-REF>)
)
</ECUC-QUERY>
</ECUC-QUERYS>
</ECUC-COND>
<PARAMETERS>

</PARAMETERS>
</SUB-CONTAINERS>

AUTOSAR CP R22-11
</CONTAINERS>
</ECUC-MODULE-DEF>
The condition formula is part of the CanIfTTGeneral container definition (see exam-
ple 2.27). The formula itself is pretty simple, it just returns the value of the EcucQuery
with the name GetTTCanEnabled.
The EcucQuery looks for an element in the ECU Configuration Value description
which matches the definition
(/AUTOSAR/EcucDefs/CanIf/CanIfPrivateCfg/CanIfSupportTTCAN)
in the local context using the refvalue function.
The EcucQuery then takes the value of the element and returns. Since the element is
of boolean type the result of the EcucQuery is already a boolean value which can be
processed by the condition formula.
2.3.9 Validation conditions
In order to describe validity constrains on a configuration element the ecucValida-

tionCond can define a set of EcucValidationConditions which can be aggre-
gated by any subclass of EcucDefinitionElement.
[TPS_ECUC_02135] Validation of EcucValidationCondition dAn EcucVali-
dationCondition of an EcucDefinitionElement is considered valid if the val-
idationFormula of that EcucValidationCondition evaluates to true.c()
[TPS_ECUC_02136] Validation of multiple EcucValidationConditions dA con-
figuration of an EcucDefinitionElement is considered valid if all of the defined
ecucValidationConds of that EcucDefinitionElement are valid.c()

AUTOSAR CP R22-11
AtpDefinition
Identifiable +configElementDefGlobal
EcucDefinitionElement «atpMixedString»
0..1 «atpUriDef»
+ scope: EcucScopeEnum [0..1] EcucQueryExpression
«atpVariation» +configElementDefLocal
+ lowerMultiplicity: PositiveInteger [0..1]
+ upperMultiplicity: PositiveInteger [0..1] 0..1 «atpUriDef»
+ upperMultiplicityInfinite: Boolean [0..1] +ecucQueryExpression 0..1
+ecucValidationCond 0..*
Identifiable
EcucValidationCondition
+validationFormula 0..1 +ecucQuery 0..*

FormulaExpression +ecucQuery Identifiable
EcucConditionFormula 0..1 EcucQuery
{subsets
atpReference}
+ecucQueryString
0..1
{subsets
atpStringReference}
Figure 2.23: Validation condition
[constr_3587] EcucValidationCondition.validationFormula always re-

quired dThe attribute EcucValidationCondition.validationFormula shall al-
()
Class EcucValidationCondition
Note Validation condition to perform a formula calculation based on EcucQueries.
Aggregated by EcucDefinitionElement.ecucValidationCond
validation EcucConditionFormula 0..1 aggr Definition of the formula used to define validation
Formula condition.
Table 2.47: EcucValidationCondition
2.3.10 Multiple aggregation of full container trees that include references
The ECU Configuration Parameter Definitions UML model may define an EcucCon-
tainerDef that is aggregated by different EcucParamConfContainerDefs in the
role subContainer. In case that the subContainer contains references then some
rules apply that are described in the following:
[TPS_ECUC_06089] Multiple aggregation of container trees that include refer-
ences to other subContainers in the same aggregated container tree dIn case an

AUTOSAR CP R22-11
EcucParamConfContainerDef is aggregated by different EcucParamConfCon-

tainerDefs in the role subContainer and this aggregated subContainer has
an EcucReferenceDef to another subContainer located in the same aggregated
EcucParamConfContainerDef structure, then the DESTINATION-REF (in the gen-
erated ECU Configuration Parameter Definition XML file) of the EcucReferenceDef
shall include the shortName path back to the aggregating EcucParamConfCon-
tainerDef in the PATH of the DESTINATION-REF.c()
The following example explains [TPS_ECUC_06089]: ContainerB and ContainerC are
aggregating the same SubContainerA in the ECU Configuration Parameter Definitions
UML model:
ContainerB: ContainerC:
ContainerA: EcucParamConfContainerDef
+subContainer ContainerA1: +reference ContainerA2Ref:

EcucParamConfContainerDef EcucReferenceDef
+subContainer ContainerA2: +destination

Figure 2.24: Example for multiple aggregation of container trees
The resulting AUTOSAR_MOD_ECUConfigurationParameters.arxml will be defined as

follows (simplified). Please note that the PATH of the DESTINATION-REF is different
in both ContainerB and ContainerC.
<CONTAINERS>
<SHORT-NAME>ContainerB</SHORT-NAME>
<SUB-CONTAINERS>
<SHORT-NAME>ContainerA</SHORT-NAME>
<SUB-CONTAINERS>
<SHORT-NAME>ContainerA1</SHORT-NAME>
<REFERENCES>

AUTOSAR CP R22-11
<SHORT-NAME>ContainerA2Ref</SHORT-NAME>
<SCOPE>LOCAL</SCOPE>
<DESTINATION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">/
AUTOSAR/EcucDefs/ExampleModule/ContainerB/ContainerA/
ContainerA2</DESTINATION-REF>
</REFERENCES>
</SUB-CONTAINERS>
</SUB-CONTAINERS>
<SHORT-NAME>ContainerC</SHORT-NAME>
<SUB-CONTAINERS>
<SHORT-NAME>ContainerA</SHORT-NAME>
<SUB-CONTAINERS>
<REFERENCES>
<SHORT-NAME>ContainerA2Ref</SHORT-NAME>
AUTOSAR/EcucDefs/ExampleModule/ContainerC/ContainerA/
ContainerA2</DESTINATION-REF>
</REFERENCES>
</SUB-CONTAINERS>
</SUB-CONTAINERS>

AUTOSAR CP R22-11
</CONTAINERS>
Listing 2.1: Example for multiple aggregation of container trees in ECU Configuration
Definition ARXML file
[constr_5345] Restriction for a reference destination in case of multiple ag-

gregated EcucParamConfContainerDefs dAn EcucReferenceDef or Ecuc-
ChoiceReferenceDef is not allowed to reference an EcucParamConfContain-
erDef as destination if
• this EcucParamConfContainerDef is aggregated by several EcucParam-
ConfContainerDefs as subContainer and
• the EcucParamConfContainerDef structures in which the referenced Ecuc-
ParamConfContainerDef is aggregated are different compared to the Ecuc-
ParamConfContainerDef structure in which the EcucReferenceDef or
EcucChoiceReferenceDef is located in.
c()

AUTOSAR CP R22-11
2.4 ECU Configuration Value Metamodel

As mentioned in section 2.2 the ECU Configuration Definition metamodel provides the
means to declare the parameters and their permitted occurrences within a configura-
tion file. This section will specify the complement to that ECU Configuration Parameter
Definition on the actual Value description side, namely the ECU Configuration Value
description.
The following sections will depict the ECU Configuration Value metamodel. Sections
2.4.1 and 2.4.2 will introduce the top-level structure of a configuration Value descrip-
tion and the module configurations, whereas the sections 2.4.3, 2.4.4 and 2.4.5 will
describe the means to file and structure the actual configuration values.
2.4.1 ECU Configuration Value Top-Level Structure
The top-level entry point to an AUTOSAR ECU Configuration Value description is the
EcucValueCollection (see figure 2.25). Because of the inheritance from AREle-
ment the EcucValueCollection can be part of an AUTOSAR description like its
counterpart the EcucDefinitionCollection does. Please note that the Ecuc-
ValueCollection and the EcucDefinitionCollection are independent from
each other.
ECU Configuration Parameter Definition ECU Configuration Parameter Values
ARElement ARElement
ARElement
AtpBlueprint AtpStructureElement
EcucValueCollection +ecuExtract
AtpBlueprintable System
EcucDefinitionCollection 0..1
+ containerIPduHeaderByteOrder: ByteOrderEnum [0..1]
+ ecuExtractVersion: RevisionLabelString [0..1]
+ pncVectorLength: PositiveInteger [0..1]
+ pncVectorOffset: PositiveInteger [0..1]
«atpVariation,atpSplitable» + systemVersion: RevisionLabelString
+module 0..*
ARElement +ecucValue 0..*

AtpBlueprint
ARElement
AtpBlueprintable +definition
EcucDefinitionElement EcucModuleConfigurationValues
0..1
EcucModuleDef + ecucDefEdition: RevisionLabelString [0..1]
+ implementationConfigVariant: EcucConfigurationVariantEnum [0..1]
+ postBuildVariantUsed: Boolean [0..1]
+container 0..*
«atpSplitable»
+container 0..* EcucIndexableValue +subContainer 0..*
+definition Identifiable
EcucDefinitionElement «atpVariation,atpSplitable»
EcucContainerValue
EcucContainerDef 0..1
+ origin: String [0..1] +moduleDescription 0..1

+ requiresIndex: Boolean [0..1] «enumeration» Implementation
EcucConfigurationVariantEnum BswImplementation
PreconfiguredConfiguration + arReleaseVersion: RevisionLabelString [0..1]

RecommendedConfiguration + vendorApiInfix: Identifier [0..1]
VariantPreCompile
VariantLinkTime
VariantPostBuild
Figure 2.25: ECU Configuration Value Top-Level Structure

AUTOSAR CP R22-11
[TPS_ECUC_02151] Existence of EcucValueCollection.ecucValue d An Ecuc-

ValueCollection without any EcucModuleConfigurationValues has no effect
on the Ecu configuration and should not occur at code generation time.c()
[constr_3588] EcucValueCollection.ecuExtract always required dThe at-
tribute EcucValueCollection.ecuExtract shall always be defined at code gen-
eration time.c()
[constr_3589] EcucModuleConfigurationValues.ecucDefEdition always re-
quired dThe attribute EcucModuleConfigurationValues.ecucDefEdition shall
always be defined at code generation time.c()
[constr_3590] EcucModuleConfigurationValues.implementationConfig-
Variant always required dThe attribute EcucModuleConfigurationValues.im-
plementationConfigVariant shall always be defined at code generation time.c
()
[constr_3591] EcucModuleConfigurationValues.definition always re-
quired dThe attribute EcucModuleConfigurationValues.definition shall al-
ways be defined at code generation time.c()
[TPS_ECUC_02152] EcucModuleConfigurationValues.container d An Ecuc-
ModuleConfigurationValues without any EcucContainerValue has no effect
on the Ecu configuration and should not occur at code generation time.c()
A valid EcucValueCollection needs to reference the System description (provided
as an ecuExtract) [2] that specifies the environment in which the configured ECU
operates. Additionally it references all Software Module configurations (see section
2.4.2) that are part of this ECU Configuration. It shall be noted that several EcucVal-
ueCollections are allowed in the context of one ecuExtract.
Class EcucValueCollection
Package M2::AUTOSARTemplates::ECUCDescriptionTemplate
Note This represents the anchor point of the ECU configuration description.
Tags:atp.recommendedPackage=EcucValueCollections
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
ecucValue EcucModule * ref References to the configuration of individual software
ConfigurationValues modules that are present on this ECU.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=ecucValue.ecucModuleConfigurationValues,
ecucValue.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
ecuExtract System 0..1 ref Represents the extract of the System Configuration that is
relevant for the ECU configured with that ECU
Configuration Description.
Table 2.48: EcucValueCollection

AUTOSAR CP R22-11
[TPS_ECUC_02141] Variable reference EcucValueCollection.ecucValue d The

reference EcucValueCollection.ecucValue is subject to variant handling. The
existence can be evaluated using the variant handling mechanism.c(RS_ECUC_-
00079)
2.4.2 Module Configurations
[TPS_ECUC_03016] EcucModuleConfigurationValues properties d The Ecuc-

ModuleConfigurationValues subsumes all configuration objects that belong to
one managed Software Module, namely Application Software Components, BSW mod-
ules, RTE and generic ECU Configuration artifacts (e.g. memory maps).c()
[TPS_ECUC_02089] The content of EcucModuleConfigurationValues is
splitable among several XML-Files d The EcucModuleConfigurationValues
aggregates the EcucContainerValue with the role container and the stereotype
atpSplitable which allows the content of a EcucModuleConfigurationVa-
lues to be split among several XML-Files.c()
[TPS_ECUC_02119] Variable existence of container on value side d The aggre-
gated container is subject to variant handling. The existence can be evaluated using
the variant handling mechanism.c(RS_ECUC_00078)
[TPS_ECUC_03017] EcucModuleConfigurationValues reference to BswIm-
plementation d If the EcucModuleConfigurationValues holds the configura-
tion values of a BSW module, a reference to the according BswImplementation
shall be provided.c()
The reference is established to the BswImplementation because this is the most
detailed information available for the configuration.
[TPS_ECUC_03035] Assignment of EcucModuleConfigurationValues to an
EcucModuleDef d The reference definition assigns the EcucModuleConfigu-
rationValues to the according EcucModuleDef it is depending on.c()
[TPS_ECUC_06066] Order of Container-, Parameter- and Reference-Values d
Container-, Parameter- and Reference-Values shall be ordered according to the
shortName of the parameter definition (which is the last chunk of DEFINITION-REF).c
()
[TPS_ECUC_06067] Sorting criteria for Containers on the Values side d Containers
on the Values side which have the same parameter definition shall be sorted according
to the following criteria: primary sorting criterion is the index. Containers without an
index are to be sorted after the containers with index. Secondary sorting criterion is
the shortName of the EcucContainerValue.c()
[TPS_ECUC_06068] Sorting criteria for References on the Values side d Refer-
ences on the Values side which have the same definition shall be sorted according to

AUTOSAR CP R22-11
the following criteria: primary sorting criterion is the index. Values without an in-
dex are to be sorted after the values with index. Secondary sorting criterion is the
reference value (Base + reference).c()
[TPS_ECUC_06069] Sorting criteria for Parameters on the Values side d Param-
eters on the Values side which have the same definition shall be sorted according to
the following criteria: primary sorting criterion is the index. Parameter values without
an index shall be sorted based on parameter values: secondary sorting criterion is the
parameter value.c()
The index is defined in the EcucIndexableValue class. EcucParameterValue
and EcucAbstractReferenceValue inherit from EcucIndexableValue.
Class EcucIndexableValue (abstract)
Note Used to support the specification of ordering of parameter values.
Base ARObject
Subclasses EcucAbstractReferenceValue, EcucContainerValue, EcucParameterValue
index PositiveInteger 0..1 attr Used to support the specification of ordering of parameter
values.
Table 2.49: EcucIndexableValue
[TPS_ECUC_06072] Container-, Parameter-, and Reference-Values with re-

quiresIndex set to true d Container-, Parameter-, and Reference-Values which have
the requiresIndex set to true in their definition shall provide an index.c()
[TPS_ECUC_03031] EcucModuleDef includes standardized and vendor-specific
parameter definitions d The EcucModuleDef, to which the EcucModuleConfig-
urationValues is associated to, is specified by the implementor of the according
Software Module. Therefore the EcucModuleDef includes standardized as well as
vendor-specific parameter definitions.c()
Class EcucModuleConfigurationValues
Note Head of the configuration of one Module. A Module can be a BSW module as well as the RTE and ECU
Infrastructure.
As part of the BSW module description, the EcucModuleConfigurationValues element has two different
roles:
The recommendedConfiguration contains parameter values recommended by the BSW module vendor.
The preconfiguredConfiguration contains values for those parameters which are fixed by the
implementation and cannot be changed.
These two EcucModuleConfigurationValues are used when the base EcucModuleConfigurationValues
(as part of the base ECU configuration) is created to fill parameters with initial values.
Tags:atp.recommendedPackage=EcucModuleConfigurationValuess
5

AUTOSAR CP R22-11
4
Class EcucModuleConfigurationValues
Element, Referrable
container EcucContainerValue * aggr Aggregates all containers that belong to this module
configuration.
Tags:
atp.Splitkey=container.shortName, container.variation
Point.shortLabel
vh.latestBindingTime=postBuild
definition EcucModuleDef 0..1 ref Reference to the definition of this EcucModule
ConfigurationValues element. Typically, this is a vendor
specific module configuration.
ecucDefEdition RevisionLabelString 0..1 attr This is the version info of the ModuleDef ECUC
Parameter definition to which this values conform to / are
based on.
For the Definition of ModuleDef ECUC Parameters the
AdminData shall be used to express the semantic
changes. The compatibility rules between the definition
and value revision labels is up to the module’s vendor.
implementation EcucConfiguration 0..1 attr Specifies the kind of deliverable this EcucModule
ConfigVariant VariantEnum ConfigurationValues element provides. If this element is
not used in a particular role (e.g. preconfigured
Configuration or recommendedConfiguration) then the
value shall be one of VariantPreCompile, VariantLink
Time, VariantPostBuild.
module BswImplementation 0..1 ref Referencing the BSW module description, which this
Description EcucModuleConfigurationValues element is configuring.
This is optional because the EcucModuleConfiguration
Values element is also used to configure the ECU
infrastructure (memory map) or Application SW-Cs.
However in case the EcucModuleConfigurationValues are
used to configure the module, the reference is mandatory
in order to fetch module specific "common" published
information.
postBuildVariant Boolean 0..1 attr Indicates whether a module implementation has or plans
Used to have (i.e., introduced at link or post-build time) new
post-build variation points. TRUE means yes, FALSE
means no. If the attribute is not defined, FALSE
semantics shall be assumed.
Table 2.50: EcucModuleConfigurationValues
Figure 2.26 depicts the different associations between the EcucModuleConfigu-

rationValues and the Basic Software Module Description. The BswIm-
plementation may specify a vendor specific pre-configured configuration Value de-
scription (preconfiguredConfiguration) that includes the configuration values
already assigned by the implementor of the Software Module and a vendor specific
recommended configuration Value description (recommendedConfiguration) that
can be used to initialize configuration editors.

AUTOSAR CP R22-11
ARElement
AtpStructureElement
System

+ systemVersion: RevisionLabelString
+ecuExtract 0..1
ARElement ARElement
AtpBlueprint EcucValueCollection
AtpBlueprintable
«atpUriDef»
+refinedModuleDef
0..1 +module 0..* +ecucValue 0..*
ARElement ARElement
AtpBlueprint EcucModuleConfigurationValues
AtpBlueprintable
EcucDefinitionElement + ecucDefEdition: RevisionLabelString [0..1]
EcucModuleDef + implementationConfigVariant: EcucConfigurationVariantEnum [0..1]
+ postBuildVariantSupport: Boolean [0..1] +definition
0..1
+vendorSpecificModuleDef 0..*
+preconfiguredConfiguration 0..* +recommendedConfiguration 0..*
+moduleDescription 0..1
Implementation
BswImplementation
+ arReleaseVersion: RevisionLabelString [0..1]

+ vendorApiInfix: Identifier [0..1]
Figure 2.26: Dependencies of ModuleConfigurations
[TPS_ECUC_02103] Configuration variant of EcucModuleConfigurationVal-

ues d The implementationConfigVariant specifies which configuration variant
has been chosen for this EcucModuleConfigurationValues. The choice is taken
from the supportedConfigVariant elements specified in the EcucModuleDef
associated to this EcucModuleConfigurationValues. The values preconfig-
uredConfiguration and recommendedConfiguration are for documentation
purposes and cannot be used for code generation.c()
The element supportedConfigVariant is described in section 2.3.2 and section
2.3.4.3.2.
[TPS_ECUC_02147] Introducing new post build variants at post build configu-
ration time dIn order to indicate that post build variants are intended to be added at
post build configuration time in a specific module implementation, postBuildVari-
antUsed of the EcucModuleConfigurationValues shall be set to TRUE.c()
[constr_3449] Impact of postBuildVariantUsed value set to FALSE dIf the
value of the EcucModuleConfigurationValues.postBuildVariantUsed is set
to FALSE or if it is not defined, it is not possible to add a post-build variant at post-build
configuration time.c()
[constr_3450] postBuildVariantUsed value in case of post build Variation-
Points dIf the configuration values of a BSW module contain at least one post build

AUTOSAR CP R22-11
VariationPoint, the value of the postBuildVariantUsed for the EcucModule-

ConfigurationValues shall be set to TRUE.c()
[constr_3451] EcucModuleConfigurationValues.postBuildVariantUsed
value setting restriction in case postBuildVariantSupport is set to TRUE dIf
EcucModuleDef.postBuildVariantSupport is set to TRUE, then EcucModule-
ConfigurationValues.postBuildVariantUsed can be either TRUE or FALSE.c
()
[constr_3452] EcucModuleConfigurationValues.postBuildVariantUsed
value setting restriction in case postBuildVariantSupport is set to FALSE
dIf EcucModuleDef.postBuildVariantSupport is set to FALSE, then EcucMod-
uleConfigurationValues.postBuildVariantUsed shall be FALSE.c()
To illustrate the structure of an ECU Configuration Value description example 2.28
depicts the top-level structure of an ECU Configuration Value description XML file that
conforms to the ECU Configuration Definition XML file that was presented in example
2.6. Please note that it is allowed to have an arbitrary number of packages before a
module package definition (e.g. /AUTOSAR/Ecuc_VendorX/CanIf/...).
The only supportedConfigVariant of example 2.6 is taken for the implementa-
tionConfigVariant element.
Example 2.28
<AR-PACKAGE>
<SHORT-NAME>ECUC1</SHORT-NAME>
<ELEMENTS>
<ECUC-VALUE-COLLECTION>
<SHORT-NAME>Configuration</SHORT-NAME>
<ECU-EXTRACT-REF DEST="SYSTEM">/some_package/some_path/
theEcuExtractForEcuXY</ECU-EXTRACT-REF>
<ECUC-VALUES>
<ECUC-MODULE-CONFIGURATION-VALUES-REF-CONDITIONAL>
<ECUC-MODULE-CONFIGURATION-VALUES-REF DEST="ECUC-MODULE-
CONFIGURATION-VALUES">/ECUC/theRteConfig</ECUC-MODULE-
CONFIGURATION-VALUES-REF>
</ECUC-MODULE-CONFIGURATION-VALUES-REF-CONDITIONAL>
</ECUC-VALUES>
</ECUC-VALUE-COLLECTION>
<ECUC-MODULE-CONFIGURATION-VALUES>
<SHORT-NAME>theRteConfig</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-MODULE-DEF">/AUTOSAR/EcucDefs/Rte</
DEFINITION-REF>
<IMPLEMENTATION-CONFIG-VARIANT>VARIANT-PRE-COMPILE</IMPLEMENTATION-
CONFIG-VARIANT>
<MODULE-DESCRIPTION-REF DEST="BSW-IMPLEMENTATION">/some_package/
some_path/theUsed_Rte_BSWModuleImplementation</MODULE-DESCRIPTION-
REF>
<CONTAINERS>
<ECUC-CONTAINER-VALUE>
<SHORT-NAME>theGeneration</SHORT-NAME>

AUTOSAR CP R22-11
<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">/AUTOSAR/
EcucDefs/Rte/RteGeneration</DEFINITION-REF>
<SUB-CONTAINERS>

</SUB-CONTAINERS>
</ECUC-CONTAINER-VALUE>
</CONTAINERS>
</ECUC-MODULE-CONFIGURATION-VALUES>
</ELEMENTS>
</AR-PACKAGE>

AUTOSAR CP R22-11
2.4.2.1 Splitable ModuleConfiguration
In the document Generic Structure Template [6] it is specified that the elements of an
aggregation are allowed to be split over several XML files if the relationship is marked
with the stereotype atpSplitable.
The stereotype atpSplitable has been introduced to support the delivery of
one module’s EcucModuleConfigurationValues in several XML files, see also
Autosar Methodology [1] chapter 2.7.8.3 and 2.7.8.4 for use-cases.
Each splitable property (attribute, aggregation, reference) need to be uniquely identifi-
able. This happens usually by shortName. The DEFINITION-REF can also be used.
For example, the EcucParameterValues of an EcucContainerValue are allowed
to be split over several XML files. Each EcucParameterValue is uniquely identifi-
able via the reference to the EcucParameterDef. More details can be found in the
Generic Structure Template [6].
In Example 2.29 a simple definition of a module’s configuration parameters is shown. It
just consists of one container which has two parameters, one parameter defined to be
PRE-COMPILE time configurable and the other parameter is POST-BUILD time config-
urable with respect to both their value and multiplicity. The values and the multiplicities
for these parameters are defined in different process steps and therefore two XML files
can be used to describe both values.
In example 2.30 the value for the PRE-COMPILE time parameter ComSignalLength
is specified, while in example 2.31 the POST-BUILD parameter’s ComSignalInit-
Value value is given.
The XML structure in both EcucModuleConfigurationValues XML files is equivalent with
respect to the packages and containers. In both XML files a container with the name
theSignal is defined. It is up to the configuration tool to merge the content of these
two files into one model. Also is the number of possible XML files not limited, so it
would be possible (although probably not reasonable) to put each parameter value into
one XML file.

AUTOSAR CP R22-11
Example 2.29
<ECUC-MODULE-DEF>
<SUPPORTED-CONFIG-VARIANT>VARIANT-POST-BUILD</SUPPORTED-CONFIG-VARIANT>
<CONTAINERS>
<SHORT-NAME>ComSignal</SHORT-NAME>
<UPPER-MULTIPLICITY>*</UPPER-MULTIPLICITY>
MULTIPLICITY>
<PARAMETERS>
<SHORT-NAME>ComSignalLength</SHORT-NAME>
<SHORT-NAME>ComSignalInitValue</SHORT-NAME>

AUTOSAR CP R22-11
</PARAMETERS>
</CONTAINERS>
</ECUC-MODULE-DEF>
Example 2.30
<SHORT-NAME>theComConfig</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-MODULE-DEF">/AUTOSAR/EcucDefs/Com</DEFINITION-
REF>
<IMPLEMENTATION-CONFIG-VARIANT>VARIANT-POST-BUILD</IMPLEMENTATION-CONFIG-
VARIANT>
theUsed_Com_BSWModuleImplementation</MODULE-DESCRIPTION-REF>
<CONTAINERS>
<SHORT-NAME>theSignal</SHORT-NAME>
EcucDefs/Com/ComSignal</DEFINITION-REF>
<PARAMETER-VALUES>
<ECUC-NUMERICAL-PARAM-VALUE>
<DEFINITION-REF DEST="ECUC-INTEGER-PARAM-DEF">/AUTOSAR/EcucDefs/
Com/ComSignal/ComSignalLength</DEFINITION-REF>
<VALUE>2</VALUE>
</ECUC-NUMERICAL-PARAM-VALUE>
</PARAMETER-VALUES>
</CONTAINERS>
Example 2.31
<SHORT-NAME>theComConfig</SHORT-NAME>
REF>
VARIANT>
theUsed_Com_BSWModuleImplementation</MODULE-DESCRIPTION-REF>
<CONTAINERS>
<SHORT-NAME>theSignal</SHORT-NAME>
EcucDefs/Com/ComSignal</DEFINITION-REF>
<PARAMETER-VALUES>
<DEFINITION-REF DEST="ECUC-INTEGER-PARAM-DEF">/AUTOSAR/EcucDefs/
Com/ComSignal/ComSignalInitValue</DEFINITION-REF>
<VALUE>0</VALUE>
</PARAMETER-VALUES>

AUTOSAR CP R22-11
</CONTAINERS>

AUTOSAR CP R22-11
2.4.3 Parameter Container Description
Symmetrically to the parameter container definition (see section 2.3.3) the parameter
container description is specified to group other containers, parameter values and ref-
erences. Figure 2.27 depicts the general structure of the configuration container Value
description and its association to the configuration definition. The dependencies reflect
the direct relationship between a EcucContainerValue and a EcucContainerDef
as well as a EcucParameterValue and a ParameterType.
EcucDefinitionElement +subContainer 0..*

Identifiable
EcucContainerDef «atpVariation,atpSplitable»
+definition EcucContainerValue
0..1
+subContainer 0..*
«atpSplitable»
EcucChoiceContainerDef +choice EcucParamConfContainerDef EcucIndexableValue
0..* + index: PositiveInteger [0..1]

«atpSplitable»
«atpSplitable»
+parameter 0..* +parameterValue 0..*
EcucParameterValue
EcucParameterDef
+definition
+ isAutoValue: Boolean [0..1]
0..1
Figure 2.27: Parameter container Value description
[constr_3592] EcucContainerValue.definition always required dThe attribute

EcucContainerValue.definition shall always be defined at code generation
time.c()
[constr_3593] EcucParameterValue.definition always required dThe attribute
EcucParameterValue.definition shall always be defined at code generation
time.c()
[TPS_ECUC_03012] EcucContainerValue defines a namespace for all included
containers, parameters and references d The EcucContainerValue inherits from
Identifiable defining a namespace for all EcucContainerValue, EcucParame-
terValue and EcucReferenceValue that belong to that EcucContainerValue.c
()
[TPS_ECUC_08043] The number of EcucContainerValue instances in post-
build time updated ECU configurations dECU configuration tools shall check that

AUTOSAR CP R22-11
the number of EcucContainerValue instances of EcucContainerDefs with Pre-

Compile or Link multiplicityConfigClass.configClass in the Variant-
PostBuild multiplicityConfigClass.configVariant within identical Ecuc-
ContainerValues or EcucModuleConfigurationValuess (the qualified short-
Name path starting from the shortName of the EcucModuleConfigurationValues
is the same) is the same in ECU configurations updated at post-build time.c()
[TPS_ECUC_08044] The number of EcucContainerValue instances in differ-
ent post-build variants dECU configuration tools shall check that the number of
EcucContainerValue instances of EcucContainerDefs with postBuildVari-
antMultiplicity set to false within identical EcucContainerValues or Ecuc-
ModuleConfigurationValuess (the qualified shortName path starting from the
shortName of the EcucModuleConfigurationValues is the same) is the same in
all variation points bound at post-build time.c()
[TPS_ECUC_03019] EcucContainerValue definition reference d The refer-
ence definition assigns the EcucContainerValue to the according EcucCon-
tainerDef21 it is depending on.c()
If the configuration Value description would be provided without an according config-
uration definition an editor could not reconstruct what kind of EcucContainerDef a
EcucContainerValue is based upon.
[TPS_ECUC_03011] EcucContainerDefs with lowerMultiplicity < 1 and the
effect on the corresponding EcucContainerValues d If a EcucContainerDef
has specified a lowerMultiplicity < 1 the corresponding EcucContainerValue
may be omitted in the ECU Configuration Value description because of being treated
as optional.c(RS_ECUC_00055)
21
including all EcucContainerDef’s decendants

AUTOSAR CP R22-11
Class EcucContainerValue
Note Represents a Container definition in the ECU Configuration Description.
Base ARObject, EcucIndexableValue, Identifiable, MultilanguageReferrable, Referrable
Aggregated by EcucContainerValue.subContainer, EcucModuleConfigurationValues.container
definition EcucContainerDef 0..1 ref Reference to the definition of this Container in the ECU
Configuration Parameter Definition.
parameterValue EcucParameterValue * aggr Aggregates all ECU Configuration Values within this
Container.
Tags:
atp.Splitkey=parameterValue, parameterValue.variation
Point.shortLabel
referenceValue EcucAbstractReference * aggr Aggregates all References with this container.
Value
Tags:
atp.Splitkey=referenceValue, referenceValue.variation
Point.shortLabel
subContainer EcucContainerValue * aggr Aggregates all sub-containers within this container.
Tags:
atp.Splitkey=subContainer.shortName, sub
Container.variationPoint.shortLabel
Table 2.51: EcucContainerValue
[TPS_ECUC_02120] Variable subContainers d The aggregated subContainer is

subject to variant handling. The existence can be evaluated using the variant handling
mechanism.c(RS_ECUC_00078)
[TPS_ECUC_02121] Variable parameterValues d The aggregated parameter-
Value is subject to variant handling. The existence can be evaluated using the variant
[TPS_ECUC_02122] Variable referenceValues d The aggregated reference-
Value is subject to variant handling. The existence can be evaluated using the variant
In example 2.32 a snippet of an ECU Configuration Value description XML file is shown
that conforms to the ECU Configuration Parameter Definition described in example
2.7. The container RteGeneration is specified to have an upperMultiplicity
of 1, so there can only be one EcucContainerValue representation. The container

AUTOSAR CP R22-11
SwComponentInstance has an upperMultiplicity of *, so there can be several

representations of this EcucContainerValue.
Example 2.32
<SHORT-NAME>theRteConfig</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-MODULE-DEF">/AUTOSAR/EcucDefs/Rte</DEFINITION-
REF>
<IMPLEMENTATION-CONFIG-VARIANT>VARIANT-PRE-COMPILE</IMPLEMENTATION-CONFIG
-VARIANT>
<MODULE-DESCRIPTION-REF DEST="BSW-IMPLEMENTATION">/some_package/some_path
/theUsed_Rte_BSWModuleImplementation</MODULE-DESCRIPTION-REF>
<CONTAINERS>
<SHORT-NAME>theGeneration</SHORT-NAME>
EcucDefs/Rte/RteGeneration</DEFINITION-REF>
<SUB-CONTAINERS>

</SUB-CONTAINERS>
<SHORT-NAME>SwcInstance1</SHORT-NAME>
EcucDefs/Rte/SwComponentInstance</DEFINITION-REF>
<SUB-CONTAINERS>

</SUB-CONTAINERS>
<SHORT-NAME>SwcInstance2</SHORT-NAME>
EcucDefs/Rte/SwComponentInstance</DEFINITION-REF>
<SUB-CONTAINERS>

</SUB-CONTAINERS>
</CONTAINERS>

AUTOSAR CP R22-11
2.4.3.1 Choice Containers
[TPS_ECUC_03020] EcucChoiceContainerDef on the value side d In the ECU

Configuration Parameter Definition the container choices are specified as part of the
EcucChoiceContainerDef. On the Value side a EcucChoiceContainerDef is
treated as a usual container, though it depends on the upperMultiplicity of the
EcucChoiceContainerDef how often the choice can be taken. Which choice has
been taken is defined by the <DEFINITION-REF> of the <SUB-CONTAINER>.c()
Example 2.33 depicts the notation of a filled out EcucChoiceContainerDef as de-
scribed in example 2.8.
For the myGwSource001 only one choice is possible, in this case the ComGwSignal
has been selected.
For the second part (ComGwDestination) three choices have been taken, myGwDes-
tination021 has chosen ComGwSignal, then myGwDestination022 has cho-
sen ComGwDestinationDescription and then myGwDestination023 has cho-
sen another ComGwSignal again.
Example 2.33
<SHORT-NAME>myChoiceExample</SHORT-NAME>
REF>
<CONTAINERS>
<SHORT-NAME>ComGwMapping001</SHORT-NAME>
EcucDefs/Com/ComGwMapping</DEFINITION-REF>
<SUB-CONTAINERS>
<SHORT-NAME>myGwSource001</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-CHOICE-CONTAINER-DEF">/AUTOSAR/
EcucDefs/Com/ComGwMapping/ComGwSource</DEFINITION-REF>
<SUB-CONTAINERS>
<SHORT-NAME>myGwSource001_1</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">/AUTOSAR
/EcucDefs/Com/ComGwMapping/ComGwSource/ComGwSignal</
DEFINITION-REF>

</SUB-CONTAINERS>
<SHORT-NAME>myGwDestination021</SHORT-NAME>
EcucDefs/Com/ComGwMapping/ComGwDestination</DEFINITION-REF>
<SUB-CONTAINERS>
<SHORT-NAME>myGwDestination021a</SHORT-NAME>

AUTOSAR CP R22-11
/EcucDefs/Com/ComGwMapping/ComGwDestination/ComGwSignal</
DEFINITION-REF>

</SUB-CONTAINERS>
<SUB-CONTAINERS>
/EcucDefs/Com/ComGwMapping/ComGwDestination/
ComGwDestinationDescription</DEFINITION-REF>

</SUB-CONTAINERS>
<SUB-CONTAINERS>
/EcucDefs/Com/ComGwMapping/ComGwDestination/ComGwSignal</
DEFINITION-REF>

</SUB-CONTAINERS>
</SUB-CONTAINERS>
</CONTAINERS>

AUTOSAR CP R22-11
2.4.4 Parameter Values
In the ECU Configuration Parameter Definition exist individual elements for the differ-
ent types of parameters (e.g. Boolean, Integer, String, see section 2.3.5). On the
ECU Configuration Value description side this distinction is no longer needed, because
every parameter value element references the corresponding definition element and
therefore has its type bound.
However there is a different distinction for the parameter values based on the variant
handling implementation (see section 2.3.4.1) and the documentation support (see
section 2.3.5.9).
[TPS_ECUC_03006] EcucParameterValue is the base class for all parameter
values dAll metamodel classes specifying parameter values are derived from Ecuc-
ParameterValue.c()
EcucIndexableValue
+ index: PositiveInteger [0..1]
+subContainer 0..*
EcucCommonAttributes Identifiable
EcucParameterValue
EcucParameterDef +definition +parameterValue EcucContainerValue
+ symbolicNameValue: Boolean [0..1] 0..1 0..*
EcucNumericalParamValue EcucTextualParamValue EcucAddInfoParamValue
«atpVariation» + value: VerbatimString [0..1]

+ value: Numerical [0..1]
+value 0..1
«atpMixed»
DocumentationBlock
Figure 2.28: Parameter description
[constr_3594] EcucNumericalParamValue.value always required dThe attribute

EcucNumericalParamValue.value shall always be defined at code generation
time.c()
[constr_3595] EcucTextualParamValue.value always required dThe attribute
EcucTextualParamValue.value shall always be defined at code generation
time.c()
[constr_3596] EcucAddInfoParamValue.value always required dThe attribute
EcucAddInfoParamValue.value shall always be defined at code generation
time.c()
[TPS_ECUC_03007] Attribute value stores the configuration value in XML-based
description dAll inheriting metamodel classes representing an ECU Configuration

AUTOSAR CP R22-11
Value specify an attribute value that stores the configuration value in XML-based
description.c()
[TPS_ECUC_03038] Assignment of an EcucParameterValue to the correspond-
ing EcucParameterDef dThe reference definition assigns the EcucParame-
terValue22 to the according EcucParameterDef it is providing the value for.c()
[TPS_ECUC_03009] A defaultValue that is specified in the ECU Configuration
Parameter Definition may be used as the initial value in the ECU Configuration
Value description dIf a defaultValue is specified in the ECU Configuration Param-
eter Definition that given value can be used as the initial value of the according
EcucParameterValue for the ECU Configuration Value description as explained by
[TPS_ECUC_01019].c()
[TPS_ECUC_08054] Semantic of an optional parameter that is not present in the
ECU Configuration Value description dThe semantic of an optional parameter that
is not present in the ECU Configuration Value description is that there is no parameter
value available, even if the ECU Parameter Definition provides a default value.c()
[TPS_ECUC_03034] Each parameter in an ECU Configuration Value description
shall have a value dIn a well-formed and completed ECU Configuration Value de-
scription each provided parameter needs to have a value specified even if it is just
copied from the defaultValue of the ECU Configuration Definition.c()
For further rules how a value can be provided if no defaultValue is specified in the
ECU Configuration Definition see section 4.2.
[TPS_ECUC_03010] Parameters that are declared as optional in the ECU Con-
figuration Definition may be left out in the ECU Configuration Value description
dIf an ECU Configuration Parameter has specified a lowerMultiplicity < 1 an
ECU Configuration Value may be left out in the ECU Configuration Value description
because of being treated as optional.c(RS_ECUC_00055)
Class EcucParameterValue (abstract)
Note Common class to all types of configuration values.
Base ARObject, EcucIndexableValue
Subclasses EcucAddInfoParamValue, EcucNumericalParamValue, EcucTextualParamValue
Aggregated by EcucContainerValue.parameterValue
annotation Annotation * aggr Possibility to provide additional notes while defining the
ECU Configuration Parameter Values. These are not
intended as documentation but are mere design notes.
5
22
and all its sub-classes

AUTOSAR CP R22-11
4
Class EcucParameterValue (abstract)
definition EcucParameterDef 0..1 ref Reference to the definition of this EcucParameterValue
subclasses in the ECU Configuration Parameter
Definition.
isAutoValue Boolean 0..1 attr If withAuto is set to "true" for this parameter definition the
isAutoValue can be set to "true". If isAutoValue is set to
"true" the actual value will not be considered during ECU
Configuration but will be (re-)calculated by the code
values.
If isAutoValue is not present the default is "false".
Table 2.52: EcucParameterValue
[TPS_ECUC_08045] The value of EcucParameterValue instances in post-build

time updated ECU configurations dECU configuration tools shall check that the value
of EcucParameterValue instances of EcucParameterDefs with PreCompile or
Link valueConfigClass.configClass in the VariantPostBuild valueCon-
figClass.configVariant within identical EcucContainerValues (the qualified
shortName path starting from the shortName of the EcucModuleConfigura-
tionValues is the same) is the same in ECU configurations updated at post-build
time.c()
[TPS_ECUC_08046] The value of EcucParameterValue instances in different
post-build variants dECU configuration tools shall check that the value of Ecuc-
ParameterValue instances of EcucParameterDefs with postBuildVariant-
Value set to false within identical EcucContainerValues (the qualified short-
Name path starting from the shortName of the EcucModuleConfigurationValues
is the same) is the same in all variation points bound at post-build time.c()
[TPS_ECUC_08047] The number of EcucParameterValue instances in post-
build time updated ECU configurations dECU configuration tools shall check that
the number of EcucParameterValue instances of EcucParameterDefs with Pre-
Compile or Link multiplicityConfigClass.configClass in the Variant-
PostBuild multiplicityConfigClass.configVariant within identical Ecuc-
ContainerValues (the qualified shortName path starting from the shortName of
the EcucModuleConfigurationValues is the same) is the same in ECU configu-
rations updated at post-build time.c()
[TPS_ECUC_08048] The number of EcucParameterValue instances in differ-
ent post-build variants dECU configuration tools shall check that the number of
EcucParameterValue instances of EcucParameterDefs with postBuildVari-
antMultiplicity set to false within identical EcucParameterValues (the qual-
ified shortName path starting from the shortName of the EcucModuleConfigura-
tionValues is the same) is the same in all variation points bound at post-build time.c
()

AUTOSAR CP R22-11
[TPS_ECUC_08002] Introduction of new EcucParamConfContainerDef in-

stances in updated post-build configuration dIf a new EcucParamConfCon-
tainerDef instance is introduced according to the [TPS_ECUC_08000] in an up-
dated post-build configuration, each EcucParameterValue and EcucReference-
Value within that EcucParamConfContainerDef instance and its aggregated
EcucParamConfContainerDefs instanced in the role subContainer may be as-
signed a new value and have arbitrary number of instances (if upperMultiplicity
is greater than lowerMultiplicity) regardless of its valueConfigClass and
multiplicityConfigClass (PreCompile, Link or PostBuild), respectively.c()
Example: HandleId value of an existing ComIPdu shall not be changed at post-build
time as it is link-time configurable. However if a new ComIPdu instance is introduced at
post-build time, it shall receive a new HandleId value. This basically means that val-
ueConfigClass and multiplicityConfigClass are applicable only to parame-
ters and references in container instances which already exist in the initial configuration
before the post-build updates.
[constr_5502] Introduction of new EcucParameterValues of type EcucFunc-
tionNameDef at post-build time dIn case a new EcucParameterValues of type
EcucFunctionNameDef (see [TPS_ECUC_02033]) is introduced at post-build time,
it’s value shall be one of the existing function names (e.g. callouts). This means that it
is not allowed to introduce new functions at post-build time.c()
2.4.4.1 Textual Parameter Value
For the storage of values of parameters which do not have a numerical representation
the element EcucTextualParamValue shall be used.
[TPS_ECUC_02126] Values for parameter types stored in the element EcucTex-
tualParamValue d Values for parameter types
• EcucEnumerationParamDef
• EcucAbstractStringParamDef and its sub-classes
shall be stored in the element EcucTextualParamValue.c()
The actual value is stored in the element value as VerbatimString and shall con-
form to the definition of the ECU Configuration Parameter Definition which is referenced
in the definition element. The restrictions on the textual representation specified
in section 2.3.5.4, section 2.3.5.5, section 2.3.5.6 and section 2.3.5.7 are applicable to
the corresponding value specifications.
In case the value of the EcucTextualParamValue shall be affected by the variant
handling, the existence of the individual alternative EcucTextualParamValue ele-
ments shall be made variant. The value element itself can not be affected by variant
handling.

AUTOSAR CP R22-11
Class EcucTextualParamValue
Note Holding a value which is not subject to variation.
Base ARObject, EcucIndexableValue, EcucParameterValue
value VerbatimString 0..1 attr Value of the parameter, not subject to variant handling.
Table 2.53: EcucTextualParamValue
2.4.4.1.1 Examples of EcucTextualParamValue
Example 2.34 depicts the configuration description of definition type EcucLinker-

SymbolDef for example 2.14.
Example 2.34
<ECUC-TEXTUAL-PARAM-VALUE>
<DEFINITION-REF DEST="ECUC-LINKER-SYMBOL-DEF">/AUTOSAR/EcucDefs/Rte/
Resource/Pim/RtePimInitializationSymbol</DEFINITION-REF>
<VALUE>MyPimInitValuesLightMaster</VALUE>
</ECUC-TEXTUAL-PARAM-VALUE>
Example 2.35 depicts the configuration description of definition type EcucFunction-

NameDef for example 2.15.
Example 2.35
<DEFINITION-REF DEST="ECUC-FUNCTION-NAME-DEF">/AUTOSAR/EcucDefs/Eep/
EepInitConfiguration/EepJobEndNotification</DEFINITION-REF>
<VALUE>Eep_VendorXY_JobEndNotification</VALUE>
Example 2.36 depicts the configuration description of definition type EcucEnumera-

tionParamDef for example 2.16.
Example 2.36
<DEFINITION-REF DEST="ECUC-ENUMERATION-PARAM-DEF">/AUTOSAR/EcucDefs/Rte/
RteGeneration/RteGenerationMode</DEFINITION-REF>
<VALUE>CompatibilityMode</VALUE>

AUTOSAR CP R22-11
2.4.4.2 Numerical Parameter Value
If the value of a configuration parameter shall be provided as subject to variant han-

dling the element EcucNumericalParamValue shall be used. The value element
of EcucNumericalParamValue is defined as <<atpVariation>> (see section
2.3.4.1).
Class EcucNumericalParamValue
Note Holding the value which is subject to variant handling.
value Numerical 0..1 attr Value which is subject to variant handling.
Tags:vh.latestBindingTime=preCompileTime
Table 2.54: EcucNumericalParamValue
[TPS_ECUC_02142] Variable value of EcucNumericalParamValue.value d The

value of EcucNumericalParamValue.value is subject to variant handling.c(RS_-
ECUC_00080)
2.4.4.2.1 Examples of EcucNumericalParamValue
Example 2.37 depicts the configuration description of definition type EcucBoolean-

ParamDef for example 2.11.
Example 2.37
<DEFINITION-REF DEST="ECUC-BOOLEAN-PARAM-DEF">/AUTOSAR/EcucDefs/Rte/
RteGeneration/RTE_DEV_ERROR_DETECT</DEFINITION-REF>
<VALUE>1</VALUE>
Example 2.38 depicts the configuration description of definition type EcucInte-

gerParamDef for example 2.12.
Example 2.38
<DEFINITION-REF DEST="ECUC-FUNCTION-NAME-DEF">/AUTOSAR/EcucDefs/Eep/
EepInitConfiguration/EepJobEndNotification</DEFINITION-REF>
<VALUE>Eep_VendorXY_JobEndNotification</VALUE>

AUTOSAR CP R22-11
Example 2.39 depicts the configuration description of definition type EcucFloat-

ParamDef for example 2.13.
Example 2.39
<DEFINITION-REF DEST="ECUC-FLOAT-PARAM-DEF">/AUTOSAR/EcucDefs/Rte/
RunnableEntityMapping/SchedulingPeriod</DEFINITION-REF>
<VALUE>74.8</VALUE>
2.4.4.3 AddInfo Parameter Value
The only type-specific distinction for the values is the ECU Configuration Parameter
Type EcucAddInfoParamDef (see section 2.3.5.9).
[TPS_ECUC_02123] The value of the parameter type EcucAddInfoParamDef d
The value of the parameter type EcucAddInfoParamDef shall be provided in the
element EcucAddInfoParamValue. This allows the usage of formated text (see
AUTOSAR Generic Structure Template [6] for further information).c()
Class EcucAddInfoParamValue
Note This parameter corresponds to EcucAddInfoParamDef.
value DocumentationBlock 0..1 aggr Holds the content of the formated text.
Table 2.55: EcucAddInfoParamValue
Example 2.40 depicts the configuration description of definition type EcucAddIn-

foParamDef for example 2.17.
Example 2.40
<ECUC-ADD-INFO-PARAM-VALUE>
<DEFINITION-REF DEST="ECUC-ADD-INFO-PARAM-DEF">/AUTOSAR/EcucDefs/Dcm/Dtc<
/DEFINITION-REF>
<VALUE>
<P>
<L-1 L="EN">Description of the Dtc 0815.</L-1>
</P>
</VALUE>
</ECUC-ADD-INFO-PARAM-VALUE>

AUTOSAR CP R22-11
2.4.5 References in the ECU Configuration Metamodel
Figure 2.29 depicts the ECU Configuration Metamodel to reference other description
elements.
MultilanguageReferrable
Identifiable
+ category: CategoryString [0..1]
EcucAbstractReferenceDef + uuid: String [0..1]
+definition
0..1
AtpFeature
+subContainer 0..*
EcucIndexableValue
EcucContainerValue «atpVariation,atpSplitable»
EcucAbstractInternalReferenceDef +value 0..1
+ requiresSymbolicNameValue: Boolean [0..1] «instanceRef»

+referenceValue
EcucIndexableValue
0..*
«atpVariation,atpSplitable» EcucAbstractReferenceValue

EcucAbstractExternalReferenceDef
EcucUriReferenceDef
EcucInstanceReferenceValue
EcucReferenceDef
EcucReferenceValue
EcucInstanceReferenceDef
EcucChoiceReferenceDef
+ destinationContext: String [0..1]
EcucForeignReferenceDef
Figure 2.29: Parameter references
[constr_3597] EcucAbstractReferenceValue.definition always required

dThe attribute EcucAbstractReferenceValue.definition shall always be de-
fined at code generation time.c()
[constr_3598] EcucInstanceReferenceValue.value always required dThe at-
tribute EcucInstanceReferenceValue.value shall always be defined at code
generation time.c()
[constr_3599] EcucReferenceValue.value always required dThe attribute Ecu-
cReferenceValue.value shall always be defined at code generation time.c()
[TPS_ECUC_03032] Generalization of all reference types d The metamodel class
EcucAbstractReferenceValue acts as the generalization of all reference types in
the ECU Configuration Value description.c()

AUTOSAR CP R22-11
[TPS_ECUC_03039] EcucAbstractReferenceValue definition reference d

The reference definition assigns the EcucAbstractReferenceValue23 to the
according EcucAbstractReferenceDef it is depending on.c()
[TPS_ECUC_03030] EcucAbstractReferenceDefs with lowerMultiplicity
< 1 and the effect on the corresponding EcucAbstractReferenceValues d If
a EcucAbstractReferenceDef has specified a lowerMultiplicity < 1 an ac-
cording EcucAbstractReferenceValue may be omitted in the ECU Configuration
Value description because of being treated as optional.c(RS_ECUC_00055)
Class EcucAbstractReferenceValue (abstract)
Note Abstract class to be used as common parent for all reference values in the ECU Configuration
Description.
Base ARObject, EcucIndexableValue
Subclasses EcucInstanceReferenceValue, EcucReferenceValue
Aggregated by EcucContainerValue.referenceValue
annotation Annotation * aggr Possibility to provide additional notes while defining a
model element (e.g. the ECU Configuration Parameter
Values). These are not intended as documentation but
are mere design notes.
definition EcucAbstractReference 0..1 ref Reference to the definition of this EcucAbstractReference
Def Value subclasses in the ECU Configuration Parameter
Definition.
isAutoValue Boolean 0..1 attr If withAuto is set to "true" for this parameter definition the
isAutoValue can be set to "true".
If isAutoValue is set to "true" the actual value will not be
considered during ECU Configuration but will be
(re-)calculated by the code generator and stored in the
value attribute afterwards. These implicit updated values
might require a re-generation of other modules which
reference these values.
If isAutoValue is not present the default is "false".
Table 2.56: EcucAbstractReferenceValue
[TPS_ECUC_03027] EcucReferenceValue provides the mechanism to refer-

ence model elements that are Referrable d The metamodel class EcucRefer-
enceValue provides the mechanism to reference to any model element of type Re-
ferrable.c(RS_ECUC_00072)
[TPS_ECUC_03028] EcucReferenceValue describes EcucReferenceDefs,
EcucChoiceReferenceDefs, and EcucForeignReferenceDefs in the Ecu
Configuration Value description d EcucReferenceValue provides the means to
describe all kinds of reference definitions except an EcucInstanceReferenceDef,
which is described by [TPS_ECUC_03033] in more detail.c()
23
and all its descendants

AUTOSAR CP R22-11
[TPS_ECUC_03029] EcucChoiceReferenceDef translates to a EcucRefer-

enceValue in the ECU Configuration Value description d A EcucChoiceRef-
erenceDef translates to a EcucReferenceValue in the ECU Configuration Value
description because the choice has to be resolved in that description. Therefore no
special configuration Value description type is introduced.c()
Class EcucReferenceValue
Note Used to represent a configuration value that has a parameter definition of type EcucAbstractReference
Def (used for all of its specializations excluding EcucInstanceReferenceDef).
Base ARObject, EcucAbstractReferenceValue, EcucIndexableValue
value Referrable 0..1 ref Specifies the destination of the reference.
Table 2.57: EcucReferenceValue
[TPS_ECUC_08049] The value of EcucAbstractReferenceValue instances in

post-build time updated ECU configurations dECU configuration tools shall check
that the value of EcucAbstractReferenceValue instances of EcucAbstractRe-
ferenceDefs with PreCompile or Link valueConfigClass.configClass in the
VariantPostBuild valueConfigClass.configVariant within identical Ecuc-
ContainerValues (the qualified shortName path starting from the shortName of
the EcucModuleConfigurationValues is the same) is the same in ECU configu-
rations updated at post-build time.c()
[TPS_ECUC_08050] The value of EcucAbstractReferenceValue instances in
different post-build variants dECU configuration tools shall check that the value
of EcucAbstractReferenceValue instances of EcucAbstractReferenceDefs
with postBuildVariantValue set to false within identical EcucContainer-
Values (the qualified shortName path starting from the shortName of the EcucMod-
uleConfigurationValues is the same) is the same in all variation points bound at
post-build time.c()
[TPS_ECUC_08051] The number of EcucAbstractReferenceValue instances
in post-build time updated ECU configurations dECU configuration tools shall
check that the number of EcucAbstractReferenceValue instances of EcucAb-
stractReferenceDefs with PreCompile or Link multiplicityConfigClass.
configClass in the VariantPostBuild multiplicityConfigClass.config-
Variant within identical EcucContainerValues (the qualified shortName path
starting from the shortName of the EcucModuleConfigurationValues is the
same) is the same in ECU configurations updated at post-build time.c()
[TPS_ECUC_08052] The number of EcucAbstractReferenceValue instances
in different post-build variants dECU configuration tools shall check that the number
of EcucAbstractReferenceValue instances of EcucAbstractReferenceDefs
with postBuildVariantMultiplicity set to false within identical EcucParam-
eterValues (the qualified shortName path starting from the shortName of the

AUTOSAR CP R22-11
EcucModuleConfigurationValues is the same) is the same in all variation points

bound at post-build time.c()
[TPS_ECUC_02093] Referenced containers shall be part of the same Ecuc-
ValueCollection as the reference itself d If a EcucAbstractReferenceValue
references a container within some EcucModuleConfigurationValues the refer-
enced container shall be part of a EcucModuleConfigurationValues which is it-
self part of the EcucValueCollection.c()
According to figure 2.25 a EcucModuleConfigurationValues is part of the Ecuc-
ValueCollection if it is referenced with the ecucValue role.
The following examples will picture that EcucReferenceValue can be used to
represent most of the specializations of EcucAbstractReferenceDef (namely
EcucReferenceDef, EcucChoiceReferenceDef, and EcucForeignRefer-
enceDef).
Example 2.41 depicts the configuration description of definition type EcucRefer-
enceDef for example 2.18.
Example 2.41
<ECUC-REFERENCE-VALUE>
<DEFINITION-REF DEST="ECUC-REFERENCE-DEF">/AUTOSAR/EcucDefs/Os/
OsApplication/OsAppScheduleTableRef</DEFINITION-REF>
<VALUE-REF DEST="ECUC-CONTAINER-VALUE">/ECUC/myOs/myOsScheduleTable1</
VALUE-REF>
</ECUC-REFERENCE-VALUE>
Example 2.42 depicts the configuration description of definition type Ecuc-

ChoiceReferenceDef for example 2.19. To illustrate the usage of a Ecuc-
ChoiceReferenceDef in more detail, this example takes advantage of the fact that a
PortPin may be used in several modes at once. Therefore it has multiple references
of different type.
Example 2.42
<DEFINITION-REF DEST="ECUC-CHOICE-REFERENCE-DEF">/AUTOSAR/EcucDefs/Port/
PortPin/PortPinMode</DEFINITION-REF>
<VALUE-REF DEST="ECUC-CONTAINER-VALUE">/ECUC/mySpi/aSpiExternalDevice1</
VALUE-REF>
Example 2.43 depicts the configuration description of definition type EcucForeign-

ReferenceDef for example 2.20.
Example 2.43

AUTOSAR CP R22-11
<DEFINITION-REF DEST="ECUC-FOREIGN-REFERENCE-DEF">/AUTOSAR/EcucDefs/Rte/
Communication/FrameMapping/SystemFrame</DEFINITION-REF>
<VALUE-REF DEST="FRAME">/SystemDescription/SystemFrameNo42</VALUE-REF>
2.4.5.1 Instance Reference Values
Due to the formalization of prototypes in the AUTOSAR Templates (see [6]) the refer-
ence to the instance of a prototype needs to declare the complete context in which the
instance is residing.
[TPS_ECUC_03033] EcucInstanceReferenceValue provides the mechanism
to reference an instance of a prototype d The metamodel class EcucIn-
stanceReferenceValue provides the mechanism to reference to an actual in-
stance of a prototype. This is achieved by specifying a relation with the stereotype
<<instanceRef>>.c(RS_ECUC_00072)
In figure 2.30 the detailed modeling of the EcucInstanceReferenceValue
<<instanceRef>> is specified.
EcucAbstractReferenceValue
EcucInstanceReferenceValue
+value 0..1
AtpInstanceRef
AnyInstanceRef
Figure 2.30: Instance Reference Value details
Class EcucInstanceReferenceValue
Note InstanceReference representation in the ECU Configuration.
Base ARObject, EcucAbstractReferenceValue, EcucIndexableValue
value AtpFeature 0..1 iref InstanceReference representation in the ECU
Configuration.
InstanceRef implemented by:AnyInstanceRef
Table 2.58: EcucInstanceReferenceValue

AUTOSAR CP R22-11
Example 2.44 depicts the configuration description of definition type EcucIn-

stanceReferenceDef for example 2.21. As one can see in the example the ref-
erence value is decomposed of the context path of the instance and the reference to
the instance itself.
Example 2.44
<ECUC-INSTANCE-REFERENCE-VALUE>
<DEFINITION-REF DEST="ECUC-INSTANCE-REFERENCE-DEF">/AUTOSAR/EcucDefs/Rte/
DataMappings/DataSRMapping/DataElementPrototypeRef</DEFINITION-REF>
<VALUE-IREF>
<CONTEXT-ELEMENT-REF DEST="SW-COMPONENT-PROTOTYPE">/DoorFR</CONTEXT-
ELEMENT-REF>
<CONTEXT-ELEMENT-REF DEST="R-PORT-PROTOTYPE">/DoorAntennaReceiver</
CONTEXT-ELEMENT-REF>
<TARGET-REF DEST="VARIABLE-DATA-PROTOTYPE">/AntennaStatus</TARGET-REF>
</VALUE-IREF>
</ECUC-INSTANCE-REFERENCE-VALUE>
The usage of ImplementationDataTypes within an AnyInstanceRef is described

in detail in [6].

AUTOSAR CP R22-11
2.4.5.2 Representation of Symbolic Names
[constr_3217] Symbolic name reference shall point only to containers with a

symbolic name value defined dIf an EcucReferenceValue exists that refers in the
role definition to an EcucAbstractInternalReferenceDef with the attribute
requiresSymbolicNameValue set to true, then the EcucContainerValue that is
the target of the reference shall refer to an EcucParamConfContainerDef in the role
definition that contains a definition of an EcucParameterDef where the attribute
symbolicNameValue exists and is set to true. The EcucContainerValue shall
define an EcucParameterValue that refers to an EcucParameterDef where the
attribute symbolicNameValue exists and is set to true.c()
Note: In other words if a symbolic name reference points to a container this container
shall have a symbolic name value defined.
Please note that [constr_3217] also applies to EcucReferenceValues of Ecu-
cUriReferenceDefs although the target of the reference is determined by matching
destinationUri.
[TPS_ECUC_03037] The shortName of the referenced container provides the
symbolic name in the implementation d The shortName of the referenced des-
tination is expected to be the provided symbolic name in the implementation later
on. Therefore the code generator of the providing module has the responsibility to
associate the provided symbolic name24 to its actual value.c()
[TPS_ECUC_02107] Values of parameters with the symbolicNameValue set to
TRUE that are assigned by the configuration editor or module generator shall
be stored in the XML file d Configuration parameter values which represent symbolic
name values shall be stored in the corresponding XML file after the configuration editor
or module generator assigned the actual value.c()
Example 2.45 depicts the configuration description of definition type EcucRefer-
enceDef with requiresSymbolicNameValue set to true for example 2.22. To
give a better impression how the referencing mechanism and code generation may
work the EcucModuleConfigurationValues of the using and the providing mod-
ules are shown here.
Example 2.45
<SHORT-NAME>myCorTst</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-MODULE-DEF">/AUTOSAR/EcucDefs/CorTst</
DEFINITION-REF>
<CONTAINERS>
<SHORT-NAME>Dem_PLL_lock_error</SHORT-NAME>
EcucDefs/CorTst/CorTstDemEventParameterRefs</DEFINITION-REF>
<REFERENCE-VALUES>
24
The one that is referenced to

AUTOSAR CP R22-11
<DEFINITION-REF DEST="ECUC-REFERENCE-DEF">/AUTOSAR/EcucDefs/
CorTst/CorTstDemEventParameterRefs/CORTST_E_CORE_FAILURE</
DEFINITION-REF>
<VALUE-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">/ECUC/myDem/
CORTST_E_CORE_FAILURE_1</VALUE-REF>
</REFERENCE-VALUES>
</CONTAINERS>
[TPS_ECUC_02108] Rule for the creation of #define symbols in the header

file for parameters with the symbolicNameValue set to TRUE dThe values of
EcucParameterDefs with effective configuration class PreCompile and symbol-
icNameValue set to TRUE shall be generated into the header file of the declaring
module as #defines. The symbol shall be composed of
• either
– the module implementation prefix {Mip} of the declaring BSW Module (ac-
cording to BswModuleList [13])
– or the apiServicePrefix for Complex Driver Modules
– or the apiServicePrefix for Xfrm Modules
• followed by the literal "Conf_" followed by
• the shortName of the EcucParamConfContainerDef of the declaring module
followed by "_" followed by
• the shortName of the EcucContainerValue container which holds the sym-
bolicNameValue configuration parameter value.
c()
Taking the specification requirements above the configuration snippet results in the
according symbolic name definition in the header file of the providing Dem module:
...
#define DemConf_DemEventParameter_CORTST_E_CORE_FAILURE_1 17
...
Especially in case of production error reporting this pattern is used extensively: The
integrator has the freedom to call the DemEventParameter container name arbitrarily.
In general it is reasonable to name the DemEventParameter like the actual production
error (e.g. FLS_E_ERASE_FAILED), however there are use-cases where the same
production error shall be reported for several instances / channels individually, thus it
is required to distinguish between these different production error occurrences (e.g.
FRIF_E_NIT_CH_A_CLUSTER_1 where FRIF_E_NIT_CH_A is the production error
name and _CLUSTER_1 encodes one specific FlexRay cluster). This needs to be kept

AUTOSAR CP R22-11
in mind when accessing the production error symbolic name from the reporting module,
e.g. FrIf shall call:
Dem_SetEventStatus(DemConf_DemEventParameter_FRIF_E_NIT_CH_A_CLUSTER_1,
DEM_EVENT_STATUS_PASSED);
In figure 2.31 another example of a symbolic name value configuration setup is shown.
The example 2.46 shows a possible value description for this definition.
ComMPncComSignal: +reference ComMPncComSignalRef:
lowerMultiplicity = 0 requiresSymbolicNameValue = true

+destination
ComConfig: +subContainer ComSignal: ComHandleId:

EcucParamConfContainerDef EcucParamConfContainerDef +parameter EcucIntegerParamDef
lowerMultiplicity = 0 symbolicNameValue = true

upperMultiplicity = * min = 0
max = 65535
+destination
DbgAddInfoComSignal: +reference DbgComSignalRef: EcucReferenceDef

Figure 2.31: Example of ComSignal symbolic name definition
Example 2.46
<SHORT-NAME>myComConfig</SHORT-NAME>
EcucDefs/Com/ComConfig</DEFINITION-REF>
<SUB-CONTAINERS>
<SHORT-NAME>PNC_02</SHORT-NAME>
EcucDefs/Com/ComConfig/ComSignal</DEFINITION-REF>
<PARAMETER-VALUES>
<DEFINITION-REF DEST="ECUC-INTEGER-PARAM-DEF">/AUTOSAR/
EcucDefs/Com/ComConfig/ComSignal/ComHandleId</DEFINITION-
REF>
<VALUE>231</VALUE>
</PARAMETER-VALUES>
<SHORT-NAME>Debuging_Sig5</SHORT-NAME>
EcucDefs/Com/ComConfig/ComSignal</DEFINITION-REF>
<PARAMETER-VALUES>
<DEFINITION-REF DEST="ECUC-INTEGER-PARAM-DEF">/AUTOSAR/
EcucDefs/Com/ComConfig/ComSignal/ComHandleId</DEFINITION-
REF>

AUTOSAR CP R22-11
<VALUE>245</VALUE>
</PARAMETER-VALUES>
</SUB-CONTAINERS>
This leads to the generation of the following definitions in the Com header file:
#define ComConf_ComSignal_PNC_02 231
#define ComConf_ComSignal_Debuging_Sig5 245
Such that the other BSW Modules - which include the Com header file - can call the
Com module using these symbols:
ComM: Com_SendSignal(ComConf_ComSignal_PNC_02, value)
Dgb: Com_SendSignal(ComConf_ComSignal_Debuging_Sig5, value)
2.4.5.2.1 Invalid configuration due to symbolic name values
[TPS_ECUC_06074] Invalid configuration due to symbolic name values dDue to

the hierarchical structure of the EcucParameterValues or the existence of post-build
variants, it is possible that the same shortName is the base for multiple symbol-
icNameValue definitions. If the respective value is equal in all occurrences of the
shortName according to [TPS_ECUC_02108], the generation of the #define shall
only be done once. If the respective value is different in any of the occurrences of the
shortName according to [TPS_ECUC_02108], the configuration is invalid.c()
Example 2.32 shows a valid and an invalid configuration due to the existence of post-
build variations.

AUTOSAR CP R22-11
DEFINITION Valid Icu configuration Invalid Icu configuration
Icu: EcucModuleDef MyIcu1: MyIcu2:

EcucModuleConfigurationValues EcucModuleConfigurationValues
+container
IcuConfigSet: IcuConfigSet:
IcuConfigSet: EcucParamConfContainerDef EcucContainerValue EcucContainerValue
+subContainer
IcuChannel0: IcuChannel0:
EcucContainerValue EcucContainerValue
IcuChannel:
IcuChannelId:
EcucNumericalParamValue
IcuChannelId: IcuChannelId:
EcucNumericalParamValue EcucNumericalParamValue value = 0
+parameter
value = 0 value = 0
IcuChannelId:
IcuChannelId:
EcucIntegerParamDef
min = 0
value = 1
max = 65535
symbolicNameValue = true :VariationPoint
:VariationPoint :VariationPoint
:VariationPoint
:PostBuildVariantCondition :PostBuildVariantCondition
value = 0 value = 1 :PostBuildVariantCondition :PostBuildVariantCondition
value = 0 value = 1
:PostBuildVariantCriterion :PostBuildVariantCriterion
Figure 2.32: SymbolicNameValues and the generation of #defines: valid and invalid con-
figurations due to the existence of post-build variations
The valid example in figure 2.32 does lead to the following definition:
#define IcuConf_IcuChannel_IcuChannel0 0
The invalid example in figure 2.32 would possibly lead to the following definitions:
where a different value would be assigned to the same symbol. This is an invalid
configuration.
Example 2.33 and 2.34 shows a valid and an invalid configuration due to the hierarchi-
cal structure of the EcucParameterValues.

AUTOSAR CP R22-11
DEFINITION Valid CanNm Configuration
CanNmChannelConfig: EcucParamConfContainerDef
Channel_01: EcucContainerValue Channel_02: EcucContainerValue
+subContainer
CanNmRxPdu: Foo: Foo2:

EcucParamConfContainerDef EcucContainerValue EcucContainerValue
+subContainer
CanNmTxPdu: Bar: Bar2:

+parameter
CanNmRxPduId: CanNmRxPduId:
CanNmRxPduId: EcucNumericalParamValue
EcucIntegerParamDef EcucNumericalParamValue
value = 1 value = 3
min = 0
max = 65535
+parameter
CanNmTxConfirmationPduId: CanNmTxConfirmationId: CanNmTxConfirmationId:

EcucIntegerParamDef EcucNumericalParamValue EcucNumericalParamValue
min = 0 value = 2 value = 4
max = 65535
Figure 2.33: SymbolicNameValues and the generation of #defines: valid configuration

due to the hierarchical structure of the EcucParameterValues

AUTOSAR CP R22-11
DEFINITION Invalid CanNm Configuration
CanNmChannelConfig: EcucParamConfContainerDef Channel_01: EcucContainerValue Channel_02: EcucContainerValue

+subContainer
Foo: Foo:
CanNmRxPdu:
+subContainer
CanNmTxPdu: Bar: Bar:

+parameter
CanNmRxPduId: CanNmRxPduId:
CanNmRxPduId: EcucNumericalParamValue EcucNumericalParamValue
EcucIntegerParamDef
value = 1 value = 3
min = 0
max = 65535
+parameter
CanNmTxConfirmationPduId: CanNmTxConfirmationId: CanNmTxConfirmationId:

EcucIntegerParamDef EcucNumericalParamValue EcucNumericalParamValue
min = 0 value = 2 value = 4

max = 65535
Figure 2.34: SymbolicNameValues and the generation of #defines: invalid configuration

due to the hierarchical structure of the EcucParameterValues
The valid example in figure 2.33 does lead to the following definition:
#define CanNmConf_CanNmRxPdu_Foo 1
#define CanNmConf_CanNmTxPdu_Bar 2
#define CanNmConf_CanNmRxPdu_Foo2 3
#define CanNmConf_CanNmTxPdu_Bar2 4
The invalid example in figure 2.34 would possibly lead to the following definitions:
where different values would be assigned to the same symbol. The value 1 would be
redefined to 3 and the value 2 would be redefined to 4. This is an invalid configuration.

AUTOSAR CP R22-11
2.4.5.3 Rules for references in the ECUC Parameter Value description
[TPS_ECUC_06047] References in the ECUC Parameter Value description with

reference definitions that refer to container definitions in the same module defi-
nition dFor reference definitions that refer to container definitions in the same module
definition the references on the value side shall only refer to container instances of this
module instance.c()
The example in figure 2.35 defines a reference inside the CanDrv module. Thus the
values can only refer to container instances within the respective CanDrv configuration
instance.
STMD VSMD Values
Refine
CanDrv VendorY/CanDrv
CanDrv: MyCanVendorY
CanGeneral: Ygeneral
CanGeneral CanTrcvRef: /MyCanVendorY/Ytrcv
CavTrcvContainer: Ytrcv
CanGeneral
CanTrcvRef
CanTrcvRef
CanTrcvContainer
CanTrcvContainer VendorZ/CanDrv CanDrv: MyCanVendorZ

CanGeneral: Zgeneral
CanTrcvRef: /MyCanVendorZ/Ztrcv
CavTrcvContainer: Ztrcv
CanGeneral
CanTrcvRef
CanTrcvContainer
Figure 2.35: Reference inside a module
[TPS_ECUC_06048] References in the ECUC Parameter Value description with

reference definitions that refer to container definitions in different module defi-
nitions dFor reference definitions that refer to container definitions in a different module
definition the references on the value side may refer to container instances of different
module instances according to the same module definition.c()
The example in figure 2.36 defines a reference between the CanIf and the CanDrv
module. Thus the values can refer to container instances of different CanDrv configu-
ration instances.

AUTOSAR CP R22-11
STMD VSMD Values

Refine
CanIf: MyCanIf
CanIf VendorX/CanIf CanIfDriverRef:
/MyCanVendorY/Ygeneral or
/MyCanVendorZ/Zgeneral
CanIfDriverRef
CanIfDriverRef
DEST-REF
Refine
CanDrv: MyCanVendorY
CanDrv VendorY/CanDrv
CanGeneral: Ygeneral
CanGeneral
CanGeneral Refine
CanDrv: MyCanVendorZ
VendorZ/CanDrv CanGeneral: Zgeneral
CanGeneral
Figure 2.36: Reference between modules
2.4.6 Derived Parameters in an ECU Configuration Description
[TPS_ECUC_03021] EcucParameterDefs with EcucDerivationSpecifica-

tion result in a EcucNumericalParamValue in the ECUC Value description d
Providing the configuration value for an instance of an EcucParameterDef which has
as EcucDerivationSpecification results in a EcucNumericalParamValue.c()
[TPS_ECUC_02125] Value of parameters with a defined derivation specification d
The value of a parameter shall be provided even when the defining EcucParameter-
Def has a EcucDerivationSpecification.c()
In this way it is guaranteed that even when a tool does not support the derivation
formula the value is still available.
With the storage of the value it is also possible to implement consistency checks
whether the actually provided value matches the result of the derivation formula.
Example 2.47 depicts the configuration description of derived parameters for example
2.24.
Example 2.47
<DEFINITION-REF DEST="ECUC-BOOLEAN-PARAM-DEF">/AUTOSAR/EcucDefs/Com/
ComConfig/ComGwMapping/CheckConsistency</DEFINITION-REF>
<VALUE>1</VALUE>

AUTOSAR CP R22-11
2.4.7 Using Variant Handling to Cope with Several Binding Times in the ECU
Configuration Value Description
The goal of this feature is to provide modeling support to handle several binding times
of the ECU Configuration Value Description in one model. The idea is to
utilize Variant Handling approach to allow different values and/or different number
of instances of certain configuration parameters in different variation points bound at
post-build time (referred to as post-build variants). In order to achieve this, at least
one PostBuildVariantCriterion shall be declared in order to define a common
selecting element for different post-build variants. The variants are specified using
different PostBuildVariantCriterionValues. An example of one criterion with
two values is shown in 2.48:
Example 2.48
<POST-BUILD-VARIANT-CRITERION>
<SHORT-NAME>PostBuildConfigSet</SHORT-NAME>
</POST-BUILD-VARIANT-CRITERION>
<POST-BUILD-VARIANT-CRITERION-VALUE-SET>
<SHORT-NAME>PostBuildVariants</SHORT-NAME>
<POST-BUILD-VARIANT-CRITERION-VALUES>
<POST-BUILD-VARIANT-CRITERION-VALUE>
<VARIANT-CRITERION-REF DEST="POST-BUILD-VARIANT-CRITERION">/EcucDemo/
PostBuildConfigSet</VARIANT-CRITERION-REF>
<VALUE>1</VALUE>
</POST-BUILD-VARIANT-CRITERION-VALUE>
<POST-BUILD-VARIANT-CRITERION-VALUE>
<VARIANT-CRITERION-REF DEST="POST-BUILD-VARIANT-CRITERION">/EcucDemo/
PostBuildConfigSet</VARIANT-CRITERION-REF>
<VALUE>2</VALUE>
</POST-BUILD-VARIANT-CRITERION-VALUE>
</POST-BUILD-VARIANT-CRITERION-VALUES>
</POST-BUILD-VARIANT-CRITERION-VALUE-SET>
[TPS_ECUC_08011] Pattern for creating a C symbol used by the EcuM/BswM to

initialize BSW modules with different post-build variants dFor the name mangling
of symbols of different post-build variants (configuration sets) of one BSW module, the
following pattern shall be used:
<Mip>_ConfigType <Mip>_Config[_<PredefinedVariant.shortName>]
where <Mip> is the module implementation prefix according to [SWS_BSW_00102],
<PredefinedVariant.shortName> is the shortName of the PredefinedVari-
ant referenced by EcucPostBuildVariantRef reference in the EcucPostBuild-
Variants container of the respective module.
In case of pure post-build configuration without post-build variants, the optional suffix
_<PredefinedVariant.shortName> shall be omitted.c(RS_ECUC_00086)

AUTOSAR CP R22-11
2.4.7.1 Example of ECU configuration using Variant Handling
This section contains an example of how ECU configuration parameters with post-
BuildVariantValue and postBuildVariantMultiplicity attributes set to
true or false inside containers with postBuildVariantMultiplicity attribute
set to true / false can be configured using Variant Handling. As an example, a
part of the Adc module configuration parameters is taken (see Figure 2.37).
Adc: EcucModuleDef
+container AdcGeneral: +parameter
upperMultiplicity = 1 EcucParamConfContainerDef AdcDevErrorDetect:
lowerMultiplicity = 0 EcucBooleanParamDef
defaultValue = false
(from ADC)
(from ADC) (from ADC)
AdcChannelId: EcucIntegerParamDef
AdcChannel: +parameter
EcucParamConfContainerDef min = 0
+container max = 1024
AdcConfigSet: EcucParamConfContainerDef upperMultiplicity = * (from ADC)

AdcChannelResolution: EcucIntegerParamDef
(from ADC) +parameter
min = 1
+subContainer max = 63
(from ADC)
AdcHwUnit:
EcucParamConfContainerDef +subContainer
upperMultiplicity = * +parameter
AdcChannelLimitCheck: EcucBooleanParamDef
(from ADC) upperMultiplicity = 1
(from ADC)
(from ADC)
Figure 2.37: Example of Parameters Configuration Using Variant Handling
The AdcDevErrorDetect parameter of the AdcGeneral container and the Adc-

ChannelLimitCheck parameter of the AdcChannel container shall have the same
value in all post-build variants (i.e. postBuildVariantValue is set to false) while
the AdcChannelId and the AdcChannelResolution parameters of the AdcCha-
nnel container can have different values in different post-build variants (i.e. post-
BuildVariantValue is set to true). All parameters shall have the same number
of instances in different post-build variants (i.e. postBuildVariantMultiplicity
is set to false). The container AdcGeneral cannot change its number of instances
between different variants (i.e. postBuildVariantMultiplicity attribute set to
false) while the container AdcChannel can (i.e. postBuildVariantMultiplic-
ity attribute set to true). This is depicted in Example 2.49.
Example 2.49
<ECUC-MODULE-DEF UUID="ECUC:c03229fe-4dca-445e-a47c-1ae11e6c1832">
<SHORT-NAME>Adc</SHORT-NAME>
<SUPPORTED-CONFIG-VARIANT>VARIANT-POST-BUILD</SUPPORTED-CONFIG-VARIANT>
<SUPPORTED-CONFIG-VARIANT>VARIANT-PRE-COMPILE</SUPPORTED-CONFIG-VARIANT
>

AUTOSAR CP R22-11
<CONTAINERS>

<ECUC-PARAM-CONF-CONTAINER-DEF UUID="ECUC:fc6e0617-8c73-4b71-b09e-
dfb10b76e50d">
<SHORT-NAME>AdcConfigSet</SHORT-NAME>
<SUB-CONTAINERS>

<ECUC-PARAM-CONF-CONTAINER-DEF UUID="ECUC:c67e7c58-3daf-455b-a213
-95ae94b248d8">
<SHORT-NAME>AdcHwUnit</SHORT-NAME>
<POST-BUILD-VARIANT-MULTIPLICITY>false</POST-BUILD-VARIANT-
MULTIPLICITY>
<PARAMETERS/>
<SUB-CONTAINERS>

<ECUC-PARAM-CONF-CONTAINER-DEF UUID="ECUC:bfd7d43b-017d-4755-9
a41-2bf12e38403d">
<SHORT-NAME>AdcChannel</SHORT-NAME>
<UPPER-MULTIPLICITY-INFINITE>true</UPPER-MULTIPLICITY-
INFINITE>
MULTIPLICITY>
<PARAMETERS>

<ECUC-INTEGER-PARAM-DEF UUID="ECUC:482b876b-9787-4e46-875a
-559b7a1427f2">
<SHORT-NAME>AdcChannelId</SHORT-NAME>
<SYMBOLIC-NAME-VALUE>false</SYMBOLIC-NAME-VALUE>
<MAX>1024</MAX>
<MIN>0</MIN>

<ECUC-BOOLEAN-PARAM-DEF UUID="ECUC:6c8938e0-f362-4cdc
-8711-6d4b429215b3">
<SHORT-NAME>AdcChannelLimitCheck</SHORT-NAME>
<DESC>

AUTOSAR CP R22-11
<L-2 L="EN">Enables or disables limit checking for an

ADC channel.</L-2>
</DESC>
<POST-BUILD-VARIANT-MULTIPLICITY>false</POST-BUILD-
VARIANT-MULTIPLICITY>
<POST-BUILD-VARIANT-VALUE>false</POST-BUILD-VARIANT-VALUE
>

<ECUC-INTEGER-PARAM-DEF UUID="ECUC:c05e44f5-f418-4772-9ed3-
ba767591baf1">
<SHORT-NAME>AdcChannelResolution</SHORT-NAME>
<POST-BUILD-VARIANT-MULTIPLICITY>false</POST-BUILD-
VARIANT-MULTIPLICITY>

AUTOSAR CP R22-11
<MAX>63</MAX>
<MIN>1</MIN>
</PARAMETERS>
</SUB-CONTAINERS>
</SUB-CONTAINERS>

<ECUC-PARAM-CONF-CONTAINER-DEF UUID="ECUC:da0aaff6-3ed6-4a15-824e-
dc32f3a8bd93">
<SHORT-NAME>AdcGeneral</SHORT-NAME>
<PARAMETERS>

<ECUC-BOOLEAN-PARAM-DEF UUID="ECUC:db321b92-621a-4a62-8778-09
b8845d8f2c">
<SHORT-NAME>AdcDevErrorDetect</SHORT-NAME>
<POST-BUILD-VARIANT-VALUE>false</POST-BUILD-VARIANT-VALUE>
</PARAMETERS>
</CONTAINERS>
</ECUC-MODULE-DEF>
The parameters with fixed value in all post-build variants inside containers with fixed
number of instances are provided normally inside the container structure they are de-
fined in (see AdcDevErrorDetect parameter in Example 2.50).
Example 2.50

AUTOSAR CP R22-11
<SHORT-NAME>theAdc</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-MODULE-DEF">/EcucDemo/Adc</DEFINITION-REF>
VARIANT>
<CONTAINERS>
<SHORT-NAME>myGeneralValue</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">/EcucDemo/Adc/
AdcGeneral</DEFINITION-REF>
<PARAMETER-VALUES>
<DEFINITION-REF DEST="ECUC-BOOLEAN-PARAM-DEF">/EcucDemo/Adc/
AdcGeneral/AdcDevErrorDetect</DEFINITION-REF>
<VALUE>1</VALUE>
</PARAMETER-VALUES>
<SUB-CONTAINERS/>
</CONTAINERS>
Similarly, the parameters with fixed value in all post-build variants inside containers
with possible different number of instances in different variants (i.e. postBuildVari-
antMultiplicity is set to true) also do not need to be duplicated in every variant.
Instead they should be defined only once which also guarantees that the value of these
parameters are the same in all variants (see AdcChannelLimitCheck parameter in
Example 2.51).
Example 2.51
<CONTAINERS>
<SHORT-NAME>myHwUnit</SHORT-NAME>
AdcConfigSet/AdcHwUnit</DEFINITION-REF>
<SUB-CONTAINERS>
<SHORT-NAME>myChannel1</SHORT-NAME>
<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">/EcucDemo/
Adc/AdcConfigSet/AdcHwUnit/AdcChannel</DEFINITION-REF>
<PARAMETER-VALUES>
<DEFINITION-REF DEST="ECUC-INTEGER-PARAM-DEF">/EcucDemo/Adc/
AdcConfigSet/AdcHwUnit/AdcChannel/AdcChannelLimitCheck</
DEFINITION-REF>
<VALUE>0</VALUE>
</PARAMETER-VALUES>
</SUB-CONTAINERS>

AUTOSAR CP R22-11
</CONTAINERS>
However for parameters which may have different value in different post-build variants
(i.e. postBuildVariantValue is set to true), the PostBuildVariantCrite-
rion shall be referenced in order to define the common selector. A specific value for
the selector is defined for each post-build variant to specify to which variant this param-
eter value is associated to (see AdcChannelResolution parameter in two post-build
variants, left and right, in Example 2.52)..
Example 2.52
<SHORT-NAME>myHwUnit</SHORT-NAME>
AdcConfigSet/AdcHwUnit</DEFINITION-REF>
<SUB-CONTAINERS>
<DEFINITION-REF DEST="ECUC-PARAM-CONF-CONTAINER-DEF">/EcucDemo/
Adc/AdcConfigSet/AdcHwUnit/AdcChannel</DEFINITION-REF>
<PARAMETER-VALUES>
<DEFINITION-REF DEST="ECUC-ENUMERATION-PARAM-DEF">/EcucDemo/
Adc/AdcConfigSet/AdcHwUnit/AdcChannel/AdcChannelResolution
</DEFINITION-REF>
<VARIATION-POINT>
<POST-BUILD-VARIANT-CONDITIONS>
<POST-BUILD-VARIANT-CONDITION>
<MATCHING-CRITERION-REF DEST="POST-BUILD-VARIANT-
CRITERION">/EcucDemo/PostBuildConfigSet</MATCHING-
CRITERION-REF>
<VALUE>1</VALUE>

</POST-BUILD-VARIANT-CONDITION>
</POST-BUILD-VARIANT-CONDITIONS>
</VARIATION-POINT>
<VALUE>10</VALUE>
<DEFINITION-REF DEST="ECUC-ENUMERATION-PARAM-DEF">/EcucDemo/
Adc/AdcConfigSet/AdcHwUnit/AdcChannel/AdcChannelResolution
</DEFINITION-REF>
<VARIATION-POINT>
<MATCHING-CRITERION-REF DEST="POST-BUILD-VARIANT-
CRITERION">/EcucDemo/PostBuildConfigSet</MATCHING-
CRITERION-REF>
<VALUE>2</VALUE>


AUTOSAR CP R22-11
</VARIATION-POINT>
<VALUE>40</VALUE>
</PARAMETER-VALUES>
</SUB-CONTAINERS>
If one container shall be used in all post-build variants (e.g. because there are pre-
compile configurations pointing to this container), it shall not define a variation point
and thus indicate its "pre-compile" nature. In case a container exists only in some
post-build variants, it shall define a variation point. Also all included elements shall
then define the respective variation point (see AdcChannel container in Example
2.53).
Example 2.53
<CONTAINERS>
AdcConfigSet/AdcHwUnit/AdcChannel</DEFINITION-REF>
<PARAMETER-VALUES>
AdcConfigSet/AdcHwUnit/AdcChannel/AdcChannelLimitCheck</
DEFINITION-REF>
<VALUE>1</VALUE>
AdcConfigSet/AdcHwUnit/AdcChannel/AdcChannelId</DEFINITION-REF
>
<VALUE>5</VALUE>
<DEFINITION-REF DEST="ECUC-ENUMERATION-PARAM-DEF">/EcucDemo/Adc/
AdcConfigSet/AdcHwUnit/AdcChannel/AdcChannelResolution</
DEFINITION-REF>
<VARIATION-POINT>
<MATCHING-CRITERION-REF DEST="POST-BUILD-VARIANT-CRITERION"
>/EcucDemo/PostBuildConfigSet</MATCHING-CRITERION-REF>
<VALUE>2</VALUE>
</VARIATION-POINT>
<VALUE>30</VALUE>

AUTOSAR CP R22-11
</PARAMETER-VALUES>
<VARIATION-POINT>
<MATCHING-CRITERION-REF DEST="POST-BUILD-VARIANT-CRITERION">/
EcucDemo/PostBuildConfigSet</MATCHING-CRITERION-REF>
<VALUE>2</VALUE>
</VARIATION-POINT>
</CONTAINERS>

AUTOSAR CP R22-11
3 ECU Configuration Parameter Definition SWS

implications
In this section several aspects of applying the ECU Configuration Specification to
AUTOSAR specifications are described.
The ECU Configuration Parameter Definitions are distributed over the BSW SWS doc-
uments. How these parameters are specified in the documents is described in section
3.1.
How the AUTOSAR COM-Stack is configured from an inter-module perspective is de-
scribed in section 3.4.
3.1 Formalization aspects

The goal of this section is to describe how the ECU Configuration Parameter Definitions
of BSW modules are specified in the SWS documents. Therefore there is not neces-
sarily a simple translation of the ECU Configuration Parameter’s values in the ECU
Configuration Value description (XML file) into the module’s configuration (header file).
It is the duty of the module’s generation tool to transform the configuration information
from the XML file into a header file.
The ECU Configuration Parameter Definitions are formalized in an UML model. This
UML model is used to partly generate the specification tables of the BSW SWS and to
generate the ECU Configuration Parameter Definition XML file. 1
Some formalization patterns have been applied when developing the ECU Configura-
tion Parameter Definition:
• Modified parameter names: Due to the limitations imposed by the AUTOSAR
XML format (32 character limit starting with a letter, etc.) the names of param-
eters and containers have been redefined. Also a different naming schema has
been applied. The original names from the SWS are provided in this document
as well.
• Added parameter multiplicities: In the original tables from the BSW SWS there is
no possibility to specify the optionality and multiplicity of parameters. The param-
eter multiplicities have been added.
• Added references: To allow a better interaction of the configuration Value de-
scriptions of several modules references between the configuration have been
introduced.
• Harmonized parameter types:
1
The generation from the UML model is only one way to create the ECU Configuration Parameter
Definition XML file. ECUC Parameters can be defined by any other method as long as an AUTOSAR
conforming ECUC Parameter Definition XML file is created.

AUTOSAR CP R22-11
– Boolean: Some parameters have been defined as enumeration or #de-

fine where the actual information stored is of type boolean. In those cases
they have been modeled as boolean.
– Float: Some parameters store a time value as integer where it is stated
that this is a time in e.g. micro-seconds. If the time specified is an absolute
time it has been formalized as a float in seconds. If the time is a factor of
some given time-base the integer is preserved.
3.1.1 ECU Configuration Parameter Definition table
The configuration parameters are structured into containers which can hold parame-
ters, references and other containers. Beside the graphical visualization in UML dia-
grams, tables are used to specify the structure of the parameters.
In the following table one container is specified which holds two parameters and also
two additional containers as an example.
SWS Item [ECUC_MA_00001]
Container Name ContainerName
Parent Container aggregatingContainerName
Description Container description
Post-Build Variant Multiplicity true
Multiplicity Configuration Class Pre-compile time X VARIANT-PRE-COMPILE
Link time X VARIANT-LINK-TIME,
VARIANT-POST-BUILD
Post-build time –
Configuration Parameters

Parameter Name ParameterName1
Parent Container ContainerName
Description Parameter description
Multiplicity 1
Type EcucIntegerParamDef
Range 0 .. 4294967295
Default value 0
Post-Build Variant Value true
Value Configuration Class Pre-compile time X VARIANT-PRE-COMPILE
Link time X VARIANT-LINK-TIME,
VARIANT-POST-BUILD
Post-build time –
Scope / Dependency scope: local

Parameter Name ParameterName1
Parent Container ContainerName
5

AUTOSAR CP R22-11
4
Description Parameter description
Multiplicity 0..1
Range 0 .. 64
Default value
Link time X VARIANT-LINK-TIME
Post-build time X VARIANT-POST-BUILD
Link time X VARIANT-LINK-TIME
Included Containers
Container Name Multiplicity Scope / Dependency
Container1 0..1 Optional sub-container
Container2 0..* Optional sub-container
For a detailed description of the elements in the tables please refer to chapter 2.

AUTOSAR CP R22-11
3.2 AUTOSAR Stack Overview

The software architecture of an AUTOSAR ECU has been divided into several parts to
allow independent modules with clean definitions of the interfaces between the different
modules. This architecture is depicted in figure 3.1.
Figure 3.1: ECU Architecture Overview [14]
The Application SW-Components are located at the top and can gain access to the
rest of the ECU and also to other ECUs only through the RTE.

AUTOSAR CP R22-11
AUTOSARParameterDefinition: EcucDefinitionCollection
Services COM-Stack IO Misc
+ HTTMSS + Mirror + ADC + SwCluC

+ Tm + SecOC + DIO + CryIf
+ Xfrm + Can + ICU + CryptoDrv
+ Crc + Com + Ocu + Cdd
+ Csm + Dds + PORT + CorTst
+ Dcm + LdCom + PWM + EcuC
+ Dem + Ethernet + SPI + Dlt
+ Det + FlexRay + FlsTst
+ FiM + IpduMplex + GPT
+ OS + J1939 + MCU
+ StbM + Lin + RamTst
+ Watchdog + PduR + MemMap
+ Xcp + KeyM
+ NetworkManagement + IKE
+ IdsM
Mode_Mgm Memory Arti
+ BswM + EA + Arti
+ ComM + EEPROM + ArtiGeneric
+ EcuM + FEE + ArtiHardware
+ Flash + ArtiOs
+ Mem + ArtiRte
+ MemAcc + ArtiValues
+ MemoryInterface
+ Nvm
+ BndM
Figure 3.2: AUTOSAR Parameter Definition Overview
The RTE provides the encapsulation of communication and basic services to the Ap-
plication SW-Components, so it is possible to map the Application SW-Components
between different ECUs.
The Basic Software Modules are located below the RTE. The Basic Software itself is
divided into the subgroups: System Services, Memory, Communication and IO HW-
Abstraction. The Complex Drivers are also located below the RTE.
Among other, the Operating System (OS), the Watchdog manager and the Diagnostic
services are located in the System Services subgroup.
The Memory subgroup contains modules to provide access to the non-volatile memo-
ries, namely Flash and EEPROM.
In the Communication subgroup the whole AUTOSAR communication stack (COM-
Stack) is specified including the COM, Network Management and the communication
drivers.
The top-level structure of the AUTOSARParameterDefinition is shown in figure
3.2.

AUTOSAR CP R22-11
The container AUTOSARParameterDefinition is the top-level element of the

AUTOSAR ECU Configuration Parameter Definition structure. Inside this container ref-
erences to the diverse configuration container definitions for the different SW modules
are defined.
The upper multiplicities defined in the context of each EcucModuleDef directly impact
the instantiation of the specific modules. If EcucModuleDef.upperMultiplicity is
set to 1 this means that the respective module can only appear once in an AUTOSAR
BSW stack. If the value of EcucModuleDef.upperMultiplicity is greater than 1
(i.e. 0..*) the module can be multiply instantiated.
SWS Item [ECUC_EcuC_00084]
ECU Conf. Name AUTOSARParameterDefinition
Description Top level container for the definition of AUTOSAR configuration parameters. All of the
parameter definitions for the different modules are contained in this container.
Included Modules
Module Name Multiplicity Scope / Dependency
Adc 0..1 Configuration of the Adc (Analog Digital Conversion) module.
Arti 0..1 The Arti Module serves as a superordinate container collecting
all information and parameters concerning ARTI.
BndM 0..1 Configuration of the BulkNvDataManager module.
BswM 0..1 Configuration of the BswM (Basic SW Mode Manager) module.
CV2x 0..* Configuration of the CV2x module (Cellular V2X Driver).
Can 0..* This container holds the configuration of a single CAN Driver.
CanIf 0..1 This container includes all necessary configuration
sub-containers according the CAN Interface configuration
structure.
CanNm 0..1 Configuration Parameters for the Can Nm module.
CanSM 0..1 Configuration of the CanSM module
CanTSyn 0..1 Configuration of the Synchronized Time-base Manager (StbM)
module with respect to global time handling on CAN.
CanTp 0..1 Configuration of the CanTp (CAN Transport Protocol) module.
CanTrcv 0..* Configuration of the CanTrcv (CAN Transceiver driver) module.
Cdd 0..* The CDD module describes the minimal requirements that are
necessary for the configuration of a CDD with respect to the
surrounding standardized BSW modules.
CnV2xM 0..* Configuration of the CnV2xM module.
CnV2xMsg 0..1 Configuration of the CnV2xMsg module.
CnV2xNet 0..1 Configuration of the CnV2xMsg module.
CnV2xSec 0..* Configuration of the CnV2xM module.
Com 0..1 Configuration of the AUTOSAR COM module.
ComM 0..1 Configuration of the ComM (Communications Manager) module.
CorTst 0..1 Configuration of the CorTst module.
Crc 0..1 Configuration of the Crc (Crc routines) module.
CryIf 0..1 Configuration of the Crypto Interface.
Crypto 0..* Configuration of the Crypto (CryptoDriver) module
Csm 0..1 Configuration of the Csm (CryptoServiceManager) module.
Dcm 0..1 Configuration of the Dcm (Diagnostic Communications Manager)
module.
5

AUTOSAR CP R22-11
4
Included Modules
Dds 0..1 Configuration of the Dds module.
Dem 0..1 Configuration of the Dem (Diagnostic Event Manager) module.
Det 0..1 Det configuration includes the functions to be called at
notification. On one side the application functions are specified
and in general it can be decided whether Dlt shall be called at
each call of Det.
Dio 0..1 Configuration of the Dio (Digital IO) module.
Dlt 0..1 –
DoIP 0..1 Configuration of the DoIP (Diagnostic over IP) module.
Ea 0..1 Configuration of the Ea (EEPROM Abstraction) module. The
module shall abstract from the device specific addressing
scheme and segmentation and provide the upper layers with a
virtual addressing scheme and segmentation as well as a
’virtually’ unlimited number of erase cycles.
EcuC 0..1 Virtual module to collect ECU Configuration specific / global
configuration information.
EcuM 0..1 Configuration of the EcuM (ECU State Manager) module.
Eep 0..* Configuration of the Eep (internal or external EEPROM driver)
module. Its multiplicity describes the number of EEPROM drivers
present, so there will be one container for each EEPROM driver
in the ECUC template. When no EEPROM driver is present then
the multiplicity is 0.
Eth 0..* Configuration of the Eth (Ethernet Driver) module.
EthIf 0..1 Configuration of the EthIf (Ethernet Interface) module.
EthSM 0..1 Configuration of the Ethernet State Manager
EthSwt 0..* Configuration of the EthSwt (Ethernet Switch Driver) module.
EthTSyn 0..1 Configuration of the Synchronized Time-base Manager (StbM)
module with respect to global time handling on Ethernet.
EthTrcv 0..* Configuration of Ethernet Transceiver Driver module
Fee 0..1 Configuration of the Fee (Flash EEPROM Emulation) module.
FiM 0..1 Configuration of the FiM (Function Inhibition Manager) module.
Fls 0..* Configuration of the Fls (internal or external flash driver) module.
Its multiplicity describes the number of flash drivers present, so
there will be one container for each flash driver in the ECUC
template. When no flash driver is present then the multiplicity is
0.
FlsTst 0..1 –
Fr 0..* Configuration of the Fr (FlexRay driver) module.
FrArTp 0..1 Configuration of the FrArTp (FlexRay Transport Protocol)
module.
FrIf 0..1 Configuration of the FrIf (FlexRay Interface) module.
FrNm 0..1 The Flexray Nm module
FrSM 0..1 Configuration of the FlexRay State Manager
FrTSyn 0..1 This represents the specific configuration variant for the TSyn on
Flexray.
FrTp 0..1 Configuration of the FlexRay Transport Protocol module
according to ISO 10681-2.
FrTrcv 0..* Configuration of the FrTrcv (FlexRay Transceiver driver) module.
Gpt 0..1 Configuration of the Gpt (General Purpose Timer) module.
HTTMS 0..1 Configuration of the Hardware Test Management start up and
shutdown (HTMSS) module.
5

AUTOSAR CP R22-11
4
Included Modules
IKE 0..1 Description for the Internet Key Exchange.
Icu 0..1 Configuration of the Icu (Input Capture Unit) module.
IdsM 0..1 –
IpduM 0..1 Configuration of the IpduM (Ipdu Multiplexer) module.
J1939Dcm 0..1 The SAE J1939 Dcm module
J1939Nm 0..1 Configuration of the J1939 Network Management module.
J1939Rm 0..1 Configuration of the J1939 Request Manager.
J1939Tp 0..1 Configuration of the J1939Tp (J1939 Transport Protocol) module.
KeyM 0..1 Configuration of the Mcu (Microcontroller Unit) module.
LdCom 0..1 Configuration of the AUTOSAR LdCom module.
Lin 0..* Configuration of the Lin (LIN driver) module.
LinIf 0..1 Configuration of the LinIf (LIN Interface) module.
LinSM 0..1 Configuration of the Lin State Manager module.
LinTp 0..1 Configuration of the LIN Transport Protocol.
LinTrcv 0..* Configuration of LIN Transceiver Driver module
Mcu 0..1 Configuration of the Mcu (Microcontroller Unit) module.
Mem 0..* Configuration of the Mem driver (internal or external memory
driver) module.
Its multiplicity describes the actual number of Mem drivers.
There will be one container for each Mem driver.
MemAcc 0..1 The MemAcc (Memory Access module) coordinates the memory
access by multiple users in order to avoid conflicts with this
shared memory resource.
The module abstracts from the memory device specific
addressing scheme and provides a logical addressing scheme to
the upper layer.
MemIf 0..1 Configuration of the MemIf (Memory Abstraction Interface)
module.
MemMap 0..1 Configuration of the Memory Mapping module.
Mirror 0..1 Configuration of the Bus Mirroring module.
Mka 1 Configuration of the MACsec Key Agreement module.
Nm 0..1 The Generic Network Management Interface module
NvM 0..1 Configuration of the NvM (NvRam Manager) module.
Ocu 0..1 Configuration of Ocu (Output Compare Unit) module.
Os 0..1 Configuration of the Os (Operating System) module.
PduR 0..1 Configuration of the PduR (PDU Router) module.
Port 0..1 Configuration of the Port module.
Pwm 0..* Configuration of Pwm (Pulse Width Modulation) module.
RamTst 0..1 Configuration of the RamTst module.
Rte 0..1 Configuration of the Rte (Runtime Environment) module.
Sd 0..1 Configuration of the Service Discovery module.
SecOC 0..1 Configuration of the SecOC (SecureOnboardCommunication)
module.
SoAd 0..1 Configuration of the SoAd (Socket Adaptor) module.
SomeIpTp 0..1 Configuration of the SomeIpTp module.
Spi 0..1 Configuration of the Spi (Serial Peripheral Interface) module.
5

AUTOSAR CP R22-11
4
Included Modules
StbM 0..1 Configuration of the Synchronized Time-base Manager (StbM)
module.
SwCluC 0..1 Module to collect Software Cluster Connection specific
configuration information.
TcpIp 0..1 Configuration of the TcpIp (TCP/IP stack) module.
Tm 0..1 Configuration of the Time Service module.
UdpNm 0..1 –
V2xBtp 0..1 Configuration of the V2xBtp (Vehicle-2-X Basic Transport)
module.
V2xDM 1 Configuration of the V2XDM module
V2xFac 0..1 Configuration of the V2xFac module.
V2xGn 0..1 Configuration of the V2xGn (Vehicle-2-X Geo Networking)
module.
V2xM 0..1 Configuration of the V2xM (V2XManagement) module.
WEth 0..* Configuration of the WEth (Wireless Ethernet Driver) module.
WEthTrcv 0..* Configuration of Ethernet Transceiver Driver module
Wdg 0..* Configuration of the Wdg (Watchdog driver) module.
WdgIf 0..1 Configuration of the WdgIf (Watchdog Interface) module.
WdgM 0..1 Configuration of the WdgM (Watchdog Manager) module.
Xcp 0..1 Configuration of the XCP module
Xfrm 0..* –

AUTOSAR CP R22-11
3.3 Virtual Module EcuC

In the configuration of an ECU there is information which needs to be shared between
multiple BSW Modules. Since it can not be defined who owns this shared information
the virtual module EcuC has been introduced to the AUTOSAR ECU Configuration
Parameter Definition.
Module Name EcuC
Description Virtual module to collect ECU Configuration specific / global configuration
information.
Post-Build Variant Support true
Supported Config Variants VARIANT-POST-BUILD, VARIANT-PRE-COMPILE
Included Containers
EcucConfigSet 0..1 This container contains the configuration parameters and sub
containers of the global PduCollection.
EcucHardware 0..1 Hardware definition of this Ecu.
EcucPartitionCollection 0..1 Collection of Partitions defined for this ECU.
EcucPostBuildVariants 0..1 Collection of toplevel PostBuildSelectable variants. The
PredefinedVariants linked inside this container will determine
how many PostBuildSelectableVariants exist. If this container
exist the name pattern for initialization of BSW modules will be
<Mip>_Config_<PredefinedVariant.shortName>. If this container
does not exist the name pattern for initialization of BSW modlues
will be <Mip>_Config.
EcucUnitGroupAssignment 0..1 Collection of UnitGroup references to support the generation of
ASAM MCD file.
EcucVariationResolver 0..1 Collection of PredefinedVariant elements containing definition of
values for SwSystemconst which shall be applied when resolving
the variability during ECU Configuration.

Container Name EcucConfigSet
Parent Container EcuC
Description This container contains the configuration parameters and sub containers of the global
PduCollection.
Included Containers
EcucPduCollection 0..1 Collection of all Pdu objects flowing through the Com-Stack.
3.3.1 Hardware description
In order to allow the unique description and access to hardware resources the
EcucHardware has been introduced.
One section of the EcucHardware is concerned with the definition of computation
cores and the assignment of unique EcucCoreIds to these cores. Additionally it is

AUTOSAR CP R22-11
possible to refer to the Ecu Resource Template HwElement which represents the core
in hardware.
EcucHardware:
+subContainer
EcucCoreId:
EcucCoreDefinition: EcucIntegerParamDef
+parameter
min = 0
lowerMultiplicity = 0 max = 65535
Ecu Resource Template
ARElement
EcucCoreHwRef: EcucForeignReferenceDef
HwDescriptionEntity
+reference
upperMultiplicity = 1 HwElement
destinationType = HW-ELEMENT
Figure 3.3: Description of ECU Hardware

Container Name EcucHardware
Description Hardware definition of this Ecu.
Included Containers
EcucCoreDefinition 0..* Definition of one Core on this Ecu.

Container Name EcucCoreDefinition
Parent Container EcucHardware
Description Definition of one Core on this Ecu.

Parameter Name EcucCoreId
Parent Container EcucCoreDefinition
Description ID of the core.
Multiplicity 1
Range 0 .. 65535
Default value –
Post-Build Variant Value false
Value Configuration Class Pre-compile time X All Variants
Link time –
Post-build time –
5

AUTOSAR CP R22-11
4
Scope / Dependency

Parameter Name EcucCoreHwRef
Parent Container EcucCoreDefinition
Description Optional reference to the HwElement of HwCategory ProcessingUnit that represents
this Core in the ECU Resource Template.
Multiplicity 0..1
Type Foreign reference to HW-ELEMENT
Post-Build Variant Multiplicity false
Multiplicity Configuration Class Pre-compile time X All Variants
Link time –
Post-build time –
Link time –
Post-build time –
Scope / Dependency
No Included Containers
3.3.2 Definition of Partitions
In order to support memory-partitioning and multi-core the notion of a EcucPartition

has been introduced into the EcuC virtual Module.
The EcuC Module can have one EcucPartitionCollection which can hold an
arbitrary number of EcucPartition elements. The memory-partitioning enables
to create protection boundaries around groups of SWCs. The allocation of SWCs
to EcucPartitions is possible via the EcucPartitionSoftwareComponentIn-
stanceRef reference to SW Component instances. An EcucPartition is imple-
mented by an OS-Application within the OS. Therefore the mapping of SWCs to parti-
tions restricts the runnable to task mapping as shown in figure 3.4.

AUTOSAR CP R22-11
EcucPartitionCollection: Identifiable
+container EcuC: EcucModuleDef
EcuPartition
lowerMultiplicity = 0 + execInUserMode: Boolean
+subContainer
EcucPartition: EcucEcuPartitionRef: EcucForeignReferenceDef

EcucParamConfContainerDef +reference
destinationType = ECU-PARTITION
upperMultiplicity = * upperMultiplicity = 1
PartitionCanBeRestarted:
+parameter
EcucBooleanParamDef
EcucDefaultBswPartition:
+parameter EcucBooleanParamDef
ComMUserEcucPartitionRef: ComMUser:
+destination EcucReferenceDef +reference EcucParamConfContainerDef
+destination EcuMFlexEcucPartitionRef: EcuMFlexUserConfig:

EcucReferenceDef +reference EcucParamConfContainerDef
+destination OsAppEcucPartitionRef: OsApplication:

EcucReferenceDef +reference
lowerMultiplicity = 0 upperMultiplicity = *
upperMultiplicity = 1 lowerMultiplicity = 0
+reference
+reference
EcucPartitionSoftwareComponentInstanceRef:
EcucInstanceReferenceDef OsAppTaskRef: EcucReferenceDef
OsTask:
destinationType = SW-COMPONENT-PROTOTYPE EcucParamConfContainerDef +destination upperMultiplicity = *
upperMultiplicity = * lowerMultiplicity = 0
destinationContext = ROOT-SW-COMPOSITION-PROTOTYPE lowerMultiplicity = 0
AtpPrototype
SwComponentPrototype
Figure 3.4: Definition of Partitions on one ECU

Container Name EcucPartitionCollection
Description Collection of Partitions defined for this ECU.
Included Containers
EcucPartition 0..* Definition of one Partition on this ECU. One Partition will be
implemented using one Os-Application.

AUTOSAR CP R22-11

Container Name EcucPartition
Parent Container EcucPartitionCollection
Description Definition of one Partition on this ECU. One Partition will be implemented using one
Os-Application.
Multiplicity Configuration Class Pre-compile time X VARIANT-PRE-COMPILE,
VARIANT-POST-BUILD
Link time –
Post-build time –

Parameter Name EcucDefaultBswPartition
Parent Container EcucPartition
Description Denotes the default BSW partition. This partition will host all BSW Modules, which are
not explicitly mapped to a different partition.
For partitions other than the default BSW partition this parameter can be omitted.
Multiplicity 0..1
Type EcucBooleanParamDef
Default value –
Link time –
Post-build time –
Link time –
Post-build time –
Scope / Dependency

Parameter Name PartitionCanBeRestarted
Description Specifies the requirement whether the Partition can be restarted. If set to true all
software executing in this partition shall be capable of handling a restart.
Multiplicity 1
Default value –
Link time –
Post-build time –
Scope / Dependency

Parameter Name EcucEcuPartitionRef
5

AUTOSAR CP R22-11
4
Description Reference to the EcuPartition to define the link to the partition described in the System
description.
Tags: atp.Status=draft
Multiplicity 0..1
Type Foreign reference to ECU-PARTITION
Link time –
Post-build time –
Link time –
Post-build time –
Scope / Dependency scope: ECU

Parameter Name EcucPartitionBswModuleDistinguishedPartition
Description This maps the abstract partition of the Bsw Module to a concrete Partition existing in
the ECU.
Multiplicity 0..*
Type Foreign reference to BSW-DISTINGUISHED-PARTITION
Link time –
Post-build time –
Link time –
Post-build time –
Scope / Dependency

Parameter Name EcucPartitionSoftwareComponentInstanceRef
Description References the SW Component instances from the Ecu Extract that shall be executed
in this partition.
Multiplicity 0..*
Type Instance reference to SW-COMPONENT-PROTOTYPE context:
ROOT-SW-COMPOSITION-PROTOTYPE
Link time –
Post-build time –
Link time –
Post-build time –
Scope / Dependency

AUTOSAR CP R22-11
The design principle is that after the creation of a partition the software (SWC) is
mapped to this partition. In the second step the BSW is configured and every member
of a partition (BSW) defines a reference to the EcucPartition element.
One example is the Os module: The Os-Application is used to implement one Partition,
therefore there shall be a reference from each Os-Application to one Partition which
specifies which partition this Os-Application is implementing.
Another example is the interaction of a SWC with the ComM: A SWC running in a
partition other than the BSW modules is requesting full communication at the ComM.
If now the partition which the SWC is running in will be stopped due to an partition
violation there is now an outstanding full communication request at the ComM which
will prohibit a network to be sent to sleep. With the provided configuration means it is
possible to implement counter measures for such use-cases.
The interaction between EcucPartition and EcucCoreDefinition is done via
the OsApplicationCoreRef of OsApplication.
EcucPartitionCollection: EcuC: EcucModuleDef
EcucParamConfContainerDef +container
BSW Module Description Template

EcucPartitionBswModuleDistinguishedPartition:
+subContainer EcucForeignReferenceDef
Referrable
EcucPartition: +reference destinationType = BSW-DISTINGUISHED-PARTITION BswDistinguishedPartition
EcucParamConfContainerDef upperMultiplicity = *
+parameter PartitionCanBeRestarted:
EcucBooleanParamDef
EcucDefaultBswPartition:
+destination OsAppEcucPartitionRef: OsApplication:

EcucReferenceDef +reference EcucParamConfContainerDef
+reference
SW Component Template
EcucPartitionSoftwareComponentInstanceRef:
EcucInstanceReferenceDef AtpPrototype
SwComponentPrototype
destinationType = SW-COMPONENT-PROTOTYPE
destinationContext = ROOT-SW-COMPOSITION-PROTOTYPE
+reference
EcucCoreId: EcucCoreDefinition: OsApplicationCoreRef:

EcucIntegerParamDef +parameter EcucParamConfContainerDef +destination EcucReferenceDef
min = 0 lowerMultiplicity = 0 lowerMultiplicity = 0

max = 65535 upperMultiplicity = * upperMultiplicity = 1
Figure 3.5: Interaction between EcucPartition and EcucCoreDefinition

AUTOSAR CP R22-11
3.3.3 PostBuild Variants
For each post-build variant (post-build configuration set) there exists exactly one "top-
level" PredefinedVariant that is valid for all post-build capable BSW modules. This
means that every module which supports post-build variants (previously known as post-
build selectable configuration sets) will need to have configurations for every single
defined PredefinedVariant that is referenced by EcucPostBuildVariantRef.
EcuC: EcucModuleDef EcucPostBuildVariants:
EcucPostBuildVariantRef: EcucForeignReferenceDef
+container EcucParamConfContainerDef +reference
lowerMultiplicity = 0 destinationType = PREDEFINED-VARIANT
Generic Structure Template

ARElement
PredefinedVariant +includedVariant 0..*
+postBuildVariantCriterionValueSet 0..*
ARElement
PostBuildVariantCriterionValueSet
+postBuildVariantCriterionValue 0..*
PostBuildVariantCriterionValue
«atpVariation»
+ value: Integer
+variantCriterion 1
ARElement
AtpDefinition
PostBuildVariantCriterion
Figure 3.6: Collection of toplevel PostBuildSelectable variants

Container Name EcucPostBuildVariants
Description Collection of toplevel PostBuildSelectable variants. The PredefinedVariants linked
inside this container will determine how many PostBuildSelectableVariants exist. If this
container exist the name pattern for initialization of BSW modules will be <Mip>_
Config_<PredefinedVariant.shortName>. If this container does not exist the name
pattern for initialization of BSW modlues will be <Mip>_Config.

Parameter Name EcucPostBuildVariantRef
Parent Container EcucPostBuildVariants
5

AUTOSAR CP R22-11
4
Description Reference to a PredefinedVariant that defines one toplevel postBuild configuration set
(covering all post-build capable BSW modules). PredefinedVariants that are referenced
here shall contain only PostBuildVariantCriterionValueSets.
Multiplicity 1..*
Type Foreign reference to PREDEFINED-VARIANT
Link time –
Post-build time –
Link time –
Post-build time –
Scope / Dependency
[constr_3307] ShortNames of PredefinedVariants referenced by EcucPost-

BuildVariantRefs dAll PredefinedVariants that are referenced by EcucPost-
BuildVariantRefs shall have different shortNames.c()
PredefinedVariants may exist in different packages and thus have the same
shortName. The generation of symbols in EcucPostBuildVariants requires these
shortNames to be different.
3.3.4 Variation Resolver Description
In order to support the variant handling approach (see Generic Structure Template [6])
the already given values of system constants are specified in using the collection
SwSystemconstantValueSet. In the EcuC the applicable SwSystemconstant-
ValueSet elements are referenced indirectly via the PredefinedVariant collec-
tion.

AUTOSAR CP R22-11
EcuC: EcucModuleDef
GenericStructureTemplate
+container
+includedVariant 0..*
EcucVariationResolver:
EcucParamConfContainerDef PredefinedVariantRef: EcucForeignReferenceDef ARElement
+reference
PredefinedVariant
lowerMultiplicity = 0 destinationType = PREDEFINED-VARIANT
+swSystemconstantValueSet 0..*
ARElement
SwSystemconstantValueSet
+swSystemconstantValue 0..*
SwSystemconstValue
«atpVariation»
+ value: Numerical
+swSystemconst 1
ARElement
AtpDefinition
SwSystemconst
Figure 3.7: Description of Variation Resolver

Container Name EcucVariationResolver
Description Collection of PredefinedVariant elements containing definition of values for Sw
Systemconst which shall be applied when resolving the variability during ECU
Configuration.

Parameter Name PredefinedVariantRef
Parent Container EcucVariationResolver
Description –
Multiplicity 1..*
Type Foreign reference to PREDEFINED-VARIANT
Link time –
Post-build time –
Link time –
Post-build time –
5

AUTOSAR CP R22-11
4
Scope / Dependency
3.3.5 UnitGroup Assignment
To support the generation of ASAM MCD files UnitGroups may be selected in the
EcuC that are relevant for the MCD system. Please note that the EcucUnitGroupAs-
signment can be used to control the generation of the A2L file in a way that the units
used for calculation are replaced by application domain specific units.
EcuC: EcucModuleDef EcucUnitGroupAssignment:
upperMultiplicity = 1 +container EcucParamConfContainerDef
+reference
EcucUnitGroupRef: EcucForeignReferenceDef
destinationType = UNIT-GROUP
ARElement
UnitGroup
Figure 3.8: Assignment of UnitGroups

Container Name EcucUnitGroupAssignment
Description Collection of UnitGroup references to support the generation of ASAM MCD file.

Parameter Name EcucUnitGroupRef
Parent Container EcucUnitGroupAssignment
Description Optional reference to the UnitGroup to support the generation of ASAM MCD file.
These UnitGroups are selecting a set of units for a specific country.
Multiplicity 1..*
Type Foreign reference to UNIT-GROUP
5

AUTOSAR CP R22-11
4
Link time –
Post-build time –
Link time –
Post-build time –
Scope / Dependency
3.3.6 Definition of Pdus
In order to support the synchronization of Handle IDs (see section 3.4.1) two modules
need to be able to refer to the same Pdu object2 . Therefore a generic Pdu container
has been defined which does not belong to any module but is defined in the EcuC
module.
Since the Pdu flowing through the COM-Stack does not belong to an individual mod-
ule, the "virtual" module EcuC has been introduced in the ECU Configuration. This
module is used to collect configuration information not associated with any specific
standardized module.
The EcucPduCollection may contain several "global" Pdu objects as shown in fig-
ure 3.9. Each Pdu may either represent a FrameTriggering (for Pdus not going
through the Pdu Router: UserDefinedPdus, NmPdus and NPdus) or PduTrigger-
ing (for all other Pdus) belonging to the specific ECU from the AUTOSAR System
Description[2] (ECU Extract). Therefore there is an optional reference to ei-
ther FrameTriggering (SysTPduToFrameTriggeringRef) or PduTriggering
(SysTPduToPduTriggeringRef) element in the System Template. Either SysT-
PduToFrameTriggeringRef or SysTPduToPduTriggeringRef shall be used.
2
For the aspect of the configuration it does not matter what kind of Pdu it is, i.e. I-PDU, L-PDU or
N-PDU.

AUTOSAR CP R22-11
EcucPduCollection: PduIdTypeEnum: +literal UINT8:

EcucParamConfContainerDef EcucEnumerationParamDef EcucEnumerationLiteralDef
+parameter +literal
+literal UINT16:
EcucEnumerationLiteralDef
+literal
PduLengthTypeEnum:
+parameter EcucEnumerationParamDef +literal UINT32:
+subContainer MetaDataType:
+destination
+subContainer
Pdu: EcucParamConfContainerDef MetaDataTypeRef:

+reference EcucReferenceDef
System Template
SysTPduToFrameTriggeringRef:
EcucForeignReferenceDef Identifiable
+reference
upperMultiplicity = 1 FrameTriggering
destinationType = FRAME-TRIGGERING
SysTPduToPduTriggeringRef:
EcucForeignReferenceDef Identifiable
+reference
lowerMultiplicity = 0 PduTriggering
destinationType = PDU-TRIGGERING
PduLength:
+parameter EcucIntegerParamDef
min = 0
max = 4294967295 J1939Requestable:
DynamicLength: upperMultiplicity = 1
+reference EcucPduDefaultPartitionRef: EcucPartition:

EcucReferenceDef +destination EcucParamConfContainerDef
upperMultiplicity = 1 upperMultiplicity = *
+subContainer
EcucPduDedicatedPartitionRef: +destination
EcucPduDedicatedPartition: EcucReferenceDef
+reference
lowerMultiplicity = 0 upperMultiplicity = 1
EcuC Values
+reference EcucPduDedicatedPartitionBswModuleRef:
EcucForeignReferenceDef ARElement
EcucModuleConfigurationValues
destinationType = ECUC-MODULE-CONFIGURATION-VALUES
Figure 3.9: Generic Pdu Container

AUTOSAR CP R22-11

Container Name EcucPduCollection
Parent Container EcucConfigSet
Description Collection of all Pdu objects flowing through the Com-Stack.

Parameter Name PduIdTypeEnum
Parent Container EcucPduCollection
Description The PduIdType is used within the entire AUTOSAR Com Stack except for bus drivers.
The size of this global type depends on the maximum number of PDUs used within one
software module. If no software module deals with more PDUs that 256, this type can
be set to uint8. If at least one software module handles more than 256 PDUs, this type
shall be set to uint16. See AUTOSAR_SWS_CommunicationStackTypes for more
details.
Multiplicity 1
Type EcucEnumerationParamDef
Range UINT16 –
UINT8 –
Scope / Dependency

Parameter Name PduLengthTypeEnum
Description The PduLengthType is used within the entire AUTOSAR Com Stack except for bus
drivers. The size of this global type depends on the maximum length of PDUs to be
sent by an ECU. If no segmentation is used the length depends on the maximum
payload size of a frame of the underlying communication system (for FlexRay
maximum size is 255 bytes, therefore uint8). If segmentation is used it depends on the
maximum length of a segmented N-SDU (in general uint16 is used). See AUTOSAR_
SWS_CommunicationStackTypes for more details.
Multiplicity 1
Range UINT16 –
UINT32 –
UINT8 –
Scope / Dependency
Included Containers
MetaDataType 0..* Meta data serves to transport information through the AUTOSAR
layers. It is transported by the PduInfoType structure via a
separate pointer to a byte array alongside the length of and a
pointer to the payload of the PDU. This container defines the
content of the meta data.
Pdu 0..* One Pdu flowing through the COM-Stack. This Pdu is used by all
Com-Stack modules to agree on referencing the same Pdu.

AUTOSAR CP R22-11

Container Name Pdu
Description One Pdu flowing through the COM-Stack. This Pdu is used by all Com-Stack modules
to agree on referencing the same Pdu.
Link time –

Parameter Name DynamicLength
Parent Container Pdu
Description This parameter defines whether the Pdu has dynamic length (true) or not (false).
Please note that the usage of this attribute is restricted by [constr_3448].
Multiplicity 0..1
Default value –
Link time –
Link time –
Scope / Dependency

Parameter Name J1939Requestable
Description Pdu can be triggered by the J1939 request message.
Multiplicity 0..1
Default value –
Link time –
Link time –
Scope / Dependency

AUTOSAR CP R22-11

Parameter Name PduLength
Description Length of the Pdu in bytes. It should be noted that in former AUTOSAR releases (Rel
2.1, Rel 3.0, Rel 3.1, Rel 4.0 Rev. 1) this parameter was defined in bits.
Multiplicity 1
Range 0 .. 4294967295
Default value –
Link time –
Scope / Dependency

Parameter Name EcucPduDefaultPartitionRef
Description Reference to EcucPartition, where the according Pdu is assigned to.
Multiplicity 0..1
Type Reference to EcucPartition
Link time –
Post-build time –
Link time –
Post-build time –

Parameter Name MetaDataTypeRef
Description Reference to meta data that is transported in the Pdu through the AUTOSAR layers.
Multiplicity 0..1
Type Reference to MetaDataType
Link time –
Post-build time –
Scope / Dependency

Parameter Name SysTPduToFrameTriggeringRef
5

AUTOSAR CP R22-11
4
Description Reference to the FrameTriggering from the SystemTemplate which this Pdu belongs to.
SysTPduToFrameTriggeringRef shall be used for UserDefinedPdus, NmPdus and
NPdus which are not going through the Pdu Router. This reference shall not be used if
SysTPduToPduTriggeringRef exists.
Multiplicity 0..1
Type Foreign reference to FRAME-TRIGGERING
Link time –
Link time –
Scope / Dependency dependency: SysTPduToFrameTriggeringRef shall be used for UserDefinedPdus, Nm
Pdus and NPdus which are not going through the Pdu Router. This reference shall not
be used if SysTPduToPduTriggeringRef exists.

Parameter Name SysTPduToPduTriggeringRef
Description Reference to the PduTriggering from the SystemTemplate which this Pdu represents.
SysTPduToPduTriggeringRef shall be used for all Pdus except UserDefinedPdus, Nm
Pdus and NPdus which are not going through the Pdu Router. For these Pdus, Sys
TPduToFrameTriggeringRef shall be used.
Multiplicity 0..1
Type Foreign reference to PDU-TRIGGERING
Link time –
Link time –
Scope / Dependency dependency: SysTPduToPduTriggeringRef shall be used for all Pdus except User
DefinedPdus, NmPdus and NPdus which are not going through the Pdu Router. This
reference shall not be used if SysTPduToFrameTriggeringRef exists.
Included Containers
EcucPduDedicatedPartition 0..* Module specific container for Pdu to partition assignment.

Container Name EcucPduDedicatedPartition
Description Module specific container for Pdu to partition assignment.
5

AUTOSAR CP R22-11
4
Link time –
Post-build time –

Parameter Name EcucPduDedicatedPartitionBswModuleRef
Parent Container EcucPduDedicatedPartition
Description Reference to BSW module, for which the according dedicated Pdu assignment is valid.
Multiplicity 1
Type Foreign reference to ECUC-MODULE-CONFIGURATION-VALUES
Link time –
Post-build time –

Parameter Name EcucPduDedicatedPartitionRef
Parent Container EcucPduDedicatedPartition
Description Module specific reference to EcucPartition, where the according Pdu is assigned to.
The dedicated partition reference shall overrule the default partition reference for the
respective module.
Multiplicity 1
Link time –
Post-build time –
[TPS_ECUC_06030] Invalid PduLength parameter value configuration

dConfiguring the PduLength larger than the underlying layer supports results in
an invalid configuration.c()
3.3.7 Pdu Meta-Data
Meta-Data of Pdus is supported by a large number of modules of the AUTOSAR com-

munication stack. The Meta-Data transports information through the layers, that is in
general abstracted by the layered architecture. The content of the Meta-Data is defined
by MetaDataType and the relation to a Pdu is created by the MetaDataTypeRef.

AUTOSAR CP R22-11
MetaDataType:
+subContainer MetaDataItemLength:
EcucIntegerParamDef
MetaDataItem:
EcucParamConfContainerDef +parameter min = 1
max = 64
requiresIndex = true
MetaDataItemType: +literal PRIORITY_8:

EcucEnumerationParamDef EcucEnumerationLiteralDef
+literal SOURCE_ADDRESS_16:
+literal TARGET_ADDRESS_16:
+literal ADDRESS_EXTENSION_8:
+literal SOCKET_CONNECTION_ID_16:
+literal LIN_NAD_8:
+parameter EcucEnumerationLiteralDef
+literal CAN_ID_32:
+literal ETHERNET_MAC_64:
+literal PRIORITY_16:
+literal VLAN_16:
+literal SDUTYPE_8:
+literal ACCEPTANCEFIELD_32:
Figure 3.10: Pdu Meta-Data

Container Name MetaDataType
Description Meta data serves to transport information through the AUTOSAR layers. It is
transported by the PduInfoType structure via a separate pointer to a byte array
alongside the length of and a pointer to the payload of the PDU. This container defines
the content of the meta data.
5

AUTOSAR CP R22-11
4
Link time –
Post-build time –
Included Containers
MetaDataItem 1..* The content of meta data in a Pdu consists of an ordered list of
meta data items. This container represents a meta data item that
is contained in meta data of a Pdu.

Container Name MetaDataItem
Parent Container MetaDataType
Description The content of meta data in a Pdu consists of an ordered list of meta data items. This
container represents a meta data item that is contained in meta data of a Pdu.
Attributes: requiresIndex=true
Link time –
Post-build time –

Parameter Name MetaDataItemLength
Parent Container MetaDataItem
Description This parameter defines the length of a meta data item in bytes.
Multiplicity 1
Range 1 .. 64
Default value –
Link time –
Post-build time –

Parameter Name MetaDataItemType
Parent Container MetaDataItem
Description This parameter defines the type of a meta data item.
Multiplicity 1
Range ACCEPTANCEFIELD_32 Acceptance field of CAN XL. Size: 32 bits.
ADDRESS_EXTENSION_8 Address extension field (N_AE) of the mixed
addressing modes with 11bit and 29bit CAN ID of
ISO 15765-2. Size: 8 bits.
5

AUTOSAR CP R22-11
4
CAN_ID_32 CAN ID according to ISO 11898-2, either 29 bits
or 11 bits. Encoding according to Can_IdType.
Size: 32 bits.
ETHERNET_MAC_64 Ethernet MAC address. Size: 64 bits.
LIN_NAD_8 LIN node address as used in the LIN transport
protocol. Size: 8 bits.
PRIORITY_16 CAN XL Priority ID. Size: 16 bits.
PRIORITY_8 Priority field of SAE J1939 IDs, or Ethernet QoS
parameter. Size: 8 bits.
SDUTYPE_8 SDU type of CAN XL. Size: 8 bits.
SOCKET_CONNECTION_ID_16 SoAd socket connection ID. Size: 16 bits.
SOURCE_ADDRESS_16 Source address of CanTp, FrTp, or DoIP
transport protocol messages, or of SAE J1939
messages. Size: 16 bits.
TARGET_ADDRESS_16 Target address of CanTp, FrTp, or DoIP transport
protocol messages, or destination address of
SAE J1939 messages. Size: 16 bits.
VLAN_16 VLAN ID of Ethernet or VCID of CAN XL. Size:
16 bits.
Link time –
Post-build time –
[constr_5059] Ordering of MetaDataItems of a MetaDataType dThe Meta-

DataItems of a MetaDataType shall be ordered according to their MetaDataItem-
Length. MetaDataItems with greater MetaDataItemLength going first.c()
Rationale for the existence of [constr_5059]: This ensures that all MetaDataItems
will be properly aligned without any padding between individual MetaDataItems.
[TPS_ECUC_06086] Relevance of the order of MetaDataItems of an Meta-
DataType dThe order of MetaDataItems of an MetaDataType defines the order
and position of the meta data items in the meta data array of the respective Pdu.c()
3.4 COM-Stack configuration

To cope with the complexity of the COM-Stack configuration, reoccurring patterns have
been applied which will be described in this section. Only the patterns, together with
some examples, are shown. To get detailed specification of the configuration for each
individual module please refer to the actual BSW SWS documents of these modules.

AUTOSAR CP R22-11
3.4.1 Handle IDs
Figure 3.11: Interfaces in the COM-Stack [14]
In figure 3.11 a detailed view of the COM-Stack modules and their interaction is shown.
There are several kinds of interactions between adjacent3 modules.
3.4.1.1 Handle ID concept
The API definitions in the COM-Stack utilize two concepts to achieve the interaction
between adjacent modules:
• Pointers to Pdu data buffer (the Pdu data buffer contains the actual communi-
cated information, depending on the actual layer the interaction happens)
• Handle IDs to identify to what Pdu the pointer is referring to.
A typical API call is for instance:
PduR_ComTransmit(PduIdType ComTxPduId, PduInfoType *PduInfoPtr)
Which BSW Module is actually providing the value of the Handle ID is specified in
the ECU Configuration Parameter Definition of the corresponding BSW Module (see
section 3.4.1.2 for details on the specification).
The choice of the value for a Handle ID is open to the implementation of the providing
module. There might be different strategies to optimize the Handle ID values and
3
Modules are called adjacent if they share an interface, so PduR and Com are adjacent, while PduR
and Can driver are not.

AUTOSAR CP R22-11
therefore the internal structures of the implementation may have an influence on the
choice of the values.
Also the Handle IDs can be chosen freely per module, so a Pdu might be sent from
Com to the PduR with the ID=5 and then the PduR transmits it further to the CanIf with
ID=19. In the configuration information of the PduR it has to be possible to conclude
that if a Pdu arrives from Com with ID=5 it has to be forwarded to the CanIf with ID=19.
It has to be guaranteed that each Pdu does have a unique handle ID within the scope
of the corresponding API. For example: The PduR gets transmission requests from
both, the Com and the Dcm modules. But there are also two distinct APIs defined for
those requests:
• PduR_ComTransmit(...)
• PduR_DcmTransmit(...)
Therefore the PduR can distinguish two Pdus, even when they have the same handle
ID but are requested via different APIs.
Another use-case in the COM-Stack only provides one API for all the callers: the inter-
face layer (CanIf, FrIf, LinIf).
• CanIf_Transmit(...)
Here it has to be guaranteed that each transmit request for a distinct Pdu does have a
unique handle ID.
The actual values of the handle IDs can only be assigned properly when the configu-
ration of one module is completed, since only then the internal data structures can be
defined.
In the next sections the patterns used to define and utilize Handle IDs are described.
3.4.1.2 Definition of Handle IDs
Handle IDs are defined by the module providing the API and used by the module calling
the API. Handle IDs that are used in callback functions (e.g. Tx Confirmation functions
or Trigger Transmit functions) shall be defined by the upper layer module. In the upper
layer module the same HandleId shall be used for the Tx Confirmation and for the Trig-
ger Transmit callback functions. I.e. the module that receives a transmission request
can call the Tx confirmation callback with a different Handle Id than the transmission
request Handle Id. This is a difference to previous releases of AUTOSAR where the Tx
confirmation was called with the same Handle Id.
The ECU Configuration Value description (which holds the actual values of configu-
ration parameters) is structured according to the individual BSW Module instances.
Therefore the ECU Configuration Parameter Definition is also structured in this way.

AUTOSAR CP R22-11
In figure 3.12 an exemplary definition of a partial Can Interface transmit configuration

is shown.
CanIfInitCfg:
+subContainer
CanIfTxPduCanId:
CanIfTxPduCfg: EcucIntegerParamDef
EcucParamConfContainerDef +parameter min = 0
+parameter CanIfTxPduId:
EcucIntegerParamDef
min = 0
max = 4294967295
Figure 3.12: Example of Can Interface Tx configuration
The configuration of the module CanIf may contain several CanIfTxPduConfig ob-
jects.
Each CanIfTxPduConfig object contains information on one Pdu which is coming
from an upper layer (e.g. PduR or Nm) and is going to some Can driver. In this
example the CanIfCanTxPduCanId and CanIfCanTxPduDlc are specified for each
to be transmitted Pdu. There is a similar structure needed for the receive use-case as
well.
Additionally the parameter CanIfCanTxPduId is specified. This integer parameter
will later hold the actual value for the handle ID. So the handle ID value is stored inside
the structure of the defining module.
Since the handle ID CanIfCanTxPduId is part of the container CanIfTxPduConfig
the semantics of the symbolic names can be applied.
The described example only applies for the communication between CanIf and Upper
Layer modules. CanDrv does not support the handle ID concept and indicates TxCon-
firmation using the PduId passed during Can_Write().
[TPS_ECUC_02106] Handle Id which needs to be shared between several mod-
ules d If a configuration parameter holds a handle Id which needs to be shared between
several modules it shall have the symbolicNameValue = true set.c()
Thus it is required that all handle Id values are accessible via a symbolic name refer-
ence (see section 3.4.1.4).

AUTOSAR CP R22-11
3.4.1.3 Agreement on Handle IDs
During the configuration of a module, information for each Pdu flowing through this
module is created (see again figure 3.12: CanIfTxPduConfig) which hold module-
specific configuration information. Now each of these "local" Pdu configurations needs
to be related to a "global" Pdu element (see section 3.3.6) representing information
flowing through the COM-Stack. This is done by introducing a EcucReferenceDef
from the "local" Pdu to the "global" Pdu.
In figure 3.13 this relationship is shown for the PduRDestPdu and the CanIfTxP-
duConfig.
+subContainer +reference +destination
PduRRoutingPaths: PduRDestPdu: PduRDestPduRef: Pdu:
EcucParamConfContainerDef EcucParamConfContainerDef EcucReferenceDef EcucParamConfContainerDef
CanIfTxPduCfg: +reference CanIfTxPduRef: +destination

CanIfInitCfg:
EcucParamConfContainerDef +subContainer EcucParamConfContainerDef EcucReferenceDef
upperMultiplicity = 1 upperMultiplicity = *
CanIfTxPduId:
min = 0
max = 4294967295
Figure 3.13: Transmission from PduR to CanIf
There are two reasons why the "global" Pdu has been introduced and why all "local"
Pdus have to point to the "global" Pdu only.
• When doing the configuration of module PduR only the "global" Pdu needs to be
present, there is no need for the "local" Pdu in the CanIf to be present yet.
• The References are stored in the "local" Pdu structure, so changes applied do
only influence the structure of the changed module.
Taking the structure shown in figure 3.13 it is now possible to generate both modules.
The CanIf (automatic) configuration editor collects all "local" CanIfTxPduConfigs
and generates/stores the values for their handle ID in CanIfCanTxPduId. If the
CanIf needs to know where the Pdu transmit request is coming from it can follow the
PduIdRef to the "global" Pdu and then "query" all references pointing to that Pdu. By
following those references in reversed direction the transmitting module can be found.
The PduR generator has to know which handle ID to use for each Pdu that has to be
sent to the CanIf. To get the actual handle ID value the mechanism is the same in the
CanIf use-case: follow the "global" Pdu reference and "query" the modules pointing to
that "global" Pdu. Then find the module(s) type this Pdu is going to be transmitted to.
In case of a multicast there might be several modules to send the same Pdu to.
With this approach a high degree of decoupling has been achieved between the con-
figuration information of the involved modules. Even when modules are adjacent and

AUTOSAR CP R22-11
need to share information like handle ID, the references between the modules are al-
ways indirect using the "global" Pdu elements.
3.4.1.4 Handle IDs with symbolic names
The usage of handle Ids together with symbolic names is targeting several use-cases
for the methodology of configuring adjacent modules. For the definition of possible
configuration approaches please refer to section A.1.1.
For the discussion of the Handle Id use-cases two basic approaches can be distin-
guished when dividing the methodology into the steps configuration editing and module
generation:
• Handle Ids assigned by the configuration editor
• Handle Ids assigned by the module generator
It is assumed that the configuration and generation of the whole stack is done using
different tools (possibly from different vendors) which might implement one of the two
approaches mentioned above.
In order to support the definition whether a parameter value shall be provided by the
user or whether it will be calculated by the editor / generator tooling the attribute
withAuto has been introduced to the EcucParameterDef (see section 2.3.5).
In requirement [TPS_ECUC_02106] it is required that all handle Ids are represented
as symbolicNameValue = true configuration parameters thus decoupling the value
from its usage.
In requirement [TPS_ECUC_02107] it is required that the assigned values are stored
in the XML (latest after module generation) so the assigned values are documented. In
case the assignment of values has to be performed at a later point in time again (with
updated input information) the non affected values can be preserved. It is also needed
to support debugging.
In requirement [TPS_ECUC_02108] it is required that the handle Id values are always
generated into the module’s header file. With this approach it is possible to freely
choose the configuration approach of the adjacent modules.
This approach has significant effect on the methodology due to the circular depen-
dencies between the adjacent modules( Com sends to the PduR using PduR handle
Ids, PduR indicates to Com using Com handle Ids). Therefore the configuration of all
adjacent modules has to be re-visited in case some handle Id changes happen. This
contributes to the approach that FIRST the configuration of the stack is performed and
SECOND the generation is triggered.
An example of this approach is provided below: By adding the attribute symbolic-
NameValue = true to the parameter holding the handle ID (in figure 3.13 this is the

AUTOSAR CP R22-11
parameter CanIfTxPduId) the code generator doing the CanIf will generate a #de-
fine in the CanIf_cfg.h file.
According to [TPS_ECUC_02108] the name of the symbol is composed of the mod-
ule abbreviation <MA> of the declaring BSW Module followed by the literal "Conf_"
followed by the shortName of the EcucParamConfContainerDef of the declaring mod-
ule followed by the shortName of the EcucContainerValue container which holds the
symbolicNameValue configuration parameter value. The value is the actual number
assigned to that handle ID.
For example in CanIf_cfg.h:
#define CanIfConf_CanIfTxPduCfg_Pdu_2345634_985 17
The benefit is that the generator of the PduR does not need to wait for the CanIf to
be configured completely and handle IDs are generated. If the CanIf publishes the
symbolic names for the handle IDs, the PduR can expect those symbolic names and
generate the PduR code using those symbolic names.
For example in PduR.c:
CanIf_Transmit( CanIfConf_CanIfTxPduCfg_Pdu_2345634_985, PduPtr
)
Therefore the PduR can be generated as soon as its own configuration is finished and
there is no need to wait for the CanIf to be finished completely. However, at least the
"local" Pdu in the CanIf has to be already created to allow this, because the name of
the symbol has to be fetched from this configuration.
Of course the PduR can only be compiled after the CanIf has been generated as well,
but with the utilization of the symbolic names together with handle IDs an even higher
degree of decoupling in the configuration process is achieved.
3.4.2 Configuration examples for the Pdu Router
In this section several use-cases of the PduR are described from the configuration point
of view. The focus is on the interaction of the PduR configuration with the configuration
of the other COM-Stack modules. Therefore only some configuration parameters are
actually shown in these examples.
3.4.2.1 Tx from Com to CanIf
In the example in figure 3.14 a Pdu is sent from the Com module – via the Pdu Router
– to the Can Interface. Since this one Pdu is handed over through these layers there is
only need for one global Pdu object System_Pdu.
The Com module’s configuration points to the System_Pdu to indicate which Pdu shall
be sent. The actual Handle Id which has to be used in the API call will however be

AUTOSAR CP R22-11
defined by the PduR in the parameter PduRSrcPdu::HandleId. In this example the

Com module has to use the Hanlde Id 23 to transmit this Pdu to the PduR.
Then, since the CanIf is pointing to the same System_Pdu the PduR can be configured
to send this Pdu to the CanIf. The Handle Id is defined in the CanIf configuration in the
parameter value of CanIfCanTxPduId.
ComIPdu: PduIdRef: System_Pdu:

EcucContainerValue EcucReferenceValue EcucContainerValue
SrcPduRef:
PduRRoutingPath: PduRSrcPdu: EcucReferenceValue
HandleId:
value = 23
PduRDestPdu: DestPduRef:
EcucContainerValue EcucReferenceValue
CanIfTxPduConfig: PduIdRef:
CanIfCanTxPduId:
value = 6
Figure 3.14: Tx from Com to CanIf example

AUTOSAR CP R22-11
3.4.2.2 Rx from CanIf to Com
In the example in figure 3.15 the reception use-case from the CanIf to the Com module
is configured. Here the Handle Ids are defined in the PduR and the Com module’s
configuration.
ComIPdu: PduIdRef: System_Pdu:

ComRxIPduHandleId:
value = 3
PduRRoutingPath: PduRDestPdu: DestPduRef:

EcucContainerValue EcucContainerValue EcucReferenceValue
SrcPduRef:
PduRSrcPdu: EcucReferenceValue
EcucContainerValue
HandleId:
value = 17
CanIfCanRxPduId: PduIdRef:
Figure 3.15: Rx from CanIf to Com example

AUTOSAR CP R22-11
3.4.2.3 Gateway from CanIf to FrIf
In the example in figure 3.16 the gateway use-case is shown. Since there are two
Pdus involved there are two System_Pdu objects defined: one which is representing
the Can Pdu and one which represents the Fr Pdu. Via the references to these two
System_Pdu objects the gateway is configured.
CanIfCanRxPduId: PduIdRef: System_Can_Pdu:

SrcPduRef:
PduRRoutingPath: PduRSrcPdu: EcucReferenceValue
HandleId:
value = 17
PduRDestPdu: DestPduRef: System_Fr_Pdu:

FrIfTxPdu: PduIdRef:
HandleId:
value = 2
Figure 3.16: Gateway from CanIf to FrIf example
3.4.3 Communication Channel IDs
For the configuration of the control path modules (e.g. Communication manager, state
managers, network managers) the respective channels are identified using a unique
Communication Channel ID approach. This is different than the configuration of the
Pdu Handle IDs of the COM-Stack (see section 3.4.1) where individual Pdu Handle
IDs are configured per module.

AUTOSAR CP R22-11
NmChannelConfig:
(from NmChannelConfig)
+reference
NmComMChannelRef: EcucReferenceDef
+destination
(from NmChannelConfig)
ComMChannel:
EcucParamConfContainerDef +destination
CanNmComMNetworkHandleRef:
lowerMultiplicity = 1 +destination EcucReferenceDef
(from ComM)
(from CanNm)
CanSMComMNetworkHandleRef:
+parameter
EcucReferenceDef
ComMChannelId: requiresSymbolicNameValue = true
EcucIntegerParamDef
+reference
(from CanSM)
max = 255
min = 0
CanSMManagerNetwork:
(from ComM)
(from CanSM)
Figure 3.17: Example of Channel interaction between ComM, Can and Nm
In figure 3.17 the ComMChannel defines a global communication channel and provides
the Communication Channel ID of this channel in the parameter value ComMChan-
nelId. Other modules using communication channels (e.g. Nm, CanSM, CanNm, ...)
refer to the ComMChannel and can utilize the Communication Channel ID in two ways:
• the module does not store the value of the Communication Channel ID itself but
always relies on the value provided by the ComM module (like shown for CanNm).
• the module replicates the value of the Communication Channel ID and requires
that the replicated id value is equal to the one provided by ComM module (like
shown for Nm and CanSM).
Both approaches are currently used in the COM-Stack configuration.
3.5 CDD module

The CDD module describes the minimal requirements that are necessary for the con-
figuration of a Complex Driver with respect to the surrounding standardized BSW mod-
ules.
[TPS_ECUC_06031] Interaction of Complex Driver with standardized AUTOSAR
BSW modules dIf a Complex Driver wants to interact with a surrounding standardized
BSW module it has to define a Vendor Specific Module Definition from the Standardized
CDD Module Definition. The rules that shall be followed when generating the Vendor
Specific Module Definition are described by [TPS_ECUC_06038].c()

AUTOSAR CP R22-11
As defined in [TPS_ECUC_06001] the shortName of a VSMD module shall be the

same as the shortName of the StMD. According to this requirement the shortName
of the module definition of a Complex Driver is always "Cdd".
[TPS_ECUC_06036] Distinction of module definitions of Complex Drivers dTo dis-
tinguish module definitions of Complex Drivers from each other the package structure
shall be used.c()
[TPS_ECUC_06037] apiServicePrefix attribute for Complex Driver module
and Xfrm module dThe module abbreviation of a Complex Driver and Xfrm Module
shall be equal to its apiServicePrefix attribute.c()
[constr_3023] Usage of apiServicePrefix dThe attribute apiServicePrefix is
mandatory for VSMDs derived from the CDD and Xfrm StMD. The attribute shall not
be provided for VSMDs derived from any other StMDs.c()
Consider a Complex Driver named "MyCdd". The VSMD of this Complex Driver has to
be derived from the CDD StMD. The shortName of the module definition of this Com-
plex Driver has to be equal to "Cdd". The apiServicePrefix attribute is mandatory
for the VSMD of this Complex Driver and has to be equal to "MyCdd".
Note that the configuration parameters for the VSMD of CDD do not specify any config-
uration class. It is up to the implementor of the specific CDD to define the configuration
class for all configuration parameters - standardized and vendor specific ones (see
[TPS_ECUC_02139]).
SWS Item [ECUC_Cdd_00016]
Module Name Cdd
Description The CDD module describes the minimal requirements that are necessary for the
configuration of a CDD with respect to the surrounding standardized BSW
modules.
Post-Build Variant Support true
Supported Config Variants VARIANT-LINK-TIME, VARIANT-POST-BUILD, VARIANT-PRE-COMPILE
Included Containers
CddComStackContribution 0..1 Contribution of COM Stack modules.
CddEcucPartitionInteraction 0..1 This optional container holds the partition interaction
configuration.
CddGeneral 0..1 Contains the general configuration parameters of the module.
CddGlobalTimeContribution 0..1 Contribution of Global Time modules.

AUTOSAR CP R22-11
Cdd: EcucModuleDef CddComStackContribution: EcucParamConfContainerDef

+container
CddEcucPartitionInteraction: EcucParamConfContainerDef
+container +parameter CddPartitionStoppedFunctionName:
lowerMultiplicity = 0 EcucFunctionNameDef
EcucPartition:
+reference
CddEcucPartitionRef: +destination lowerMultiplicity = 0
EcucReferenceDef upperMultiplicity = *
CddGlobalTimeContribution:
+container EcucParamConfContainerDef
CddInstanceId:
CddGeneral: +parameter EcucIntegerParamDef
min = 0
+container upperMultiplicity = 1
CddModuleId:
+parameter
EcucIntegerParamDef
min = 255
max = 4095
defaultValue = 255
Figure 3.18: Cdd Module

Container Name CddGeneral
Parent Container Cdd
Description Contains the general configuration parameters of the module.

Parameter Name CddInstanceId
Parent Container CddGeneral
Description Specifies the InstanceId of this module instance. If only one instance is present it shall
have the Id 0.
Multiplicity 1
Range 0 .. 255
Default value –
Link time –
Post-build time –

AUTOSAR CP R22-11

Parameter Name CddModuleId
Parent Container CddGeneral
Description Specifies the ModuleId of this module.
Multiplicity 0..1
Range 255 .. 4095
Default value 255
Link time –
Post-build time –
[constr_5108] CddModuleId range restriction dThe range of CddModuleId is re-

stricted to the value 255 and to the range of values 2048..4095.c()
Container Name CddEcucPartitionInteraction
Description This optional container holds the partition interaction configuration.

Parameter Name CddPartitionStoppedFunctionName
Parent Container CddEcucPartitionInteraction
Description Function name to be called when the partition which is triggering the Complex Driver is
stopped.
Multiplicity 1
Type EcucFunctionNameDef
Default value –
Regular Expression –
Scope / Dependency

Parameter Name CddEcucPartitionRef
Parent Container CddEcucPartitionInteraction
Description Reference to the "EcucPartition" which executes the software which triggers the CDD.
Multiplicity 1
Scope / Dependency

AUTOSAR CP R22-11

Container Name CddComStackContribution
Description Contribution of COM Stack modules.
Included Containers
CddComIfUpperLayerContribution 0..1 Parameters that are necessary for the configuration of a
Complex Driver that serves as the UpperLayer of the Com
Interface module.
CddComMLowerLayerContribution 0..1 Parameters that are necessary for the configuration of a
Complex Driver that serves as the LowerLayer of the
Communication Manager module.
CddGenericNmLowerLayer 0..1 Parameters that are necessary for the configuration of a
Contribution Complex Driver that serves as the LowerLayer of the Generic
NM module.
CddJ1939RmContribution 0..1 Contribution of J1939Rm module
CddPduRLowerLayerContribution 0..1 Parameters that are necessary for the configuration of a
Complex Driver that serves as the LowerLayer of the Pdu Router
module.
CddPduRUpperLayerContribution 0..1 Parameters that are necessary for the configuration of a
Complex Driver that serves as the UpperLayer of the Pdu Router
module.
CddSoAdUpperLayerContribution 0..1 Parameters that are necessary for the configuration of a
Complex Driver that serves as the UpperLayer of the SoAd
module.
The following sections describe particular COM stack modules and the interaction with
Complex Drivers.
3.5.1 Pdu Router
In the AUTOSAR COM Stack upper and lower layer Complex Drivers are allowed to
access the Pdu Router. In both cases the Pdus that are exchanged between the CDD
and the Pdu Router shall be configured. The contribution of the Complex Driver implies
a reference to the global Pdu and the definition of a HandleId. Figure 3.19 shows an
example of a Complex Driver between the CanIf and the PduR and one Complex Driver
above the PduR.

AUTOSAR CP R22-11
Figure 3.19: CDD Example
Figure 3.20 shows the CDD contribution in the configuration model.

Note that the optional presence of the TxPdu and RxPdu does not influence the exis-
tence of the respective APIs in the Cdd.

AUTOSAR CP R22-11
CddPduRUpperLayerContribution: CddPduRUpperLayerTxPdu: +reference CddPduRUpperLayerPduRef: +destination Pdu:


upperMultiplicity = 1 +subContainer upperMultiplicity = * upperMultiplicity = *
CddPduRUpperLayerHandleId:
min = 0
max = 65535
CddPduRUpperLayerRxPdu: +reference CddPduRUpperLayerPduRef: +destination

+subContainer upperMultiplicity = * CddPduRUpperLayerHandleId:
EcucIntegerParamDef
+parameter
min = 0
max = 65535
CddPduRLowerLayerPduRef: +destination
CddPduRLowerLayerContribution: CddPduRLowerLayerTxPdu: +reference
EcucReferenceDef
upperMultiplicity = 1 +subContainer upperMultiplicity = * CddPduRLowerLayerHandleId:
EcucIntegerParamDef
+parameter
min = 0
max = 65535
CddPduRLowerLayerRxPdu: +reference CddPduRLowerLayerPduRef: +destination

+subContainer lowerMultiplicity = 0
CddPduRLowerLayerHandleId:
EcucIntegerParamDef
+parameter
min = 0
max = 65535
CddComIfPduRef: +destination
CddComIfUpperLayerContribution: CddComIfUpperLayerTxPdu:
upperMultiplicity = 1 CddComIfHandleId:
+subContainer upperMultiplicity = *
EcucIntegerParamDef
+parameter
min = 0
max = 65535
CddComIfPduRef: +destination
CddComIfUpperLayerRxPdu:
+subContainer upperMultiplicity = *
CddComIfHandleId:
EcucIntegerParamDef
+parameter
min = 0
max = 65535
Figure 3.20: PduR and Com Interface contribution

AUTOSAR CP R22-11
CddPduRUpperLayerTxPdu: CddPduRApiType:
EcucParamConfContainerDef +parameter EcucEnumerationParamDef
CddPduRUpperLayerRxPdu:
EcucParamConfContainerDef +parameter
CddPduRLowerLayerTxPdu:
upperMultiplicity = * +literal IF:
CddPduRLowerLayerRxPdu:
+literal TP:
lowerMultiplicity = 0 EcucEnumerationLiteralDef
CddSoAdUpperLayerTxPdu:
CddSoAdUpperLayerRxPdu:
Figure 3.21: Configuration of the CDD interface API type

Container Name CddPduRUpperLayerContribution
Parent Container CddComStackContribution
Description Parameters that are necessary for the configuration of a Complex Driver that serves as
the UpperLayer of the Pdu Router module.
Included Containers
CddPduRUpperLayerRxPdu 0..* This container specifies Rx PDUs that are exchanged between
the CDD and the standardized BSW module.
CddPduRUpperLayerTxPdu 0..* This container specifies Tx PDUs that are exchanged between

Container Name CddPduRLowerLayerContribution
the LowerLayer of the Pdu Router module.

AUTOSAR CP R22-11
Included Containers
CddPduRLowerLayerRxPdu 0..* This container specifies Rx PDUs that are exchanged between
CddPduRLowerLayerTxPdu 0..* This container specifies Tx PDUs that are exchanged between

Container Name CddPduRUpperLayerTxPdu
Parent Container CddPduRUpperLayerContribution
Description This container specifies Tx PDUs that are exchanged between the CDD and the
standardized BSW module.

Parameter Name CddPduRApiType
Parent Container CddPduRUpperLayerTxPdu
Description This parameter configures the type of the CDD interface (IF/TP)
Multiplicity 0..1
Range IF –
TP –
Scope / Dependency

Parameter Name CddPduRUpperLayerHandleId
Description ECU wide unique, symbolic handle for the Pdu.
Multiplicity 0..1
Type EcucIntegerParamDef (Symbolic Name generated for this parameter)
Range 0 .. 65535
Default value –
Scope / Dependency

Parameter Name CddPduRUpperLayerPduRef
Description Reference to the "global" Pdu structure to allow harmonization of handle IDs in the
COM-Stack.
Multiplicity 1
Type Reference to Pdu
Scope / Dependency

AUTOSAR CP R22-11

Container Name CddPduRUpperLayerRxPdu
Parent Container CddPduRUpperLayerContribution
Description This container specifies Rx PDUs that are exchanged between the CDD and the

Parent Container CddPduRUpperLayerRxPdu
Multiplicity 0..1
Range IF –
TP –
Scope / Dependency

Parameter Name CddPduRUpperLayerHandleId
Multiplicity 0..1
Range 0 .. 65535
Default value –
Scope / Dependency

Parameter Name CddPduRUpperLayerPduRef
COM-Stack.
Multiplicity 1
Scope / Dependency

Container Name CddPduRLowerLayerTxPdu
Parent Container CddPduRLowerLayerContribution
5

AUTOSAR CP R22-11
4

Parent Container CddPduRLowerLayerTxPdu
Multiplicity 0..1
Range IF –
TP –
Scope / Dependency

Parameter Name CddPduRLowerLayerHandleId
Multiplicity 0..1
Range 0 .. 65535
Default value –
Scope / Dependency

Parameter Name CddPduRLowerLayerPduRef
COM-Stack.
Multiplicity 1
Scope / Dependency

Container Name CddPduRLowerLayerRxPdu
Parent Container CddPduRLowerLayerContribution

AUTOSAR CP R22-11

Parent Container CddPduRLowerLayerRxPdu
Multiplicity 0..1
Range IF –
TP –
Scope / Dependency

Parameter Name CddPduRLowerLayerHandleId
Multiplicity 0..1
Range 0 .. 65535
Default value –
Scope / Dependency

Parameter Name CddPduRLowerLayerPduRef
COM-Stack.
Multiplicity 1
Scope / Dependency
3.5.2 COM Interface modules
A Complex Driver is not allowed to access the COM Stack modules FrDrv, CanDrv and
LinDrv. For these modules there is no more than one user. Therefore the lower layer
of the COM Stack Bus Interface modules (FrIf, LinIf, CanIf) is not regarded in the CDD
module. Upper layer Complex Drivers are allowed to access the interface of these
modules. Equal to the PduRContribution the CddComIfUpperLayerContribu-
tion of the Complex Driver implies a reference to the global Pdu and the definition of
a HandleId. Figure 3.20 shows the CDD contribution in the configuration model.

AUTOSAR CP R22-11
Note that the optional presence of the TxPdu and RxPdu does not influence the exis-
tence of the respective APIs in the Cdd.
Container Name CddComIfUpperLayerContribution
the UpperLayer of the Com Interface module.
Included Containers
CddComIfUpperLayerRxPdu 0..* This container specifies Rx PDUs that are exchanged between
CddComIfUpperLayerTxPdu 0..* This container specifies Tx PDUs that are exchanged between

Container Name CddComIfUpperLayerTxPdu
Parent Container CddComIfUpperLayerContribution

Parameter Name CddComIfHandleId
Parent Container CddComIfUpperLayerTxPdu
Multiplicity 0..1
Range 0 .. 65535
Default value –
Scope / Dependency

Parameter Name CddComIfPduRef
Parent Container CddComIfUpperLayerTxPdu
COM-Stack.
Multiplicity 1
Scope / Dependency

AUTOSAR CP R22-11

Container Name CddComIfUpperLayerRxPdu
Parent Container CddComIfUpperLayerContribution

Parameter Name CddComIfHandleId
Parent Container CddComIfUpperLayerRxPdu
Multiplicity 0..1
Range 0 .. 65535
Default value –
Scope / Dependency

Parameter Name CddComIfPduRef
Parent Container CddComIfUpperLayerRxPdu
COM-Stack.
Multiplicity 1
Scope / Dependency
3.5.3 Communication Manager
Complex Drivers are allowed to access the Communication Manager on the upper
layer. The contribution of the lower layer Complex Driver implies for each channel a
reference to to the unique handle to identify one certain network handle in the ComM
configuration.
CddComStackContribution: CddComMLowerLayerContribution: CddComMLowerLayerChannel:
EcucParamConfContainerDef +subContainer EcucParamConfContainerDef +subContainer EcucParamConfContainerDef
upperMultiplicity = 1 upperMultiplicity = 1 upperMultiplicity = *
+reference
ComMChannel:
EcucParamConfContainerDef +destination CddComMLowerLayerChannelRef:
EcucReferenceDef
upperMultiplicity = 256 requiresSymbolicNameValue = true
Figure 3.22: ComM lower layer contribution

AUTOSAR CP R22-11

Container Name CddComMLowerLayerContribution
the LowerLayer of the Communication Manager module.
Included Containers
CddComMLowerLayerChannel 1..* This container contains the network specific parameters.

Container Name CddComMLowerLayerChannel
Parent Container CddComMLowerLayerContribution
Description This container contains the network specific parameters.

Parameter Name CddComMLowerLayerChannelRef
Parent Container CddComMLowerLayerChannel
Description Unique handle to identify one certain network. Reference to one of the network
handles configured for the ComM.
Multiplicity 1
Type Symbolic name reference to ComMChannel
Scope / Dependency
3.5.4 Generic Network Management
Complex Drivers are allowed to access the GenericNm module on the upper layer. The
contribution of the lower layer Complex Driver implies in each NmChannel configura-
tion a reference to the respective NM channel handle.
CddComStackContribution: CddGenericNmLowerLayerContribution: CddGenericNmLowerLayerChannel:
EcucParamConfContainerDef +subContainer EcucParamConfContainerDef +subContainer EcucParamConfContainerDef
upperMultiplicity = 1 upperMultiplicity = 1 upperMultiplicity = *
+reference
ComMChannel:
+destination CddGenericNmComMNetworkHandleRef:
EcucReferenceDef
Figure 3.23: GenericNm lower layer contribution

AUTOSAR CP R22-11

Container Name CddGenericNmLowerLayerContribution
the LowerLayer of the Generic NM module.
Included Containers
CddGenericNmLowerLayer 1..* NM Channel specific configuration parameters.
Channel

Container Name CddGenericNmLowerLayerChannel
Parent Container CddGenericNmLowerLayerContribution
Description NM Channel specific configuration parameters.

Parameter Name CddGenericNmComMNetworkHandleRef
Parent Container CddGenericNmLowerLayerChannel
Description This reference points to the unique channel defined by the ComMChannel and
provides access to the unique channel index value in ComMChannelId.
Multiplicity 1
Type Symbolic name reference to ComMChannel
Scope / Dependency
3.5.5 Socket Adaptor
Complex Drivers are allowed to access the SoAd module on the upper layer. The Pdus
that are exchanged between the CDD and the SoAd shall be configured. The contribu-
tion of the Complex Driver implies a reference to the global Pdu and the definition of a
HandleId. Figure 3.24 shows the CDD contribution in the configuration model.

AUTOSAR CP R22-11
CddComStackContribution:
+subContainer
CddSoAdUpperLayerContribution: CddSoAdUpperLayerTxPdu: +reference CddSoAdUpperLayerPduRef: +destination Pdu:

lowerMultiplicity = 0 upperMultiplicity = * lowerMultiplicity = 0
upperMultiplicity = 1 lowerMultiplicity = 0 upperMultiplicity = *
+subContainer
CddSoAdUpperLayerHandleId:
EcucIntegerParamDef
+parameter
min = 0
max = 65535
+parameter
CddPduRApiType: +literal IF:

EcucEnumerationParamDef EcucEnumerationLiteralDef
+literal TP:
+parameter
CddSoAdUpperLayerRxPdu:
EcucParamConfContainerDef +reference CddSoAdUpperLayerPduRef: +destination
EcucReferenceDef
+subContainer
CddSoAdUpperLayerHandleId:
EcucIntegerParamDef
+parameter symbolicNameValue = true
min = 0
max = 65535
Figure 3.24: SoAd contribution

Container Name CddSoAdUpperLayerContribution
the UpperLayer of the SoAd module.
Included Containers
CddSoAdUpperLayerRxPdu 0..* This container specifies Rx PDUs that are exchanged between
CddSoAdUpperLayerTxPdu 0..* This container specifies Tx PDUs that are exchanged between

AUTOSAR CP R22-11

Container Name CddSoAdUpperLayerTxPdu
Parent Container CddSoAdUpperLayerContribution

Parent Container CddSoAdUpperLayerTxPdu
Multiplicity 0..1
Range IF –
TP –
Scope / Dependency

Parameter Name CddSoAdUpperLayerHandleId
Multiplicity 0..1
Range 0 .. 65535
Default value –
Scope / Dependency

Parameter Name CddSoAdUpperLayerPduRef
COM-Stack.
Multiplicity 1
Scope / Dependency

Container Name CddSoAdUpperLayerRxPdu
Parent Container CddSoAdUpperLayerContribution
5

AUTOSAR CP R22-11
4

Parent Container CddSoAdUpperLayerRxPdu
Multiplicity 0..1
Range IF –
TP –
Scope / Dependency

Parameter Name CddSoAdUpperLayerHandleId
Multiplicity 1
Range 0 .. 65535
Default value –
Scope / Dependency

Parameter Name CddSoAdUpperLayerPduRef
COM-Stack.
Multiplicity 1
Scope / Dependency

AUTOSAR CP R22-11
3.5.6 J1939Rm
The J1939Rm provides a CDD interface with several callout functions. To be able to
generate a header file for a CDD that can in turn be included in J1939Rm to make the
callout prototypes available a J1939Rm CDD contribution is available.
Container Name CddJ1939RmContribution
Description Contribution of J1939Rm module

Parameter Name CddJ1939RmAckIndication
Parent Container CddJ1939RmContribution
Description Defines whether the <User>_AckIndication callback function is implemented.
Multiplicity 1
Default value –

Parameter Name CddJ1939RmRequestIndication
Description Defines whether the <User>_RequestIndication callback function is implemented.
Multiplicity 1
Default value –

Parameter Name CddJ1939RmRequestTimeoutIndication
Description Defines whether the <User>_RequestTimeoutIndication callback function is
implemented.
Multiplicity 1
Default value –

AUTOSAR CP R22-11
3.5.7 Global Time Synchronization
Complex Drivers, which implement Timebase Providers for Global Time Synchroniza-
tion, are allowed to access the StbM to manage the synchronized time-bases.
Figure 3.25 shows the CDD contribution in the configuration model.
StbMSynchronizedTimeBase:
Cdd: EcucModuleDef CddGlobalTimeContribution: EcucParamConfContainerDef
+container EcucParamConfContainerDef
upperMultiplicity = * lowerMultiplicity = 0 upperMultiplicity = *
+destination
CddSynSynchronizedTimeBaseRef:
+subContainer
EcucReferenceDef
+reference
CddGlobalTimeDomain: requiresSymbolicNameValue = true
upperMultiplicity = * CddGlobalTimeDomainId:
+parameter
EcucIntegerParamDef
min = 0
max = 31
CddGlobalTimeMaster: CddGlobalTimeSlave:
CddGlobalTimeTxPeriod: EcucParamConfContainerDef EcucParamConfContainerDef
+parameter
EcucFloatParamDef
min = 0.0 upperMultiplicity = 1 upperMultiplicity = 1
CddGlobalTimeMasterPdu: CddGlobalTimeSlavePdu:
+reference +reference
CddGlobalTimeMasterPduRef: CddGlobalTimeSlavePduRef:
EcucReferenceDef EcucReferenceDef
+destination +destination
CddComIfUpperLayerTxPdu: CddComIfUpperLayerRxPdu:
upperMultiplicity = * upperMultiplicity = *
Figure 3.25: Global time contribution

Container Name CddGlobalTimeContribution
Description Contribution of Global Time modules.

AUTOSAR CP R22-11
Included Containers
CddGlobalTimeDomain 1..* This represents the existence of a CDD global time domain. The
CddGlobalTimeContribution can administrate several global time
domains at the same time that in itself form a hierarchy of
domains and sub-domains.

Container Name CddGlobalTimeDomain
Parent Container CddGlobalTimeContribution
Description This represents the existence of a CDD global time domain. The CddGlobalTime
Contribution can administrate several global time domains at the same time that in itself
form a hierarchy of domains and sub-domains.

Parameter Name CddGlobalTimeDomainId
Parent Container CddGlobalTimeDomain
Description The global time domain ID.
Multiplicity 1
Range 0 .. 31
Default value –

Parameter Name CddSynSynchronizedTimeBaseRef
Description Mandatory reference to the required synchronized time-base.
Multiplicity 1
Type Symbolic name reference to StbMSynchronizedTimeBase
Included Containers
CddGlobalTimeMaster 0..1 Configuration of the global time master. Each global time domain
is required to have exactly one global time master. This master
may or may not exist on the configured ECU.
CddGlobalTimeSlave 0..1 Configuration of a global time slave. Each global time domain is
required to have at least one time slave. The configured ECU
may or may not represent a time slave.

Container Name CddGlobalTimeMaster
Description Configuration of the global time master. Each global time domain is required to have
exactly one global time master. This master may or may not exist on the configured
ECU.

AUTOSAR CP R22-11

Parameter Name CddGlobalTimeTxPeriod
Parent Container CddGlobalTimeMaster
Description This represents configuration of the TX period. Unit: seconds
Multiplicity 1
Type EcucFloatParamDef
Range [0 .. INF]
Default value –
Included Containers
CddGlobalTimeMasterPdu 0..1 This container encloses the configuration of the PDU that is
supposed to contain the global time information.
Please note that the configuration of CddGlobalTimeMasterPdu
is optional and shall only be used for Complex Drivers that are
using Pdus for carrying timeSync information.

Container Name CddGlobalTimeSlave
Description Configuration of a global time slave. Each global time domain is required to have at
least one time slave. The configured ECU may or may not represent a time slave.
Included Containers
CddGlobalTimeSlavePdu 0..1 This container encloses the configuration of the PDU that is
supposed to contain the global time information.
Please note that the configuration of CddGlobalTimeSlavePdu is
optional and shall only be used for Complex Drivers that are
using Pdus for carrying timeSync information.

Container Name CddGlobalTimeMasterPdu
Parent Container CddGlobalTimeMaster
Description This container encloses the configuration of the PDU that is supposed to contain the
global time information.
Please note that the configuration of CddGlobalTimeMasterPdu is optional and shall
only be used for Complex Drivers that are using Pdus for carrying timeSync
information.

Parameter Name CddGlobalTimeMasterPduRef
Parent Container CddGlobalTimeMasterPdu
Description This represents the reference to the Pdu taken to transmit the global time information.
The global time master of a global time domain is the sender of this Pdu.
5

AUTOSAR CP R22-11
4
Multiplicity 1
Type Reference to CddComIfUpperLayerTxPdu

Container Name CddGlobalTimeSlavePdu
Parent Container CddGlobalTimeSlave
Description This container encloses the configuration of the PDU that is supposed to contain the
global time information.
Please note that the configuration of CddGlobalTimeSlavePdu is optional and shall only
be used for Complex Drivers that are using Pdus for carrying timeSync information.

Parameter Name CddGlobalTimeSlavePduRef
Parent Container CddGlobalTimeSlavePdu
Description This represents the reference to the Pdu taken to transmit the global time information.
All the time slaves are supposed to receive the Pdu.
Multiplicity 1
Type Reference to CddComIfUpperLayerRxPdu
3.6 EcuM configuration to initialize post-build capable BSW Mod-

ules
The EcuMDriverInitItem contains EcuMModuleRef references to configurations (
EcucModuleConfigurationValues) of module instances which shall be initialized
by EcuM.
EcucModuleConfigurationValues may contain VariationPoints. In order to
initialize a post-build capable BSW module the reference in the VariationPoint to
the PostBuildVariantCriterion with the right PostBuildVariantCriteri-
onValue shall be used (see section 2.4.7).
Which PredefinedVariants exist is defined by EcucPostBuildVariants as de-
scribed in section 3.3.3.

AUTOSAR CP R22-11
3.7 Optional reporting of Production Errors and Extended Produc-

tion Errors
The reporting of Production errors from any BSW Module to the Dem is configurable
(see figure 2.16 for an example). The respective EcucReferenceDefs with the at-
tribute requiresSymbolicNameValue set to true from the reporting module to the
DemEventParameter are optional.
[TPS_ECUC_02143] Optional configuration of Production Error and Extended
Production Error reporting dThe configuration of Production Error and Extended Pro-
duction Error reporting is optional for the reporting BSW module. Due to further func-
tional requirements in the reporting BSW Module it may still be required to detect the
Production Error or Extended Production Error and behave accordingly, even when the
reporting to the Dem is not configured.c()
Another possibility is to configure and report the Production Error or Extended Produc-
tion Error to the Dem and then filter inside the Dem configuration the behavior for this
DemEventParameter such that it will not have an effect.
3.8 Converting time parameters of main functions to ticks

Typically the time related parameters in AUTOSAR are given as float values. Never-
theless for some parameters the unit [ticks] is required. The advantage of having ticks
in the ECU configuration is that the final value is already known before the code gen-
erator is called. Otherwise it depends on the implementer of the code generator what
final value is calculated.
[TPS_ECUC_08010] Ticks in the Ecuc Parameter Value description dAn error shall
be generated if the generated number of ticks with the current main cycle does not
match the desired timing.c()

AUTOSAR CP R22-11
3.9 Clock Tree Configuration

In the standardized ECU Configuration Parameter Definition only HW independent pa-
rameters can be specified. Since the clock tree is highly HW dependent the MCU clock
reference point has been introduced which allows an abstract description of clock prop-
erties independent of the hardware.
Thus the details of the clock tree configuration shall be hardware/vendor specific ad-
ditions to the MCU Driver Configuration added by the implementor of the MCU Driver.
This means, that other drivers (possibly vendor specific), such as CAN Driver, need a
mechanism to derive the correct settings for their timing registers, since they do not
know the actual hardware specific parameters.
The MCU module defines a container McuClockReferencePoint (multiplicity 1..*).
In this container a parameter McuClockReferencePointFrequency (type float, in
Hz) is provided.
McuClockReferencePointFrequency:
EcucFloatParamDef
min = 0
Mcu: EcucModuleDef
max = INF
lowerMultiplicity = 0 +parameter
+container McuClockReferencePoint:
McuModuleConfiguration: McuClockSettingConfig: +subContainer
EcucParamConfContainerDef EcucParamConfContainerDef upperMultiplicity = *
upperMultiplicity = 1 +subContainer lowerMultiplicity = 1
McuClockSettingId:
min = 0
max = 255
McuModeSettingConf: McuMode: EcucIntegerParamDef

+subContainer EcucParamConfContainerDef +parameter
lowerMultiplicity = 1 min = 0
upperMultiplicity = * max = 255
McuRamDefaultValue:
McuRamSectorSettingConf: EcucIntegerParamDef
min = 0
upperMultiplicity = * max = 255
McuRamSectionBaseAddress:
+subContainer
min = 0
max = 4294967295
McuRamSectionSize:
min = 0
max = 4294967295
McuRamSectionWriteSize:
min = 0
max = 4294967295
defaultValue = 8
Figure 3.26: MCU Setting

AUTOSAR CP R22-11
SWS Item [ECUC_Mcu_00174]

Container Name McuClockReferencePoint
Parent Container McuClockSettingConfig
Description This container defines a reference point in the Mcu Clock tree. It defines the frequency
which then can be used by other modules as an input value. Lower multiplicity is 1, as
even in the simplest case (only one frequency is used), there is one frequency to be
defined.
SWS Item [ECUC_Mcu_00175]

Parameter Name McuClockReferencePointFrequency
Parent Container McuClockReferencePoint
Description This is the frequency for the specific instance of the McuClockReferencePoint
container. It shall be given in Hz.
Multiplicity 1
Type EcucFloatParamDef
Range [0 .. INF]
Default value –
Link time –
Scope / Dependency scope: ECU
The ECU integrator and/or MCU configuration/generation tool need to derive from
those required output frequencies - together with other parameters such as input clock
frequency - how its internal settings for prescalers, muxes, etc. need to be configured.
The users of clock frequencies (e.g. CanDrv, LinDrv, PWM) define in their configu-
ration a reference to the container McuClockReferencePoint that allows them to
select which input clock they choose. In that container the modules generator will find
the frequency to use as input frequency (value of parameter McuClockReference-
PointFrequency). The users of clock frequencies might need to adjust the clock
further by setting local prescalers and dividers.
The configuration editor for the peripheral module (i.e. CanDrv configuration editor)
can support the integrator by only allowing a selection of those clock reference points
that can be connected physically to that peripheral.
The design guideline is that all settings until the MCU clock reference point are under
the responsibility of the MCU Driver (see figure 3.27). Further adjustments on the clock
frequency are under the responsibility of the specific user peripheral’s driver.

AUTOSAR CP R22-11
Figure 3.27: Clocktree example

AUTOSAR CP R22-11
4 Rules to follow in different configuration activities

This chapter defines rules relevant for the relation between standardized module defini-
tions and vendor specific module definitions, rules for building the base ECU config-
uration Value description and rules for configuration editors. The generation
of the base ECU configuration Value description as a part of the ECU con-
figuration process is explained in the AUTOSAR Methodology ( [1], chapter 2.7.3 and
chapter 3.6.1.3).
4.1 Deriving vendor specific module definitions from standard-

ized module definitions
The basic relationship between the Vendor Specific Module Definition (ab-
breviated with VSMD in this chapter) and Standardized Module Definition (ab-
breviated StMD in this chapter) is depicted in figure 4.1.
Basic Software Module

Developer
Basic Software Designer 0..1 0..1
«performs»
«performs»
1 «input» «output»
1
Define Vendor Specific
AUTOSAR Standardized ECU Module Definition
Configuration Parameter Definition BSW Module Vendor-
Specific Configuration
Parameter Definition
Figure 4.1: Generating Vendor Specific Module Definitions (per module)
Please note that also a pure VSMD which has no counterpart in the StMD is allowed to
exist. Vendor specific parameters/containers/references with no relationship to StMD
may also be available in a VSMD. Figure 4.2 shows an example with pure vendor
specific containers and references (marked with red color).

AUTOSAR CP R22-11
STMD VSMD
Refine
CanIf VendorX/CanIf
pure vendor specific reference
CanIfTrcvRef DEST-REF (2)
CanIfDriverRef
DEST-REF
CanIfDriverRef
Refine DEST-REF (1)
VendorY/CanDrv pure
CanDrv
vendor specific
reference definition
CanGeneral CanGeneral
CanDrvTrcvChannel
pure vendor specific container
Figure 4.2: Relation between STMD and VSMD
In example 4.1 the StMD of the two modules of figure 4.2 is defined.
Example 4.1
<AR-PACKAGE>
<SHORT-NAME>AUTOSAR</SHORT-NAME>
<AR-PACKAGES>
<AR-PACKAGE>
<ELEMENTS>
<ECUC-MODULE-DEF>
<CONTAINERS>
<SHORT-NAME>CanIfDriver</SHORT-NAME>
<REFERENCES>
<SHORT-NAME>CanIfDriverRef</SHORT-NAME>
AUTOSAR/EcucDefs/CanDrv/CanGeneral</DESTINATION-REF>
</REFERENCES>
</CONTAINERS>
</ECUC-MODULE-DEF>
<ECUC-MODULE-DEF>
<SHORT-NAME>CanDrv</SHORT-NAME>
<CONTAINERS>
<SHORT-NAME>CanGeneral</SHORT-NAME>

AUTOSAR CP R22-11
</CONTAINERS>
</ECUC-MODULE-DEF>
</ELEMENTS>
</AR-PACKAGE>
</AR-PACKAGES>
</AR-PACKAGE>
In Example 4.2 the VSMD of a CanDrv implementation is shown. Here a vendor

specific container CanDrvTrcvContainer has been introduced.
Example 4.2
<AR-PACKAGE>
<SHORT-NAME>VendorX</SHORT-NAME>
<ELEMENTS>
<ECUC-MODULE-DEF>
<REFINED-MODULE-DEF-REF DEST="ECUC-MODULE-DEF">/AUTOSAR/EcucDefs/
CanIf</REFINED-MODULE-DEF-REF>
<CONTAINERS>
<SHORT-NAME>CanIfDriver</SHORT-NAME>
<REFERENCES>
AUTOSAR/EcucDefs/CanDrv/CanGeneral</DESTINATION-REF>
<SHORT-NAME>CanIfDrvTrcvRef</SHORT-NAME>
VendorY/CanDrv/CanDrvTrcvChannel</DESTINATION-REF>
</REFERENCES>
</CONTAINERS>
</ECUC-MODULE-DEF>
</ELEMENTS>
</AR-PACKAGE>
In Example 4.3 the VSMD of a CanIf implementation is shown. The implicitly refined
reference CanIfDriverRef still has the DESTINATION-REF in the VSMD pointing to
the standardized AUTOSAR short-name path.
Additionally the pure vendor specific reference CanIfTrcvRef has been introduced
which points to the vendor specific container CanDrvTrcvContainer using the
DESTINATION-REF with a fully qualified vendor specific short-name path.
Example 4.3
<AR-PACKAGE>
<SHORT-NAME>VendorY</SHORT-NAME>

AUTOSAR CP R22-11
<ELEMENTS>
<ECUC-MODULE-DEF>
<SHORT-NAME>CanDrv</SHORT-NAME>
CanDrv</REFINED-MODULE-DEF-REF>
<CONTAINERS>
<SHORT-NAME>CanTrcvChannel</SHORT-NAME>
</CONTAINERS>
</ECUC-MODULE-DEF>
</ELEMENTS>
</AR-PACKAGE>
[TPS_ECUC_06038] Rules to validate a BSW module implementation dThe follow-

ing rules shall be checked by tools that validate whether a SW module implementation
conforms to its AUTOSAR specification.c()
• [TPS_ECUC_01001] lowerMultiplicity and upperMultiplicity of
modules in the VSMD dThe lowerMultiplicity of the module in the VSMD
shall be equal or bigger to what is defined in the StMD. The upperMultiplic-
ity of that module shall be equal or less to what is defined in the StMD. StMD
lowerMult ≤ VSMD lowerMult ≤ VSMD upperMult ≤ StMD upperMult.c(RS_-
ECUC_00002)
• [TPS_ECUC_06001] shortName of a VSMD module dThe shortName of a
VSMD module shall be the same as the shortName of the StMD.c(RS_ECUC_-
00086)
• [TPS_ECUC_06049] Restriction of supportedConfigVariants in the
VSMD dThe supported EcucModuleDef.supportedConfigVariant shall be
restricted in the VSMD to the actually supported configuration variants of this
implementation. This can be a subset of the EcucModuleDef.supportedCon-
figVariant in the StMD.c()
• [TPS_ECUC_06003] Package structure of the VSMD dThe package structure
of the VSMD has to be different than "/AUTOSAR/EcucDefs/" so that it is pos-
sible to distinguish the standardized from the vendor specific module definitions.
Example 4.4 shows the difference between the VSMD and StMD. The package
structure of the vendor specific CanIf module definition begins with "/VendorX/-
CanIf" and the package structure of the vendor specific CanDrv module definition
begins with "/VendorY/Can".c()
• [TPS_ECUC_06015] DESTINATION-REF in the VSMD dThe DESTINATION-
REF in the VSMD shall point to the standardized AUTOSAR short-name path
(e.g. /AUTOSAR/EcucDefs/Can/CanController) if the reference definition has an

AUTOSAR CP R22-11
STMD counterpart. In this case the vendor specific short-name path (e.g. /Ven-
dorX/Can) shall not be used. Example 4.4 shows a DESTINATION-REF from the
CanIf module provided from VendorX to the CanDrv module provided by VendorY.
The DESTINATION-REF content is not changed from "/AUTOSAR/EcucDefs/..."
in the VSMD.c()
• [TPS_ECUC_06046] Vendor specific reference definition with no counter-
part in the STMD dA pure vendor specific reference definition (which has no
counterpart in the STMD) can refer either
– to a standardized container (has a counterpart in the STMD) or
– to a vendor specific container.
In either case it is possible to use the fully qualified vendor specific short-name
path for the DESTINATION-REF. Only for the first option (reference to standard-
ized container) it is alternatively possible to use the standardized AUTOSAR
short-name path.c()
Example 4.4
CanIf and CanDrv AUTOSAR standardized XML:

<AR-PACKAGE>
<SHORT-NAME>AUTOSAR</SHORT-NAME>
<AR-PACKAGES>
<AR-PACKAGE>
<ELEMENTS>
<ECUC-MODULE-DEF>
<CONTAINERS>
<SHORT-NAME>CanIfDriverConfig</SHORT-NAME>
<REFERENCES>

AUTOSAR/EcucDefs/Can/CanGeneral</DESTINATION-REF>
</REFERENCES>
</CONTAINERS>
</ECUC-MODULE-DEF>
<ECUC-MODULE-DEF>
<SHORT-NAME>Can</SHORT-NAME>
<CONTAINERS>
<PARAMETERS>

</PARAMETERS>
</CONTAINERS>

AUTOSAR CP R22-11
</ECUC-MODULE-DEF>
</ELEMENTS>
</AR-PACKAGE>
</AR-PACKAGES>
</AR-PACKAGE>
CanIf VendorX XML:

<AR-PACKAGE>
<SHORT-NAME>VendorX</SHORT-NAME>
<ELEMENTS>
<ECUC-MODULE-DEF>
CanIf</REFINED-MODULE-DEF-REF>
<CONTAINERS>
<SHORT-NAME>CanIfDriverConfig</SHORT-NAME>
<REFERENCES>

AUTOSAR/EcucDefs/Can/CanGeneral</DESTINATION-REF>
</REFERENCES>
</CONTAINERS>
</ECUC-MODULE-DEF>
</ELEMENTS>
</AR-PACKAGE>
CanDrv VendorY XML:

<AR-PACKAGE>
<SHORT-NAME>VendorY</SHORT-NAME>
<ELEMENTS>
<ECUC-MODULE-DEF>
<SHORT-NAME>Can</SHORT-NAME>
<REFINED-MODULE-DEF-REF DEST="ECUC-MODULE-DEF">/AUTOSAR/EcucDefs/Can<
/REFINED-MODULE-DEF-REF>
<CONTAINERS>
<PARAMETERS>

</PARAMETERS>
</CONTAINERS>
</ECUC-MODULE-DEF>
</ELEMENTS>
</AR-PACKAGE>
For all EcucContainerDefs and EcucParameterDefs and EcucAbstractRef-

erenceDefs defined within the EcucModuleDef in the StMD, it holds:

AUTOSAR CP R22-11
• [TPS_ECUC_06007] Elements defined in the StMD shall be present in the

VSMD dElements defined in the StMD shall be present in the VSMD and shall
not be omitted, even if the upperMultiplicity of an element in the VSMD is
set to 0.c(RS_ECUC_00002, RS_ECUC_00055, RS_ECUC_00070)
• [TPS_ECUC_06008] lowerMultiplicity and upperMultiplicity of el-
ements in the VSMD dThe lowerMultiplicity of an element in the VSMD
shall be bigger or equal and the upperMultiplicity shall be equal or less
than in the StMD:
StMD lowerMult ≤ VSMD lowerMult ≤ VSMD upperMult ≤ StMD upperMult.c()
[TPS_ECUC_08005] The value of the EcucContainerDef.multiplicity-
ConfigClass attribute in the VSMD in case it is not defined in the StMD
dIf the multiplicityConfigClass attribute of an EcucContainerDef is not
defined in the StMD, it shall be defined in the VSMD for all EcucContainerDefs
that have upperMultiplicity greater than lowerMultiplicity. This in-
cludes vendor specific EcucContainerDefs.c()
• [TPS_ECUC_08006] The value of the EcucContainerDef.multiplicity-
ConfigClass attribute in the VSMD in case it is defined in the StMD dIf
the multiplicityConfigClass attribute of an EcucContainerDef is de-
fined in the StMD and its upperMultiplicity is greater than lowerMulti-
plicity, multiplicityConfigClass.configClass for each multiplic-
ityConfigClass.configVariant in the VSMD shall be the same or higher
(where PreCompile is considered to be the lowest and PostBuild the highest)
as in the StMD with respect to the selected subset defined by the actually imple-
mented supportedConfigVariant of the corresponding EcucModuleDef.c
()
• [TPS_ECUC_08036] The value of the EcucParameterDef.valueCon-
figClass and the EcucAbstractReferenceDef.valueConfigClass at-
tributes in the VSMD in case they are not defined in the StMD dIf the value-
ConfigClass attribute for an EcucParameterDef or an EcucAbstractRe-
ferenceDef is not defined in the StMD, it shall be defined in the VSMD for all
EcucParameterDefs and EcucAbstractReferenceDefs.c()
• [TPS_ECUC_08037] The value of the EcucParameterDef.multiplicity-
ConfigClass and the EcucAbstractReferenceDef.multiplicityCon-
figClass attributes in the VSMD in case they are not defined in the StMD
dIf the multiplicityConfigClass attribute for an EcucParameterDef or an
EcucAbstractReferenceDef is not defined in the StMD, it shall be defined in
the VSMD for all EcucParameterDefs and EcucAbstractReferenceDefs.c
()

AUTOSAR CP R22-11
• [TPS_ECUC_08038] The value of the EcucParameterDef.valueCon-

figClass and the EcucAbstractReferenceDef.valueConfigClass at-
tributes in the VSMD in case they are defined in the StMD dIf the valueCon-
figClass attribute for an EcucParameterDef or an EcucAbstractRefer-
enceDef is defined in the StMD, valueConfigClass.configClass for each
valueConfigClass.configVariant in the VSMD shall be the same or higher
(where PreCompile is considered to be the lowest and PostBuild the highest)
as in the StMD with respect to the selected subset defined by the actually imple-
mented supportedConfigVariant of the corresponding EcucModuleDef.c
()
• [TPS_ECUC_08039] The value of the EcucParameterDef.multiplicity-
ConfigClass and the EcucAbstractReferenceDef.multiplicityCon-
figClass attributes in the VSMD in case they are defined in the StMD dIf the
multiplicityConfigClass attribute for an EcucParameterDef or an Ecu-
cAbstractReferenceDef is defined in the StMD, multiplicityConfig-
Class.configClass for each multiplicityConfigClass.configVari-
ant in the VSMD shall be the same or higher (where PreCompile is considered
to be the lowest and PostBuild the highest) as in the StMD with respect to the
selected subset defined by the actually implemented supportedConfigVari-
ant of the corresponding EcucModuleDef.c()
• [TPS_ECUC_08021] The value of the EcucModuleDef.postBuildVari-
antSupport attribute in the VSMD in case it is not defined in the StMD dIf
the postBuildVariantSupport attribute for an EcucModuleDef is not de-
fined in the StMD, the corresponding VSMD can set it to either false or true.c
()
antSupport attribute in the VSMD in case it set to false in the StMD dIf the
postBuildVariantSupport attribute for an EcucModuleDef is set to false,
the corresponding VSMD shall also set it to false.c()
This means that if the value of the postBuildVariantSupport attribute for
one BSW module is set to false in the StMD, this BSW module does not support
variation points bound at post-build time.
antSupport attribute in the VSMD in case it is set to true in the StMD
dIf the postBuildVariantSupport attribute for an EcucModuleDef is set to
true, the corresponding VSMD can set it to either false or true.c()
This means that if the value of the postBuildVariantSupport attribute for
one BSW module is set to true in the StMD, this BSW module supports variation
points bound at post-build time which may or may not be used.
• [TPS_ECUC_08025] The value of the EcucContainerDef.postBuildVari-
antMultiplicity attribute in the VSMD in case it is not defined in the
StMD dIf the EcucModuleDef.postBuildVariantSupport is set to true and

AUTOSAR CP R22-11
the postBuildVariantMultiplicity attribute of an EcucContainerDef in

this EcucModuleDef in the StMD is not defined, it shall be defined in the VSMD
for all EcucContainerDefs that have upperMultiplicity greater than low-
erMultiplicity. This includes vendor specific EcucContainerDefs.c()
antMultiplicity attribute in the VSMD in case it is set to false in the
StMD dIf the EcucModuleDef.postBuildVariantSupport is set to true and
the postBuildVariantMultiplicity attribute of an EcucContainerDef in
this EcucModuleDef in the StMD is set to false, the corresponding VSMD may
set it to either false or true (if [constr_5506] is fulfilled).c()
antMultiplicity in the VSMD in case it is set to true in the StMD dIf the
EcucModuleDef.postBuildVariantSupport is set to true and the post-
BuildVariantMultiplicity attribute of an EcucContainerDef in this
EcucModuleDef in the StMD is set to true, the corresponding VSMD shall
also set it to true.c()
• [TPS_ECUC_08028] The value of the EcucParameterDef.postBuildVari-
antMultiplicity and the EcucAbstractReferenceDef.postBuild-
VariantMultiplicity attributes in the VSMD in case they are not de-
fined in the StMD dIf the EcucModuleDef.postBuildVariantSupport is
set to true and the postBuildVariantMultiplicity for an EcucParam-
eterDef or an EcucAbstractReferenceDef in this EcucModuleDef in the
StMD is not defined, it shall be defined in the VSMD for all EcucParameterDefs
and EcucAbstractReferenceDefs that have upperMultiplicity greater
than lowerMultiplicity. This includes vendor specific EcucParameter-
Defs and EcucAbstractReferenceDefs.c()
• [TPS_ECUC_08029] The value of the EcucParameterDef.postBuild-
VariantValue and the EcucAbstractReferenceDef.postBuildVari-
antValue attributes in the VSMD in case they are not defined in the StMD
dIf the EcucModuleDef.postBuildVariantSupport is set to true and the
postBuildVariantValue for an EcucParameterDef or an EcucAbstrac-
tReferenceDef in this EcucModuleDef in the StMD is not defined, it shall be
defined in the VSMD for all EcucParameterDefs and EcucAbstractRefer-
enceDefs. This includes vendor specific EcucParameterDefs and EcucAb-
stractReferenceDefs.c()
antValue attributes in the VSMD in case they are set to false in the StMD
tReferenceDef in this EcucModuleDef in the StMD is set to false, the cor-
responding VSMD may set it to either false or true.c()

AUTOSAR CP R22-11

VariantMultiplicity attributes in the VSMD in case they are set to
false in the StMD dIf the EcucModuleDef.postBuildVariantSupport is
set to true and the postBuildVariantMultiplicity for an EcucParam-
eterDef or an EcucAbstractReferenceDef in this EcucModuleDef in the
StMD is set to false, the corresponding VSMD may set it to either false or
true.c()
antValue attributes in the VSMD in case they are set to true in the StMD
tReferenceDef in this EcucModuleDef in the StMD is set to true, the corre-
sponding VSMD shall also set it to true.c()
VariantMultiplicity attributes in the VSMD in case they are set to true
in the StMD dIf the EcucModuleDef.postBuildVariantSupport is set to
true and the postBuildVariantMultiplicity for an EcucParameter-
Def or an EcucAbstractReferenceDef in this EcucModuleDef in the StMD
is set to true, the corresponding VSMD shall also set it to true.c()
• [TPS_ECUC_01034] ShortName of elements in the VSMD that are taken over
from the StMD dElements taken over from the StMD to the VSMD shall use
exactly the same shortName, since the short name identifies the element. This
holds for container definitions and individual parameters.c()
• [TPS_ECUC_01035] UUID of elements in the VSMD that are taken over from
the StMD dElements taken over from the StMD to the VSMD shall have unique
uuid in each Value description. Thus a new uuid might be generated when
taking over an element.c()
• [TPS_ECUC_01005] Origin attribute of parameters in the VSMD that are
taken over from the StMD dThe origin attribute shall not be changed for any
parameter taken over from the StMD, even when attributes of the parameter are
modified in the VSMD.c()
• [TPS_ECUC_01006] DefaultValues of parameters in the VSMD dThe de-
faultValue attribute may be changed (or added, if missing).c()
• [TPS_ECUC_01007] min, max values of parameters in the VSMD dThe min
values specified in the VSMD shall be bigger or equal, the max value shall be
less or equal than the corresponding value specified in the StMD:
c() StMD minValue ≤ VSMD minValue ≤ VSMD maxValue ≤ StMD maxValue.
• [TPS_ECUC_06045] min, max values of parameters in the VSMD in case that
the min or max value in the StMD is set to infinite dIf the min value equals -inf

AUTOSAR CP R22-11
or the max value equals inf in the StMD the min/max values in the VSMD shall
be replaced with the actually supported min/max values for this implementation.c
()
• [TPS_ECUC_01009] Calculation of derived parameters in the StMD may
change in the VSMD dFor derived parameters defined in the StMD, the values
of the calculationFormula and calculationLanguage may change in the
VSMD.c()
• [TPS_ECUC_01011] Vendor specific choices in EcucChoiceContain-
erDefs dAdditional vendor specific choices (i.e. aggregated EcucParam-
ConfContainerDefs) may be added to EcucChoiceContainerDefs in the
VSMD.c(RS_ECUC_00002)
• [TPS_ECUC_01013] Vendor specific destinations in EcucChoiceRef-
erenceDefs dAdditional vendor specific references may be added for Ecuc-
ChoiceReferenceDefs in the VSMD.c(RS_ECUC_00002)
• [TPS_ECUC_01014] Addition of vendor specific parameter definitions, con-
tainer definitions and references dAdditional vendor specific parameter defini-
tions, container definitions and references shall be added to the VSMD according
to the alphabetical order.c(RS_ECUC_00002)
• [TPS_ECUC_01015] Origin attribute in vendor specific elements dThe ori-
gin attribute of vendor specific additional elements shall contain the name of the
vendor that defines the element.c(RS_ECUC_00002)
• [TPS_ECUC_02084] Addition of vendor specific EcucEnumerationLiter-
alDefs to an EcucEnumerationParamDef from the StMD dFor an EcucEnu-
merationParamDef from the StMD there can be additional EcucEnumera-
tionLiteralDefs added in the VSMD if the scope of the EcucEnumera-
tionParamDef is local.c()
• [TPS_ECUC_05002] Creation of VSMD from the StMD dInduce VSMD into the
StMD in a simplified manner, so that the configuration can be carried out without
any disarray.c(RS_ECUC_00002)
• [TPS_ECUC_05003] desc field of parameters in VSMD dThe desc in VSMD
can be used to specify detailed information about the respective parameter.c
(RS_ECUC_00002)
• [TPS_ECUC_02134] requiresIndex setting in the VSMD dThe re-
quiresIndex setting may be changed in the VSMD.c()
• [TPS_ECUC_02137] EcucValidationConditions from the StMD shall be
taken over to the VSMD. dIf the StMD defines any ecucValidationConds
they shall be taken to the VSMD.c()

AUTOSAR CP R22-11
• [TPS_ECUC_02138] Addition of vendor specific EcucValidationCondi-

tions dAdditional ecucValidationConds may be added to the VSMD. Se-
mantically they shall provide more restrictive validation conditions than the ones
defined in the StMD.c()
Figure 4.3 shows an overview about rules, which shall be checked by tools that validate
whether a SW module implementation conforms to its AUTOSAR specification. In this
example three parameters are defined in the StMD.
The multiplicity in each of these parameter definitions specifies how often a parameter
is allowed to occur in the ECU Configuration Value description. In the VSMD optional
elements (with lowerMultiplicity = 0) shall be present, but the lowerMulti-
plicity and upperMultiplicity may be set to 0, as it happens with parameter A
(1). The lowerMultiplicity of parameters in the VSMD shall be bigger or equal
than in the StMD (1, 2, 3). The upperMultiplicity of parameters in the VSMD
shall be equal (2) or less (1, 3) than in the StMD. New vendor specific parameters may
also be added in the VSMD (4).
The VSMD defines which parameters are available in which container and what kind of
restrictions are to be respected.
[TPS_ECUC_06009] Existence of a parameter in the Ecuc Parameter Value de-
scription in case the upperMultiplicity of the parameter definition is zero dIf the
upperMultiplicity of a parameter definition in the VSMD is 0, the parameter may
be omitted in the parameter Value description. If such a parameter exists in the param-
eter Value description it shall be ignored by the tool (5).c(RS_ECUC_00082)
[TPS_ECUC_06010] Existence of a parameter in the Ecuc Parameter Value de-
scription in case the lowerMultiplicity of the parameter definition is bigger than
zero dIf the lowerMultiplicity of a parameter definition is bigger than 0, the pa-
rameter shall exist in the parameter Value description (6).c(RS_ECUC_00082)
[TPS_ECUC_06011] Missing parameters in the Ecuc Parameter Value description
dMissing parameters shall be detected by tools (8).c()
[TPS_ECUC_06012] Parameters without parameter definitions in the Ecuc Param-
eter Value description dIf Parameters without parameter definitions exist this shall be
reported latest during code generation (9).c()
[TPS_ECUC_06013] Number of parameters in the Ecuc Parameter Value descrip-
tion dThe number of parameters in the ECUC Value description shall not exceed
the upperMultiplicity of the parameter definition in the VSMD (7).c(RS_ECUC_-
00082)

AUTOSAR CP R22-11
Standardized MD VSMD Param Value
1 5
Param A Param A
a=8
0..1 0..0
2 Param B 6
b=15
1..1
Param B
Container Container
1..1 3 7
Param C
c=16
0..255
Container
Param C 4 Param D
0..* c=8
1..1 8
d=2
9
e=5
Figure 4.3: Relation between standardized module definition and vendor specific module
definition
Example 4.5 depicts the usage of VSMD in case of parameter definition.
Example 4.5
<SHORT-NAME>ClockRate</SHORT-NAME>
<SHORT-NAME>VendorExtensionEnabled</SHORT-NAME>
<ORIGIN>VendorXYZ_v1.3</ORIGIN>
Example 4.6 depicts the usage of VSMD in case of parameter description.
Example 4.6
<DEFINITION-REF DEST="ECUC-INTEGER-PARAM-DEF">/VendorXYZ/Mcu/McuGeneral/
ClockRate</DEFINITION-REF>
<VALUE>123</VALUE>
<DEFINITION-REF DEST="ECUC-BOOLEAN-PARAM-DEF">/VendorXYZ/Mcu/McuGeneral/
VendorExtensionEnabled</DEFINITION-REF>
<VALUE>1</VALUE>
In case of a CDD module the configuration parameters for the VSMD of CDD do not
specify any configuration class. It is up to the implementor of the specific CDD to de-
fine the configuration class for all configuration parameters - standardized and vendor
specific ones.

AUTOSAR CP R22-11
[TPS_ECUC_02139] Definition of configuration classes for all CDD configuration

parameters and references dFor the CDD module the standardized configuration pa-
rameters do not specify any configuration class. It is up to the implementor of the
specific CDD module to define the configuration class for all configuration parameters
- standardized and vendor specific ones in the VSMD.c()
[TPS_ECUC_02144] Definition of supported config variants for CDD dFor the CDD
module the standardized configuration does not specify any supported configuration
variants. It is up to the implementor of the specific CDD module to define the configu-
ration variant in the VSMD (therefore [TPS_ECUC_06049] does not apply).c()
4.2 Rules for building the Base ECU configuration

The AUTOSAR Methodology ( [1], chapter 2.7.3 and chapter 3.6.1.3) defines the activ-
ity how to generate the base ECU configuration Value description. The following rules
apply during generation of the base ECU configuration for a module:
• [TPS_ECUC_01016] Generation of instances for mandatory definitions dFor
mandatory containers, parameters and references (i.e. with lowerMultiplic-
ity > 0 in their definition) at least the number of instances defined by the low-
erMultiplicity shall be generated.c()
E.g. the configuration of a CAN controller may contain the configuration of one
or more hardware objects, depending on the hardware. The configuration of
hardware objects is done in a subcontainer. Since at least one hardware object is
always present, one instance of this subcontainer always has to be present and
shall be generated together with the enclosing container for the CAN controller.
• [TPS_ECUC_01017] Generation of instances for optional definitions dFor
optional containers, parameters and references (i.e. with lowerMultiplicity
= 0 in their definition), no instances may be generated.c()
E.g. the configuration may contain the definition of RX PDUs in a subcontainer.
One subcontainer instance is defined for each PDU received. Since there may be
no RX PDUs, it is well possible that no container instance needs to be generated.
• [TPS_ECUC_01018] Generation of instances for container definitions with
variable multiplicity dFor containers with variable multiplicity (i.e. lowerMul-
tiplicity < upperMultiplicity), any number of instances between lower
and upper multiplicity may be generated. (additional instances may be added
during editing of the configuration Value description).c()
E.g., continuing the previous example, several instances may be generated if the
definition of RX PDUs can be derived from the ECU extract of System descrip-
tion. If the ECU receives several frames on a CAN bus, at least one RX PDU is
normally present per received frame.

AUTOSAR CP R22-11
• [TPS_ECUC_01019] Setting of the initial values for configuration parame-

ters dFor the setting of the initial values for configuration parameters, the following
sources shall be used (in decreasing priority)c()
– [TPS_ECUC_01020] Values fixed by the implementation as defined in
the Vendor Specific Pre-configured Configuration Value description
dSince the module implementation fixes those configuration parameters,
those values shall be included in the base ECU configuration Value descrip-
tion and shall not be changed in later editing.c()
– [TPS_ECUC_01021] Values derived from the ECU extract of the system
configuration. dThe ECU extract may define the basis for the Ecu config-
uration Value description, e.g. for COM stack configuration, the system de-
scription provides configuration information for bus speed, frame definitions
etc, which can be taken over into the ECU configuration Value description.
This derivation of the Ecu configuration Value description from the ECU ex-
tract of the system configuration shall take place according to the mapping
rules defined in annex D "Harmonization between Upstream Templates and
ECU Configuration" of [2].c() E.g. The signal definitions relevant for the COM
stack can be derived from the ECU extract of system configuration. One
container instance with all relevant parameter values taken from the system
configuration will be generated for each signal.
– [TPS_ECUC_01022] Values provided by the implementor in the BSWMD
in the Vendor Specific Recommended Configuration Value description.
dImplementors may provide configuration settings in the BSWMD provided
with their implementation. This allows the implementor to provide the inte-
grator with his hints which values might be most useful for his implementa-
tion of the module on a specific ECU.c()
– [TPS_ECUC_01023] Default values provided as part of the parameter
definition. dSince each configuration parameter is defined only once, all
instances of the parameter will have the same initial value when the default
values is taken as input to the base configuration.c()
[TPS_ECUC_01024] Generation of parameters without an initial value dIf
no initial value can be derived from any of these sources for a parameter, the
parameter will be generated without an initial value.c()
[TPS_ECUC_04004] Iterative development of the ECU Configura-
tion Value description dIf an existing ECU Configuration Value
description exist and an updated ECU Extract of System Configura-
tion or BSW Module Description is released the existing ECU Configu-
ration Value Description shall be taken into consideration when updating
to a new version of ECU Configuration Value description, i.e, the Gen-
erate Base ECU Configuration Value description activity shall con-
sist of a merge functionality. This functionality is optional since the first time an
ECU Configuration Value description is generated there is no existing
ECU Configuration Value description.c()

AUTOSAR CP R22-11
4.3 Rules for navigating in Ecu Configuration Artifacts

The following rules apply for tools that are navigating in Ecu Configuration Artifacts:
ARElement
EcucValueCollection
+ecucValue 0..*
ARElement ARElement
AtpBlueprint EcucModuleConfigurationValues
AtpBlueprintable +definition
EcucDefinitionElement + ecucDefEdition: RevisionLabelString [0..1]
0..1
EcucModuleDef + implementationConfigVariant: EcucConfigurationVariantEnum [0..1]
+vendorSpecificModuleDef 0..*
+moduleDescription 0..1
Implementation
BswImplementation
+ arReleaseVersion: RevisionLabelString [0..1]

+ vendorApiInfix: Identifier [0..1]
Figure 4.4: Ecu Configuration Artifacts
• [TPS_ECUC_06039] BswImplementation and vendorSpecificMod-

uleDef shall be known by tools dThe tool knows his BswImplementation
element and subsequently the vendorSpecificModuleDef.c()
• [TPS_ECUC_06040] EcucValueCollection is the input for tools dThe tool
shall get the EcucValueCollection as input information. Please note that
the input can be provided as multiple files and can be structured in an arbitrary
package structure.c()
• [TPS_ECUC_06041] Tools shall respect the EcucModuleConfigura-
tionValues elements that are referenced by the EcucValueCollection
d. The tool shall respect only those EcucModuleConfigurationValues ele-
ments which are referenced by the EcucValueCollection.c()
• [TPS_ECUC_06042] Tools interaction with EcucModuleConfigurationVa-
lues dThe tool shall directly interact only with those EcucModuleConfigu-
rationValues elements whose definition reference is equal to the vendor-
SpecificModuleDef reference from the BswImplementation.c() Example:
If two CAN drivers from different vendors are to be configured with respective
tools each tool can find the EcucModuleConfigurationValues to directly in-
teract with using the definition references.

AUTOSAR CP R22-11
4.4 Post-build Time Consistency

When generating a post-build configuration, it shall be assured that the correct pre-
compile and link-time configuration is used.
During initialization, it shall be possible to determine if the pre-compile and link-time
configurations matches the post-build configuration (e.g. this can be done by placing
a checksum based on the pre-compile and link-time configuration parameters in the
pre-compile and link-time configuration and also placing the same checksum in the
post-build configuration which are then compared).
Note that pre-compile and link time configuration parameters that are part of the con-
tainers that are introduced at post-build time (according to [TPS_ECUC_08002]) shall
not be considered for the consistency check.
In addition to this, additional check may be applied in order to assure that the compati-
ble version of the configuration generator is used.

AUTOSAR CP R22-11
A Possible Implementations for the Configuration

Steps
A.1 Alternative Approaches

This chapter contains description of alternative approaches and information that is not
part of the AUTOSAR, but can be helpful and give some guidance.
A.1.1 Alternative Configuration Editor Approaches
[TPS_ECUC_02124] Tooling approaches that are supported by the ECUC param-

eter definition and ECUC Value description dThe ECUC parameter definitions and
ECUC Value descriptions are designed to support a variety of different tooling ap-
proaches.
In the following, the different approaches that have been considered during the devel-
opment of the specification are introduced. These tooling approaches are supported
by ECUC parameter definition and ECUC Value description. Other approaches might
be consistent with this specification, but have not been considered explicitly.c(RS_-
ECUC_00043, RS_ECUC_00071, RS_ECUC_00074)
Tool suppliers have a high degree of freedom in the approach their tools may take to
ECU Configuration.
ECU Configuration tools might consist of a single monolithic editor capable of manip-
ulating all aspects of ECU Configuration, it could be a core tool framework that takes
plug-in components to manipulate particular aspects of ECU Configuration, it might
be a set of specialized tools each capable of configuring a particular type or subset
of software modules or, probably more likely, software vendors could supply individual
custom tools to configure only the code blocks that they supply (similar to microproces-
sor vendors providing specialized debuggers for their own micros).
Common to the different tool approaches is that each configuration editor shall be ca-
pable of reading an (possibly incomplete) ECU Configuration Value descrip-
tion and writing back its modified configuration results in the same format.
The modification may include changed values of ECU Configuration values and added
instances of containers with all included ECU Configuration Values (only for container-
s/parameters with variable multiplicity).
In every case, the ECU Configuration Value description is expected to be
the point of reference, the backbone of the process.
The sections below look at some possible tool forms and identify some of their
strengths and weaknesses.

AUTOSAR CP R22-11
A.1.1.1 Custom Editors (Informative)
.c
Configure Generate RTE
RTE RTE Code
.h
AUTOSAR AUTOSAR
RTE
RTE RTE
Header
Configuration Generator
Editor
.c
Configure Generate COM
COM COM Configuration
.XML Code
ECU
Configuration
.h
Values
AUTOSAR AUTOSAR
COM
COM COM
Configuration
Header
Editor
.c
Configure Generate OS OS
OS Configuration
Code
.h
AUTOSAR AUTOSAR
OS
OS OS
Configuration
Header
Editor
Figure A.1: Custom Editors and Generators
In the custom editors approach as shown in figure A.1, each BSW module is delivered
bundled with a custom configuration editor and a generator (E.g. in figure A.1 the
AUTOSAR RTE Configuration Editor and AUTOSAR RTE Generator).
These tools can be optimized to the particular task of configuring one BSW module and
would likely be quite powerful. The complex dependencies between the BSW module
configuration and other configuration items in the ECU Configuration Value de-
scription could be expressed and supported in the tool.
Each vendor of a BSW module would need to provide a tool. System and ECU engi-
neers would require a large number of tools to deal with the range of BSW modules.
Each tool would probably have an individual look and feel and this could increase the
training and experience required to become proficient.

AUTOSAR CP R22-11
A.1.1.2 Generic Tools (Informative)
.c
Configure Generate DIO

DIO DIO Configuration
Code
.XML .h
Configuration
DIO
Parameter
Configuration
Definition
Header
for DIO AUTOSAR
Generic
Generator
.c
Configure Generate SPI
SPI SPI Configuration
AUTOSAR
Generic
.XML Code
Configuration
Editor ECU
.XML Configuration .h
Values
Configuration SPI
Definition Header
for ADC
.c
Configure Generate EEPROM
EEPROM EEPROM Configuration
Code
.XML .h
AUTOSAR
Configuration EEPROM
EEPROM
Generator
Definition Header
for
Figure A.2: Generic Configuration Editor
An AUTOSAR Generic Configuration Editor as shown in figure A.2 would be

able to configure any parameter defined in Configuration Parameter Defini-
tions. It would read those definitions and provide a generic interface to edit values
for all parameters in the ECU Configuration Value description.
It would only be able to resolve the relatively simple dependencies explicitly defined in
the Configuration Parameter Definitions. Only a limited number of editors
would be required, maybe only one, and the look and feel is less likely to vary greatly
between generic tools.
Training and tooling costs are therefore likely to be lower. Examples of such tools that
already exist are tresos, GENy, DAvE and MICROSAR. On the generation side, either
a generic generator may be used, or custom generators for the individual modules.

AUTOSAR CP R22-11
A.1.1.3 Tools Framework (Informative)
ECU Configuration Editor
Standardized API
OS Configuration MCAL Configuration

Plug-In Plug-In
EcuC1
COM Configuration
Plug-In
ECU Configuration Framework
Figure A.3: Framework Tools
The tool framework as shown in figure A.3 is a cross between custom tools and generic
tools where dedicated configuration steps (OS, COM, MCAL, etc.) are integrated as
plug-ins into the common ECU Configuration framework.
The heart of the tool would be a framework that provides certain core services such
as importing and exporting data from standard file formats, maintaining standard in-
ternal data structures and providing an HMI to the user. This ensures that the ECU
Configuration Value description is read, interpreted and written in a defined
way.
The frame could also monitor and control the user / project work flow. It provides a low
initial tooling and training investment. The power of the approach would be the ability
to add plug-in modules that extend the core functionality.
These would allow very sophisticated features, potentially dedicated to one BSW mod-
ule, to be added by individual suppliers. Additionally, it would be possible to add generic
plug-ins that addressed a specific aspect of configuration across all BSW modules.
This approach relies upon a standard framework: multiple framework standards could
lead to high tool costs.
An example of this kind of tool is the LabVIEW test and measurement tool from National
Instruments and the Eclipse framework.
A.1.2 Alternative Generation Approaches
As stated before, the ECU Configuration Value description is the only con-
figuration source that stores the configuration parameters for all modules of an
AUTOSAR based ECU.
However, for several modules such as OS, existing configuration languages have al-
ready been established. Those languages probably will in future still be used for

AUTOSAR CP R22-11
non-AUTOSAR systems. Thus, modules that are used both for AUTOSAR and non-
AUTOSAR systems shall support different configuration languages in parallel.
This can be implemented in different ways, as shown in figure A.4.
AUTOSAR OSEK
OS to OS
OIL Generator
Rew riter
.XML .c
OIL file Generate
Extract OIL
ECU OSEK OIL
based OS OS
Configuration {xor}
Configuration
Values
Code
.h
Generate OS
OS
Configuration
Header
AUTOSAR
OS
Generator
Figure A.4: Module generator implementation alternatives, example for OS
In a fully AUTOSAR based approach, the generator reads in the ECU Configura-
tion Value Description and output the relevant source code directly in one step,
supported by a AUTOSAR OS Generator in the example given.
To support reuse of existing generator tools, this single step can be split into two
steps. Then the first activity is to extract all OS configuration information from
the ECU Configuration Value description using an AUTOSAR OS to OIL
Rewriter and to store it in the format used by the legacy tools (OIL file in the
example chosen).
The existing OSEK OS Generator may then read the intermediate format to gener-
ate the code. However, the intermediate format shall not be changed by any legacy
configuration tools, since those changes would possibly make the overall configuration
inconsistent, and since changes would be lost with the next generation of the interme-
diate format.
[TPS_ECUC_01025] Generate and extract activities are fully automatic dThus,
none of the activities (extract, generate) shall include any engineering step with deci-
sions taken by an engineer. They are fully automatic, since all input driving these steps
is included in the ECU Configuration Value Description.c()

AUTOSAR CP R22-11
B AUTOSAR Service Components

In the ECU Extract of the System Configuration only application Software
Components are considered, while RTE and all BSW modules are not taken into ac-
count. In contrast, the ECU Configuration needs to consider all aspects of the
ECU software, therefore means to support the addition of the BSW and RTE need to
be provided.
To support this, the ECU Configuration Description allows the ECU extract to
be extended by adding AUTOSAR Service prototypes and assembly connectors estab-
lishing the connections between applications and AUTOSAR service components (see
figure B.1 EcuTopLevelCompositionPrototype).
AUTOSAR Services are modules like the NvRam Manager, the Watchdog Manager,
the ECU State Manager, etc., which possess the characteristic trait that they interact
with application software components using standardized AUTOSAR interfaces.
EcuTopLevelCompositionPrototype
Service B Service A Module prototype
Figure B.1: Structure of the EcuTopLevelCompositionPrototype introduced in the ECU

Configuration
To enable the extension of the existing ECU Extract towards a complete soft-
ware system in the ECU Configuration, the aggregation of SwComponentPro-
totype and SwConnector by CompositionSwComponentType is stereotyped
atpSplitable.
This is shown in figure B.2. Making these aggregations atpSplitable allows
the addition of AUTOSAR service component prototypes and connector prototypes to
the CompositionSwComponentType contained in the ECU extract during the ECU
integration without changing the artifacts which had been delivered as ECU extract.

AUTOSAR CP R22-11
ARElement
EcucValueCollection
+ecuExtract 0..1
ARElement
AtpStructureElement
System

+ systemVersion: RevisionLabelString
+rootSoftwareComposition 0..1
AtpPrototype
Identifiable
RootSwCompositionPrototype
«isOfType»
1
{redefines
+softwareComposition
atpType}
SwComponentType
CompositionSwComponentType
«atpVariation,atpSplitable» «atpVariation,atpSplitable»
+component 0..* +connector 0..*
AtpPrototype AtpStructureElement
SwComponentPrototype SwConnector
Figure B.2: Splittable aggregations of SwComponentPrototype and SwConnector
[TPS_ECUC_02087] Creation of ServiceSwComponentTypes dWhen generating

the AUTOSAR Service SW-Components the actual service needs1 expressed by the
Application SW-Components are collected.
For each AUTOSAR service required, a ServiceSwComponentType shall be created
complete with an appropriate number of ports to enable the connection of all application
component ports expressing the needs for the AUTOSAR service.c(RS_ECUC_00073)
[TPS_ECUC_06014] Content of CompositionSwComponentType in the ECU Con-
figuration dThe CompositionSwComponentType in the ECU Configuration shall
contain, additionally to prototypes of all application SW-Components running on the
ECU as contained in the ECU Extract, SwComponentPrototypes for all required
AUTOSAR Service modules and AssemblySwConnectors for the required connec-
tions between the Application SW-Component ports and the AUTOSAR Service mod-
ule’s ports.c(RS_ECUC_00076)
1
The needs of the Application SW-Components are defined in the SW-Component description in the
ServiceNeeds section.

AUTOSAR CP R22-11
C Glossary
Artifact This is a Work Product Definition that provides a description and definition for
tangible work product types. Artifacts may be composed of other artifacts ([15]).
At a high level, an artifact is represented as a single conceptual file.
AUTOSAR Tool This is a software tool which supports one or more tasks defined as
AUTOSAR tasks in the methodology. Depending on the supported tasks, an
AUTOSAR tool can act as an authoring tool, a converter tool, a processor tool or
as a combination of those (see separate definitions).
AUTOSAR Authoring Tool An AUTOSAR Tool used to create and modify AUTOSAR
XML Descriptions. Example: System Description Editor.
AUTOSAR Converter Tool An AUTOSAR Tool used to create AUTOSAR XML files by
converting information from other AUTOSAR XML files. Example: ECU Flattener
AUTOSAR Definition This is the definition of parameters which can have values. One
could say that the parameter values are Instances of the definitions. But in the
meta model hierarchy of AUTOSAR, definitions are also instances of the meta
model and therefore considered as a description. Examples for AUTOSAR def-
initions are: EcucParameterDef, PostBuildVariantCriterion, SwSys-
temconst.
AUTOSAR XML Description In AUTOSAR this means "filled Template". In fact an
AUTOSAR XML description is the XML representation of an AUTOSAR model.
The AUTOSAR XML description can consist of several files. Each individual file
represents an AUTOSAR partial model and shall validate successfully against the
AUTOSAR XML schema.
AUTOSAR Meta-Model This is an UML2.0 model that defines the language for de-
scribing AUTOSAR systems. The AUTOSAR meta-model is an UML represen-
tation of the AUTOSAR templates. UML2.0 class diagrams are used to describe
the attributes and their interrelationships. Stereotypes, UML tags and OCL ex-
pressions (object constraint language) are used for defining specific semantics
and constraints.
AUTOSAR Meta-Model Tool The AUTOSAR Meta-Model Tool is the tool that gener-
ates different views (class tables, list of constraints, diagrams, XML Schema etc.)
on the AUTOSAR meta-model.
AUTOSAR Model This is a representation of an AUTOSAR product. The AUTOSAR
model represents aspects suitable to the intended use according to the
AUTOSAR methodology.
Strictly speaking, this is an instance of the AUTOSAR meta-model. The infor-
mation contained in the AUTOSAR model can be anything that is representable
according to the AUTOSAR meta-model.

AUTOSAR CP R22-11
AUTOSAR Partial Model In AUTOSAR, the possible partitioning of models is marked

in the meta-model by atpSplitable. One partial model is represented in
an AUTOSAR XML description by one file. The partial model does not need to
fulfill all semantic constraints applicable to an AUTOSAR model.
AUTOSAR Processor Tool An AUTOSAR Tool used to create non-AUTOSAR files by
processing information from AUTOSAR XML files. Example: RTE Generator
AUTOSAR Specification Element An AUTOSAR Specification Element is a named
element that is part of an AUTOSAR specification. Examples: requirement, con-
straint, specification item, class or attribute in the meta model, methodology, de-
liverable, methodology activity, model element, bsw module etc.
AUTOSAR Template The term "Template" is used in AUTOSAR to describe the for-
mat different kinds of descriptions. The term template comes from the idea, that
AUTOSAR defines a kind of form which shall be filled out in order to describe a
model. The filled form is then called the description.
In fact the AUTOSAR templates are now defined as a meta-model.
AUTOSAR Validation Tool A specialized AUTOSAR Tool which is able to check an
AUTOSAR model against the rules defined by a profile.
AUTOSAR XML Schema This is a W3C XML schema that defines the language for
exchanging AUTOSAR models. This Schema is derived from the AUTOSAR
meta-model. The AUTOSAR XML Schema defines the AUTOSAR data exchange
format.
Blueprint This is a model from which other models can be derived by copy and re-
finement. Note that in contrast to meta model resp. types, this process is not an
instantiation.
Instance Generally this is a particular exemplar of a model or of a type.
Life Cycle Life Cycle is the course of development/evolutionary stages of a model
element during its life time.
Meta-Model This defines the building blocks of a model. In that sense, a Meta-Model
represents the language for building models.
Meta-Data This includes pertinent information about data, including information about
the authorship, versioning, access-rights, timestamps etc.
Model A Model is an simplified representation of reality. The model represents the
aspects suitable for an intended purpose.
Partial Model This is a part of a model which is intended to be persisted in one par-
ticular artifact.
Pattern in GST This is an approach to simplify the definition of the meta model by ap-
plying a model transformation. This transformation creates an enhanced model
out of an annotated model.

AUTOSAR CP R22-11
Profile Authoring Support Data Data that is used for efficient authoring of a profile.
E.g. list of referable constraints, meta-classes, meta-attributes or other reusable
model assets (blueprints)
Profile Authoring Tool A specialized AUTOSAR Tool which focuses on the authoring
of profiles for data exchange points. It e.g. provides support for the creation of
profiles from scratch, modification of existing profiles or composition of existing
profiles.
Profile Compatibility Checker Tool A specialized AUTOSAR Tool which focuses on
checking the compatibility of profiles for data exchange. Note that this compat-
ibility check includes manual compatibility checks by engineers and automated
assistance using more formal algorithms.
Profile Consistency Checker Tool A specialized AUTOSAR Tool which focuses on
checking the consistency of profiles.
Property A property is a structural feature of an object. As an example a “connector”
has the properties “receive port” and “send port”
Properties are made variant by the atpVariation.
Prototype This is the implementation of a role of a type within the definition of another
type. In other words a type may contain Prototypes that in turn are typed by
"Types". Each one of these prototypes becomes an instance when this type is
instantiated.
Type A type provides features that can appear in various roles of this type.
Value This is a particular value assigned to a “Definition”.
Variability Variability of a system is its quality to describe a set of variants. These
variants are characterized by variant specific property settings and / or selections.
As an example, such a system property selection manifests itself in a particular
“receive port” for a connection.
This is implemented using the atpVariation.
Variant A system variant is a concrete realization of a system, so that all its proper-
ties have been set respectively selected. The software system has no variability
anymore with respect to the binding time.
This is implemented using EvaluatedVariantSet.
Variation Binding A variant is the result of a variation binding process that resolves
the variability of the system by assigning particular values/selections to all the
system’s properties.
This is implemented by VariationPoint.
Variation Binding Time The variation binding time determines the step in the method-
ology at which the variability given by a set of variable properties is resolved.

AUTOSAR CP R22-11
This is implemented by vh.LatestBindingtime at the related properties.

Variation Definition Time The variation definition time determines the step in the
methodology at which the variation points are defined.
Variation Point A variation point indicates that a property is subject to variation. Fur-
thermore, it is associated with a condition and a binding time which define the
system context for the selection / setting of a concrete variant.
This is implemented by VariationPoint.

AUTOSAR CP R22-11
D Change History
D.1 Change History between AUTOSAR R4.0.1 against R3.1.5
D.1.1 Renamed Meta-Model Elements for AUTOSAR Release 4.0
In the course of preparing AUTOSAR Release 4.0 some of the existing meta-model
elements have been renamed for a better clarity and consistency with respect to other
meta-mode elements.
D.1.2 Deleted SWS Items
SWS Item Rationale

[ecuc_sws_3000] Removed type specific value definitions.
[ecuc_sws_1031] The requirement from chapter A.1.1 has been changed to
[TPS_ECUC_02124] because there were two requirements for this Id.
[ecuc_sws_2046] Removed due to changes on the derived parameter structure.
[ecuc_sws_2085] Removed due to changes in Ecu Extract description.
[ecuc_sws_2086] Removed due to changes in Ecu Extract description.
[ecuc_sws_2045] EcuC Parameter Definitions can also be manually generated.
[ecuc_sws_2113] currently not supported by the Variant Handling concept (aggregation of Prim-
itives).
[ecuc_sws_2068] Replaced requirement by [TPS_ECUC_02012].
[ecuc_sws_1000] Replaced requirement by [TPS_ECUC_06038].
[ecuc_sws_1002] Replaced with [TPS_ECUC_06007] and [TPS_ECUC_06008] for clarification
of derivation rules.
[ecuc_sws_1003] Replaced with [TPS_ECUC_06007] and [TPS_ECUC_06008] for clarification
of derivation rules.
[ecuc_sws_1010] Removed for clarification of derivation rules.
[ecuc_sws_1012] Removed for clarification of derivation rules.

AUTOSAR CP R22-11
Table D.1: Deleted SWS Items
D.1.3 Changed SWS Items
SWS Item Heading

[TPS_ECUC_02029] Subclasses of EcucAbstractStringParamDef
[TPS_ECUC_02030] Programming language identifier limitations
[TPS_ECUC_02031] Restriction on the length of EcucLinkerSymbolDef values and defaultValue
[TPS_ECUC_02108] Rule for the creation of #define symbols in the header file for parameters with
the symbolicNameValue set to TRUE
[ecuc_sws_5001] Refined because of unclear requirement.
[TPS_ECUC_03021] EcucParameterDefs with EcucDerivationSpecification result in a EcucNumer-
icalParamValue in the ECUC Value description
[TPS_ECUC_02047] Derivation of parameter values
[TPS_ECUC_02087] Creation of ServiceSwComponentTypes
[TPS_ECUC_02000] Modeling of ECU Configuration Value and ECU Configuration Parameter Def-
inition metamodels
[ecuc_sws_2084] Incompatible inter module queries.
[ecuc_sws_6002] Incompatible inter module queries.
[TPS_ECUC_- Link time configuration
01032]
[TPS_ECUC_02030] Programming language identifier limitations
[TPS_ECUC_02095] VSMD refines the StMD
[TPS_ECUC_03007] Attribute value stores the configuration value in XML-based description
[TPS_ECUC_03034] Each parameter in an Ecuc Configuration Value description shall have a value
[TPS_ECUC_03010] Parameters that are declared as optional in the ECU Configuration Definition
may be left out in the ECU Configuration Value description
[TPS_ECUC_03040] The value of an EcucNumericalParamValue shall be unambiguously an integer
value
[TPS_ECUC_02107] Values of parameters with the symbolicNameValue set to TRUE that are as-
signed by the configuration editor or module generator shall be stored in the
XML file
[TPS_ECUC_02001] Transformation of the ECU Configuration Value and ECU Configuration Pa-
rameter Definition metamodels to schema definitions
[TPS_ECUC_02002] Generic structure of all AUTOSAR templates
[TPS_ECUC_06004] AdminData field in ECU Configuration Parameter Definition XML file
[TPS_ECUC_02067] Multiplicity of the to be chosen containers
[TPS_ECUC_02012] Allowed choice of available to be chosen containers in the ECU Configuration
Value description
[TPS_ECUC_02009] Expression of optionality of containers, parameters and references
[TPS_ECUC_02029] Subclasses of EcucAbstractStringParamDef
[TPS_ECUC_02087] Creation of ServiceSwComponentTypes
Table D.2: Changed SWS Items
D.1.4 Added SWS Items
SWS Item Heading

[TPS_ECUC_02110] Variable lower and upper multiplicity in ECU Configuration Parameter definition

AUTOSAR CP R22-11
[TPS_ECUC_02111] Variable default value in EcucBooleanParamDef

[TPS_ECUC_02112] Variable default value in EcucAbstractStringParamDef
[ecuc_sws_2113] Implement Variant Handling Concept.
[TPS_ECUC_02114] Variable default value in EcucIntegerParamDef
[TPS_ECUC_02115] Variable default value in EcucFloatParamDef
[TPS_ECUC_02116] Variable min, max values in EcucIntegerParamDef
[TPS_ECUC_02117] Variable min, max values in EcucFloatParamDef
[TPS_ECUC_02119] Variable existence of container on value side
[TPS_ECUC_02120] Variable subContainers
[TPS_ECUC_02121] Variable parameterValues
[TPS_ECUC_02122] Variable referenceValues
[TPS_ECUC_02118] EcucAddInfoParamDef properties
[TPS_ECUC_02123] The value of the parameter type EcucAddInfoParamDef
[TPS_ECUC_02124] Tooling approaches that are supported by the ECUC parameter definition and
ECUC Value description
[TPS_ECUC_02125] Value of parameters with a defined derivation specification
[TPS_ECUC_02126] Values for parameter types stored in the element EcucTextualParamValue
[TPS_ECUC_02127] Possible values for EcucBooleanParamDef parameters
[TPS_ECUC_02128] Formal description of the derivation
[TPS_ECUC_02129] Informal description of the derivation
[TPS_ECUC_02130] Standardized Module Definition package structure
[TPS_ECUC_06014] Content of CompositionSwComponentType in the ECU Configuration
[TPS_ECUC_06015] DESTINATION-REF in the VSMD
[TPS_ECUC_06016] Countably infinite number of containers, parameters and references in the
ECU Configuration Value description
[TPS_ECUC_- Existence of upperMultiplicityInfinite and upperMultiplicity is mutually exclusive
06017]
[TPS_ECUC_06018] Input and Output of the refvalue function
[TPS_ECUC_06019] Output of the refvalue function if the EcucDefinitionElement points to a not
existing element in the ECU Configuration Parameter Definition
[TPS_ECUC_06020] Output of the refvalue function if no element in the ECU Configuration Value
description is found
[TPS_ECUC_06021] Input and Output of the deref function
[TPS_ECUC_06022] Output of the deref function in case the first input parameter is a reference
[TPS_ECUC_06023] Cases where the deref function reports an error
[TPS_ECUC_06024] Input of the value function
[TPS_ECUC_06025] Output of the value function
[TPS_ECUC_06026] Cases where the value function reports an error
[TPS_ECUC_06027] Input of the count function
[TPS_ECUC_06028] Output of the count function
[TPS_ECUC_06029] Output of the count function in case the input parameter set is empty
[TPS_ECUC_06030] Invalid PduLength parameter value configuration
[TPS_ECUC_06031] Interaction of Complex Driver with standardized AUTOSAR BSW modules
[TPS_ECUC_06032] Min and max values in EcucIntegerParamDef
[TPS_ECUC_06033] Min and max values in EcucFloatParamDef
[TPS_ECUC_06034] Special float values
[TPS_ECUC_- Link time configuration
01032]
[TPS_ECUC_06036] Distinction of module definitions of Complex Drivers
[TPS_ECUC_06037] apiServicePrefix attribute for Complex Driver modules
[TPS_ECUC_06038] Rules to validate a BSW module implementation
[TPS_ECUC_06043] EcucModuleDef categories
[TPS_ECUC_06044] refinedModuleDef reference in the StMD

AUTOSAR CP R22-11
[TPS_ECUC_06035] Regular expression

[TPS_ECUC_06006] EcucLinkerSymbolDef properties
[TPS_ECUC_06007] Elements defined in the StMD shall be present in the VSMD
[TPS_ECUC_06008] lowerMultiplicity and upperMultiplicity of elements in the VSMD
[TPS_ECUC_06009] Existence of a parameter in the Ecuc Parameter Value description in case the
upperMultiplicity of the parameter definition is zero
[TPS_ECUC_06010] Existence of a parameter in the Ecuc Parameter Value description in case the
lowerMultiplicity of the parameter definition is bigger than zero
[TPS_ECUC_06011] Missing parameters in the Ecuc Parameter Value description
[TPS_ECUC_06012] Parameters without parameter definitions in the Ecuc Parameter Value de-
scription
[TPS_ECUC_06013] Number of parameters in the Ecuc Parameter Value description
Table D.3: Added SWS Items
SWS Item Heading

[TPS_ECUC_02072] Signed EcucIntegerParamDef value range
SWS Item Heading

[TPS_ECUC_02131] Origin information in literal definitions
[TPS_ECUC_06039] BswImplementation and vendorSpecificModuleDef shall be known by tools
[TPS_ECUC_06040] EcucValueCollection is the input for tools
[TPS_ECUC_06041] Tools shall respect the EcucModuleConfigurationValues elements that are ref-
erenced by the EcucValueCollection
[TPS_ECUC_06042] Tools interaction with EcucModuleConfigurationValues
[TPS_ECUC_06043] EcucModuleDef categories
[TPS_ECUC_06044] refinedModuleDef reference in the StMD
[TPS_ECUC_06045] min, max values of parameters in the VSMD in case that the min or max value
in the StMD is set to infinite
SWS Item Rationale

[ecuc_sws_5001] Removed because it was unclear.

AUTOSAR CP R22-11
SWS Item Heading

[TPS_ECUC_02041] EcucForeignReferenceDef properties
[TPS_ECUC_02082] Specification of the destinationType in a EcucInstanceReferenceDef
[TPS_ECUC_02083] Specification of the destinationContext in a EcucInstanceReferenceDef
[TPS_ECUC_- Removal of standardized EcucEnumerationLiteralDefs in the VSMD
06002]
[TPS_ECUC_06015] DESTINATION-REF in the VSMD
[TPS_ECUC_06025] Output of the value function
[TPS_ECUC_06037] apiServicePrefix attribute for Complex Driver modules
[TPS_ECUC_02108] Rule for the creation of #define symbols in the header file for parameters with
the symbolicNameValue set to TRUE
SWS Item Heading

[TPS_ECUC_- The postBuildChangeable attribute shall only be set to true for containers lo-
02132] cated within a multipleConfigurationContainer
[TPS_ECUC_- upperMultiplicity of a multipleConfigurationContainer
02133]
[TPS_ECUC_06046] Vendor specific reference definition with no counterpart in the STMD
[TPS_ECUC_06047] References in the ECUC Parameter Value description with reference defini-
tions that refer to container definitions in the same module definition
[TPS_ECUC_06048] References in the ECUC Parameter Value description with reference defini-
tions that refer to container definitions in different module definitions
[TPS_ECUC_06049] Restriction of supportedConfigVariants in the VSMD
[TPS_ECUC_- supportedConfigVariants in the VSMD in case VariantPostBuild is supported
06050] in the StMD
[TPS_ECUC_- ImplementationConfigClass of an EcucParameterDef or EcucAbstractRefer-
06051] enceDef in VSMD
[TPS_ECUC_- Supported configuration variants in the VSMD
06052]
[TPS_ECUC_- VSMD Configuration variant “VariantPreCompile”
06053]
[TPS_ECUC_- VSMD Configuration variant “VariantLinkTime”
06054]
[TPS_ECUC_- VSMD Configuration variant “VariantPostBuildLoadable”
06055]
[TPS_ECUC_- VSMD Configuration variant “VariantPostBuildSelectable”
06056]
[TPS_ECUC_06057] Input of the strValue function
[TPS_ECUC_06058] Output of the strValue function
[TPS_ECUC_06059] Cases where the strValue function reports an error
[TPS_ECUC_06060] Input of the valueAt function
[TPS_ECUC_06061] Output of the valueAt function
[TPS_ECUC_06062] Cases where the valueAt function reports an error

AUTOSAR CP R22-11
[TPS_ECUC_06063] Input of the strValueAt function

[TPS_ECUC_06064] Output of the strValueAt function
[TPS_ECUC_06065] Cases where the strValueAt function reports an error
[TPS_ECUC_06066] Order of Container-, Parameter- and Reference-Values
[TPS_ECUC_06067] Sorting criteria for Containers on the Values side
[TPS_ECUC_06068] Sorting criteria for References on the Values side
[TPS_ECUC_06069] Sorting criteria for Parameters on the Values side
[TPS_ECUC_06070] Sorting of Ecu Configuration Parameter Definitions
[TPS_ECUC_- ECU Configuration Editor shall be able to read parameter values in any order
06071]
[TPS_ECUC_06072] Container-, Parameter-, and Reference-Values with requiresIndex set to true
[TPS_ECUC_- The ECU Configuration Editor shall be able to work with arbitrary package
06073] structures
[TPS_ECUC_06074] Invalid configuration due to symbolic name values
D.3.4 Added Constraints
Number Heading
[constr_3022] EcucModuleDef category restriction
[constr_3023] Usage of apiServicePrefix
Table D.9: Added Constraints in R4.0.3
SWS Item Rationale
SWS Item Heading

[TPS_ECUC_06067] Sorting criteria for Containers on the Values side
[TPS_ECUC_06072] Container-, Parameter-, and Reference-Values with requiresIndex set to true
[TPS_ECUC_02039] References between containers are established with the EcucReferenceDef
[TPS_ECUC_02040] EcucChoiceReferenceDef properties
[TPS_ECUC_- ImplementationConfigClass of an EcucParameterDef or EcucAbstractRefer-
06051] enceDef in VSMD

AUTOSAR CP R22-11
SWS Item Heading

[TPS_ECUC_02134] requiresIndex setting in the VSMD
[TPS_ECUC_02135] Validation of EcucValidationCondition
[TPS_ECUC_02136] Validation of multiple EcucValidationConditions
[TPS_ECUC_02137] EcucValidationConditions from the StMD shall be taken over to the VSMD.
[TPS_ECUC_02138] Addition of vendor specific EcucValidationConditions
[TPS_ECUC_02139] Definition of configuration classes for all CDD configuration parameters and
references
[TPS_ECUC_02141] Variable reference EcucValueCollection.ecucValue
[TPS_ECUC_02142] Variable value of EcucNumericalParamValue.value
[TPS_ECUC_- Configuration class of parameters and references within postBuildChange-
08001] able containers
[TPS_ECUC_08002] Introduction of new EcucParamConfContainerDef instances in a post-build
loadable configuration set
[TPS_ECUC_08003] Usage of postBuildChangeable attribute is independent of aggregated sub-
Containers
[TPS_ECUC_- Changing of values and multiplicities of EcucParameterValues at post-build
08004] time
[TPS_ECUC_08005] postBuildChangeable attribute in the VSMD in case it is not defined in the
StMD
[TPS_ECUC_08006] postBuildChangeable attribute in the VSMD in case it is set to false in the
StMD
[TPS_ECUC_- postBuildChangeable attribute in the VSMD in case it is set to true in the
08007] StMD
[TPS_ECUC_- Usage of the multiple configuration container in EcucModuleDefs with sup-
08008] portedConfigVariant of VariantPostBuild
[TPS_ECUC_- Names of containers inside a multiple configuration set
08009]
[TPS_ECUC_08010] Ticks in the Ecuc Parameter Value description
[TPS_ECUC_08011] Pattern for creating a C symbol used by the EcuM/BswM to initialize post-
build Bsw modules
[TPS_ECUC_02143] Optional configuration of Production Error and Extended Production Error
reporting
[TPS_ECUC_02144] Definition of supported config variants for CDD
[constr_3509] Applicability of scope attribute

[constr_5500] Applicability of postBuildChangeable attribute
[constr_5501] EcucParameterValues and EcucAbstractReferenceValues in EcucCon-
tainerValues that exist in multiple configuration sets
[constr_5502] EcucParameterValues of type EcucFunctionNameDef
[constr_5503] symbolicNameValue parameters in post-build configuration sets
[constr_5504] Removing an instance of the EcucContainerDef in post-build time

AUTOSAR CP R22-11
SWS Item Rationale

[TPS_ECUC_- Removal of standardized EcucEnumerationLiteralDefs in the VSMD
06002]
[TPS_ECUC_- Migrated to TR_METH_01114
01036]
01027]
01028]
[TPS_ECUC_- Equivalent to TR_METH_01095
01031]
01032]
04006]
04007]
01029]
01030]
[TPS_ECUC_- Deprecated
04000]
[TPS_ECUC_- Relies on deprecated chapter
04001]
[TPS_ECUC_- Contradictory to the variant handling approach described in chapter 2.4.7
02132]
SWS Item Heading

[TPS_ECUC_- ImplementationConfigClass of an EcucParameterDef or EcucAbstrac-
06051] tReferenceDef in VSMD
[TPS_ECUC_- ECU Configuration Editor shall be able to merge ECU Configuration
04002] Value descriptions
SWS Item Heading

[TPS_ECUC_06075] EcucFunctionNameDef shall represent a valid C Identifier

AUTOSAR CP R22-11
SWS Item Heading

[TPS_ECUC_- Configuration variants of a BSW module in the ECU Configuration Parameter
02022] Definition
SWS Item Heading

[TPS_ECUC_- Mandatory configuration of CddConfigSet for post build configured CDD
02140]
SWS Item Heading

[TPS_ECUC_06076] Use cases where the reference refinedModuleDef is mandatory
[TPS_ECUC_06077] Use cases where the reference refinedModuleDef is optional
[constr_3091] Multiplicity of implementationConfigClass

[constr_3092] Usage of EcucImplementationConfigurationClass.configVariant and EcucImplemen-
tationConfigurationClass.configClass attributes
D.7.1 Added Traceables in 4.2.1
Id Heading

AUTOSAR CP R22-11
[TPS_ECUC_06078] EcucUriReferenceDef properties

[TPS_ECUC_06079] destinationUriNestingContract is set to targetContainer
[TPS_ECUC_06080] destinationUriNestingContract is set to leafOfTargetContainer
[TPS_ECUC_06081] destinationUriNestingContract is set to vertexOfTargetCon-
tainer
[TPS_ECUC_08012] Module support for post-build variants
[TPS_ECUC_08013] Different number of EcucContainerDef instances in different post-build
variants
[TPS_ECUC_08014] Usage of postBuildVariantMultiplicity attribute is independent of
aggregated subContainers
[TPS_ECUC_08015] Different number of EcucCommonAttributess instances in different post-
build variants
[TPS_ECUC_08016] Different values of EcucCommonAttributess instances in different post-
build variants
[TPS_ECUC_08017] Derivation of information from parameter values bound at PreCompile time
[TPS_ECUC_08018] Derivation of information from parameter values bound at Link time
[TPS_ECUC_08019] Derivation of information from parameter values bound at PostBuild time
[TPS_ECUC_08021] The value of the EcucModuleDef.postBuildVariantSupport attribute
in the VSMD in case it is not defined in the StMD
[TPS_ECUC_08025] The value of the EcucContainerDef.postBuildVariantMultiplicity
attribute in the VSMD in case it is not defined in the StMD
attribute in the VSMD in case it is set to false in the StMD
in the VSMD in case it is set to true in the StMD
[TPS_ECUC_08028] The value of the EcucParameterDef.postBuildVariantMultiplicity
and the EcucAbstractReferenceDef.postBuildVariantMultiplic-
ity attributes in the VSMD in case they are not defined in the StMD
[TPS_ECUC_08029] The value of the EcucParameterDef.postBuildVariantValue and
the EcucAbstractReferenceDef.postBuildVariantValue attributes
in the VSMD in case they are not defined in the StMD
in the VSMD in case they are set to false in the StMD
ity attributes in the VSMD in case they are set to false in the StMD
in the VSMD in case they are set to true in the StMD
ity attributes in the VSMD in case they are set to true in the StMD
[TPS_ECUC_08034] Different values of EcucCommonAttributess instances in different config-
uration times
[TPS_ECUC_08035] Different number of instances of EcucCommonAttributess in different con-
figuration times
[TPS_ECUC_08036] The value of the EcucParameterDef.valueConfigClass and the Ecu-
cAbstractReferenceDef.valueConfigClass attributes in the VSMD in
case they are not defined in the StMD
[TPS_ECUC_08037] The value of the EcucParameterDef.multiplicityConfigClass
and the EcucAbstractReferenceDef.multiplicityConfigClass at-
tributes in the VSMD in case they are not defined in the StMD

AUTOSAR CP R22-11
[TPS_ECUC_08038] The value of the EcucParameterDef.valueConfigClass and the Ecu-

cAbstractReferenceDef.valueConfigClass attributes in the VSMD in
case they are defined in the StMD
[TPS_ECUC_08039] The value of the EcucParameterDef.multiplicityConfigClass
and the EcucAbstractReferenceDef.multiplicityConfigClass at-
tributes in the VSMD in case they are defined in the StMD
in the VSMD in case it set to false in the StMD
[TPS_ECUC_08043] The number of EcucContainerValue instances in post-build time updated
ECU configurations
[TPS_ECUC_08044] The number of EcucContainerValue instances in different post-build vari-
ants
[TPS_ECUC_08045] The value of EcucParameterValue instances in post-build time updated
ECU configurations
[TPS_ECUC_08046] The value of EcucParameterValue instances in different post-build variants
[TPS_ECUC_08047] The number of EcucParameterValue instances in post-build time updated
ECU configurations
[TPS_ECUC_08048] The number of EcucParameterValue instances in different post-build vari-
ants
[TPS_ECUC_08049] The value of EcucAbstractReferenceValue instances in post-build time
updated ECU configurations
[TPS_ECUC_08050] The value of EcucAbstractReferenceValue instances in different post-
build variants
[TPS_ECUC_08051] The number of EcucAbstractReferenceValue instances in post-build
time updated ECU configurations
[TPS_ECUC_08052] The number of EcucAbstractReferenceValue instances in different
post-build variants
Table D.21: Added Traceables in 4.2.1
D.7.2 Changed Traceables in 4.2.1
Id Heading
[TPS_ECUC_01021] Values derived from the ECU extract of the system configuration.
[TPS_ECUC_02016] Configuration class of parameter and reference definitions
[TPS_ECUC_02019] Configuration class “PostBuild”
[TPS_ECUC_02056] Derivation of information from Link parameters
[TPS_ECUC_02057] Derivation of information from PostBuild parameters
[TPS_ECUC_02058] Derivation of information from PreCompile parameters
[TPS_ECUC_02097] Supported configuration variants in the StMD and the VSMD
[TPS_ECUC_02098] StMD Configuration variant "VariantPreCompile"
[TPS_ECUC_02099] StMD Configuration variant "VariantLinkTime"
[TPS_ECUC_02100] StMD Configuration variant "VariantPostBuild"
[TPS_ECUC_02101] EcucAbstractConfigurationClass usage
[TPS_ECUC_02102] Configuration class selection for parameters and references for supported
configuration variants
[TPS_ECUC_02139] Definition of configuration classes for all CDD configuration parameters and
references
[TPS_ECUC_06001] shortName of a VSMD module
[TPS_ECUC_06046] Vendor specific reference definition with no counterpart in the STMD

AUTOSAR CP R22-11
[TPS_ECUC_08000] Different number of EcucContainerDef instances in different configuration

times
[TPS_ECUC_08002] Introduction of new EcucParamConfContainerDef instances in updated
post-build configuration
[TPS_ECUC_08003] Usage of multiplicityConfigClass.configClass attribute is indepen-
dent of its aggregated subContainers
[TPS_ECUC_08005] The value of the EcucContainerDef.multiplicityConfigClass at-
tribute in the VSMD in case it is not defined in the StMD
[TPS_ECUC_08006] The value of the EcucContainerDef.multiplicityConfigClass at-
tribute in the VSMD in case it is defined in the StMD
[TPS_ECUC_08011] Pattern for creating a C symbol used by the EcuM/BswM to initialize BSW
modules with different post-build variants
Table D.22: Changed Traceables in 4.2.1
D.7.3 Deleted Traceables in 4.2.1
Id Heading
[TPS_ECUC_02055] Derivation of information from AUTOSAR Templates
[TPS_ECUC_02076] “NOAffect” affection
[TPS_ECUC_02077] “PCAffectsLT” affection
[TPS_ECUC_02078] “PCAffectsPB” affection
[TPS_ECUC_02079] “PCAffectsLTAndPB” affection
[TPS_ECUC_02080] “LTAffectsPB” affection
[TPS_ECUC_02081] Parameters or references which are affected may be referenced with the
affected reference
[TPS_ECUC_02091] multipleConfigurationContainer approach
[TPS_ECUC_02092] multipleConfigurationContainer allows several EcucContainer-
Value elements in the ECU Configuration
[TPS_ECUC_02104] Valid configuration set names
[TPS_ECUC_02105] Uniqueness of configuration set names
[TPS_ECUC_02133] upperMultiplicity of a multipleConfigurationContainer
[TPS_ECUC_02140] Mandatory configuration of CddConfigSet for post build configured CDD
[TPS_ECUC_03042] Definition of multiple configuration sets
[TPS_ECUC_03043] Occurrence of multiple configuration containers in the ECUC Value descrip-
tion
[TPS_ECUC_03044] Name of the configuration set
[TPS_ECUC_03045] Parameter value description structure underneath the multiple configuration
container
[TPS_ECUC_03046] Values of pre-compile time and link time parameters in different configuration
sets
[TPS_ECUC_03047] EcucReferenceValue in multiple configuration sets
[TPS_ECUC_06050] supportedConfigVariants in the VSMD in case VariantPostBuild is
supported in the StMD
[TPS_ECUC_06051] ImplementationConfigClass of an EcucParameterDef or EcucAbstrac-
tReferenceDef in VSMD
[TPS_ECUC_06052] Supported configuration variants in the VSMD
[TPS_ECUC_06053] VSMD Configuration variant “VariantPreCompile”
[TPS_ECUC_06054] VSMD Configuration variant “VariantLinkTime”
[TPS_ECUC_06055] VSMD Configuration variant “VariantPostBuildLoadable”
[TPS_ECUC_06056] VSMD Configuration variant “VariantPostBuildSelectable”
[TPS_ECUC_08001] Configuration class of parameters and references within
postBuildChangeable containers.

AUTOSAR CP R22-11
[TPS_ECUC_08004] Changing of values and multiplicities of EcucParameterValues at post-

build time
[TPS_ECUC_08007] postBuildChangeable attribute in the VSMD in case it is set to true in the
StMD
[TPS_ECUC_08008] Usage of the multiple configuration container in EcucModuleDefs with sup-
portedConfigVariant of VariantPostBuild
[TPS_ECUC_08009] Names of containers inside a multiple configuration set
Table D.23: Deleted Traceables in 4.2.1
D.7.4 Added Constraints in 4.2.1
Id Heading
[constr_3119] Necessary content of EcucDestinationUriDefs that are referenced by an Ecuc-
ContainerDef
[constr_3120] Applicable attributes when destinationUriNestingContract is set to tar-
getContainer
[constr_5015] Multiplicity of multiplicityConfigClass
[constr_5506] Applicability of postBuildVariantMultiplicity attribute
[constr_5507] Value of EcucContainerDef.postBuildVariantMultiplicity if post-
BuildVariantSupport is set to false
[constr_5509] Value of postBuildVariantMultiplicity if postBuildVariantSupport is
set to false
[constr_5510] Value of postBuildVariantValue if postBuildVariantSupport is set to
false
[constr_5512] postBuildVariantValue attribute of symbolicNameValue parameters
[constr_5514] Applicability of the multiplicityConfigClass attribute
[constr_5520] valueConfigClass attribute of symbolicNameValue parameters
[constr_5521] multiplicityConfigClass attribute of symbolicNameValue parameters
[constr_5522] postBuildVariantMultiplicity attribute of symbolicNameValue parame-
ters
[constr_5523] Allowed configClasses for paired configVariants
Table D.24: Added Constraints in 4.2.1
D.7.5 Changed Constraints in 4.2.1
Id Heading
[constr_3091] Multiplicity of valueConfigClass
[constr_3092] Usage of configVariant and configClass attributes
[constr_5500] Applicability of the multiplicityConfigClass attribute
[constr_5502] Introduction of new EcucParameterValues of type EcucFunctionNameDef at
post-build time
[constr_5504] Removing an instance of the EcucContainerDef at post-build time
Table D.25: Changed Constraints in 4.2.1
D.7.6 Deleted Constraints in 4.2.1
Id Heading

AUTOSAR CP R22-11
[constr_5501] EcucParameterValues and EcucAbstractReferenceValues in EcucCon-

tainerValues that exist in multiple configuration sets
[constr_5503] symbolicNameValue parameters in post-build configuration sets
Table D.26: Deleted Constraints in 4.2.1
Id Heading
[TPS_ECUC_08053] AUTOSAR release version in VSMD
[TPS_ECUC_08054] Semantic of an optional parameter that is not present in the ECU Configura-
tion Value description
Id Heading
[TPS_ECUC_01001] lowerMultiplicity and upperMultiplicity of modules in the VSMD
[TPS_ECUC_02072] Signed EcucIntegerParamDef value range
[TPS_ECUC_02108] Rule for the creation of #define symbols in the header file for parameters
with the symbolicNameValue set to TRUE
[TPS_ECUC_03027] EcucReferenceValue provides the mechanism to reference model ele-
ments that are Referrable
[TPS_ECUC_03033] EcucInstanceReferenceValue provides the mechanism to reference an
instance of a prototype
[TPS_ECUC_03034] Each parameter in an ECU Configuration Value description shall have a
value
none
Id Heading
[constr_3200] Restriction on values of EcucDefinitionElement.relatedTraceItem in the
VSMD
[constr_3217] Symbolic name reference shall point only to containers with a symbolic name value
defined

AUTOSAR CP R22-11
Id Heading
[constr_3022] EcucModuleDef category restriction
[constr_5507] Value of EcucContainerDef.postBuildVariantMultiplicity if post-
BuildVariantSupport is set to false
[constr_5509] Value of postBuildVariantMultiplicity if postBuildVariantSupport is
set to false
[constr_5510] Value of postBuildVariantValue if postBuildVariantSupport is set to
false
none
Id Heading
[TPS_ECUC_02145] Attribute requiresSymbolicNameValue
[TPS_ECUC_02146] Symbolic Name Reference properties
[TPS_ECUC_02147] Introducing new post build variants at post build configuration time
[TPS_ECUC_06082] Definition of interval type for EcucFloatParamDef.min and EcucFloat-
ParamDef.max
[TPS_ECUC_06083] Attribute EcucFloatParamDef.min.intervalType is not defined
[TPS_ECUC_06084] Attribute EcucFloatParamDef.max.intervalType is not defined
[TPS_ECUC_06085] Ordering of MetaDataItems of an MetaDataType
[TPS_ECUC_06086] Relevance of the order of MetaDataItems of an MetaDataType
Id Heading
none

AUTOSAR CP R22-11
Id Heading
[constr_3228] EcucSymbolicNameReferenceDef presupposes requiresSymbolic-
NameValue set to true
[constr_3233] EcucModuleDef that relies on EcucCommonAttributes with valueConfig-
Class set to Link/PostBuild of another EcucModuleDef
[constr_3234] EcucModuleDef that relies on EcucCommonAttributes with multiplicity-
ConfigClass set to Link/PostBuild of another EcucModuleDef
[constr_3235] EcucModuleDef that relies on EcucContainerDefs with multiplicityCon-
figClass set to Link/PostBuild of another EcucModuleDef
[constr_3236] EcucModuleDef that relies on EcucCommonAttributes with postBuildVari-
antValue set to true of another EcucModuleDef
[constr_3237] EcucModuleDef that relies on EcucCommonAttributes with postBuildVari-
antMultiplicity set to true of another EcucModuleDef
[constr_3238] EcucModuleDef that relies on EcucContainerDef with postBuildVariant-
Multiplicity set to true of another EcucModuleDef
[constr_3307] ShortNames of PredefinedVariants referenced by EcucPostBuildVari-
antRefs
Id Heading
[constr_3217] Symbolic name reference shall point only to containers with a symbolic name value
defined
none
Number Heading
[TPS_ECUC_06087] INF and -INF allowed as defaultValue in EcucFloatParamDef

AUTOSAR CP R22-11
Number Heading
[TPS_ECUC_06074] Invalid configuration due to symbolic name values
none
none
none
none
Number Heading
[TPS_ECUC_02148] Replacement for EcucSymbolicNameReferenceDef

AUTOSAR CP R22-11
Number Heading
[TPS_ECUC_02063] Parameters with symbolicNameValue = true
[TPS_ECUC_02147] Introducing new post build variants at post build configuration time
EcucReferenceValue describes EcucReferenceDefs, Ecuc-
[TPS_ECUC_03028] ChoiceReferenceDefs, and EcucForeignReferenceDefs in the Ecu
Configuration Value description
The shortName of the referenced container provides the symbolic name in
[TPS_ECUC_03037]
the implementation
Parameters without parameter definitions in the Ecuc Parameter Value de-
[TPS_ECUC_06012]
scription
Number Heading
[TPS_ECUC_02032] EcucSymbolicNameReferenceDef properties
[TPS_ECUC_02145] Attribute requiresSymbolicNameValue
EcucSymbolicNameReferenceDef translates to a EcucReference-
[TPS_ECUC_03036]
Value in the ECU Configuration Value description
Table D.39: Deleted Traceables in 4.4.0
Number Heading
[constr_3449] Impact of postBuildVariantUsed value set to FALSE
[constr_3450] postBuildVariantUsed value in case of post build VariationPoints
EcucModuleConfigurationValues.postBuildVariantUsed value setting re-
[constr_3451]
striction in case postBuildVariantSupport is set to TRUE
EcucModuleConfigurationValues.postBuildVariantUsed value setting re-
[constr_3452]
striction in case postBuildVariantSupport is set to FALSE
none

AUTOSAR CP R22-11
Number Heading
EcucSymbolicNameReferenceDef presupposes requiresSymbolic-
[constr_3228]
NameValue set to true
Table D.41: Deleted Constraints in 4.4.0
D.12 Change History between AUTOSAR R4.4.0 against R19-11
D.12.1 Added Traceables in 19-11
Number Heading
Specification of the destinationType format in a EcucForeignRefer-
[TPS_ECUC_06088]
enceDef
Table D.42: Added Traceables in 19-11
D.12.2 Changed Traceables in 19-11
Number Heading
[TPS_ECUC_01001] lowerMultiplicity and upperMultiplicity of modules in the VSMD
[TPS_ECUC_01005] Origin attribute of parameters in the VSMD that are taken over from the StMD
[TPS_ECUC_01007] min, max values of parameters in the VSMD
[TPS_ECUC_01025] Generate and extract activities are fully automatic
[TPS_ECUC_01035] UUID of elements in the VSMD that are taken over from the StMD
[TPS_ECUC_04004] Iterative development of the ECU Configuration Value description
Existence of a parameter in the Ecuc Parameter Value description in case the
[TPS_ECUC_06010]
lowerMultiplicity of the parameter definition is bigger than zero
[TPS_ECUC_06031] Interaction of Complex Driver with standardized AUTOSAR BSW modules
[TPS_ECUC_06032] Min and max values in EcucIntegerParamDef
[TPS_ECUC_06033] Min and max values in EcucFloatParamDef
Table D.43: Changed Traceables in 19-11

AUTOSAR CP R22-11
D.12.3 Deleted Traceables in 19-11
Number Heading
[TPS_ECUC_02148] Replacement for EcucSymbolicNameReferenceDef
[TPS_ECUC_06085] Ordering of MetaDataItems of an MetaDataType
Table D.44: Deleted Traceables in 19-11
D.12.4 Added Constraints in 19-11
Number Heading
[constr_5059] Ordering of MetaDataItems of a MetaDataType
Table D.45: Added Constraints in 19-11
D.12.5 Changed Constraints in 19-11
none
D.12.6 Deleted Constraints in 19-11
none
D.13 Change History between AUTOSAR R19-11 against R20-11
D.13.1 Added Traceables in R20-11
Number Heading
[TPS_ECUC_02149] Existence of EcucDefinitionCollection.module
[TPS_ECUC_02150] Existence of EcucModuleDef.container
[TPS_ECUC_02151] Existence of EcucValueCollection.ecucValue
[TPS_ECUC_02152] EcucModuleConfigurationValues.container
Table D.46: Added Traceables in R20-11
D.13.2 Changed Traceables in R20-11
none

AUTOSAR CP R22-11
D.13.3 Deleted Traceables in R20-11
Number Heading
[TPS_ECUC_02088] Configuration Editor shall display the content of the longName to users
ECU Configuration Editor shall be able to merge ECU Configuration
[TPS_ECUC_04002]
Value descriptions
[TPS_ECUC_04003] ECU Configuration Editor shall be able to work with subsets of parameters
ECU Configuration Editor shall be able to generate and import EcucModule-
[TPS_ECUC_04005]
ConfigurationValues
[TPS_ECUC_06071] ECU Configuration Editor shall be able to read parameter values in any order
The ECU Configuration Editor shall be able to work with arbitrary package
[TPS_ECUC_06073]
structures
Table D.47: Deleted Traceables in R20-11
D.13.4 Added Constraints in R20-11
Number Heading
[constr_3570] EcucDefinitionElement.lowerMultiplicity always required
[constr_3571] EcucCommonAttributes.origin always required
[constr_3572] EcucParameterDef.symbolicNameValue always required
[constr_3573] EcucAbstractConfigurationClass.configClass always required
[constr_3574] EcucAbstractConfigurationClass.configVariant always required
[constr_3575] EcucEnumerationLiteralDef.origin always required
[constr_3576] EcucInstanceReferenceDef.destinationContext always required
[constr_3577] EcucInstanceReferenceDef.destinationType always required
[constr_3578] EcucForeignReferenceDef.destinationType always required
[constr_3579] EcucReferenceDef.destination always required
[constr_3580] EcucUriReferenceDef.destinationUri always required
[constr_3581] EcucDestinationUriDefSet.destinationUriDef always required
[constr_3582] EcucDestinationUriDef.destinationUriPolicy always required
EcucDestinationUriPolicy.destinationUriNestingContract always re-
[constr_3583]
quired
[constr_3584] EcucQuery.ecucQueryExpression always required
[constr_3585] EcucConditionFormula.ecucQuery always required
[constr_3586] EcucConditionFormula.ecucQueryString always required
[constr_3587] EcucValidationCondition.validationFormula always required
[constr_3588] EcucValueCollection.ecuExtract always required
[constr_3589] EcucModuleConfigurationValues.ecucDefEdition always required
EcucModuleConfigurationValues.implementationConfigVariant al-
[constr_3590]
ways required
5

AUTOSAR CP R22-11
4
Number Heading
[constr_3591] EcucModuleConfigurationValues.definition always required
[constr_3592] EcucContainerValue.definition always required
[constr_3593] EcucParameterValue.definition always required
[constr_3594] EcucNumericalParamValue.value always required
[constr_3595] EcucTextualParamValue.value always required
[constr_3596] EcucAddInfoParamValue.value always required
[constr_3597] EcucAbstractReferenceValue.definition always required
[constr_3598] EcucInstanceReferenceValue.value always required
[constr_3599] EcucReferenceValue.value always required
[constr_5108] CddModuleId range restriction
Table D.48: Added Constraints in R20-11
D.13.5 Changed Constraints in R20-11
none
D.13.6 Deleted Constraints in R20-11
none
none
Number Heading
[TPS_ECUC_06069] Sorting criteria for Parameters on the Values side
Table D.49: Changed Traceables in R21-11

AUTOSAR CP R22-11
Number Heading
[TPS_ECUC_02006] Container definition
[TPS_ECUC_02043] Each EcucContainerDef is Identifiable
none
Number Heading
[constr_5520] valueConfigClass attribute of symbolicNameValue parameters
Table D.51: Changed Constraints in R21-11
none
Number Heading
Multiple aggregation of container trees that include references to other
[TPS_ECUC_06089]
subContainers in the same aggregated container tree
Table D.52: Added Traceables in R22-11

AUTOSAR CP R22-11
Number Heading
Expression of optionality of containers, parameters and references in the
[TPS_ECUC_02009]
Ecuc Parameter Definition UML model
Rule for the creation of #define symbols in the header file for parameters
[TPS_ECUC_02108]
with the symbolicNameValue set to TRUE
[TPS_ECUC_06037] apiServicePrefix attribute for Complex Driver module and Xfrm module
Table D.53: Changed Traceables in R22-11
Number Heading
Existence of upperMultiplicityInfinite and upperMultiplicity
[TPS_ECUC_06017]
is mutually exclusive
Number Heading
Existence of upperMultiplicityInfinite and upperMultiplicity is
[constr_5325]
mutually exclusive
EcucDefinitionElement.upperMultiplicity or
[constr_5342]
EcucDefinitionElement.upperMultiplicityInfinite always required
[constr_5345] Restriction for a reference destination in case of multiple aggregated

EcucParamConfContainerDefs
Table D.55: Added Constraints in R22-11
Number Heading
Table D.56: Changed Constraints in R22-11

AUTOSAR CP R22-11
none

AUTOSAR CP R22-11
E Mentioned Class Tables

For the sake of completeness, this chapter contains a set of class tables representing
meta-classes mentioned in the context of this document but which are not contained
directly in the scope of describing specific meta-model semantics.
Class ARElement (abstract)
Package M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::ARPackage
Note An element that can be defined stand-alone, i.e. without being part of another element (except for
packages of course).
Base ARObject, CollectableElement, Identifiable, MultilanguageReferrable, PackageableElement, Referrable
Subclasses AclObjectSet, AclOperation, AclPermission, AclRole, AliasNameSet, ApplicationPartition, AutosarData
Type, BaseType, BlueprintMappingSet, BswEntryRelationshipSet, BswModuleDescription, BswModule
Entry, BuildActionManifest, CalibrationParameterValueSet, ClientIdDefinitionSet, ClientServerInterfaceTo
BswModuleEntryBlueprintMapping, Collection, CompuMethod, ConsistencyNeedsBlueprintSet, Constant
Specification, ConstantSpecificationMappingSet, CpSoftwareCluster, CpSoftwareClusterBinaryManifest
Descriptor, CpSoftwareClusterMappingSet, CpSoftwareClusterResourcePool, CryptoEllipticCurveProps,
CryptoServiceCertificate, CryptoServiceKey, CryptoServicePrimitive, CryptoServiceQueue, Crypto
SignatureScheme, DataConstr, DataExchangePoint, DataTransformationSet, DataTypeMappingSet,
DiagnosticCommonElement, DiagnosticConnection, DiagnosticContributionSet, DltContext, DltEcu,
Documentation, E2EProfileCompatibilityProps, EcucDefinitionCollection, EcucDestinationUriDefSet,
EcucModuleConfigurationValues, EcucModuleDef, EcucValueCollection, EndToEndProtectionSet, EthIp
Props, EthTcpIpIcmpProps, EthTcpIpProps, EvaluatedVariantSet, FMFeature, FMFeatureMap, FM
FeatureModel, FMFeatureSelectionSet, FlatMap, GeneralPurposeConnection, HwCategory, HwElement,
HwType, IPSecConfigProps, IPv6ExtHeaderFilterSet, IdsCommonElement, IdsDesign, Implementation,
InterpolationRoutineMappingSet, J1939ControllerApplication, KeywordSet, LifeCycleInfoSet, LifeCycle
StateDefinitionGroup, LogAndTraceMessageCollectionSet, MacSecGlobalKayProps, MacSecParticipant
Set, McFunction, McGroup, ModeDeclarationGroup, ModeDeclarationMappingSet, OsTaskProxy,
PhysicalDimension, PhysicalDimensionMappingSet, PortInterface, PortInterfaceMappingSet, Port
PrototypeBlueprint, PostBuildVariantCriterion, PostBuildVariantCriterionValueSet, PredefinedVariant,
RapidPrototypingScenario, SdgDef, SignalServiceTranslationPropsSet, SomeipSdClientEventGroup
TimingConfig, SomeipSdClientServiceInstanceConfig, SomeipSdServerEventGroupTimingConfig,
SomeipSdServerServiceInstanceConfig, SwAddrMethod, SwAxisType, SwComponentMapping
Constraints, SwComponentType, SwRecordLayout, SwSystemconst, SwSystemconstantValueSet, Swc
BswMapping, System, SystemSignal, SystemSignalGroup, TDCpSoftwareClusterMappingSet, Tcp
OptionFilterSet, TimingExtension, TlsConnectionGroup, TlvDataIdDefinitionSet, TransformationProps
Set, Unit, UnitGroup, ViewMapSet
– – – – –
Table E.1: ARElement
Class ARPackage
Note AUTOSAR package, allowing to create top level packages to structure the contained ARElements.
ARPackages are open sets. This means that in a file based description system multiple files can be used
to partially describe the contents of a package.
This is an extended version of MSR’s SW-SYSTEM.
Base ARObject, AtpBlueprint, AtpBlueprintable, CollectableElement, Identifiable, MultilanguageReferrable,
Referrable
Aggregated by ARPackage.arPackage, AUTOSAR.arPackage
5

AUTOSAR CP R22-11
4
Class ARPackage
arPackage ARPackage * aggr This represents a sub package within an ARPackage,
thus allowing for an unlimited package hierarchy.
Tags:
atp.Splitkey=arPackage.shortName, arPackage.variation
Point.shortLabel
vh.latestBindingTime=blueprintDerivationTime
element PackageableElement * aggr Elements that are part of this package
Tags:
atp.Splitkey=element.shortName, element.variation
Point.shortLabel
vh.latestBindingTime=systemDesignTime
referenceBase ReferenceBase * aggr This denotes the reference bases for the package. This is
the basis for all relative references within the package.
The base needs to be selected according to the base
attribute within the references.
Tags:
atp.Splitkey=referenceBase.shortLabel
Table E.2: ARPackage
Class AUTOSAR
Package M2::AUTOSARTemplates::AutosarTopLevelStructure
Note Root element of an AUTOSAR description, also the root element in corresponding XML documents.
Tags:xml.globalElement=true
Base ARObject
adminData AdminData 0..1 aggr This represents the administrative data of an Autosar file.
arPackage ARPackage * aggr This is the top level package in an AUTOSAR model.
Tags:
atp.Splitkey=arPackage.shortName, arPackage.variation
Point.shortLabel
vh.latestBindingTime=blueprintDerivationTime
fileInfo FileInfoComment 0..1 aggr This represents a possibility to provide a structured
Comment comment in an AUTOSAR file.
Stereotypes: atpStructuredComment
Tags:
xml.roleElement=true
xml.sequenceOffset=-10
xml.typeElement=false
introduction DocumentationBlock 0..1 aggr This represents an introduction on the Autosar file. It is
intended for example to represent disclaimers and legal
notes.
Table E.3: AUTOSAR

AUTOSAR CP R22-11
Class AdminData
Package M2::MSR::AsamHdo::AdminData
Note AdminData represents the ability to express administrative information and custom extensions for an
element. This administration information is to be treated as meta-data such as revision id or state of the
file. There are basically the following kinds of meta-data
• The language and/or used languages.
• Revision information covering e.g. revision number, state, release date, changes. Note that this
information can be given in general as well as related to a particular company.
• Document meta-data specific for a company
Beside that a custom extension of model-data is possible by
• Special data
Base ARObject
Aggregated by AUTOSAR.adminData, Describable.adminData, Identifiable.adminData
docRevision DocRevision * aggr This allows to denote information about the current
(ordered) revision of the object.
Note that information about previous revisions can also
be logged here. The entries shall be sorted descendant
by date in order to reflect the history. Therefore the most
recent entry representing the current version is denoted
first.
Tags:
xml.roleWrapperElement=true
xml.typeWrapperElement=false
language LEnum 0..1 attr This attribute specifies the master language of the
document or the document fragment. The master
language is the one in which the document is maintained
and from which the other languages are derived from. In
particular in case of inconsistencies, the information in
the master language is priority.
sdg Sdg * aggr This property allows to keep special data which is not
represented by the standard model. It can be utilized to
keep e.g. tool specific data.
Tags:
atp.Splitkey=sdg
usedLanguages MultiLanguagePlainText 0..1 aggr This property specifies the languages which are provided
in the document. Therefore it should only be specified in
the top level admin data. For each language provided in
the document there is one entry in MultilanguagePlain
Text. The content of each entry can be used for
illustration of the language. The used language itself
depends on the language attribute in the entry.
Table E.4: AdminData

AUTOSAR CP R22-11
Class AnyInstanceRef
Package M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::AnyInstanceRef
Note Describes a reference to any instance in an AUTOSAR model. This is the most generic form of an
instance ref. Refer to the superclass notes for more details.
Base ARObject, AtpInstanceRef
Aggregated by Collection.collectedInstance, Collection.sourceInstance, DocumentationContext.feature, EcucInstance
ReferenceValue.value, FlatInstanceDescriptor.ecuExtractReference, FlatInstanceDescriptor.upstream
Reference, RptContainer.byPassPoint, RptHook.rptArHook, ViewMap.firstElementInstance, ViewMap.
secondElementInstance
base AtpClassifier 1 ref This is the base from which navigation path begins.
Stereotypes: atpDerived
contextElement AtpFeature * ref This is one step in the navigation path specified by the
(ordered) instance ref.
target AtpFeature 1 ref This is the target of the instance ref.
Table E.5: AnyInstanceRef
Class AssemblySwConnector
Package M2::AUTOSARTemplates::SWComponentTemplate::Composition
Note AssemblySwConnectors are exclusively used to connect SwComponentPrototypes in the context of a
CompositionSwComponentType.
Base ARObject, AtpClassifier , AtpFeature, AtpStructureElement, Identifiable, MultilanguageReferrable,
Referrable, SwConnector
Aggregated by AtpClassifier .atpFeature, CompositionSwComponentType.connector
provider AbstractProvidedPort 0..1 iref Instance of providing port.
Prototype
InstanceRef implemented by:PPortInComposition
InstanceRef
requester AbstractRequiredPort 0..1 iref Instance of requiring port.
Prototype
InstanceRef implemented by:RPortInComposition
InstanceRef
Table E.6: AssemblySwConnector
Class BswImplementation
Package M2::AUTOSARTemplates::BswModuleTemplate::BswImplementation
Note Contains the implementation specific information in addition to the generic specification (BswModule
Description and BswBehavior). It is possible to have several different BswImplementations referring to
the same BswBehavior.
Tags:atp.recommendedPackage=BswImplementations
Base ARElement, ARObject, CollectableElement, Identifiable, Implementation, MultilanguageReferrable,
PackageableElement, Referrable
arRelease RevisionLabelString 0..1 attr Version of the AUTOSAR Release on which this
Version implementation is based. The numbering contains three
levels (major, minor, revision) which are defined by
AUTOSAR.
5

AUTOSAR CP R22-11
4
Class BswImplementation
behavior BswInternalBehavior 0..1 ref The behavior of this implementation.
This relation is made as an association because
• it follows the pattern of the SWCT
• since ARElement cannot be splitted, but we want
supply the implementation later, the Bsw
Implementation is not aggregated in BswBehavior
preconfigured EcucModule * ref Reference to the set of preconfigured (i.e. fixed)
Configuration ConfigurationValues configuration values for this BswImplementation.
If the BswImplementation represents a cluster of several
modules, more than one EcucModuleConfigurationValues
element can be referred (at most one per module),
otherwise at most one such element can be referred.
Tags:xml.roleWrapperElement=true
recommended EcucModule * ref Reference to one or more sets of recommended
Configuration ConfigurationValues configuration values for this module or module cluster.
vendorApiInfix Identifier 0..1 attr In driver modules which can be instantiated several times
on a single ECU, SRS_BSW_00347 requires that the
names of files, APIs, published parameters and memory
allocation keywords are extended by the vendorId and a
vendor specific name. This parameter is used to specify
the vendor specific name. In total, the implementation
specific API name is generated as follows: <Module
Name>_<vendorId>_ <vendorApiInfix>_<API name from
SWS>.
E.g. assuming that the vendorId of the implementer is
123 and the implementer chose a vendorApiInfix of
"v11r456" an API name Can_Write defined in the SWS
will translate to Can_123_v11r456_Write.
This attribute is mandatory for all modules with upper
multiplicity > 1. It shall not be used for modules with
upper multiplicity =1.
See also SWS_BSW_00102.
vendorSpecific EcucModuleDef * ref Reference to
ModuleDef
• the vendor specific EcucModuleDef used in this
BswImplementation if it represents a single
module
• several EcucModuleDefs used in this Bsw
Implementation if it represents a cluster of
modules
• one or no EcucModuleDefs used in this Bsw
Implementation if it represents a library
Tags:xml.roleWrapperElement=true
Table E.7: BswImplementation
Primitive CIdentifier
Package M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::PrimitiveTypes
Note This datatype represents a string, that follows the rules of C-identifiers.
Tags:
xml.xsd.customType=C-IDENTIFIER
xml.xsd.pattern=[a-zA-Z_][a-zA-Z0-9_]*
xml.xsd.type=string
5

AUTOSAR CP R22-11
4
Primitive CIdentifier
blueprintValue String 1 attr This represents a description that documents how the
value shall be defined when deriving objects from the
blueprint.
Tags:
atp.Status=draft
xml.attribute=true
namePattern String 0..1 attr This attribute represents a pattern which shall be used to
define the value of the identifier if the CIdentifier in
question is part of a blueprint.
For more details refer to TPS_StandardizationTemplate.
Tags:xml.attribute=true
Table E.8: CIdentifier
Class CompositionSwComponentType
Note A CompositionSwComponentType aggregates SwComponentPrototypes (that in turn are typed by Sw
ComponentTypes) as well as SwConnectors for primarily connecting SwComponentPrototypes among
each others and towards the surface of the CompositionSwComponentType. By this means, hierarchical
structures of software-components can be created.
Tags:atp.recommendedPackage=SwComponentTypes
Base ARElement, ARObject, AtpBlueprint, AtpBlueprintable, AtpClassifier , AtpType, CollectableElement,
Identifiable, MultilanguageReferrable, PackageableElement, Referrable, SwComponentType
component SwComponent * aggr The instantiated components that are part of this
Prototype composition. The aggregation of SwComponentPrototype
is subject to variability with the purpose to support the
conditional existence of a SwComponentPrototype.
Please be aware: if the conditional existence of Sw
ComponentPrototypes is resolved post-build the
deselected SwComponentPrototypes are still contained in
the ECUs build but the instances are inactive in that they
are not scheduled by the RTE.
The aggregation is marked as atpSplitable in order to
allow the addition of service components to the ECU
extract during the ECU integration.
The use case for having 0 components owned by the
CompositionSwComponentType could be to deliver an
empty CompositionSwComponentType to e.g. a supplier
for filling the internal structure.
Tags:
atp.Splitkey=component.shortName, component.variation
Point.shortLabel
5

AUTOSAR CP R22-11
4
Class CompositionSwComponentType
connector SwConnector * aggr SwConnectors have the principal ability to establish a
connection among PortPrototypes. They can have many
roles in the context of a CompositionSwComponentType.
Details are refined by subclasses.
The aggregation of SwConnectors is subject to variability
with the purpose to support variant data flow.
The aggregation is marked as atpSplitable in order to
allow the extension of the ECU extract with AssemblySw
Connectors between ApplicationSwComponentTypes and
ServiceSwComponentTypes during the ECU integration.
Tags:
atp.Splitkey=connector.shortName, connector.variation
Point.shortLabel
constantValue ConstantSpecification * ref Reference to the ConstantSpecificationMapping to be
Mapping MappingSet applied for initValues of PPortComSpecs and RPortCom
Spec.
Tags:atp.Splitkey=constantValueMapping
dataType DataTypeMappingSet * ref Reference to the DataTypeMapping to be applied for the
Mapping used ApplicationDataTypes in PortInterfaces.
Background: when developing subsystems it may happen
that ApplicationDataTypes are used on the surface of
CompositionSwComponentTypes. In this case it would be
reasonable to be able to also provide the intended
mapping to the ImplementationDataTypes. However, this
mapping shall be informal and not technically binding for
the implementors mainly because the RTE generator is
not concerned about the CompositionSwComponent
Types.
Rationale: if the mapping of ApplicationDataTypes on the
delegated and inner PortPrototype matches then the
mapping to ImplementationDataTypes is not impacting
compatibility.
Tags:atp.Splitkey=dataTypeMapping
instantiation InstantiationRTEEvent * aggr This allows to define instantiation specific properties for
RTEEventProps Props RTE Events, in particular for instance specific scheduling.
Tags:
atp.Splitkey=instantiationRTEEventProps.shortLabel,
instantiationRTEEventProps.variationPoint.shortLabel
Table E.9: CompositionSwComponentType
Class Describable (abstract)

Package M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::Identifiable
Note This meta-class represents the ability to add a descriptive documentation to non identifiable elements.
Base ARObject
Subclasses CyclicTiming, EventControlledTiming, HwElementConnector, HwPinConnector, HwPinGroupConnector, I
PduTiming, Ipv4DhcpServerConfiguration, Ipv6DhcpServerConfiguration, PncMapping, Socket
Connection, TransformationComSpecProps, TransformationDescription, TransformationISignalProps
5

AUTOSAR CP R22-11
4
Class Describable (abstract)
adminData AdminData 0..1 aggr This represents the administrative data for the
describable object.
Tags:
atp.Splitkey=adminData
category CategoryString 0..1 attr The category is a keyword that specializes the semantics
of the Describable. It affects the expected existence of
attributes and the applicability of constraints.
desc MultiLanguageOverview 0..1 aggr This represents a general but brief (one paragraph)
Paragraph description what the object in question is about. It is only
one paragraph! Desc is intended to be collected into
overview tables. This property helps a human reader to
identify the object in question.
More elaborate documentation, (in particular how the
object is built or used) should go to "introduction".
introduction DocumentationBlock 0..1 aggr This represents more information about how the object in
question is built or is used. Therefore it is a
DocumentationBlock.
Table E.10: Describable
Class DocRevision
Package M2::MSR::AsamHdo::AdminData
Note This meta-class represents the ability to maintain information which relates to revision management of
documents or objects.
Base ARObject
Aggregated by AdminData.docRevision
date DateTime 1 attr This specifies the date and time, when the object in
question was released
issuedBy String 0..1 attr This is the name of an individual or an organization who
issued the current revision of the document or document
fragment.
modification Modification * aggr This property represents one particular modification in
comparison to its predecessor.
Tags:
revisionLabel RevisionLabelString 0..1 attr This attribute represents the version number of the object.
5

AUTOSAR CP R22-11
4
Class DocRevision
revisionLabelP1 RevisionLabelString 0..1 attr This attribute represents the version number of the first
predecessor of the object.
revisionLabelP2 RevisionLabelString 0..1 attr This attribute represents the version number of the
second predecessor of the object.
This attribute is used if the object is the result of a merge
process in which two branches are merged in to one new
revision.
state NameToken 0..1 attr The attribute state represents the current state of the
current file according to the configuration management
plan. It is a NameToken until possible states are
standardized.
Table E.11: DocRevision
Class Documentation
Package M2::AUTOSARTemplates::GenericStructure::DocumentationOnM1
Note This meta-class represents the ability to handle a so called standalone documentation. Standalone
means, that such a documentation is not embedded in another ARElement or identifiable object. The
standalone documentation is an entity of its own which denotes its context by reference to other objects
and instances.
Tags:atp.recommendedPackage=Documentations
Element, Referrable
context DocumentationContext * aggr This is the context of the particular documentation.
documentation PredefinedChapter 0..1 aggr This is the content of the documentation related to the
Content specified contexts.
Table E.12: Documentation
Class Frame (abstract)

Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note Data frame which is sent over a communication medium. This element describes the pure Layout of a
frame sent on a channel.
Base ARObject, CollectableElement, FibexElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Subclasses AbstractEthernetFrame, CanFrame, FlexrayFrame, LinFrame
frameLength Integer 0..1 attr The used length (in bytes) of the referencing frame.
Should not be confused with a static byte length reserved
for each frame by some platforms (e.g. FlexRay).
The frameLength of zero bytes is allowed.
Please consider also TPS_SYST_02255.
5

AUTOSAR CP R22-11
4
Class Frame (abstract)
pduToFrame PduToFrameMapping * aggr A frames layout as a sequence of Pdus.
Mapping
atpVariation: The content of a frame can be variable.
Tags:
atp.Splitkey=pduToFrameMapping.shortName, pduTo
FrameMapping.variationPoint.shortLabel
Table E.13: Frame
Class FrameTriggering (abstract)

Note The FrameTriggering describes the instance of a frame sent on a channel and defines the manner of
triggering (timing information) and identification of a frame on the channel, on which it is sent.
For the same frame, if FrameTriggerings exist on more than one channel of the same cluster the fan-out/
in is handled by the Bus interface.
Subclasses CanFrameTriggering, EthernetFrameTriggering, FlexrayFrameTriggering, LinFrameTriggering
Aggregated by PhysicalChannel.frameTriggering
frame Frame 1 ref One frame can be triggered several times, e.g. on
different channels. If a frame has no frame triggering, it
won’t be sent at all. A frame triggering has assigned
exactly one frame, which it triggers.
framePort FramePort * ref References to the FramePort on every ECU of the system
which sends and/or receives the frame.
References for both the sender and the receiver side
shall be included when the system is completely defined.
pduTriggering PduTriggering * ref This reference provides the relationship to the Pdu
Triggerings that are implemented by the FrameTriggering.
The reference is optional since no PduTriggering can be
defined for NmPdus and XCP Pdus.
Tags:
atp.Splitkey=pduTriggering.pduTriggering, pdu
Triggering.variationPoint.shortLabel
Table E.14: FrameTriggering
Class HwElement
Package M2::AUTOSARTemplates::EcuResourceTemplate
Note This represents the ability to describe Hardware Elements on an instance level. The particular types of
hardware are distinguished by the category. This category determines the applicable attributes. The
possible categories and attributes are defined in HwCategory.
Tags:atp.recommendedPackage=HwElements
Base ARElement, ARObject, CollectableElement, HwDescriptionEntity , Identifiable, MultilanguageReferrable,
5

AUTOSAR CP R22-11
4
Class HwElement
hwElement HwElementConnector * aggr This represents one particular connection between two
Connection hardware elements.
Tags:
atp.Splitkey=hwElementConnection, hwElement
Connection.variationPoint.shortLabel
hwPinGroup HwPinGroup * aggr This aggregation is used to describe the connection
facilities of a hardware element. Note that hardware
element has no pins but only pingroups.
Tags:
atp.Splitkey=hwPinGroup.shortName, hwPin
Group.variationPoint.shortLabel
nestedElement HwElement * ref This association is used to establish hierarchies of hw
elements. Note that one particular HwElement can be
target of this association only once. I.e. multiple
instantiation of the same HwElement is not supported (at
any hierarchy level).
Tags:
atp.Splitkey=nestedElement.hwElement, nested
Element.variationPoint.shortLabel
Table E.15: HwElement
Class Identifiable (abstract)

Note Instances of this class can be referred to by their identifier (within the namespace borders). In addition to
this, Identifiables are objects which contribute significantly to the overall structure of an AUTOSAR
description. In particular, Identifiables might contain Identifiables.
Base ARObject, MultilanguageReferrable, Referrable
Subclasses ARPackage, AbstractDoIpLogicAddressProps, AbstractEvent, AbstractImplementationDataTypeElement,
AbstractSecurityEventFilter , AbstractSecurityIdsmInstanceFilter , AbstractServiceInstance, AppOsTask
ProxyToEcuTaskProxyMapping, ApplicationEndpoint, ApplicationError, ApplicationPartitionToEcuPartition
Mapping, AsynchronousServerCallResultPoint, AtpBlueprint, AtpBlueprintable, AtpClassifier , Atp
Feature, AutosarOperationArgumentInstance, AutosarVariableInstance, BinaryManifestAddressable
Object, BinaryManifestItemDefinition, BinaryManifestResource, BinaryManifestResourceDefinition,
BlockState, BswInternalTriggeringPoint, BswModuleDependency, BuildActionEntity , BuildAction
Environment, CanTpAddress, CanTpChannel, CanTpNode, Chapter, ClassContentConditional, ClientId
Definition, ClientServerOperation, Code, CollectableElement, ComManagementMapping, Comm
ConnectorPort, CommunicationConnector , CommunicationController , Compiler, ConsistencyNeeds,
ConsumedEventGroup, CouplingPort, CouplingPortStructuralElement, CpSoftwareClusterResource, Cp
SoftwareClusterResourceToApplicationPartitionMapping, CpSoftwareClusterToEcuInstanceMapping, Cp
SoftwareClusterToResourceMapping, CryptoServiceMapping, DataPrototypeGroup, DataTransformation,
DependencyOnArtifact, DiagEventDebounceAlgorithm, DiagnosticConnectedIndicator, DiagnosticData
Element, DiagnosticDebounceAlgorithmProps, DiagnosticFunctionInhibitSource, DiagnosticParameter
Element, DiagnosticRoutineSubfunction, DltApplication, DltArgument, DltLogChannel, DltMessage, DoIp
Interface, DoIpLogicAddress, DoIpRoutingActivation, ECUMapping, EOCExecutableEntityRefAbstract,
EcuPartition, EcucContainerValue, EcucDefinitionElement, EcucDestinationUriDef, EcucEnumeration
LiteralDef, EcucQuery, EcucValidationCondition, EndToEndProtection, EthernetWakeupSleepOnDataline
Config, EventHandler, ExclusiveArea, ExecutableEntity , ExecutionTime, FMAttributeDef, FMFeatureMap
5

AUTOSAR CP R22-11
4
4
Assertion, FMFeatureMapCondition, FMFeatureMapElement, FMFeatureRelation, FMFeatureRestriction,
FMFeatureSelection, FlatInstanceDescriptor, FlexrayArTpNode, FlexrayTpConnectionControl, FlexrayTp
Node, FlexrayTpPduPool, FrameTriggering, GeneralParameter, GlobalTimeGateway, GlobalTimeMaster ,
GlobalTimeSlave, HeapUsage, HwAttributeDef, HwAttributeLiteralDef, HwPin, HwPinGroup, IPSecRule,
IPv6ExtHeaderFilterList, ISignalToIPduMapping, ISignalTriggering, IdentCaption, InternalTriggeringPoint,
J1939SharedAddressCluster, J1939TpNode, Keyword, LifeCycleState, LinScheduleTable, LinTpNode,
Linker, MacMulticastGroup, MacSecKayParticipant, McDataInstance, MemorySection, ModeDeclaration,
ModeDeclarationMapping, ModeSwitchPoint, NetworkEndpoint, NmCluster , NmEcu, NmNode, NvBlock
Descriptor, PackageableElement, ParameterAccess, PduActivationRoutingGroup, PduToFrameMapping,
PduTriggering, PerInstanceMemory, PhysicalChannel, PortElementToCommunicationResourceMapping,
PortGroup, PortInterfaceMapping, PossibleErrorReaction, ResourceConsumption, RootSwComposition
Prototype, RptComponent, RptContainer, RptExecutableEntity, RptExecutableEntityEvent, RptExecution
Context, RptProfile, RptServicePoint, RteEventInCompositionSeparation, RteEventInCompositionToOs
TaskProxyMapping, RteEventInSystemSeparation, RteEventInSystemToOsTaskProxyMapping,
RunnableEntityGroup, SdgAttribute, SdgClass, SecureCommunicationAuthenticationProps, Secure
CommunicationFreshnessProps, SecurityEventContextProps, ServerCallPoint, ServiceNeeds, Signal
ServiceTranslationElementProps, SignalServiceTranslationEventProps, SignalServiceTranslationProps,
SocketAddress, SomeipTpChannel, SpecElementReference, StackUsage, StaticSocketConnection,
StructuredReq, SwGenericAxisParamType, SwServiceArg, SwcServiceDependency, SwcToApplication
PartitionMapping, SwcToEcuMapping, SwcToImplMapping, SystemMapping, TDCpSoftwareCluster
Mapping, TDCpSoftwareClusterResourceMapping, TcpOptionFilterList, TimingClock , TimingClockSync
Accuracy, TimingCondition, TimingConstraint, TimingDescription, TimingExtensionResource, Timing
ModeInstance, TlsCryptoCipherSuite, TlsCryptoCipherSuiteProps, Topic1, TpAddress, TraceableTable,
TraceableText, TracedFailure, TransformationProps, TransformationTechnology, Trigger, VariableAccess,
VariationPointProxy, ViewMap, VlanConfig, WaitPoint
adminData AdminData 0..1 aggr This represents the administrative data for the identifiable
object.
Tags:
atp.Splitkey=adminData
annotation Annotation * aggr Possibility to provide additional notes while defining a
model element (e.g. the ECU Configuration Parameter
Values). These are not intended as documentation but
are mere design notes.
category CategoryString 0..1 attr The category is a keyword that specializes the semantics
of the Identifiable. It affects the expected existence of
attributes and the applicability of constraints.
desc MultiLanguageOverview 0..1 aggr This represents a general but brief (one paragraph)
Paragraph description what the object in question is about. It is only
one paragraph! Desc is intended to be collected into
overview tables. This property helps a human reader to
identify the object in question.
More elaborate documentation, (in particular how the
object is built or used) should go to "introduction".
introduction DocumentationBlock 0..1 aggr This represents more information about how the object in
question is built or is used. Therefore it is a
DocumentationBlock.
5

AUTOSAR CP R22-11
4
uuid String 0..1 attr The purpose of this attribute is to provide a globally
unique identifier for an instance of a meta-class. The
values of this attribute should be globally unique strings
prefixed by the type of identifier. For example, to include a
DCE UUID as defined by The Open Group, the UUID
would be preceded by "DCE:". The values of this attribute
may be used to support merging of different AUTOSAR
models. The form of the UUID (Universally Unique
Identifier) is taken from a standard defined by the Open
Group (was Open Software Foundation). This standard is
widely used, including by Microsoft for COM (GUIDs) and
by many companies for DCE, which is based on CORBA.
The method for generating these 128-bit IDs is published
in the standard and the effectiveness and uniqueness of
the IDs is not in practice disputed. If the id namespace is
omitted, DCE is assumed. An example is
"DCE:2fac1234-31f8-11b4-a222-08002b34c003". The
uuid attribute has no semantic meaning for an AUTOSAR
model and there is no requirement for AUTOSAR tools to
manage the timestamp.
Table E.16: Identifiable
Primitive Identifier
Note An Identifier is a string with a number of constraints on its appearance, satisfying the requirements typical
programming languages define for their Identifiers.
This datatype represents a string, that can be used as a c-Identifier.
It shall start with a letter, may consist of letters, digits and underscores.
Tags:
xml.xsd.customType=IDENTIFIER
xml.xsd.maxLength=128
xml.xsd.pattern=[a-zA-Z][a-zA-Z0-9_]*
xml.xsd.type=string
blueprintValue String 0..1 attr This represents a description that documents how the
blueprint.
Tags:
atp.Status=draft
xml.attribute=true
namePattern String 0..1 attr This attribute represents a pattern which shall be used to
define the value of the identifier if the identifier in question
is part of a blueprint.
For more details refer to TPS_StandardizationTemplate.
Table E.17: Identifier

AUTOSAR CP R22-11
Class ImplementationDataType
Package M2::AUTOSARTemplates::CommonStructure::ImplementationDataTypes
Note Describes a reusable data type on the implementation level. This will typically correspond to a typedef in
C-code.
Tags:atp.recommendedPackage=ImplementationDataTypes
Base ARElement, ARObject, AbstractImplementationDataType, AtpBlueprint, AtpBlueprintable, AtpClassifier ,
AtpType, AutosarDataType, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
dynamicArray String 0..1 attr Specifies the profile which the array will follow in case this
SizeProfile data type is a variable size array.
isStructWith Boolean 0..1 attr This attribute is only valid if the attribute category is set to
Optional STRUCTURE.
Element
If set to true, this attribute indicates that the
ImplementationDataType has been created with the
intention to define at least one element of the structure as
optional.
subElement ImplementationData * aggr Specifies an element of an array, struct, or union data
(ordered) TypeElement type.
The aggregation of ImplementionDataTypeElement is
subject to variability with the purpose to support the
conditional existence of elements inside a Implementation
DataType representing a structure.
Tags:
atp.Splitkey=subElement.shortName, sub
Element.variationPoint.shortLabel
symbolProps SymbolProps 0..1 aggr This represents the SymbolProps for the Implementation
DataType.
Tags:atp.Splitkey=symbolProps.shortName
typeEmitter NameToken 0..1 attr This attribute is used to control which part of the
AUTOSAR toolchain is supposed to trigger data type
definitions.
Table E.18: ImplementationDataType
Enumeration IntervalTypeEnum
Note This enumerator specifies the type of an interval.
Aggregated by Limit.intervalType, LimitValueVariationPoint.intervalType
Literal Description
closed The area is limited by the value given. The value itself is included.
open The area is limited by the value given. The value itself is not included.
Table E.19: IntervalTypeEnum

AUTOSAR CP R22-11
Primitive Limit
Note This class represents the ability to express a numerical limit. Note that this is in fact a NumericalVariation
Point but has the additional attribute intervalType.
Tags:
xml.xsd.customType=LIMIT-VALUE
xml.xsd.pattern=(0[xX][0-9a-fA-F]+)|(0[0-7]+)|(0[bB][0-1]+)|(([+\-]?[1-9]
[0-9]+(\.[0-9]+)?|[+\-]?[0-9](\.[0-9]+)?)([eE]([+\-]?)[0-9]+)?)|\.0|INF|-INF|NaN
xml.xsd.type=string
intervalType IntervalTypeEnum 0..1 attr This specifies the type of the interval. If the attribute is
missing the interval shall be considered as "CLOSED".
Table E.20: Limit
Class MlFormula
Package M2::MSR::Documentation::BlockElements::Formula
Note This meta-class represents the ability to express a formula in a documentation. The formula can be
expressed by various means. If more than one representation is available, they need to be consistent.
The rendering system can use the representation which is most appropriate.
Base ARObject, DocumentViewSelectable, Paginateable
Aggregated by DocumentationBlock.formula, EcucConditionSpecification.informalFormula, EcucDerivationSpecification.
informalFormula
formulaCaption Caption 0..1 aggr This element specifies the identification or heading of a
formula.
genericMath MultiLanguagePlainText 0..1 aggr this rpresents the semantic and mathematical
descriptions which are processed by a math-processor.
lGraphic LGraphic * aggr This represents a formula as an embedded figure.
Tags:
xml.roleWrapperElement=false
texMath MultiLanguagePlainText 0..1 aggr this is the TeX representation of TeX formula. A TeX
formula can be processed by a TeX or a LaTeX processor.
verbatim MultiLanguageVerbatim 0..1 aggr this represents a formula using only text and white-space.
It can be used to denote the formula in a kind of pseudo
code or whatever appears approprate.
Table E.21: MlFormula
Class MultilanguageReferrable (abstract)

Note Instances of this class can be referred to by their identifier (while adhering to namespace borders). They
also may have a longName. But they are not considered to contribute substantially to the overall
structure of an AUTOSAR description. In particular it does not contain other Referrables.
Base ARObject, Referrable
Subclasses Caption, DefItem, DocumentationContext, Identifiable, SdgCaption, TraceReferrable, Traceable
5

AUTOSAR CP R22-11
4
Class MultilanguageReferrable (abstract)
longName MultilanguageLong 0..1 aggr This specifies the long name of the object. Long name is
Name targeted to human readers and acts like a headline.
Table E.22: MultilanguageReferrable
Class NPdu
Note This is a Pdu of the Transport Layer. The main purpose of the TP Layer is to segment and reassemble
IPdus.
Tags:atp.recommendedPackage=Pdus
Base ARObject, CollectableElement, FibexElement, IPdu, Identifiable, MultilanguageReferrable, Packageable
Element, Pdu, Referrable
– – – – –
Table E.23: NPdu
Class NmPdu
Note Network Management Pdu
iSignalToIPdu ISignalToIPduMapping * aggr This optional aggregation is used to describe NmUser
Mapping Data that is transmitted in the NmPdu. The counting of
the startPosition starts at the beginning of the NmPdu
regardless whether Cbv or Nid are used.
nmData Boolean 0..1 attr Defines if the Pdu contains NM Data. If the NmPdu does
Information not aggregate any ISignalToIPduMappings it still may
contain UserData that is set via Nm_SetUserData(). If the
ISignalToIPduMapping exists then the nmDataInformation
attribute shall be ignored.
nmVote Boolean 0..1 attr Defines if the Pdu contains NM Vote information.
Information
unusedBit Integer 0..1 attr AUTOSAR COM is filling not used areas of an Pdu with
Pattern this bit-pattern. This attribute can only be used if the nm
DataInformation attribute is set to true.
Table E.24: NmPdu
Class <<atpMixedString>> NumericalValueVariationPoint

Package M2::AUTOSARTemplates::GenericStructure::VariantHandling::AttributeValueVariationPoints
Note This class represents an attribute value variation point for Numerical attributes.
Note that this class might be used in the extended meta-model only.
5

AUTOSAR CP R22-11
4
Class <<atpMixedString>> NumericalValueVariationPoint
Base ARObject, AbstractNumericalVariationPoint, AttributeValueVariationPoint, FormulaExpression, Sw
SystemconstDependentFormula
Aggregated by VariationPointProxy.valueAccess
– – – – –
Table E.25: NumericalValueVariationPoint
Class PackageableElement (abstract)

Note This meta-class specifies the ability to be a member of an AUTOSAR package.
Base ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Referrable
Subclasses ARElement, EnumerationMappingTable, FibexElement
– – – – –
Table E.26: PackageableElement
Class Pdu (abstract)

Note Collection of all Pdus that can be routed through a bus interface.
Element, Referrable
Subclasses GeneralPurposePdu, IPdu, NmPdu, UserDefinedPdu
hasDynamic Boolean 0..1 attr This attribute defines whether the Pdu has dynamic
Length length (true) or not (false). Please note that the usage of
this attribute is restricted by [constr_3448].
length UnlimitedInteger 0..1 attr Pdu length in bytes. In case of dynamic length IPdus
(containing a dynamical length signal), this value
indicates the maximum data length. It should be noted
that in former AUTOSAR releases (Rel 2.1, Rel 3.0, Rel
3.1, Rel 4.0 Rev. 1) this parameter was defined in bits.
The Pdu length of zero bytes is allowed.
Table E.27: Pdu
Class PduTriggering
Note The PduTriggering describes on which channel the IPdu is transmitted. The Pdu routing by the PduR is
only allowed for subclasses of IPdu.
Depending on its relation to entities such channels and clusters it can be unambiguously deduced
whether a fan-out is handled by the Pdu router or the Bus Interface.
If the fan-out is specified between different clusters it shall be handled by the Pdu Router. If the fan-out is
specified between different channels of the same cluster it shall be handled by the Bus Interface.
5

AUTOSAR CP R22-11
4
Class PduTriggering
Aggregated by PhysicalChannel.pduTriggering
iPdu Pdu 1 ref Reference to the Pdu for which the PduTriggering is
defined. One I-Pdu can be triggered on different channels
(PduR fan-out). The Pdu routing by the PduR is only
allowed for subclasses of IPdu.
Nevertheless is the reference to the Pdu element
necessary since the PduTriggering element is also used
to specify the sending and receiving connections to Ecu
Ports.
iPduPort IPduPort * ref References to the IPduPort on every ECU of the system
which sends and/or receives the I-PDU.
References for both the sender and the receiver side
shall be included when the system is completely defined.
iSignal ISignalTriggering * ref This reference provides the relationship to the ISignal
Triggering Triggerings that are implemented by the PduTriggering.
The reference is optional since no ISignalTriggering can
be defined for DCM and Multiplexed Pdus.
Tags:
atp.Splitkey=iSignalTriggering.iSignalTriggering, iSignal
Triggering.variationPoint.shortLabel
secOcCrypto SecOcCryptoService 0..1 ref This reference identifies the crypto profile applicable to
Mapping Mapping the usage (send, receive) of the also referenced Secured
IPdu.
Obviously, this reference is only applicable if the
Pdutriggering also references a SecuredIPdu in the role i
Pdu.
triggerIPduSend TriggerIPduSend * aggr Defines the trigger for the Com_TriggerIPDUSend API
Condition Condition call. Only if all defined TriggerIPduSendConditions
evaluate to true (AND associated) the Com_Trigger
IPDUSend API shall be called.
Table E.28: PduTriggering
Class PortPrototype (abstract)

Package M2::AUTOSARTemplates::SWComponentTemplate::Components
Note Base class for the ports of an AUTOSAR software component.
The aggregation of PortPrototypes is subject to variability with the purpose to support the conditional
existence of ports.
Base ARObject, AtpBlueprintable, AtpFeature, AtpPrototype, Identifiable, MultilanguageReferrable, Referrable
Subclasses AbstractProvidedPortPrototype, AbstractRequiredPortPrototype
Aggregated by AtpClassifier .atpFeature, SwComponentType.port
clientServer ClientServerAnnotation * aggr Annotation of this PortPrototype with respect to client/
Annotation server communication.
delegatedPort DelegatedPort 0..1 aggr Annotations on this delegated port.
Annotation Annotation
ioHwAbstraction IoHwAbstractionServer * aggr Annotations on this IO Hardware Abstraction port.
Server Annotation
Annotation
5

AUTOSAR CP R22-11
4
Class PortPrototype (abstract)
modePort ModePortAnnotation * aggr Annotations on this mode port.
Annotation
nvDataPort NvDataPortAnnotation * aggr Annotations on this non voilatile data port.
Annotation
parameterPort ParameterPort * aggr Annotations on this parameter port.
Annotation Annotation
senderReceiver SenderReceiver * aggr Collection of annotations of this ports sender/receiver
Annotation Annotation communication.
triggerPort TriggerPortAnnotation * aggr Annotations on this trigger port.
Annotation
Table E.29: PortPrototype
Class PostBuildVariantCriterion
Package M2::AUTOSARTemplates::GenericStructure::VariantHandling
Note This class specifies one particular PostBuildVariantSelector.
Tags:atp.recommendedPackage=PostBuildVariantCriterions
Base ARElement, ARObject, AtpDefinition, CollectableElement, Identifiable, MultilanguageReferrable,
compuMethod CompuMethod 1 ref The compuMethod specifies the possible values for the
variant criterion serving as an enumerator.
Table E.30: PostBuildVariantCriterion
Class PostBuildVariantCriterionValue
Note This class specifies the value which shall be assigned to a particular variant criterion in order to bind the
variation point. If multiple criterion/value pairs are specified, they all shall match to bind the variation
point.
Base ARObject
Aggregated by PostBuildVariantCriterionValueSet.postBuildVariantCriterionValue
annotation Annotation * aggr This provides the ability to add information why the value
is set like it is.
value Integer 1 attr This is the particular value of the post-build variant
criterion.
Tags:
variantCriterion PostBuildVariant 1 ref This association selects the variant criterion whose value
Criterion is specified.
Table E.31: PostBuildVariantCriterionValue

AUTOSAR CP R22-11
Class PredefinedVariant
Note This specifies one predefined variant. It is characterized by the union of all system constant values and
post-build variant criterion values aggregated within all referenced system constant value sets and post
build variant criterion value sets plus the value sets of the included variants.
Tags:atp.recommendedPackage=PredefinedVariants
Element, Referrable
includedVariant PredefinedVariant * ref The associated variants are considered part of this
PredefinedVariant. This means the settings of the
included variants are included in the settings of the
referencing PredefinedVariant. Nevertheless the included
variants might be included in several predefined variants.
postBuildVariant PostBuildVariant * ref This is the postBuildVariantCriterionValueSet contributing
CriterionValue CriterionValueSet to the predefinded variant.
Set
sw SwSystemconstant * ref This ist the set of Systemconstant Values contributing to
Systemconstant ValueSet the predefined variant.
ValueSet
Table E.32: PredefinedVariant
Class Referrable (abstract)

Note Instances of this class can be referred to by their identifier (while adhering to namespace borders).
Base ARObject
Subclasses AtpDefinition, BswDistinguishedPartition, BswModuleCallPoint, BswModuleClientServerEntry, Bsw
VariableAccess, CouplingPortTrafficClassAssignment, DiagnosticEnvModeElement, EthernetPriority
Regeneration, ExclusiveAreaNestingOrder, HwDescriptionEntity , ImplementationProps, LinSlaveConfig
Ident, ModeTransition, MultilanguageReferrable, PncMappingIdent, SingleLanguageReferrable, SoConI
PduIdentifier, SocketConnectionBundle, TimeSyncServerConfiguration, TpConnectionIdent
shortName Identifier 1 attr This specifies an identifying shortName for the object. It
needs to be unique within its context and is intended for
humans but even more for technical reference.
Stereotypes: atpIdentityContributor
Tags:
xml.enforceMinMultiplicity=true
shortName ShortNameFragment * aggr This specifies how the Referrable.shortName is
Fragment composed of several shortNameFragments.
Table E.33: Referrable
Class ServiceNeeds (abstract)

Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note This expresses the abstract needs that a Software Component or Basic Software Module has on the
configuration of an AUTOSAR Service to which it will be connected. "Abstract needs" means that the
model abstracts from the Configuration Parameters of the underlying Basic Software.
5

AUTOSAR CP R22-11
4
Class ServiceNeeds (abstract)
Subclasses BswMgrNeeds, ComMgrUserNeeds, CryptoKeyManagementNeeds, CryptoServiceJobNeeds, Crypto
ServiceNeeds, DiagnosticCapabilityElement, DltUserNeeds, DoIpServiceNeeds, EcuStateMgrUser
Needs, ErrorTracerNeeds, FunctionInhibitionAvailabilityNeeds, FunctionInhibitionNeeds, Global
SupervisionNeeds, HardwareTestNeeds, IdsMgrCustomTimestampNeeds, IdsMgrNeeds, IndicatorStatus
Needs, J1939DcmDm19Support, J1939RmIncomingRequestServiceNeeds, J1939RmOutgoingRequest
ServiceNeeds, NvBlockNeeds, SecureOnBoardCommunicationNeeds, SupervisedEntityCheckpoint
Needs, SupervisedEntityNeeds, SyncTimeBaseMgrUserNeeds, V2xDataManagerNeeds, V2xFacUser
Needs, V2xMUserNeeds, VendorSpecificServiceNeeds
Aggregated by BswServiceDependency.serviceNeeds, SwcServiceDependency.serviceNeeds
– – – – –
Table E.34: ServiceNeeds
Class ServiceSwComponentType
Package M2::AUTOSARTemplates::SWComponentTemplate::Components
Note ServiceSwComponentType is used for configuring services for a given ECU. Instances of this class are
only to be created in ECU Configuration phase for the specific purpose of the service configuration.
Tags:atp.recommendedPackage=SwComponentTypes
Base ARElement, ARObject, AtomicSwComponentType, AtpBlueprint, AtpBlueprintable, AtpClassifier , Atp
Type, CollectableElement, Identifiable, MultilanguageReferrable, PackageableElement, Referrable, Sw
ComponentType
– – – – –
Table E.35: ServiceSwComponentType
Class SwComponentPrototype
Note Role of a software component within a composition.
Base ARObject, AtpFeature, AtpPrototype, Identifiable, MultilanguageReferrable, Referrable
Aggregated by AtpClassifier .atpFeature, CompositionSwComponentType.component
type SwComponentType 0..1 tref Type of the instance.
Stereotypes: isOfType
Table E.36: SwComponentPrototype
Class SwConnector (abstract)

Note The base class for connectors between ports. Connectors have to be identifiable to allow references from
the system constraint template.
Base ARObject, AtpClassifier , AtpFeature, AtpStructureElement, Identifiable, MultilanguageReferrable,
Referrable
Subclasses AssemblySwConnector, DelegationSwConnector, PassThroughSwConnector
Aggregated by AtpClassifier .atpFeature, CompositionSwComponentType.connector
5

AUTOSAR CP R22-11
4
Class SwConnector (abstract)
mapping PortInterfaceMapping 0..1 ref Reference to a PortInterfaceMapping specifying the
mapping of unequal named PortInterface elements of the
two different PortInterfaces typing the two PortPrototypes
which are referenced by the ConnectorPrototype.
Table E.37: SwConnector
Class <<atpVariation>> SwDataDefProps

Package M2::MSR::DataDictionary::DataDefProperties
Note This class is a collection of properties relevant for data objects under various aspects. One could
consider this class as a "pattern of inheritance by aggregation". The properties can be applied to all
objects of all classes in which SwDataDefProps is aggregated.
Note that not all of the attributes or associated elements are useful all of the time. Hence, the process
definition (e.g. expressed with an OCL or a Document Control Instance MSR-DCI) has the task of
implementing limitations.
SwDataDefProps covers various aspects:
• Structure of the data element for calibration use cases: is it a single value, a curve, or a map, but
also the recordLayouts which specify how such elements are mapped/converted to the Data
Types in the programming language (or in AUTOSAR). This is mainly expressed by properties
like swRecordLayout and swCalprmAxisSet
• Implementation aspects, mainly expressed by swImplPolicy, swVariableAccessImplPolicy, sw
AddrMethod, swPointerTagetProps, baseType, implementationDataType and additionalNative
TypeQualifier
• Access policy for the MCD system, mainly expressed by swCalibrationAccess
• Semantics of the data element, mainly expressed by compuMethod and/or unit, dataConstr,
invalidValue
• Code generation policy provided by swRecordLayout
Base ARObject
Aggregated by AutosarDataType.swDataDefProps, CompositeNetworkRepresentation.networkRepresentation, Data
Prototype.swDataDefProps, DataPrototypeTransformationProps.networkRepresentationProps,
DiagnosticDataElement.swDataDefProps, DiagnosticEnvDataElementCondition.swDataDefProps, Dlt
Argument.networkRepresentation, FlatInstanceDescriptor.swDataDefProps, ImplementationDataType
Element.swDataDefProps, InstantiationDataDefProps.swDataDefProps, ISignal.networkRepresentation
Props, McDataInstance.resultingProperties, ParameterAccess.swDataDefProps, PerInstanceMemory.sw
DataDefProps, ReceiverComSpec.networkRepresentation, SenderComSpec.networkRepresentation,
SomeipDataPrototypeTransformationProps.networkRepresentation, SwPointerTargetProps.swDataDef
Props, SwServiceArg.swDataDefProps, SwSystemconst.swDataDefProps, SystemSignal.physicalProps
additionalNative NativeDeclarationString 0..1 attr This attribute is used to declare native qualifiers of the
TypeQualifier programming language which can neither be deduced
from the baseType (e.g. because the data object
describes a pointer) nor from other more abstract
attributes. Examples are qualifiers like "volatile", "strict" or
"enum" of the C-language. All such declarations have to
be put into one string.
5

AUTOSAR CP R22-11
4
annotation Annotation * aggr This aggregation allows to add annotations (yellow pads
...) related to the current data object.
Tags:
baseType SwBaseType 0..1 ref Base type associated with the containing data object.
compuMethod CompuMethod 0..1 ref Computation method associated with the semantics of
this data object.
dataConstr DataConstr 0..1 ref Data constraint for this data object.
displayFormat DisplayFormatString 0..1 attr This property describes how a number is to be rendered
e.g. in documents or in a measurement and calibration
system.
display DisplayPresentation 0..1 attr This attribute controls the presentation of the related data
Presentation Enum for measurement and calibration tools.
implementation AbstractImplementation 0..1 ref This association denotes the ImplementationDataType of
DataType DataType a data declaration via its aggregated SwDataDefProps. It
is used whenever a data declaration is not directly
referring to a base type. Especially
• redefinition of an ImplementationDataType via a
"typedef" to another ImplementationDatatype
• the target type of a pointer (see SwPointerTarget
Props), if it does not refer to a base type directly
• the data type of an array or record element within
an ImplementationDataType, if it does not refer to
a base type directly
• the data type of an SwServiceArg, if it does not
refer to a base type directly
invalidValue ValueSpecification 0..1 aggr Optional value to express invalidity of the actual data
element.
stepSize Float 0..1 attr This attribute can be used to define a value which is
added to or subtracted from the value of a DataPrototype
when using up/down keys while calibrating.
swAddrMethod SwAddrMethod 0..1 ref Addressing method related to this data object. Via an
association to the same SwAddrMethod it can be
specified that several DataPrototypes shall be located in
the same memory without already specifying the memory
section itself.
5

AUTOSAR CP R22-11
4
swAlignment AlignmentType 0..1 attr The attribute describes the intended typical alignment of
the DataPrototype. If the attribute is not defined the
alignment is determined by the swBaseType size and the
memoryAllocationKeywordPolicy of the referenced Sw
AddrMethod.
swBit SwBitRepresentation 0..1 aggr Description of the binary representation in case of a bit
Representation variable.
swCalibration SwCalibrationAccess 0..1 attr Specifies the read or write access by MCD tools for this
Access Enum data object.
swCalprmAxis SwCalprmAxisSet 0..1 aggr This specifies the properties of the axes in case of a
Set curve or map etc. This is mainly applicable to calibration
parameters.
swComparison SwVariableRefProxy * aggr Variables used for comparison in an MCD process.
Variable
Tags:
swData SwDataDependency 0..1 aggr Describes how the value of the data object has to be
Dependency calculated from the value of another data object (by the
MCD system).
swHostVariable SwVariableRefProxy 0..1 aggr Contains a reference to a variable which serves as a
host-variable for a bit variable. Only applicable to bit
objects.
Tags:
swImplPolicy SwImplPolicyEnum 0..1 attr Implementation policy for this data object.
swIntended Numerical 0..1 attr The purpose of this element is to describe the requested
Resolution quantization of data objects early on in the design
process.
The resolution ultimately occurs via the conversion
formula present (compuMethod), which specifies the
transition from the physical world to the standardized
world (and vice-versa) (here, "the slope per bit" is present
implicitly in the conversion formula).
In the case of a development phase without a fixed
conversion formula, a pre-specification can occur through
swIntendedResolution.
The resolution is specified in the physical domain
according to the property "unit".
swInterpolation Identifier 0..1 attr This is a keyword identifying the mathematical method to
Method be applied for interpolation. The keyword needs to be
related to the interpolation routine which needs to be
invoked.
5

AUTOSAR CP R22-11
4
swIsVirtual Boolean 0..1 attr This element distinguishes virtual objects. Virtual objects
do not appear in the memory, their derivation is much
more dependent on other objects and hence they shall
have a swDataDependency .
swPointerTarget SwPointerTargetProps 0..1 aggr Specifies that the containing data object is a pointer to
Props another data object.
swRecord SwRecordLayout 0..1 ref Record layout for this data object.
Layout
swRefresh MultidimensionalTime 0..1 aggr This element specifies the frequency in which the object
Timing involved shall be or is called or calculated. This timing
can be collected from the task in which write access
processes to the variable run. But this cannot be done by
the MCD system.
So this attribute can be used in an early phase to express
the desired refresh timing and later on to specify the real
refresh timing.
swTextProps SwTextProps 0..1 aggr the specific properties if the data object is a text object.
swValueBlock Numerical 0..1 attr This represents the size of a Value Block
Size
Tags:
swValueBlock Numerical * attr This attribute is used to specify the dimensions of a value
SizeMult block (VAL_BLK) for the case that that value block has
(ordered) more than one dimension.
The dimensions given in this attribute are ordered such
that the first entry represents the first dimension, the
second entry represents the second dimension, and so
on.
For one-dimensional value blocks the attribute swValue
BlockSize shall be used and this attribute shall not exist.
Tags:vh.latestBindingTime=preCompileTime
unit Unit 0..1 ref Physical unit associated with the semantics of this data
object. This attribute applies if no compuMethod is
specified. If both units (this as well as via compuMethod)
are specified the units shall be compatible.
valueAxisData ApplicationPrimitive 0..1 ref The referenced ApplicationPrimitiveDataType represents
Type DataType the primitive data type of the value axis within a
compound primitive (e.g. curve, map). It supersedes
CompuMethod, Unit, and BaseType.
Table E.38: SwDataDefProps

AUTOSAR CP R22-11
Class SwPointerTargetProps
Note This element defines, that the data object (which is specified by the aggregating element) contains a
reference to another data object or to a function in the CPU code. This corresponds to a pointer in the
C-language.
The attributes of this element describe the category and the detailed properties of the target which is
either a data description or a function signature.
Base ARObject
Aggregated by SwDataDefProps.swPointerTargetProps
functionPointer BswModuleEntry 0..1 ref The referenced BswModuleEntry serves as the signature
Signature of a function pointer definition. Primary use case: function
pointer passed as argument to other function.
swDataDef SwDataDefProps 0..1 aggr The properties of the target data type.
Props
Tags:
atp.Splitkey=swDataDefProps
targetCategory Identifier 0..1 attr This specifies the category of the target:
• In case of a data pointer, it shall specify the
category of the referenced data.
• In case of a function pointer, it could be used to
denote the category of the referenced Bsw
ModuleEntry.
Table E.39: SwPointerTargetProps
Class SwServiceArg
Package M2::MSR::DataDictionary::ServiceProcessTask
Note Specifies the properties of a data object exchanged during the call of an SwService, e.g. an argument or
a return value.
The SwServiceArg can also be used in the argument list of a C-macro. For this purpose the category
shall be set to "MACRO". A reference to implementationDataType can optional be added if the actual
argument has an implementationDataType.
Aggregated by BswModuleEntry.argument, BswModuleEntry.returnType
direction ArgumentDirection 0..1 attr Specifies the direction of the data transfer. The direction
Enum shall indicate the direction of the actual information that is
being consumed by the caller and/or the callee, not the
direction of formal arguments in C.
The attribute is optional for backwards compatibility
reasons. For example, if a pointer is used to pass a
memory address for the expected result, the direction
shall be "out". If a pointer is used to pass a memory
address with content to be read by the callee, its direction
shall be "in".
swArraysize ValueList 0..1 aggr This turns the argument of the service to an array.
5

AUTOSAR CP R22-11
4
Class SwServiceArg
swDataDef SwDataDefProps 0..1 aggr Data properties of this SwServiceArg.
Props
Tags:
Table E.40: SwServiceArg
Class SwSystemconst
Package M2::MSR::DataDictionary::SystemConstant
Note This element defines a system constant which serves an input to select a particular variation point. In
particular a system constant serves as an operand of the binding function (swSyscond) in a Variation
point.
Note that the binding process can only happen if a value was assigned to to the referenced system
constants.
Tags:atp.recommendedPackage=SwSystemconsts
Base ARElement, ARObject, AtpDefinition, CollectableElement, Identifiable, MultilanguageReferrable,
swDataDef SwDataDefProps 0..1 aggr This denotes the data definition properties of the system
Props constant. This supports to express the limits and
optionally a conversion within the internal to physical
values by a compu method.
Tags:
Table E.41: SwSystemconst
Class SwSystemconstantValueSet
Note This meta-class represents the ability to specify a set of system constant values.
Tags:atp.recommendedPackage=SwSystemconstantValueSets
Element, Referrable
sw SwSystemconstValue * aggr This is one particular value of a system constant.
Systemconstant
Value
Table E.42: SwSystemconstantValueSet
Class SwTextProps
Note This meta-class expresses particular properties applicable to strings in variables or calibration
parameters.
5

AUTOSAR CP R22-11
4
Class SwTextProps
Base ARObject
Aggregated by SwDataDefProps.swTextProps
arraySize ArraySizeSemantics 0..1 attr This attribute controls the semantics of the arraysize for
Semantics Enum the array representing the string in an Implementation
DataType.
It is there to support a safe conversion between
ApplicationDatatype and ImplementationDatatype, even
for variable length strings as required e.g. for Support of
SAE J1939.
baseType SwBaseType 0..1 ref This is the base type of one character in the string. In
particular this baseType denotes the intended encoding of
the characters in the string on level of ApplicationData
Type.
swFillCharacter Integer 0..1 attr Filler character for text parameter to pad up to the
maximum length swMaxTextSize.
The value will be interpreted according to the encoding
specified in the associated base type of the data object,
e.g. 0x30 (hex) represents the ASCII character zero as
filler character and 0 (dec) represents an end of string as
filler character.
The usage of the fill character depends on the arraySize
Semantics.
swMaxTextSize Integer 0..1 attr Specifies the maximum text size in characters. Note the
size in bytes depends on the encoding in the
corresponding baseType.
Tags:
Table E.43: SwTextProps
Class UnitGroup
Package M2::MSR::AsamHdo::Units
Note This meta-class represents the ability to specify a logical grouping of units.The category denotes the unit
system that the referenced units are associated to.
In this way, e.g. country-specific unit systems (CATEGORY="COUNTRY") can be defined as well as
specific unit systems for certain application domains.
In the same way a group of equivalent units, can be defined which are used in different countries, by
setting CATEGORY="EQUIV_UNITS". KmPerHour and MilesPerHour could such be combined to one
group named "vehicle_speed". The unit MeterPerSec would not belong to this group because it is
normally not used for vehicle speed. But all of the mentioned units could be combined to one group
named "speed".
Note that the UnitGroup does not ensure the physical compliance of the units. This is maintained by the
physical dimension.
Tags:atp.recommendedPackage=UnitGroups
Element, Referrable
5

AUTOSAR CP R22-11
4
Class UnitGroup
unit Unit * ref This represents one particular unit in the UnitGroup.
Table E.44: UnitGroup
Class UserDefinedPdu
Note UserDefinedPdu allows to describe PDU-based communication over Complex Drivers. If a new BSW
module is added above the BusIf (e.g. a new Nm module) then this Pdu element shall be used to
describe the communication.
cddType String 0..1 attr This attribute defines the CDD that transmits or receives
the UserDefinedIPdu. If several CDDs are defined this
attribute is used to distinguish between them.
Table E.45: UserDefinedPdu
Class <<atpMixed>> ValueList

Note This is a generic list of numerical values.
Base ARObject
Aggregated by RuleBasedAxisCont.swArraysize, RuleBasedValueCont.swArraysize, SwAxisCont.swArraysize, Sw
ServiceArg.swArraysize, SwValueCont.swArraysize
v Numerical 0..1 attr This is a particular numerical value without variation.
vf (ordered) Numerical * attr This is one entry in the list of numerical values
Tags:
xml.roleWrapperElement=false
Table E.46: ValueList
Class VariationPoint
Note This meta-class represents the ability to express a "structural variation point". The container of the
variation point is part of the selected variant if swSyscond evaluates to true and each postBuildVariant
Criterion is fulfilled.
Base ARObject
5

AUTOSAR CP R22-11
4
Class VariationPoint
blueprint DocumentationBlock 0..1 aggr This represents a description that documents how the
Condition variation point shall be resolved when deriving objects
from the blueprint.
Note that variationPoints are not allowed within a
blueprintCondition.
desc MultiLanguageOverview 0..1 aggr This allows to describe shortly the purpose of the
Paragraph variation point.
formalBlueprint BlueprintGenerator 0..1 aggr This represents a description that documents how the
Generator variation point shall be resolved when deriving objects
from the blueprint by using ARMQL.
Note that variationPoints are not allowed within a formal
BlueprintGenerator.
Tags:
atp.Status=draft
postBuildVariant PostBuildVariant * aggr This is the set of post build variant conditions which all
Condition Condition shall be fulfilled in order to (postbuild) bind the variation
point.
sdg Sdg 0..1 aggr An optional special data group is attached to every
variation point. These data can be used by external
software systems to attach application specific data. For
example, a variant management system might add an
identifier, an URL or a specific classifier.
shortLabel Identifier 0..1 attr This provides a name to the particular variation point to
support the RTE generator. It is necessary for supporting
splitable aggregations and if binding time is later than
codeGenerationTime, as well as some RTE conditions. It
needs to be unique with in the enclosing Identifiables with
the same ShortName.
Stereotypes: atpIdentityContributor
swSyscond ConditionByFormula 0..1 aggr This condition acts as Binding Function for the Variation
Point. Note that the multiplicity is 0..1 in order to support
pure postBuild variants.
Table E.47: VariationPoint
Primitive VerbatimString
Note This primitive represents a string in which white-space needs to be preserved.
Tags:
xml.xsd.customType=VERBATIM-STRING
xml.xsd.type=string
xml.xsd.whiteSpace=preserve
5

AUTOSAR CP R22-11
4
Primitive VerbatimString
blueprintValue String 0..1 attr This represents a description that documents how the
blueprint.
Tags:
atp.Status=draft
xml.attribute=true
xmlSpace XmlSpaceEnum 0..1 attr This attribute is used to signal an intention that in that
element, white space should be preserved by
applications. It is defined according to xml:space as
declared by W3C.
Tags:
xml.attribute=true
xml.attributeRef=true
xml.name=space
xml.nsPrefix=xml
Table E.48: VerbatimString

AUTOSAR CP R22-11
F Splitable Elements in the Scope of this Document

This chapter contains a table of all model elements stereotyped atpSplitable
in the scope of this document.
Each entry in the table consists of the identification of the specific model element itself
and the applicable value of the tagged value atp.Splitkey.
For more information about the concept of splitable model elements and how these
shall be treated please refer to [6].
Name of splitable element Splitkey
ARPackage.arPackage arPackage.shortName, arPackage.variation
Point.shortLabel
ARPackage.element element.shortName, element.variationPoint.short
Label
ARPackage.referenceBase referenceBase.shortLabel
Describable.adminData adminData
EcucChoiceContainerDef.choice choice.shortName
EcucContainerValue.parameterValue parameterValue, parameterValue.variation
Point.shortLabel
EcucContainerValue.referenceValue referenceValue, referenceValue.variationPoint.short
Label
EcucContainerValue.subContainer subContainer.shortName, subContainer.variation
Point.shortLabel
EcucEnumerationParamDef.literal literal.shortName
EcucModuleConfigurationValues.container container.shortName, container.variationPoint.short
Label
EcucModuleDef.container container.shortName
EcucParamConfContainerDef.parameter parameter.shortName
EcucParamConfContainerDef.reference reference.shortName
EcucParamConfContainerDef.subContainer subContainer.shortName
EcucValueCollection.ecucValue ecucValue.ecucModuleConfigurationValues, ecuc
Value.variationPoint.shortLabel
Identifiable.adminData adminData
SwPointerTargetProps.swDataDefProps swDataDefProps
SwServiceArg.swDataDefProps swDataDefProps
SwSystemconst.swDataDefProps swDataDefProps
Table F.1: Usage of splitable elements

AUTOSAR CP R22-11
G Variation Points in the Scope of this Document

This chapter contains a table of all model elements stereotyped atpVariation
in the scope of this document.
Each entry in the table consists of the identification of the model element itself and the
applicable value of the tagged value vh.latestBindingTime.
For more information about the concept of variation points and how model elements
that contain variation points shall be treated please refer to [6].
Variation Point Latest Binding Time
ARPackage.arPackage blueprintDerivationTime
ARPackage.element systemDesignTime
EcucAbstractStringParamDef codeGenerationTime
EcucBooleanParamDef.defaultValue codeGenerationTime
EcucContainerValue.parameterValue postBuild
EcucContainerValue.referenceValue postBuild
EcucContainerValue.subContainer postBuild
EcucDefinitionElement.lowerMultiplicity codeGenerationTime
EcucDefinitionElement.upperMultiplicity codeGenerationTime
EcucDefinitionElement.upperMultiplicityInfinite codeGenerationTime
EcucFloatParamDef.defaultValue codeGenerationTime
EcucFloatParamDef.max codeGenerationTime
EcucFloatParamDef.min codeGenerationTime
EcucFunctionNameDef codeGenerationTime
EcucIntegerParamDef.defaultValue codeGenerationTime
EcucIntegerParamDef.max codeGenerationTime
EcucIntegerParamDef.min codeGenerationTime
EcucLinkerSymbolDef codeGenerationTime
EcucModuleConfigurationValues.container postBuild
EcucMultilineStringParamDef codeGenerationTime
EcucNumericalParamValue.value preCompileTime
EcucStringParamDef codeGenerationTime
EcucValueCollection.ecucValue preCompileTime
SwDataDefProps codeGenerationTime
SwDataDefProps.swValueBlockSize preCompileTime
SwDataDefProps.swValueBlockSizeMult preCompileTime
SwTextProps.swMaxTextSize preCompileTime
ValueList.vf preCompileTime
Table G.1: Usage of variation points

AUTOSAR TPS ECUConfiguration

Uploaded by

Copyright:

Available Formats

AUTOSAR TPS ECUConfiguration

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

AUTOSAR TPS ECUConfiguration

Uploaded by

Copyright:

Available Formats

Specification of ECU Configuration

Document Status published

Document Change History

1 of 311 Document ID 87: AUTOSAR_TPS_ECUConfiguration

• Updated specification to avoid usage

2 of 311 Document ID 87: AUTOSAR_TPS_ECUConfiguration

• Support unidirectional CDD

3 of 311 Document ID 87: AUTOSAR_TPS_ECUConfiguration

• Extended the Ecu Query Language

4 of 311 Document ID 87: AUTOSAR_TPS_ECUConfiguration

• Updated "refvalue" function

5 of 311 Document ID 87: AUTOSAR_TPS_ECUConfiguration

AUTOSAR • Fixed foreign reference to

6 of 311 Document ID 87: AUTOSAR_TPS_ECUConfiguration

7 of 311 Document ID 87: AUTOSAR_TPS_ECUConfiguration

8 of 311 Document ID 87: AUTOSAR_TPS_ECUConfiguration

9 of 311 Document ID 87: AUTOSAR_TPS_ECUConfiguration

2.3.10 Multiple aggregation of full container trees that include refer-

10 of 311 Document ID 87: AUTOSAR_TPS_ECUConfiguration

3.5 CDD module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198

D Change History 254

11 of 311 Document ID 87: AUTOSAR_TPS_ECUConfiguration

D.4.1 Deleted SWS Items . . . . . . . . . . . . . . . . . . . . . . . 259

12 of 311 Document ID 87: AUTOSAR_TPS_ECUConfiguration

D.11.5 Changed Constraints in 4.4.0 . . . . . . . . . . . . . . . . . . 271

F Splitable Elements in the Scope of this Document 310

G Variation Points in the Scope of this Document 311

13 of 311 Document ID 87: AUTOSAR_TPS_ECUConfiguration

14 of 311 Document ID 87: AUTOSAR_TPS_ECUConfiguration

15 of 311 Document ID 87: AUTOSAR_TPS_ECUConfiguration

       

«input» VFB AUTOSAR

Develop System «input»

0..* Transformer Design

Develop Basic Software Develop Application

ECU Software Delivered

Figure 1.1: AUTOSAR Methodology Overview (from [1])

16 of 311 Document ID 87: AUTOSAR_TPS_ECUConfiguration

Generate BSW and

Configure BSW and RTE

Figure 1.2: Ecu Configuration Overview (from [1])

17 of 311 Document ID 87: AUTOSAR_TPS_ECUConfiguration

Table 1.1: Abbreviations used in the scope of this Document

18 of 311 Document ID 87: AUTOSAR_TPS_ECUConfiguration

1.2 Document Conventions

19 of 311 Document ID 87: AUTOSAR_TPS_ECUConfiguration

The headers in the table have the following meaning:

1.3 Binding Times of Constraints

20 of 311 Document ID 87: AUTOSAR_TPS_ECUConfiguration

1.4 Requirements Tracing

21 of 311 Document ID 87: AUTOSAR_TPS_ECUConfiguration

Table 1.2: RequirementsTracing

22 of 311 Document ID 87: AUTOSAR_TPS_ECUConfiguration

2.2 ECU Configuration Template Structure

23 of 311 Document ID 87: AUTOSAR_TPS_ECUConfiguration

Specification of ECU Configuration

Figure 2.1: Parameter Definition and ECU Configuration Value files

24 of 311 Document ID 87: AUTOSAR_TPS_ECUConfiguration

25 of 311 Document ID 87: AUTOSAR_TPS_ECUConfiguration