Autosar Tps Ecuresourcetemplate

Specification of ECU Resource Template

AUTOSAR CP R20-11

Document Title Specification of ECU Resource

Template
Document Owner AUTOSAR
Document Responsibility AUTOSAR
Document Identification No 60
Document Status published

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

Date Release Changed by Description
AUTOSAR
2020-11-30 R20-11 Release • No content changes
Management
AUTOSAR • Editorial changes
2019-11-28 R19-11 Release • Changed Document Status from
Management Final to published
AUTOSAR
2018-10-31 4.4.0 Release • Editorial changes
Management
AUTOSAR
2017-12-08 4.3.1 Release • Layout update.
Management
AUTOSAR
Management
AUTOSAR
Management
AUTOSAR
Management
AUTOSAR
Management
AUTOSAR • Added specification item numbers for
2013-03-15 4.1.1
Administration tracing.
1 of 58 Document ID 60: AUTOSAR_TPS_ECUResourceTemplate

AUTOSAR CP R20-11
AUTOSAR • Added detailed change history

2011-12-22 4.0.3 (appendix C)
Administration
• Added [constr_3500]
AUTOSAR • Added Glossary appendix.

2010-09-30 3.1.5 • Updated category definitions to
Administration
upper case.
AUTOSAR
2010-02-02 3.1.4 • Reworked for Release 4.0.
Administration
AUTOSAR
2008-02-01 3.0.2 • Correction of References
Administration
AUTOSAR • Document meta information

2007-12-21 3.0.1 extended
Administration
• Small layout adaptations made
• Legal disclaimer revised
AUTOSAR • Release Notes added
2007-01-24 2.1.15
Administration • "‘Advice for users"’ revised
• "‘Revision Information"’ added
AUTOSAR
2005-05-31 1.0 Initial release
Administration

AUTOSAR CP R20-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 R20-11
Table of Contents
1 Introduction 7
1.1 Scope of the ECU Resource Template . . . . . . . . . . . . . . . . . . 7
1.2 Overview ECU Resource Template . . . . . . . . . . . . . . . . . . . . 8
1.3 Requirements Traceability . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4 Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.5 Requirements Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2 General Hardware Description 16
2.1 Hardware Description Entity . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Hardware Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3 Hardware Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.1 Multiple occurrence of Hardware Elements . . . . . . . . . . 21
2.4 Hardware Pin and Pin Group . . . . . . . . . . . . . . . . . . . . . . . 22
2.5 Hardware Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5.1 Scope of Connections . . . . . . . . . . . . . . . . . . . . . . 25
2.6 Hardware Category Definition . . . . . . . . . . . . . . . . . . . . . . . 26
2.6.1 Vendor specific extensions of Hardware Category Definition . 29
2.7 Ecu Resource Variant Handling . . . . . . . . . . . . . . . . . . . . . . 30
2.8 Documentation Support . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.9 Infrastructural aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3 Hardware Type Specific Description 32
3.1 HwElement categories . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1.1 Ecu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1.2 Processing Unit . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.1.3 Micro-Controller . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1.4 Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.1.5 Communication Controller . . . . . . . . . . . . . . . . . . . 33
3.1.6 Communication Transceiver . . . . . . . . . . . . . . . . . . . 34
3.1.7 Digital IO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1.8 Analog IO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1.9 Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1.10 Watchdog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1.11 SensorActuator . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2 HwPinGroup categories . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.1 CommunicationPort . . . . . . . . . . . . . . . . . . . . . . . 35
3.3 HwPin categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
A Examples 37
A.1 Hardware Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
A.2 Hierarchy of Hardware Elements . . . . . . . . . . . . . . . . . . . . . 37
A.3 HwPinGroups and HwPins . . . . . . . . . . . . . . . . . . . . . . . . . 38
A.4 Hardware Element Connection . . . . . . . . . . . . . . . . . . . . . . 39
A.5 Combined Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

AUTOSAR CP R20-11
A.5.1 Micro-controller description . . . . . . . . . . . . . . . . . . . 41

A.5.2 Transceiver description . . . . . . . . . . . . . . . . . . . . . 42
A.5.3 Ecu description . . . . . . . . . . . . . . . . . . . . . . . . . . 43
A.6 Attribute Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
A.7 Attribute Value Example . . . . . . . . . . . . . . . . . . . . . . . . . . 46
B Glossary 47
C History of Constraints and Specification Items 51

C.1 Constraint and Specification Item History of this document according
to AUTOSAR Release R4.0.2 . . . . . . . . . . . . . . . . . . . . . . . 51
C.2.1 Added Constraints in R4.0.3 . . . . . . . . . . . . . . . . . . 51
C.3.1 Added Constraints in R4.1.1 . . . . . . . . . . . . . . . . . . 51
C.3.2 Added Traceables in R4.1.1 . . . . . . . . . . . . . . . . . . . 51
to AUTOSAR Release R19-11 . . . . . . . . . . . . . . . . . . . . . . . 53
to AUTOSAR Release R20-11 . . . . . . . . . . . . . . . . . . . . . . . 53
D Mentioned Class Tables 54

AUTOSAR CP R20-11
References
[1] Requirements on ECU Resource Template
AUTOSAR_RS_ECUResourceTemplate
[2] Meta Model
AUTOSAR_MMOD_MetaModel
[3] Software Component Template
AUTOSAR_TPS_SoftwareComponentTemplate
[4] XML Schema Production Rules
AUTOSAR_TPS_XMLSchemaProductionRules
[5] Standardization Template
AUTOSAR_TPS_StandardizationTemplate
[6] Generic Structure Template
AUTOSAR_TPS_GenericStructureTemplate
[7] IEEE standard for radix-independent floating-point arithmetic
(ANSI/IEEE Std 854-1987)
[8] Software Process Engineering Meta-Model Specification
http://www.omg.org/spec/SPEM/2.0/

AUTOSAR CP R20-11
1 Introduction
One of the most prominent goals of AUTOSAR is the standardization of descriptions
relevant for automotive software applications. In this context, the description of under-
lying ECU hardware is one of the major topics to resolve.
This document contains a specification of the modeling elements required to describe
the hardware to the necessary extent. One aspect of the ECU Resource Template is to
provide the system design engineer with the necessary information to assist the sys-
tem partitioning, e.g. available memory and communication means of dedicated ECUs.
Another aspect of the ECU Resource Template is to support the ECU Configuration en-
gineers and tools with information required for the configuration of the micro-controller
and ECU abstraction layer residing on a particular ECU.
The focus of the ECU Resource Template is to describe an already engineered piece of
hardware, its content and structure. It is not in the focus of the ECU Resource Template
to support the design of electronics hardware itself. There are established tools and
exchange formats to aid in the design of electronics hardware already available. But
such tools may be able to export their design using the AUTOSAR ECU Resource
Template format for later usage in AUTOSAR design tools.
Where applicable, please consult the glossary and the abbreviation list contained in
this document. The general characteristics of the ECU Resource Description are intro-
duced followed by a detailed description of the hardware components inside the ECU.
1.1 Scope of the ECU Resource Template

The scope of the ECU Resource Template is the description of ECUs by means of the
following basic building blocks:
• Hardware Elements
• Hardware PinGroups and Hardware Pins
• Hardware Connections
The HW Elements are the main describing elements of an ECU, For example: Process-
ing units, memory, peripherals and sensors/actuators. HW Elements have a unique
name and can be identified within an ECU description. HW Elements do not nec-
essarily have to be described on the level of an ECU. It is possible to describe HW
Elements as parts of other HW Elements. By this means a hierarchical description of
HW Elements can be created.
HW Elements provide HW PinGroups and HW Pins for being interconnected among
each others. HW PinGroups allow a rough description of how certain groups of HW
Pins are arranged. The detailed description can be done using the HW Pins.

AUTOSAR CP R20-11
HW Connections are used to describe connections on several levels:

• connections between HW Elements
• connections between HW PinGroups
• connections between HW Pins
The different levels of abstraction allow to define and gather the required information for
the different use-cases of the ECU Resource Template. For a rough understanding how
the HW Elements are arranged in the ECU the connections between HW Elements are
sufficient. To actually know at which HW Pin a certain signal is provided the detailed
HW Pin connections are required.
1.2 Overview ECU Resource Template

Figure 1.1 depicts the main elements of an ECU Resource description and their inter-
relations.
Figure 1.1: Overview of ECU Resource template
Modeling elements in the ECU Resource Template can be hierarchically organized.

A particular ECU (the physical box containing the electronics) can be described as a
hierarchical composition of one or more micro-controllers and ECU electronics. Each
micro-controller is in turn composed of processing units, memory, peripherals and man-
agement units.
The same approach can be used to describe a particular ECU in combination with all
sensors and actuators attached to the ECU.
The ECU Electronics is the hardware present on the ECU to guarantee the operation
of the Processing Units (clock) as well as the conditioning of signals going out of the
ECU or coming in (communication transceiver, amplifier, discrete electronics).

AUTOSAR CP R20-11
1.3 Requirements Traceability

Tracing of the Requirements on ECU Resource Template [1].
Requirement Description Satisfied by
[RS_ECUR_00005] Support The ECU Resource template The relationships between
configuration of Basic shall provide means to upstream templates and ECU
Software describe hardware properties Configuration are described in
which are supporting the the AUTOSAR Metamodel [2].
configuration of the AUTOSAR The configuration parameters
Basic Software. in the M1 model contain a
number of tagged values with
the mapping information.
[RS_ECUR_00003] Describe The ECU Resource template The requirement is fulfilled by
characteristic properties of shall provide means to the defined categories and
specific hardware elements describe the common and their attributes in chapter 3.
characteristic properties of
hardware elements based on
their kind.
[RS_ECUR_00004] Describe The ECU Resource template A HW vendor can extend the
generic hardware shall provide means to categories of AUTOSAR. New
describe hardware elements of categories can be defined.
any kind. Attributes can be added to
existing categories and new
literals to existing
enumerations.
[RS_ECUR_00006] Describe The ECU Resource template Hardware Connections can be
connections between shall provide means to described on several levels in
hardware elements describe in an abstracted way the ECU Resource Template.
how the individual hardware These levels are described in
elements - in an ECU and on chapter 2.5.
the outside of the ECU - are
connected.
[RS_ECUR_00014] Timing The ECU Resource template A HW vendor can extend the
properties of hardware shall provide means to categories of AUTOSAR. New
describe the timing properties categories can be defined.
for hardware I/O, e.g. the New timing attributes can be
latency introduced by a digital added to existing categories
I/O hardware port. and new literals to existing
enumerations.
[RS_ECUR_00015] Describe It shall be possible to describe The requirement is fulfilled by
variability of the hardware the variability the actual the AUTOSAR Variant
hardware provides. Handling concept (chapter 2.7).
[RS_ECUR_00017] The ECU Resource template The requirement is fulfilled by
Documentation Support shall provide means to add the AUTOSAR Documentation
documentation to the hardware Support concept (chapter 2.8).
elements.

AUTOSAR CP R20-11

[RS_ECUR_00018] Support The ECU Resource template The containment hierarchy of
hardware descriptions from shall provide means to hardware elements is not
several sources combine the hardware represented as a hierarchical
descriptions from several structure in the XML
sources. description but as linked list.
This modeling allows the usage
of different ARXML files for the
description of the container and
the nested hardware elements
(chapter 2.3).
Processing Unit specification shall provide dedicated means the Processing Unit Category
to describe a processing unit. (chapter 3.1.2).
A processing unit shall be
defined as the core of the micro
controller / processor.
[RS_ECUR_00008] Available The ECU Resource template The requirement is fulfilled by
memory shall provide dedicated means the Memory Category
to describe memory segments. (chapter 3.1.4).
This includes all possible
memory kinds like RAM, ROM,
EEPROM, Flash, etc.
communication means shall provide dedicated means the Hw Pin Group Categories.
to describe communication (chapter 3.2).
hardware.
IO HW-Peripherals shall provide dedicated means the Digital IO (chapter 3.1.7)
to describe IO-HW-Peripherals. and Analog IO (chapter 3.1.8)
categories.
IO-HW-Abstraction shall provide the abstract the ECU Abstraction Software
specification connection information Component that is defined in
between the hardware sensor / the Software Component
actuator and the IO-HW Template [3]. The ECU
peripheral using the Abstraction is a special
IO-HW-Abstraction layer. AtomicSwComponentType that
resides between a
software-component that wants
to access ECU periphery and
the Microcontroller Abstraction.
sensors and actuators shall provide dedicated means the SensorActuator Category
to describe sensors and (chapter 3.1.11).
actuators.
[RS_ECUR_00012] The UML representation of the The requirement is fulfilled by
Development according to the ECU Resource template the AUTOSAR development
AUTOSAR Generic Structure SHALL be developed process.
Template document according to the AUTOSAR
Generic Structure Template.

AUTOSAR CP R20-11

[RS_ECUR_00013] The XML representation for the The requirement is fulfilled by
Transformation of ECU ECU Resource template shall the AUTOSAR XML Schema
Resource template modeling be derived from its UML generation process. The
according to the AUTOSAR representation according to the document called XML Schema
XML Schema Production AUTOSAR XML Schema Production Rules [4] for XML
Rules Production Rules. describes how XML is used
and how the meta-model
designed in the "Ecu Resource
Template" should be translated
by the "Schema Generator"
(MDS) into XML-Schema
(XSD) "Data Exchange
Format".

AUTOSAR CP R20-11
1.4 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.
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
Attribute Type Mult. Kind Note
adminData AdminData 0..1 aggr This represents the administrative data of an Autosar file.
Tags:xml.sequenceOffset=10
5

AUTOSAR CP R20-11
4
Class AUTOSAR
arPackage ARPackage * aggr This is the top level package in an AUTOSAR model.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=arPackage.shortName, arPackage.variation
Point.shortLabel
vh.latestBindingTime=blueprintDerivationTime
xml.sequenceOffset=30
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 rpresent disclaimers and legal
notes.
Table 1.1: AUTOSAR
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.
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-

AUTOSAR CP R20-11
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 ([5]).
The representation of requirements in AUTOSAR documents follows the table specified
in [TPS_STDT_00078], see Standardization Template, chapter Support for Traceability
([5]).

AUTOSAR CP R20-11
1.5 Requirements Tracing

The following tables reference the requirements specified in [1] and links to the fulfill-
ment of these. Please note that if column “Satisfied by” is empty for a specific require-
ment this means that this requirement is not fulfilled by this document.
[RS_ECUR_00003] Describe characteristic [TPS_ECUR_01003]
properties of specific hardware [TPS_ECUR_01014]
elements
[RS_ECUR_00004] Describe generic hardware [TPS_ECUR_01000]
[TPS_ECUR_01001]
[TPS_ECUR_01002]
[TPS_ECUR_01003]
[TPS_ECUR_01005]
[RS_ECUR_00005] Support configuration of Basic [TPS_ECUR_01015]
Software
[RS_ECUR_00006] Describe connections between [TPS_ECUR_01006]
hardware elements
[RS_ECUR_00007] Processing Unit specification [TPS_ECUR_01007]
[TPS_ECUR_01034]
[TPS_ECUR_01035]
[TPS_ECUR_01036]
[TPS_ECUR_01037]
[TPS_ECUR_01038]
[RS_ECUR_00008] Available memory [TPS_ECUR_01008]
[RS_ECUR_00009] Available communication means [TPS_ECUR_01009]
[TPS_ECUR_01010]
[TPS_ECUR_01013]
[RS_ECUR_00010] Available IO HW-Peripherals [TPS_ECUR_01011]
[RS_ECUR_00011] Available sensors and actuators [TPS_ECUR_01012]
[RS_ECUR_00012] Development according to the [TPS_ECUR_01032]
AUTOSAR Generic Structure
Template document
[RS_ECUR_00013] Transformation of ECU [TPS_ECUR_01033]
Resource template modeling
according to the AUTOSAR XML
Schema Production Rules
[RS_ECUR_00014] Timing properties of hardware [TPS_ECUR_01031]
[RS_ECUR_00015] Describe variability of the [TPS_ECUR_01003]
hardware [TPS_ECUR_01014]
[TPS_ECUR_01029]
[RS_ECUR_00016] IO-HW-Abstraction specification [TPS_ECUR_01006]
[RS_ECUR_00017] Documentation Support [TPS_ECUR_01030]
[RS_ECUR_00018] Support hardware descriptions [TPS_ECUR_01018]
from several sources

AUTOSAR CP R20-11
2 General Hardware Description

The ECU Resource Template utilizes the basic building blocks
• hardware elements
• hierarchies of hardware elements
• hardware pins
• hardware pin groups
• hardware connections
to describe the relevant aspects of the actual hardware. The ECU Resource Template
allows however to choose the appropriate level of detail in the description of the hard-
ware, depending on the use case. It also allows to describe arbitrary hardware and its
connections.
[TPS_ECUR_01015] Support of AUTOSAR Basic Software configuration dThe
primary goal of the ECU Resource Template is to support the configuration of the
AUTOSAR Basic Software by providing information on the respective hardware and
the how the hardware is connected to each other.c(RS_ECUR_00005)
In figure 2.1 the overview of the involved classes is shown.

AUTOSAR CP R20-11
ARElement Referrable
HwAttributeValue
HwType HwDescriptionEntity +hwAttributeValue
+hwType + vt: VerbatimString [0..1]
«atpVariation» 0..*
«atpVariation»
0..1 + v: Numerical [0..1]
+hwElement ARElement +hwPinGroup

Identifiable
HwElement
2 «atpVariation» 0..* HwPinGroup
+hwPinGroup +hwPinGroup
+nestedElement 2 1
0..*
«atpVariation» +hwPinGroupContent 1
«atpMixed»
«atpVariation»
HwPinGroupContent

«atpVariation»
«atpVariation»

+hwPin 1

Identifiable

HwPin
+ pinNumber: Integer [0..1]
+hwPin 2
+hwElementConnection
0..*
Describable Describable Describable

HwElementConnector +hwPinGroupConnection HwPinGroupConnector +hwPinConnection HwPinConnector
«atpVariation» 0..* «atpVariation» 0..*
+hwPinConnection
«atpVariation» 0..*

Figure 2.1: Overview of ECU Resource template classes
2.1 Hardware Description Entity

In order to allow flexibility of the ECU Resource Template with respect to the descrip-
tion of a multitude of hardware types the ECU Resource Template only provides the
generic means to describe hardware elements and their connectivity. The description
of specific attributes can be provided according to section 2.6.
[TPS_ECUR_01002] Definition of Hardware Elements dThe HwDescriptionEn-
tity allows to provide a set of attribute values which are defined by one or more
hardware categories.c(RS_ECUR_00004)

AUTOSAR CP R20-11
Please refer to chapter 3 for details on the actual applicable hardware categories and
corresponding attributes.
The HwDescriptionEntity is able to specify for which hardware categories (see
section 2.6) this HwDescriptionEntity is applicable. It is possible to define several
references in the role hwCategory.
• [TPS_ECUR_01000] Definition of HwCategory dIt shall be possible to refer-
ence different kinds of HwCategory elements in order to describe different as-
pects of the hardware (e.g. a Can controller with an integrated Spi channel).c
(RS_ECUR_00004)
• [TPS_ECUR_01001] Extension of HwCategory dIt shall be possible to extend
the standardized HwCategory specification with additional attributes.c(RS_-
ECUR_00004)
For more details see section Vendor specific extensions of Hardware Category
Definition.
For a description of the hwType reference please refer to section 2.2.
Each HwDescriptionEntity may aggregate several HwAttributeValue ele-
ments.
Class HwDescriptionEntity (abstract)
Package M2::AUTOSARTemplates::EcuResourceTemplate
Note This meta-class represents the ability to describe a hardware entity.
Base ARObject, Referrable
Subclasses HwElement, HwPin, HwPinGroup, HwType
hwAttribute HwAttributeValue * aggr This aggregation represents a particular hardware
Value attribute value.
Stereotypes: atpVariation
Tags:
vh.latestBindingTime=systemDesignTime
hwCategory HwCategory * ref One of the associations representing one particular
category of the hardware entity.
hwType HwType 0..1 ref This association is used to assign an optional HwType
which contains the common attribute values for all
occurences of this HwDescriptionEntity. Note that Hw
Types can not be redefined and therefore shall not have a
hwType reference.
Table 2.1: HwDescriptionEntity
[TPS_ECUR_01014] Definition of HwAttributeValue dThe HwAttributeValue

is used to specify one value for a predefined attribute. The link of the attribute is defined
with the reference to HwAttributeDef in the role hwAttributeDef which is subject
to variant handling.c(RS_ECUR_00003, RS_ECUR_00015)
The definition of attributes is described in section 2.6.

AUTOSAR CP R20-11
[TPS_ECUR_01003] Values of hardware attributes dThe actual value of a HwAt-

tributeValue can be provided in one of two ways:
• vt - the value is specified in a textual representation.
• v - the value is specified in a numerical representation. The actual value can be
subject to variant handling.
c(RS_ECUR_00003, RS_ECUR_00004, RS_ECUR_00015)
For more details see section Ecu Resource Variant Handling.
Class HwAttributeValue
Package M2::AUTOSARTemplates::EcuResourceTemplate::HwElementCategory
Note This metaclass represents the ability to assign a hardware attribute value. Note that v and vt are mutually
exclusive.
Base ARObject
annotation Annotation 0..1 aggr Optional annotation that can be added to each Hw
AttributeValue.
hwAttributeDef HwAttributeDef 1 ref This association represents the definition of the particular
hardware attribute value.
v Numerical 0..1 attr This represents a numerical hardware attribute value.
Tags:vh.latestBindingTime=systemDesignTime
vt VerbatimString 0..1 attr This represents a textual hardware attribute value.
Table 2.2: HwAttributeValue
2.2 Hardware Type

[TPS_ECUR_01016] Definition of HwType dThe HwType is used to gather attribute
values for elements which can occur several times in an Ecu and will not change due
to their multiple usage.c()
For details on the multiple occurrence of hardware elements please refer to section
2.3.1.
A HwType is an ARElement which inherits from HwDescriptionEntity. The fea-
tures of ARElement allow the hardware type to have a name and stand for its own
inside some package. The features of HwDescriptionEntity allow the hardware
type to describe hardware categories and attribute values (see section 2.1).
[TPS_ECUR_01017] Attribute values defined in the HwType are applicable for all
occurrences of this HwType dThe attribute values defined in the HwType are appli-
cable for all occurrences of this HwType, although it is possible to override the value in
the HwElement.c()
For more details see section Hardware Element.

AUTOSAR CP R20-11
[constr_3511] HwType shall not have a reference to another HwType dA HwType

(being a HwDescriptionEntity) shall not have a reference to another HwType in
the role hwType. The definition of HwTypes is not hierarchical.c()
The HwType does not specify any structural features of the hardware. The description
of hardware pin groups, hardware pins and hardware connections is only possible at
the hardware element level.
Class HwType
Note This represents the ability to describe Hardware types on an abstract 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=HwTypes
Base ARElement, ARObject, CollectableElement, HwDescriptionEntity , Identifiable, MultilanguageReferrable,
PackageableElement, Referrable
– – – – –
Table 2.3: HwType
2.3 Hardware Element

[TPS_ECUR_01005] The HwElement describes one piece of hardware dThe
HwElement describes how one piece of hardware - as a building block - is contribut-
ing to the overall circuit describing the ECU. It can be used to describe any hardware,
independent of their granularity and scale. So an ECU can be described as a whole,
the connected sensors and actuators, the built-in micro-controller and communication
transceiver. But also the processing cores and the memory segments inside the micro-
controller can be described.c(RS_ECUR_00004)
[TPS_ECUR_01018] HwElement is self contained dEach HwElement can be de-
scribed in a self contained way because the HwElement is an ARElement.c(RS_-
ECUR_00018)
Each HwElement inherits from HwDescriptionEntity and is therefore capable to
describe a set of attributes (see section 2.1 for details).
[TPS_ECUR_01019] HwElement can refer to a HwType dEach HwElement can op-
tionally refer to a HwType element in the role hwType. In the HwType the attribute
values, which are common for all occurrences of the hardware type, are described. In
case the HwElement provides an attribute value which is also provided in the refer-
enced HwType the attribute value from the HwElement takes precedence.c()
The features of the nestedElement reference are specified in section 2.3.1.
The HwElement can describe several HwPinGroup elements which are contained in
the role hwPinGroup (for details on the HwPinGroup refer to section 2.4).

AUTOSAR CP R20-11
The hardware element can describe several HwElementConnector elements which

are contained in the role hwElementConnection (for details on the HwElement-
Connector refer to section 2.5).
Class HwElement
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,
hwElement HwElementConnector * aggr This represents one particular connection between two
Connection hardware elements.
Tags:
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:
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:
Table 2.4: HwElement
2.3.1 Multiple occurrence of Hardware Elements
[TPS_ECUR_01020] Hierarchy of hardware dThe hierarchy of hardware is described

via referencing the contained hardware elements with the role nestedElement. The
containment hierarchy of hardware elements is not represented as a hierarchical struc-
ture in the XML description but as linked list.c()
This modeling allows the usage of different ARXML files for the description of the con-
tainer hardware element and the nested hardware elements. E.g. the CPU is described
by a Semiconductor-Vendor, the project specific usage of such a CPU is described by
the ECU vendor.
[constr_3512] No support of multiple instantiation dAn essential constraint is that
each HwElement can only be target of one nestedElement reference. This means
that there is no concept of multiple instantiation of hardware elements. If the same

AUTOSAR CP R20-11
hardware element shall be used several times (using the nestedElement reference)
each occurrence has to have its own description. This is also true for nested elements
of the referenced nested element.c()
Thus the hardware element and all its structural features (hardware pin groups, hard-
ware pins and hardware connections) need to be cloned. There is however the possi-
bility to reference the same HwType from several HwElement clones.
2.4 Hardware Pin and Pin Group

The HwPinGroup allows to describe dedicated channels of connectivity for hardware
elements. It can be used to describe grouped hardware ports like ADC and DIO. It
can structure the port information hierarchically. At the detailed level it can be used to
describe individual hardware pins.
Each HwPinGroup is Identifiable. A HwPinGroup can only exist inside a HwEle-
ment or another HwPinGroup.
Each HwPinGroup inherits from HwDescriptionEntity and is therefore capable to
describe a set of attributes (see section 2.1 for details).
The content of the HwPinGroup is aggregated in the role hwPinGroupContent.
Class HwPinGroup
Note This meta-class represents the ability to describe groups of pins which are used to connect hardware
elements. This group acts as a bundle of pins. Thereby they allow to describe high level connections. Pin
groups can even be nested.
Base ARObject, HwDescriptionEntity , Identifiable, MultilanguageReferrable, Referrable
hwPinGroup HwPinGroupContent 1 aggr This aggregation describes the contained pins/pin groups.
Content
Table 2.5: HwPinGroup
The HwPinGroupContent can contain HwPinGroup and HwPin. The HwPinGroup-

Content is defined as «atpMixed» (see Generic Structure Template [6]). The ele-
ments contained in the HwPinGroupContent (HwPinGroup and HwPin) can occur
in an arbitrary order and multiple times. This allows to describe the ordered occurrence
of pins and pin groups within pin groups. One major use-case is to describe physical
connectors and plugs with chambers and pins.

AUTOSAR CP R20-11
Class <<atpMixed>> HwPinGroupContent

Note This meta-class specifies a mixture of hwPins and hwPinGroups.
Base ARObject
hwPin HwPin 1 aggr This aggregation represents a hardware pin in a hardware
pin group.
Tags:
xml.roleWrapperElement=false
hwPinGroup HwPinGroup 1 aggr This aggregation represents a nested hardware pin group.
Tags:
xml.roleWrapperElement=false
Table 2.6: HwPinGroupContent
Each HwPin is Identifiable. A HwPin can only exist inside a HwPinGroupCon-

tent and therefore indirectly in a HwPinGroup.
Each HwPin inherits from HwDescriptionEntity and is therefore capable to de-
scribe a set of attributes (see section 2.1 for details).
Class HwPin
Note This meta-class represents the possibility to describe a hardware pin.
Base ARObject, HwDescriptionEntity , Identifiable, MultilanguageReferrable, Referrable
pinNumber Integer 0..1 attr This attribute contains the physical pin number.
Table 2.7: HwPin
2.5 Hardware Connection

Connections can be described on several levels in the ECU Resource Template. This
allows the expression of details on the needed level of abstraction.
[TPS_ECUR_01006] Connections between HwElements dThe HwElementCon-
nector allows to describe the connection between two HwElements. It is not meant
to describe the actual technical connectivity between the two hardware elements. It
is used to describe the general connectivity between the hardware elements.c(RS_-
ECUR_00006, RS_ECUR_00016)

AUTOSAR CP R20-11
Class HwElementConnector
Note This meta-class represents the ability to connect two hardware elements. The details of the connection
can be refined by hwPinGroupConnection.
Base ARObject, Describable
hwElement HwElement 2 ref This association connects two hardware elements.
hwPin HwPinConnector * aggr This represents one particular connection between two
Connection hardware pins. This connection shall be used if
pin-to-pin-connection is to be described but no description
of the connection between the hierarchical composition of
HwPinGroups (using HwPinGroupConnector) is required.
Tags:
hwPinGroup HwPinGroupConnector * aggr This represents one particular connection between two
Connection hardware pin groups.
Tags:
Table 2.8: HwElementConnector
The HwPinGroupConnector allows to describe the connection between two HwPin-

Groups.
Class HwPinGroupConnector
Note This meta-class represents the ability to connect two pin groups.
hwPin HwPinConnector * aggr This represents one particular connection between two
Connection hardware pins. The connected pins shall match the
connection provided by the parent hwPinGroup
Connection.
Tags:vh.latestBindingTime=systemDesignTime
hwPinGroup HwPinGroup 2 ref This association connects two hardware pin groups.
Table 2.9: HwPinGroupConnector
The HwPinConnector allows to describe the connection between two HwPins.

Class HwPinConnector
Note This meta-class represents the ability to connect two pins.
5

AUTOSAR CP R20-11
4
Class HwPinConnector
hwPin HwPin 2 ref This association connects two hardware pins.
Table 2.10: HwPinConnector
2.5.1 Scope of Connections
The hardware connections are part of a hardware element and connect the two artifacts
via references to the description of the artifacts. In principle such references can refer
to any hardware element and its features in the input information. But the scope of
connections is restricted based on the containing hardware element of the hardware
connection.
[constr_3513] Scope of connections dEach hardware connection shall only connect
features which both are in the hierarchical scope of the hardware element. The hierar-
chical scope encloses
• all features belonging to the hardware element containing the connection
• all features belonging to hardware elements which are referenced directly and
indirectly in the nestedElement relation from the hardware element containing
connection.
c()
Especially it is allowed to specify connections in hardware elements which are in
deeper hierarchical level and also connections which cross hierarchical levels.
In the example from figure A.1 the following connections are allowed:
• connections specified in the scope of hardware element "MyEcu"
– all the shown connections can be specified on this level
– even the connections inside another hierarchical hardware element (e.g. be-
tween "Pu1" and "Can") can be specified on this level
– even the connections crossing hierarchical levels (e.g. between "Can" and
"Trcv") can be specified on this level
• connections specified in the scope of hardware element "MicroController"
– only the connections inside the hardware element "MicroController" (e.g. be-
tween "Pu1" and "Can") can be specified.

AUTOSAR CP R20-11
2.6 Hardware Category Definition

The definition of dedicated hardware types allows a flexible usage of the ECU Re-
source Template. Since the definition of hardware types and the applicable attributes
is specified as an AUTOSAR XML file itself it can be updated and extended without the
needs to update the AUTOSAR XML-Schema.
In figure 2.2 the relationship between the definition and the description of hardware is
shown.
ARElement Referrable
AtpDefinition +hwCategory HwDescriptionEntity
HwCategory 0..*

«atpVariation»
+hwAttributeDef 0..* +hwAttributeValue 0..* +hwType 0..1
Identifiable ARElement
HwAttributeValue
HwAttributeDef +hwAttributeDef
HwType
+ vt: VerbatimString [0..1]
+ isRequired: Boolean 1
«atpVariation»
+ v: Numerical [0..1]
+hwAttributeLiteral 0..* +unit 0..1 +annotation 0..1
Identifiable ARElement GeneralAnnotation ARElement

HwAttributeLiteralDef Unit Annotation HwElement
+ factorSiToUnit: Float [0..1]

+ offsetSiToUnit: Float [0..1]
+nestedElement 0..*
«atpVariation»
Figure 2.2: Definition of hardware categories
The element HwCategory specifies what type of hardware is defined. This can be a
for example a memory segment, a processing unit, a communication transceiver etc.
The HwCategory is later referenced from the HwDescriptionEntity in the role
hwCategory to describe what type of hardware is described. Possible values for the
shortName of the HwCategory element are defined in table 3.1 and table 3.5.
The HwCategory may contain several HwAttributeDef elements.
Class HwCategory
Note This metaclass represents the ability to declare hardware categories and its particular attributes.
Tags:atp.recommendedPackage=HwCategorys
Base ARElement, ARObject, AtpDefinition, CollectableElement, Identifiable, MultilanguageReferrable,
5

AUTOSAR CP R20-11
4
Class HwCategory
hwAttributeDef HwAttributeDef * aggr This aggregation describes particular hardware attribute
definition.
Table 2.11: HwCategory
The HwAttributeDef specifies one attribute which is applicable for the HwCate-
gory.
The name of the attribute is defined in the shortName.
The type of the attribute is specified by the category. Applicable values for the
category of HwAttributeDef are defined in table 2.12.
[constr_3500] category of HwAttributeDef shall not be extended dIn contrast
to the general rule that category can be extended by user-specific values it is not al-
lowed to extend the meaning of the attribute category of meta-class HwAttribut-
eDefc()
Category Description
Defines a boolean attribute.
The values of a boolean attribute can be provided in
• textual format ’true’ / ’false’ (using the vt element
BOOLEAN of HwAttributeValue
• numerical format ’1’ (true) / ’0’ (false) (using the v
element of HwAttributeValue
Defines an integer attribute.

The values of an integer attribute can be a signed /
INTEGER
unsigned whole number. The value has to fit in a signed /
unsigned 64-bit number space.
Defines a float attribute.
The value of a float attribute is represented as an IEEE
FLOAT
double-precision 64-bit floating point of the IEEE
754-1985 standard [7].
Defines an enumeration attribute. The possible
enumeration literals are defined with the element vt.
ENUMERATION
The value of an enumeration attribute is provided as text
in the vt element of HwAttributeValue.
Defines a string attribute.
STRING The value of a string attribute is provided as text in the vt
element of HwAttributeValue.
Table 2.12: Hardware Attribute Categories
The element isRequired specifies whether the attribute is mandatory for the defined
category.

AUTOSAR CP R20-11
[TPS_ECUR_01031] Definition of attribute unit dOptionally the attribute definition

can have a reference to a Unit element which specifies in which unit the value of this
attribute shall be specified.c(RS_ECUR_00014)
For details on the Unit specification please refer to the Software Component Tem-
plate [3].

AUTOSAR CP R20-11
Class HwAttributeDef
Note This metaclass represents the ability to define a particular hardware attribute.
The category of this element defines the type of the attributeValue. If the category is Enumeration the hw
AttributeEnumerationLiterals specify the available literals.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
hwAttribute HwAttributeLiteralDef * aggr The available EnumerationLiterals of the Enumeration
Literal definition. Only applicable if the category of the Hw
AttributeDef equals Enumeration.
isRequired Boolean 1 attr This attribute specifies if the defined attribute value is
required to be provided.
unit Unit 0..1 ref This association specifies the physical unit of the defined
hardware attribute. This is optional due to the fact that
there are textual attributes.
Table 2.13: HwAttributeDef
In case the category of the HwAttributeDef is set to Enumeration the applicable

enumeration literals are specified with the element HwAttributeLiteralDef.
Class HwAttributeLiteralDef
Note One available EnumerationLiteral of the Enumeration definition. Only applicable if the category of the Hw
AttributeDef equals Enumeration.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
– – – – –
Table 2.14: HwAttributeLiteralDef
In example A.8 the definition of some attributes for the MemorySegment category are
described.
2.6.1 Vendor specific extensions of Hardware Category Definition
In order to allow the description of arbitrary hardware and their relationships the ECU
Resource Template allows the extension of the definition of hardware categories and
and hardware attributes. When extending the ECU Resource Description for vendor
specific usage the following rules shall be respected:
• [TPS_ECUR_01021] Definition of new hardware categories dNew hardware
categories for HwElement and HwPinGroup and HwPin can be defined if they
are different from the already defined categories. This definition shall be in a
package which is not the AUTOSAR package. A HwDescriptionEntity shall
then reference the extended hardware category.c()
For more details on the already defined categories see chapter Hardware Type
Specific Description.

AUTOSAR CP R20-11
• [TPS_ECUR_01022] Extension of existing hardware categories dAn existing

hardware category can be extended with new attribute definitions. The exten-
sion is via defining a hardware category of the same name as the standardized
one in a different package than AUTOSAR. A HwDescriptionEntity shall then
reference the standardized and the extended hardware category.c()
For more details on the already existing hardware categories see chapter Hard-
ware Type Specific Description.
• [TPS_ECUR_01023] No redefinition of hardware attributes dAn extension of
the standardized hardware category shall not define the same hardware at-
tributes as already defined in the standardized hardware category.c()
• [TPS_ECUR_01024] Extension of enumeration dAn existing enumeration at-
tribute can be extended with new enumeration literals.c()
For more details on existing enumerations attributes see chapter Hardware Type
• [TPS_ECUR_01025] No removal od existing enumeration literals
dEnumeration literals shall not be removed from the specified enumeration
attributes.c()
For more details on existing enumerations attributes see chapter Hardware Type
• [TPS_ECUR_01026] No change of category dThe category (type) of specified
attributes shall not be changed.c()
For more details see chapter Hardware Type Specific Description.
• [TPS_ECUR_01027] No change of isRequired value dThe value of the is-
Required element shall not be changed for specified attributes.c()
• [TPS_ECUR_01028] No change of Unit value dThe value of the Unit element
shall not be changed for specified attributes.c()
2.7 Ecu Resource Variant Handling

For details on the AUTOSAR variant handling support please refer to the AUTOSAR
Generic Structure Template [6]. The structure is shown in figure 2.1.
[TPS_ECUR_01029] Support for variant handling dIn the description of a hardware
element the following relationships are subject to variant handling:
• nestedElement

AUTOSAR CP R20-11
• hwPinGroup
• hwElementConnection
c(RS_ECUR_00015)
The existence of a HwPinGroup can be variant via the aggregation role hwPinGroup
from HwElement. So different alternatives of HwPinGroup can be specified. The
content of the HwPinGroup can as well be variant via the roles hwPinGroup and
hwPin from the HwPinGroupContent.
The existence of a HwElementConnector can be variant via the aggregation role
hwElementConnection from HwElement. The existence of individual HwPin-
GroupConnectors and HwPinConnectors in several roles is as well subject to vari-
ability.
For the description of attribute values the existence of the HwAttributeValue and
the actual v element are subject to variability (see also figure 2.2).
2.8 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].
[TPS_ECUR_01030] Documentation support dAn optional documentation block can
be applied to any Identifiable and Describable element in an Ecu Resource
Description. This type of documentation is typically used to capture a short introduction
about the role of an element or respectively how it is built.c(RS_ECUR_00017)
2.9 Infrastructural aspects

[TPS_ECUR_01032] Modeling of ECU Resource metamodel dThe modeling of the
ECU Configuration Value and ECU Configuration Parameter Definition metamodels is
done according to the Generic Structure Template [6].c(RS_ECUR_00012)
[TPS_ECUR_01033] Transformation of the ECU Resource metamodel to schema
definition dThe transformation of the ECU Resource metamodel to schema definitions
is done according to the XML Schema Production Rules [4].c(RS_ECUR_00013)

AUTOSAR CP R20-11
3 Hardware Type Specific Description

Chapter 2 introduced the general building blocks which are provided to describe hard-
ware elements and their relationships. But in order to use the information from the ECU
Resource Description to aid the configuration of an ECU there is need to describe ded-
icated attributes of specific hardware elements (e.g. memory size).
The following sections deal with the special elements that are necessary to specify a
partly or complete engineered ECU with the ECU Resource Template.
3.1 HwElement categories

An overview of the applicable categories for HwElement is shown in table 3.1.
Ecu Describes an Ecu (see section 3.1.1).
ProcessingUnit Describes a micro-controller core (see section 3.1.2).
MicroController Describes a micro-controller (see section 3.1.3).
MemorySegment Describes a memory segment (see section 3.1.4).
CommunicationController Describes a communication controller (see section 3.1.5).
CommunicationTransceiver Describes a communication transceiver (see section 3.1.6).
Digital Describes a digital IO peripheral (see section 3.1.7).
Analog Describes an analog IO peripheral (see section 3.1.8).
Timer Describes a timer peripheral (see section 3.1.9).
Watchdog Describes a watchdog peripheral (see section 3.1.10).
SensorActuator Describes sensors and actuators (see section 3.1.11).
Table 3.1: Hardware Element Categories
3.1.1 Ecu
[TPS_ECUR_01034] Category of an Ecu dThe category of an ECU is defined as

Ecu.c(RS_ECUR_00007)
Currently no special attributes are defined for the ECU.
There exists an inconsistency between the System Template and the ECU Resource
Template concerning the usage of the term “Ecu”. In the System Template “Ecu” is
used to determine one instance of an AUTOSAR Stack (e.g. like in ECUInstance). In
the Ecu Resource Template ’Ecu" is used to describe the physical box (HardwareEle-
ment of category Ecu) containing the electronics which may contain several processing
units with several AUTOSAR Stack instances running.
3.1.2 Processing Unit
The processing unit describes one core of a micro-controller.

AUTOSAR CP R20-11
[TPS_ECUR_01007] Category of a processing unit dThe category of a processing

unit is defined as ProcessingUnit.c(RS_ECUR_00007)
Currently no special attributes are defined for the processing unit.
3.1.3 Micro-Controller
The micro-controller describes one piece of hardware as delivered by the manufacturer

of the micro-controller hardware. Typically the micro-controller contains one or several
processing units, memory segments and peripherals.
[TPS_ECUR_01035] Category of a micro-controller dThe category of a micro-
controller is defined as MicroController.c(RS_ECUR_00007)
Currently no special attributes are defined for the micro-controller.
Example A.1 shows a simple description of a high-level view on a micro-controller.
3.1.4 Memory
[TPS_ECUR_01008] Attributes for the category MemorySegment dThe special at-

tributes which are applicable for the category MemorySegment hardware elements are
defined in table 3.2.c(RS_ECUR_00008)
Attribute Required Unit Description

Specifies the size of the memory segment in
memorySize true INTEGER
bytes.
Specifies the type of memory:
• RAM
• ROM
memoryType true ENUMERATION
• EEPROM
• Flash
Table 3.2: MemorySegment Hardware Element Parameters
3.1.5 Communication Controller
[TPS_ECUR_01009] Category of a communication controller dThe category of a

communication controller is CommunicationController.c(RS_ECUR_00009)

AUTOSAR CP R20-11
Specifies the type of communication controller:

• CAN
• TTCAN
communication
• LIN
Controller true ENUMERATION
Type • FlexRay
• Ethernet
• Spi
Table 3.3: CommunicationController Hardware Element Attributes
3.1.6 Communication Transceiver
[TPS_ECUR_01010] Category of a communication transceiver dThe category of

a communication transceiver is defined as CommunicationTransceiver.c(RS_-
ECUR_00009)
supports Specifies whether the transceiver can be
false BOOLEAN
Disabling disabled.
supports Specifies whether the transceiver can indicate
false BOOLEAN
WakeUp a wake-up situation on the bus.
Table 3.4: CommunicationTransceiver Hardware Element Attributes
3.1.7 Digital IO
[TPS_ECUR_01011] Category of a digital IO dThe category of a digital IO hardware

element is defined as Digital.c(RS_ECUR_00010)
Currently no special attributes are defined for the digital IO.
3.1.8 Analog IO
[TPS_ECUR_01036] Category of an analog IO dThe category of an analog IO hard-

ware element is defined as Analog.c(RS_ECUR_00007)
Currently no special attributes are defined for the analog IO.

AUTOSAR CP R20-11
3.1.9 Timer
[TPS_ECUR_01037] Category of a timer dThe category of a timer is defined as

Timer.c(RS_ECUR_00007)
Currently no special attributes are defined for the timer.
3.1.10 Watchdog
[TPS_ECUR_01038] Category of a watchdog dThe category of a watchdog is defined

as Watchdog.c(RS_ECUR_00007)
Currently no special attributes are defined for the watchdog.
3.1.11 SensorActuator
[TPS_ECUR_01012] Category of a sensor/actuator dThe category of a sensor/actu-

ator is defined as SensorActuator.c(RS_ECUR_00011)
Currently no special attributes are defined for the sensor/actuator.
3.2 HwPinGroup categories

An overview of the applicable categories for HwPinGroup is shown in table 3.5.
CommunicationPort Describes a communication connector (see section 3.2.1).
Table 3.5: Hardware Pin Group Categories
3.2.1 CommunicationPort
[TPS_ECUR_01013] Category of a Communication Port dThe category of a Com-

munication Port is defined as CommunicationPort.c(RS_ECUR_00009)

AUTOSAR CP R20-11
Specifies the type of communication port:

• CAN
• TTCAN
communication • LIN
true ENUMERATION
PortType
• FlexRay
• Ethernet
• Spi
Table 3.6: CommunicationPort Hardware Element Attributes
3.3 HwPin categories

There are no dedicated categories specified for HwPin.

AUTOSAR CP R20-11
A Examples
A.1 Hardware Element

Example A.1 shows a simple description of a high-level view on a micro-controller.
Example A.1
<AR-PACKAGE>
<SHORT-NAME>VendorA</SHORT-NAME>
<ELEMENTS>
<HW-ELEMENT>
<SHORT-NAME>MicroController_0815</SHORT-NAME>
<HW-CATEGORY-REFS>
<HW-CATEGORY-REF DEST="HW-CATEGORY">/AUTOSAR/MicroController</HW-
CATEGORY-REF>
</HW-CATEGORY-REFS>
</HW-ELEMENT>
</ELEMENTS>
</AR-PACKAGE>
A.2 Hierarchy of Hardware Elements

Example A.2 shows the hierarchical description of a processing unit in a micro-
controller.
Example A.2
<AR-PACKAGE>
<ELEMENTS>
<HW-ELEMENT>
<HW-CATEGORY-REFS>
CATEGORY-REF>
</HW-CATEGORY-REFS>
<NESTED-ELEMENTS>
<HW-ELEMENT-REF-CONDITIONAL>
<HW-ELEMENT-REF DEST="HW-ELEMENT">/VendorA/ProcessingUnit0</HW-
ELEMENT-REF>
</HW-ELEMENT-REF-CONDITIONAL>
</NESTED-ELEMENTS>
</HW-ELEMENT>
<HW-ELEMENT>
<SHORT-NAME>ProcessingUnit0</SHORT-NAME>
<HW-CATEGORY-REFS>
<HW-CATEGORY-REF DEST="HW-CATEGORY">/AUTOSAR/ProcessingUnit</HW-
CATEGORY-REF>
</HW-CATEGORY-REFS>
</HW-ELEMENT>

AUTOSAR CP R20-11
</ELEMENTS>
</AR-PACKAGE>
A.3 HwPinGroups and HwPins

Example A.3 shows the description of pin groups and pins of the micro-controller.
Example A.3
<AR-PACKAGE>
<ELEMENTS>
<HW-ELEMENT>
<HW-CATEGORY-REFS>
CATEGORY-REF>
</HW-CATEGORY-REFS>
<HW-PIN-GROUPS>
<HW-PIN-GROUP>
<SHORT-NAME>Adc</SHORT-NAME>
<HW-PIN-GROUP-CONTENT>
<HW-PIN-GROUP>
<SHORT-NAME>AdcPortA</SHORT-NAME>
</HW-PIN-GROUP>
<HW-PIN-GROUP>
<SHORT-NAME>AdcPortB</SHORT-NAME>
<HW-PIN-GROUP-CONTENT>
<HW-PIN>
<SHORT-NAME>AdcB01</SHORT-NAME>
</HW-PIN>
<HW-PIN>
<SHORT-NAME>AdcB02</SHORT-NAME>
</HW-PIN>
</HW-PIN-GROUP-CONTENT>
</HW-PIN-GROUP>
</HW-PIN-GROUP-CONTENT>
</HW-PIN-GROUP>
</HW-PIN-GROUPS>
</HW-ELEMENT>
</ELEMENTS>
</AR-PACKAGE>

AUTOSAR CP R20-11
A.4 Hardware Element Connection

Example A.4 shows the description of the internal structure of a micro-controller in
order to define which memory segments are accessible from which processing unit
(core).
Example A.4
<AR-PACKAGE>
<ELEMENTS>
<HW-ELEMENT>
<HW-CATEGORY-REFS>
CATEGORY-REF>
</HW-CATEGORY-REFS>
<NESTED-ELEMENTS>
<HW-ELEMENT-REF DEST="HW-ELEMENT">/VendorA/Core0</HW-ELEMENT-REF>
<HW-ELEMENT-REF DEST="HW-ELEMENT">/VendorA/Core1</HW-ELEMENT-REF>
<HW-ELEMENT-REF DEST="HW-ELEMENT">/VendorA/Mem01</HW-ELEMENT-REF>

</NESTED-ELEMENTS>
<HW-ELEMENT-CONNECTIONS>
<HW-ELEMENT-CONNECTOR>
<HW-ELEMENT-REFS>
<HW-ELEMENT-REF DEST="HW-ELEMENT">/VendorA/Core0</HW-ELEMENT-
REF>
<HW-ELEMENT-REF DEST="HW-ELEMENT">/VendorA/Mem01</HW-ELEMENT-
REF>
</HW-ELEMENT-REFS>
</HW-ELEMENT-CONNECTOR>
<HW-ELEMENT-REFS>
<HW-ELEMENT-REF DEST="HW-ELEMENT">/VendorA/Core0</HW-ELEMENT-
REF>
<HW-ELEMENT-REF DEST="HW-ELEMENT">/VendorA/Mem02</HW-ELEMENT-
REF>
</HW-ELEMENT-REFS>

</HW-ELEMENT-CONNECTIONS>
</HW-ELEMENT>
<HW-ELEMENT>
<SHORT-NAME>Core0</SHORT-NAME>
<HW-CATEGORY-REFS>
CATEGORY-REF>
</HW-CATEGORY-REFS>

AUTOSAR CP R20-11
</HW-ELEMENT>
<HW-ELEMENT>
<SHORT-NAME>Core1</SHORT-NAME>
<HW-CATEGORY-REFS>
CATEGORY-REF>
</HW-CATEGORY-REFS>
</HW-ELEMENT>
<HW-ELEMENT>
<SHORT-NAME>Mem01</SHORT-NAME>
<HW-CATEGORY-REFS>
<HW-CATEGORY-REF DEST="HW-CATEGORY">/AUTOSAR/MemorySegment</HW-
CATEGORY-REF>
</HW-CATEGORY-REFS>
</HW-ELEMENT>
<HW-ELEMENT>
<HW-CATEGORY-REFS>
CATEGORY-REF>
</HW-CATEGORY-REFS>
</HW-ELEMENT>
<HW-ELEMENT>
<HW-CATEGORY-REFS>
CATEGORY-REF>
</HW-CATEGORY-REFS>
</HW-ELEMENT>
</ELEMENTS>
</AR-PACKAGE>
A.5 Combined Example

In this example section several mechanisms are utilized to describe an Ecu and some
of its electronics attributes. The overview is shown in figure A.1. The individual sections
describe the different abstraction layers.

AUTOSAR CP R20-11
Figure A.1: Example of Ecu description
A.5.1 Micro-controller description
The micro-controller consists of the processing unit, a Can controller and a Dio module.
The processing unit is defined to have access to both of the peripherals.
The Dio module defines two HwPinGroups in order to support more detailed connec-
tion description.
The whole micro-controller is defined in an own ARPackage so it can be used in several
projects.
Example A.5
<AR-PACKAGE>
<SHORT-NAME>CpuVendor</SHORT-NAME>
<ELEMENTS>
<HW-ELEMENT>
<SHORT-NAME>MicroController</SHORT-NAME>
<NESTED-ELEMENTS>
<HW-ELEMENT-REF
DEST="HW-ELEMENT">Pu1</HW-ELEMENT-REF>
<HW-ELEMENT-REF
DEST="HW-ELEMENT">Can</HW-ELEMENT-REF>
<HW-ELEMENT-REF
DEST="HW-ELEMENT">Dio</HW-ELEMENT-REF>
</NESTED-ELEMENTS>

AUTOSAR CP R20-11
<HW-ELEMENT-REFS>
<HW-ELEMENT-REF
<HW-ELEMENT-REF
DEST="HW-ELEMENT">Can</HW-ELEMENT-REF>
</HW-ELEMENT-REFS>
<HW-ELEMENT-REFS>
<HW-ELEMENT-REF
<HW-ELEMENT-REF
DEST="HW-ELEMENT">Dio</HW-ELEMENT-REF>
</HW-ELEMENT-REFS>
</HW-ELEMENT>
<HW-ELEMENT>
<SHORT-NAME>Pu1</SHORT-NAME>
</HW-ELEMENT>
<HW-ELEMENT>
<SHORT-NAME>Can</SHORT-NAME>
</HW-ELEMENT>
<HW-ELEMENT>
<SHORT-NAME>Dio</SHORT-NAME>
<HW-PIN-GROUPS>
<HW-PIN-GROUP>
<SHORT-NAME>D0</SHORT-NAME>
</HW-PIN-GROUP>
<HW-PIN-GROUP>
<SHORT-NAME>D1</SHORT-NAME>
</HW-PIN-GROUP>
</HW-PIN-GROUPS>
</HW-ELEMENT>
</ELEMENTS>
</AR-PACKAGE>
A.5.2 Transceiver description
The transceiver module is defined as a HwElement which provides three HwPin-

Groups to describe its connectivity.
The transceiver module is defined in an own ARPackage so it can be used in several
projects.
Example A.6
<AR-PACKAGE>
<SHORT-NAME>TransceiverVendor</SHORT-NAME>
<ELEMENTS>

AUTOSAR CP R20-11
<HW-ELEMENT>
<SHORT-NAME>Trcv</SHORT-NAME>
<HW-PIN-GROUPS>
<HW-PIN-GROUP>
<SHORT-NAME>enable</SHORT-NAME>
</HW-PIN-GROUP>
<HW-PIN-GROUP>
<SHORT-NAME>wakeup</SHORT-NAME>
</HW-PIN-GROUP>
<HW-PIN-GROUP>
<SHORT-NAME>CanBus</SHORT-NAME>
</HW-PIN-GROUP>
</HW-PIN-GROUPS>
</HW-ELEMENT>
</ELEMENTS>
</AR-PACKAGE>
A.5.3 Ecu description
The Ecu contains the micro-controller and the transceiver.

The Ecu defines one HwPinGroup to represent the CanBus communication to the
outside of the Ecu.
The Ecu defines the detailed connectivity inside.
Example A.7
<AR-PACKAGE>
<SHORT-NAME>EcuVendor</SHORT-NAME>
<ELEMENTS>
<HW-ELEMENT>
<SHORT-NAME>MyEcu</SHORT-NAME>
<NESTED-ELEMENTS>
<HW-ELEMENT-REF
DEST="HW-ELEMENT">/CpuVendor/MicroController</HW-ELEMENT-REF>
<HW-ELEMENT-REF
DEST="HW-ELEMENT">/TransceiverVendor/Trcv</HW-ELEMENT-REF>
</NESTED-ELEMENTS>
<HW-PIN-GROUPS>
<HW-PIN-GROUP>
<SHORT-NAME>CanBus</SHORT-NAME>
</HW-PIN-GROUP>
</HW-PIN-GROUPS>
<HW-ELEMENT-REFS>
<HW-ELEMENT-REF

AUTOSAR CP R20-11
DEST="HW-ELEMENT">/CpuVendor/Can</HW-ELEMENT-REF>
<HW-ELEMENT-REF
</HW-ELEMENT-REFS>
<HW-ELEMENT-REFS>
<HW-ELEMENT-REF
DEST="HW-ELEMENT">/CpuVendor/Dio</HW-ELEMENT-REF>
<HW-ELEMENT-REF
</HW-ELEMENT-REFS>
<HW-PIN-GROUP-CONNECTIONS>
<HW-PIN-GROUP-CONNECTOR>
<HW-PIN-GROUP-REFS>
<HW-PIN-GROUP-REF DEST="HW-PIN-GROUP">/CpuVendor/Dio/D0</HW
-PIN-GROUP-REF>
<HW-PIN-GROUP-REF DEST="HW-PIN-GROUP">/TransceiverVendor/
Trcv/enable</HW-PIN-GROUP-REF>
</HW-PIN-GROUP-REFS>
</HW-PIN-GROUP-CONNECTOR>
<HW-PIN-GROUP-REFS>
<HW-PIN-GROUP-REF DEST="HW-PIN-GROUP">/CpuVendor/Dio/D1</HW
-PIN-GROUP-REF>
<HW-PIN-GROUP-REF DEST="HW-PIN-GROUP">/TransceiverVendor/
Trcv/wakeup</HW-PIN-GROUP-REF>
</HW-PIN-GROUP-CONNECTIONS>
<HW-ELEMENT-REFS>
<HW-ELEMENT-REF
<HW-ELEMENT-REF
DEST="HW-ELEMENT">/EcuVendor/MyEcu</HW-ELEMENT-REF>
</HW-ELEMENT-REFS>
<HW-PIN-GROUP-CONNECTIONS>
<HW-PIN-GROUP-REFS>
<HW-PIN-GROUP-REF
DEST="HW-PIN-GROUP">/TransceiverVendor/Trcv/Can</HW-PIN-
GROUP-REF>
<HW-PIN-GROUP-REF
DEST="HW-PIN-GROUP">/EcuVendor/CanBus</HW-PIN-GROUP-REF>
</HW-PIN-GROUP-CONNECTIONS>
</HW-ELEMENT>
</ELEMENTS>
</AR-PACKAGE>

AUTOSAR CP R20-11
A.6 Attribute Definition

Example A.8 shows how a category and associated attribute definitions are described
in the ECU Resource Template.
Example A.8
<AR-PACKAGE>
<SHORT-NAME>AUTOSAR</SHORT-NAME>
<ELEMENTS>
<HW-CATEGORY>
<SHORT-NAME>MemorySegment</SHORT-NAME>
<HW-ATTRIBUTE-DEFS>
<HW-ATTRIBUTE-DEF>
<SHORT-NAME>memorySize</SHORT-NAME>
<DESC>
<L-2 L="EN">Specifies the size of the memory segment in
bytes.</L-2>
</DESC>
<CATEGORY>INTEGER</CATEGORY>
<IS-REQUIRED>true</IS-REQUIRED>
</HW-ATTRIBUTE-DEF>
<HW-ATTRIBUTE-DEF>
<SHORT-NAME>memoryType</SHORT-NAME>
<DESC>
<L-2 L="EN">Specifies the type of memory: RAM, ROM, EEPROM,
Flash.</L-2>
</DESC>
<CATEGORY>ENUMERATION</CATEGORY>
<HW-ATTRIBUTE-LITERALS>
<HW-ATTRIBUTE-LITERAL-DEF><SHORT-NAME>RAM</SHORT-NAME></HW-
ATTRIBUTE-LITERAL-DEF>
<HW-ATTRIBUTE-LITERAL-DEF><SHORT-NAME>ROM</SHORT-NAME></HW-
ATTRIBUTE-LITERAL-DEF>
<HW-ATTRIBUTE-LITERAL-DEF><SHORT-NAME>FLASH</SHORT-NAME></
HW-ATTRIBUTE-LITERAL-DEF>
<HW-ATTRIBUTE-LITERAL-DEF><SHORT-NAME>EEPROM</SHORT-NAME></
HW-ATTRIBUTE-LITERAL-DEF>
</HW-ATTRIBUTE-LITERALS>
<IS-REQUIRED>true</IS-REQUIRED>
</HW-ATTRIBUTE-DEF>
</HW-ATTRIBUTE-DEFS>
</HW-CATEGORY>
</ELEMENTS>
</AR-PACKAGE>

AUTOSAR CP R20-11
A.7 Attribute Value Example

Example A.9 shows the description of attributes which have been defined using the
ECU Resource Template (see example A.8).
Example A.9
<AR-PACKAGE>
<ELEMENTS>
<HW-ELEMENT>
<SHORT-NAME>MemorySeg001</SHORT-NAME>
<HW-CATEGORY-REFS>
CATEGORY-REF>
</HW-CATEGORY-REFS>
<HW-ATTRIBUTE-VALUES>
<HW-ATTRIBUTE-VALUE>
<HW-ATTRIBUTE-DEF-REF DEST="HW-ATTRIBUTE-DEF">/AUTOSAR/
MemorySegment/memoryType</HW-ATTRIBUTE-DEF-REF>
<VT>RAM</VT>
</HW-ATTRIBUTE-VALUE>
<HW-ATTRIBUTE-VALUE>
<HW-ATTRIBUTE-DEF-REF DEST="HW-ATTRIBUTE-DEF">/AUTOSAR/
MemorySegment/memorySize</HW-ATTRIBUTE-DEF-REF>
<V>1024</V>
</HW-ATTRIBUTE-VALUE>
</HW-ATTRIBUTE-VALUES>
</HW-ELEMENT>
</ELEMENTS>
</AR-PACKAGE>

AUTOSAR CP R20-11
B 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 ([8]).
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 R20-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 R20-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 R20-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 R20-11
C History of Constraints and Specification Items

Please note that the lists in this chapter also include constraints and specification items
that have been removed from the specification in a later version. These constraints and
specification items do not appear as hyperlinks in the document.
C.1 Constraint and Specification Item History of this document

according to AUTOSAR Release R4.0.2
No changes.

C.2.1 Added Constraints in R4.0.3
Number Heading
[constr_3500] category of HwAttributeDef shall not be extended
Table C.1: Added Constraints in R4.0.3

C.3.1 Added Constraints in R4.1.1
Number Heading
[constr_3511] HwType shall not have a reference to another HwType
[constr_3512] No support of multiple instantiation
[constr_3513] Scope of connections
Table C.2: Added Constraints in R4.1.1
C.3.2 Added Traceables in R4.1.1
SWS Item Rationale

[TPS_ECUR_01000] Definition of HwCategory
[TPS_ECUR_01001] Extension of HwCategory
[TPS_ECUR_01002] Definition of Hardware Elements
[TPS_ECUR_01003] Values of hardware attributes
[TPS_ECUR_01005] The HwElement describes one piece of hardware
[TPS_ECUR_01006] Connections between HwElements
[TPS_ECUR_01007] The category of a processing unit is defined as ProcessingUnit.

AUTOSAR CP R20-11
[TPS_ECUR_01008] The special attributes which are applicable for the category MemorySegment
hardware elements are defined in table 3.2.
[TPS_ECUR_01009] The category of a communication controller is CommunicationCon-
troller.
[TPS_ECUR_01010] The category of a communication transceiver is defined as Communica-
tionTransceiver.
[TPS_ECUR_01011] The category of a digital IO hardware element is defined as Digital.
[TPS_ECUR_01012] The category of a sensor/actuator is defined as SensorActuator.
[TPS_ECUR_01013] The category of a Communication Port is defined as CommunicationPort.
[TPS_ECUR_01014] Definition of HwAttributeValue
[TPS_ECUR_01015] Support of AUTOSAR Basic Software configuration
[TPS_ECUR_01016] Definition of HwType
[TPS_ECUR_01017] Attribute values defined in the HwType are applicable for all occurrences of
this HwType
[TPS_ECUR_01018] HwElement is self contained
[TPS_ECUR_01019] HwElement can refer to a HwType
[TPS_ECUR_01020] Hierarchy of hardware
[TPS_ECUR_01021] Definition of new hardware categories
[TPS_ECUR_01022] Extension of existing hardware categories
[TPS_ECUR_01023] No redefinition of hardware attributes
[TPS_ECUR_01024] Extension of enumeration
[TPS_ECUR_01025] No removal od existing enumeration literals
[TPS_ECUR_01026] No change of category
[TPS_ECUR_01027] No change of isRequired value
[TPS_ECUR_01028] No change of Unit value
[TPS_ECUR_01029] Support for variant handling
[TPS_ECUR_01030] Documentation support
[TPS_ECUR_01031] Definition of attribute unit
[TPS_ECUR_01032] Modeling of ECU Resource metamodel
[TPS_ECUR_01033] Transformation of the ECU Resource metamodel to schema definition
[TPS_ECUR_01034] Category of an Ecu
[TPS_ECUR_01035] Category of a micro-controller
[TPS_ECUR_01036] Category of an analog IO
[TPS_ECUR_01037] Category of a timer
[TPS_ECUR_01038] Category of a watchdog
Table C.3: Added Traceables in R4.1.1

No changes.

No changes.

AUTOSAR CP R20-11

No changes.

No changes.

No changes.

No changes.

No changes.

according to AUTOSAR Release R19-11
No changes.

according to AUTOSAR Release R20-11
No changes.

AUTOSAR CP R20-11
D 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, CryptoServiceCertificate,
CryptoServiceKey, CryptoServicePrimitive, CryptoServiceQueue, DataConstr, DataExchangePoint, Data
TransformationSet, DataTypeMappingSet, DiagnosticCommonElement, DiagnosticConnection,
DiagnosticContributionSet, Documentation, E2EProfileCompatibilityProps, EcucDefinitionCollection,
EcucDestinationUriDefSet, EcucModuleConfigurationValues, EcucModuleDef, EcucValueCollection, End
ToEndProtectionSet, EthIpProps, EthTcpIpIcmpProps, EthTcpIpProps, EvaluatedVariantSet, FMFeature,
FMFeatureMap, FMFeatureModel, FMFeatureSelectionSet, FlatMap, GeneralPurposeConnection, Hw
Category, HwElement, HwType, IPSecConfigProps, IPv6ExtHeaderFilterSet, IdsCommonElement, Ids
Design, Implementation, InterpolationRoutineMappingSet, J1939ControllerApplication, KeywordSet, Life
CycleInfoSet, LifeCycleStateDefinitionGroup, McFunction, McGroup, ModeDeclarationGroup, Mode
DeclarationMappingSet, PhysicalDimension, PhysicalDimensionMappingSet, PortInterface, PortInterface
MappingSet, PortPrototypeBlueprint, PostBuildVariantCriterion, PostBuildVariantCriterionValueSet,
PredefinedVariant, RapidPrototypingScenario, SdgDef, SignalServiceTranslationPropsSet, SomeipSd
ClientEventGroupTimingConfig, SomeipSdClientServiceInstanceConfig, SomeipSdServerEventGroup
TimingConfig, SomeipSdServerServiceInstanceConfig, SwAddrMethod, SwAxisType, SwComponent
Type, SwRecordLayout, SwSystemconst, SwSystemconstantValueSet, SwcBswMapping, System,
SystemSignal, SystemSignalGroup, TDCpSoftwareClusterMappingSet, TcpOptionFilterSet, Timing
Extension, TlvDataIdDefinitionSet, TransformationPropsSet, Unit, UnitGroup, ViewMapSet
– – – – –
Table D.1: ARElement
Class ARPackage
Package M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::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
5

AUTOSAR CP R20-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
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.
Stereotypes: atpSplitable
Tags:
atp.Splitkey=referenceBase.shortLabel
Table D.2: ARPackage
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
adminData AdminData 0..1 aggr This represents the administrative data for the
describable object.
Tags:xml.sequenceOffset=-20
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 particlar how the
object is built or used) should go to "introduction".
5

AUTOSAR CP R20-11
4
Class Describable (abstract)
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 D.3: Describable
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, Application
Endpoint, ApplicationError, ApplicationPartitionToEcuPartitionMapping, AsynchronousServerCallResult
Point, AtpBlueprint, AtpBlueprintable, AtpClassifier , AtpFeature, AutosarOperationArgumentInstance,
AutosarVariableInstance, BinaryManifestAddressableObject, BinaryManifestItemDefinition, Binary
ManifestResource, BinaryManifestResourceDefinition, BlockState, BswInternalTriggeringPoint, Bsw
ModuleDependency, BuildActionEntity , BuildActionEnvironment, CanTpAddress, CanTpChannel, CanTp
Node, Chapter, ClassContentConditional, ClientIdDefinition, ClientServerOperation, Code, Collectable
Element, ComManagementMapping, CommConnectorPort, CommunicationConnector , Communication
Controller , Compiler, ConsistencyNeeds, ConsumedEventGroup, CouplingPort, CouplingPortStructural
Element, CpSoftwareClusterResource, CpSoftwareClusterResourceToApplicationPartitionMapping, Cp
SoftwareClusterToEcuInstanceMapping, CpSoftwareClusterToResourceMapping, CryptoService
Mapping, DataPrototypeGroup, DataTransformation, DependencyOnArtifact, DiagEventDebounce
Algorithm, DiagnosticConnectedIndicator, DiagnosticDataElement, DiagnosticFunctionInhibitSource,
DiagnosticRoutineSubfunction, DltArgument, DltLogChannel, DltMessage, DoIpInterface, DoIpLogic
Address, DoIpRoutingActivation, ECUMapping, EOCExecutableEntityRefAbstract, EcuPartition, Ecuc
ContainerValue, EcucDefinitionElement, EcucDestinationUriDef, EcucEnumerationLiteralDef, Ecuc
Query, EcucValidationCondition, EndToEndProtection, EthernetWakeupSleepOnDatalineConfig,
ExclusiveArea, ExecutableEntity , ExecutionTime, FMAttributeDef, FMFeatureMapAssertion, FMFeature
MapCondition, FMFeatureMapElement, FMFeatureRelation, FMFeatureRestriction, FMFeatureSelection,
FlatInstanceDescriptor, FlexrayArTpNode, FlexrayTpConnectionControl, FlexrayTpNode, FlexrayTpPdu
Pool, FrameTriggering, GeneralParameter, GlobalTimeGateway, GlobalTimeMaster , GlobalTimeSlave,
HeapUsage, HwAttributeDef, HwAttributeLiteralDef, HwPin, HwPinGroup, IPSecRule, IPv6ExtHeader
FilterList, ISignalToIPduMapping, ISignalTriggering, IdentCaption, InternalTriggeringPoint, J1939Shared
AddressCluster, J1939TpNode, Keyword, LifeCycleState, LinScheduleTable, LinTpNode, Linker, Mac
MulticastGroup, McDataInstance, MemorySection, ModeDeclaration, ModeDeclarationMapping, Mode
SwitchPoint, NetworkEndpoint, NmCluster , NmEcu, NmNode, NvBlockDescriptor, PackageableElement,
ParameterAccess, PduToFrameMapping, PduTriggering, PerInstanceMemory, PhysicalChannel, Port
ElementToCommunicationResourceMapping, PortGroup, PortInterfaceMapping, PossibleErrorReaction,
ResourceConsumption, RootSwCompositionPrototype, RptComponent, RptContainer, RptExecutable
Entity, RptExecutableEntityEvent, RptExecutionContext, RptProfile, RptServicePoint, RunnableEntity
Group, SdgAttribute, SdgClass, SecureCommunicationAuthenticationProps, SecureCommunication
FreshnessProps, SecurityEventContextProps, ServerCallPoint, ServiceNeeds, SignalServiceTranslation
ElementProps, SignalServiceTranslationEventProps, SignalServiceTranslationProps, SocketAddress,
SomeipTpChannel, SpecElementReference, StackUsage, StaticSocketConnection, StructuredReq, Sw
GenericAxisParamType, SwServiceArg, SwcServiceDependency, SwcToApplicationPartitionMapping,
SwcToEcuMapping, SwcToImplMapping, SystemMapping, TDCpSoftwareClusterMapping, TDCp
SoftwareClusterResourceMapping, TcpOptionFilterList, TimingCondition, TimingConstraint, Timing
Description, TimingExtensionResource, TimingModeInstance, TlsCryptoCipherSuite, Topic1, TpAddress,
TraceableTable, TraceableText, TracedFailure, TransformationProps, TransformationTechnology, Trigger,
VariableAccess, VariationPointProxy, ViewMap, VlanConfig, WaitPoint
5

AUTOSAR CP R20-11
4
Class Identifiable (abstract)
adminData AdminData 0..1 aggr This represents the administrative data for the identifiable
object.
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.
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.
Tags:xml.attribute=true
Table D.4: Identifiable
Class Referrable (abstract)

Note Instances of this class can be referred to by their identifier (while adhering to namespace borders).
Base ARObject
5

AUTOSAR CP R20-11
4
Class Referrable (abstract)
Subclasses AtpDefinition, BswDistinguishedPartition, BswModuleCallPoint, BswModuleClientServerEntry, Bsw
VariableAccess, CouplingPortTrafficClassAssignment, DiagnosticDebounceAlgorithmProps, Diagnostic
EnvModeElement, EthernetPriorityRegeneration, EventHandler, ExclusiveAreaNestingOrder, Hw
DescriptionEntity , ImplementationProps, LinSlaveConfigIdent, ModeTransition, MultilanguageReferrable,
PduActivationRoutingGroup, PncMappingIdent, SingleLanguageReferrable, SoConIPduIdentifier, Socket
ConnectionBundle, 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
xml.sequenceOffset=-100
shortName ShortNameFragment * aggr This specifies how the Referrable.shortName is
Fragment composed of several shortNameFragments.
Table D.5: Referrable
Class Unit
Package M2::MSR::AsamHdo::Units
Note This is a physical measurement unit. All units that might be defined should stem from SI units. In order to
convert one unit into another factor and offset are defined.
For the calculation from SI-unit to the defined unit the factor (factorSiToUnit ) and the offset (offsetSiTo
Unit ) are applied as follows:
x [{unit}] := y * [{siUnit}] * factorSiToUnit [[unit]/{siUnit}] + offsetSiToUnit [{unit}]
For the calculation from a unit to SI-unit the reciprocal of the factor (factorSiToUnit ) and the negation of
the offset (offsetSiToUnit ) are applied.
y {siUnit} := (x*{unit} - offsetSiToUnit [{unit}]) / (factorSiToUnit [[unit]/{siUnit}]
Tags:atp.recommendedPackage=Units
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
displayName SingleLanguageUnit 0..1 aggr This specifies how the unit shall be displayed in
Names documents or in user interfaces of tools.The displayName
corresponds to the Unit.Display in an ASAM MCD-2MC
file.
factorSiToUnit Float 0..1 attr This is the factor for the conversion from SI Units to units.
The inverse is used for conversion from units to SI Units.
offsetSiToUnit Float 0..1 attr This is the offset for the conversion from and to siUnits.
physical PhysicalDimension 0..1 ref This association represents the physical dimension to
Dimension which the unit belongs to. Note that only values with units
of the same physical dimensions might be converted.
Table D.6: Unit

Autosar Tps Ecuresourcetemplate

Uploaded by

Copyright:

Available Formats

Autosar Tps Ecuresourcetemplate

Uploaded by

Document Information

Original Description:

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 Ecuresourcetemplate

Uploaded by

Copyright:

Available Formats

Specification of ECU Resource Template

Document Title Specification of ECU Resource

Document Status published

Document Change History

1 of 58 Document ID 60: AUTOSAR_TPS_ECUResourceTemplate

AUTOSAR • Added detailed change history

AUTOSAR • Added Glossary appendix.

AUTOSAR • Document meta information

2 of 58 Document ID 60: AUTOSAR_TPS_ECUResourceTemplate

3 of 58 Document ID 60: AUTOSAR_TPS_ECUResourceTemplate

4 of 58 Document ID 60: AUTOSAR_TPS_ECUResourceTemplate

A.5.1 Micro-controller description . . . . . . . . . . . . . . . . . . . 41

C History of Constraints and Specification Items 51

5 of 58 Document ID 60: AUTOSAR_TPS_ECUResourceTemplate

6 of 58 Document ID 60: AUTOSAR_TPS_ECUResourceTemplate

1.1 Scope of the ECU Resource Template

7 of 58 Document ID 60: AUTOSAR_TPS_ECUResourceTemplate

HW Connections are used to describe connections on several levels:

1.2 Overview ECU Resource Template

Figure 1.1: Overview of ECU Resource template

Modeling elements in the ECU Resource Template can be hierarchically organized.

8 of 58 Document ID 60: AUTOSAR_TPS_ECUResourceTemplate

1.3 Requirements Traceability

9 of 58 Document ID 60: AUTOSAR_TPS_ECUResourceTemplate

Requirement Description Satisfied by

10 of 58 Document ID 60: AUTOSAR_TPS_ECUResourceTemplate

Requirement Description Satisfied by

11 of 58 Document ID 60: AUTOSAR_TPS_ECUResourceTemplate

1.4 Document Conventions

12 of 58 Document ID 60: AUTOSAR_TPS_ECUResourceTemplate

Table 1.1: AUTOSAR

The first rows in the table have the following meaning:

13 of 58 Document ID 60: AUTOSAR_TPS_ECUResourceTemplate

14 of 58 Document ID 60: AUTOSAR_TPS_ECUResourceTemplate

1.5 Requirements Tracing

15 of 58 Document ID 60: AUTOSAR_TPS_ECUResourceTemplate

2 General Hardware Description

16 of 58 Document ID 60: AUTOSAR_TPS_ECUResourceTemplate

+hwElement ARElement +hwPinGroup

+ pinNumber: Integer [0..1]

Describable Describable Describable

Figure 2.1: Overview of ECU Resource template classes

2.1 Hardware Description Entity

17 of 58 Document ID 60: AUTOSAR_TPS_ECUResourceTemplate

Table 2.1: HwDescriptionEntity

[TPS_ECUR_01014] Definition of HwAttributeValue dThe HwAttributeValue

18 of 58 Document ID 60: AUTOSAR_TPS_ECUResourceTemplate

[TPS_ECUR_01003] Values of hardware attributes dThe actual value of a HwAt-

Table 2.2: HwAttributeValue

2.2 Hardware Type

19 of 58 Document ID 60: AUTOSAR_TPS_ECUResourceTemplate

[constr_3511] HwType shall not have a reference to another HwType dA HwType

2.3 Hardware Element

20 of 58 Document ID 60: AUTOSAR_TPS_ECUResourceTemplate

The hardware element can describe several HwElementConnector elements which

Table 2.4: HwElement

2.3.1 Multiple occurrence of Hardware Elements

[TPS_ECUR_01020] Hierarchy of hardware dThe hierarchy of hardware is described

21 of 58 Document ID 60: AUTOSAR_TPS_ECUResourceTemplate