0% found this document useful (0 votes)

362 views

AUTOSAR TPS SystemTemplate

Uploaded by

zhanghuchenhuge

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

362 views

AUTOSAR TPS SystemTemplate

Uploaded by

zhanghuchenhuge

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 2391

System Template

AUTOSAR CP R21-11

Document Title System Template

Document Owner AUTOSAR
Document Responsibility AUTOSAR
Document Identification No 63

Document Status published

Part of AUTOSAR Standard Classic Platform
Part of Standard Release R21-11

Document Change History

Date Release Changed by Description
• Rework of Log and Trace model
• Rework of TLS modeling using IANA
AUTOSAR Parameters
2021-11-25 R21-11 Release • Introduction of Affinity Constraints
Management • Minor corrections / clarifications /
editorial changes; For details please
refer to the ChangeDocumentation
• Added support for 10-BASE-T1S
• Added support for Software Clusters
AUTOSAR • Improved RTE Fan-in and RTE
2020-11-30 R20-11 Release Fan-out description
Management • Introduced modeling approach for
Service Discovery Service Interfaces
on VFB level
• Rework of Ethernet communication
model
• Added support for Signal-To-Service
Translation
AUTOSAR • Added support for IPsec
2019-11-28 R19-11 Release configuration
Management • Minor corrections / clarifications /
editorial changes; For details please
refer to the ChangeDocumentation
• Changed Document Status from
Final to published

1 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• Added support for BusMirorring

• Reworked the modeling of LinSlaves
AUTOSAR • Introduced Crypto Infrastructure for
2018-10-31 4.4.0 Release SecuredIPdu
Management • Minor corrections / clarifications /
editorial changes; For details please
refer to the ChangeDocumentation
AUTOSAR • Minor corrections / clarifications /
2017-12-08 4.3.1 Release editorial changes; For details please
Management refer to the ChangeDocumentation
• Added support for new E2E Profiles
7, 11 and 22
• Improved configuration of Ethernet
AUTOSAR Switch Ports
2016-11-30 4.3.0 Release • Introduced Security Profiles
Management • Minor corrections / clarifications /
editorial changes; For details please
refer to the ChangeDocumentation
AUTOSAR • Minor corrections / clarifications /
2015-07-31 4.2.2 Release editorial changes; For details please
Management refer to the ChangeDocumentation
• Introduction of data transformation
• Introduction of SecuredIPdu
• Introduction of Switch Configuration
AUTOSAR • Introduction of Global Time
2014-10-31 4.2.1 Release Synchronization
Management • Improved support for CanFD
• Minor corrections / clarifications /
editorial changes; For details please
refer to the BWCStatement
AUTOSAR
2014-03-31 4.1.3 Release • Various fixes and clarifications
Management

2 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• Set
CanNmCluster.nmChannelActive,
FlexrayArTpChannel.timeFrIf and
FlexrayArTpChannel.maxFrIf to
deprecated
• Added SoAd Pdu Collection
attributes to SocketConnection
• Added SoAdRouting-
AUTOSAR Group.eventGroupControlType
2013-10-31 4.1.2 Release • Introduced
Management SocketAddress.multicastConnector
• Clarified usage of
ISignal.dataTypePolicy
• Described the handling of
ComSpecs during flattening
• Introduced new Pdu types:
GeneralPurposePdu and
GeneralPurposeIPdu
• Made RootSwCompositionProto-
type.calibrationParameterValueSet
"atpSplitable"
• Made RootSwCompositionProto-
type.flatMap
"atpSplitable"
• Added new Ethernet addressing
attributes to SocketConnection to
help to derive the Ecu Configurations
for the Server and the Clients

3 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• Added support for remote activation

of RunnableEntitys
• Added support VLANs and Service
Discovery
• Reworked the SoAd configuration
• Introduced SenderReceiverComposi-
teElementToSignalMapping and
ClientServerToSignalMapping
• Added support for CAN FD
• Reworked the J1939 TP
AUTOSAR configuration
2013-03-15 4.1.1 • Clarification of the usage of
Administration
swDataDefProps on ISignals and
SystemSignals
• Added support for Complex Drivers
in the Topology
• Updated IPduM to allow only static
part reception
• Added LinSlaveConfig class to the
LinMaster
• Clarified meaning of
PduToFrameMapping.startPosition
• Added support for Partial Networking
• Added support for Complex Drivers
• Added support for new COM transfer
properties
• Added support for transmission
mode switch via
Com_SwitchIpduTxMode COM API
• Added support for treating byte
AUTOSAR arrays with primitive type mapping
2011-12-22 4.0.3
Administration • Added support for partial routing in
signal gateways
• Added support for FlexRay
AUTOSAR TP
• Added rules for creation of Pdu
Triggerings and Pdu Ports
• Explained the general approach of
bit counting

4 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

5 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• Implemented support for LIN 2.1

• Implemented support for Network
Management (FlexRayNm, CanNm,
LinNm, UdpNm)
• adapted IPdu Multiplexer model to
ASAM Fibex 3.1
• Reworked "ECU Extract" chapter
• Introduced "System Extract"
• Introduced EndToEndProtection for
ISignalIPdus
• Reworked "Transport Layer" chapter
• Implemented Variant Handling
concept
AUTOSAR • Implemented Documentation support
2009-12-04 3.1.4 concept
Administration
• Implemented support for J1939
communication
• Implemented support for TTCan
• Implemented support for for TCP/IP
and DoIP.
• Introduced Pdu Counter and Pdu
Replication
• Implemented VMM/AMM concept
• Introduced low-level routing of
NPdu’s
• Implemented support for dynamic
signals
• Introduced PdurIPduGroups
• Clarified semantics of Data
Mappings
• Added inheritance from Identifiable
AUTOSAR
2009-02-04 3.1.2 to PduToFrameMapping
Administration
• Added "FlexRayChannelName"
attribute to FlexRayPhysicalChannel
element.

6 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• Added the boolean attribute

"payloadPreambleIndicator" to the
"FlexrayFrameTriggering".
• Added extension that allows the
assignment of IPduGroups to ECUs.
AUTOSAR
2008-08-13 3.1.1 • Added missing reference from
Administration
"ClientServerComposite-
TypeMapping" to
"ArgumentPrototype"
• Alignment with AUTOSAR IPduM
SWS
• Moved "canAddressingMode"
attribute from "CanCluster" to the
AUTOSAR
2008-02-01 3.0.2 "CanFrameTriggering" element
Administration
• Clarified the descriptions of several
elements and attributes.
• Communication part reworked from
scratch
• Alignment with ECU Configuration
• Added support for Transport
Protocols
AUTOSAR • Major changes in Topology chapter
2007-12-21 3.0.1
Administration after harmonisation with Fibex
(removed complex Topologies)
• Document meta information
extended
• Small layout adaptations made

7 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• Support for Signal Groups added.

• Rework of the Topology Description
• Introduction of PDUs. Description of
the PDU Multiplexer, PDU Gateway.
• FlexRay: multiple transmission of a
frame within one communication
cycle is supported now.
• Removed the concept of Variant
Descriptions (Properties) and
CompToECUMappingConstraints
AUTOSAR relying on the property concept.
2006-11-28 2.1 • Split SwCompToEcuMapping in two
Administration
classes in order to allow separation
of SWC-to-ECU mapping and
Implementation-to-SWC mapping.
• Removed preliminary chapter on
MOST as it is not part of the
standard.
• For all Instance References in the
System Template added diagrams to
the meta-model containing detailed
representations of these references.
AUTOSAR
2005-05-31 1.0 Initial Release
Administration

8 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

9 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-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.

10 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Table of Contents
1 Introduction 26
1.1 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.2 Requirements Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.3 Requirements not fulfilled by TPS requirements . . . . . . . . . . . . . 31
1.4 Methodology for Defining Formal Template . . . . . . . . . . . . . . . . 33
1.5 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
1.6 UML Meta-Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
1.7 Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
1.7.1 Detailed Representation of InstanceRef Associations . . . . 42
1.7.2 Variant Handling . . . . . . . . . . . . . . . . . . . . . . . . . 42
1.7.3 Timing Extensions . . . . . . . . . . . . . . . . . . . . . . . . 42
1.7.4 Documentation Support . . . . . . . . . . . . . . . . . . . . . 42
1.7.5 Stereotype atpSplitable in the System Template . . . . . . . 44
1.8 AUTOSAR System Template and ASAM FIBEX . . . . . . . . . . . . . 44
2 System 46
2.1 Data interpretation of bus content in different contexts . . . . . . . . . 50
2.1.1 Nm NID/CBV . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.2 ClientIdDefinitionSet . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
2.3 InterpolationRoutingMappingSet . . . . . . . . . . . . . . . . . . . . . 51
3 Topology 54
3.1 ECUs and their communication capabilities . . . . . . . . . . . . . . . 55
3.1.1 ECU Instance . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.1.2 Communication Controller . . . . . . . . . . . . . . . . . . . 58
3.1.3 Communication Connector . . . . . . . . . . . . . . . . . . . 59
3.2 Communication Clustering . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.2.1 Communication Cluster . . . . . . . . . . . . . . . . . . . . . 61
3.2.2 Physical Channel . . . . . . . . . . . . . . . . . . . . . . . . 62
3.3 Specialized Attributes of the Topology Entities . . . . . . . . . . . . . . 64
3.3.1 CAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.3.1.1 CAN Cluster . . . . . . . . . . . . . . . . . . . . . . . 66
3.3.1.2 CAN Communication Controller . . . . . . . . . . . . 67
3.3.1.3 CAN Physical Channel . . . . . . . . . . . . . . . . . 71
3.3.1.4 CAN Communication Connector . . . . . . . . . . . 71
3.3.2 TTCAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.3.2.1 TTCAN Cluster . . . . . . . . . . . . . . . . . . . . . 73
3.3.2.2 TTCAN Communication Controller . . . . . . . . . . 74
3.3.2.3 TTCAN Physical Channel . . . . . . . . . . . . . . . 75
3.3.2.4 TTCAN Communication Connector . . . . . . . . . . 75
3.3.3 SAE J1939 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.3.4 FlexRay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
3.3.4.1 FlexRay Cluster . . . . . . . . . . . . . . . . . . . . . 77
3.3.4.2 FlexRay Communication Controller . . . . . . . . . . 79

11 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

3.3.4.3 FlexRay Communication Connector . . . . . . . . . 84

3.3.4.4 FlexRay Physical Channel . . . . . . . . . . . . . . . 84
3.3.5 LIN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
3.3.5.1 LIN Cluster . . . . . . . . . . . . . . . . . . . . . . . 87
3.3.5.2 LIN Communication Controller . . . . . . . . . . . . 87
3.3.5.3 LIN Master . . . . . . . . . . . . . . . . . . . . . . . 88
3.3.5.4 LIN Slave . . . . . . . . . . . . . . . . . . . . . . . . 90
3.3.5.5 LIN Communication Connector . . . . . . . . . . . . 92
3.3.5.6 LIN Physical Channel . . . . . . . . . . . . . . . . . 93
3.3.6 Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
3.3.6.1 Ethernet Cluster . . . . . . . . . . . . . . . . . . . . 96
3.3.6.2 Ethernet Physical Channel . . . . . . . . . . . . . . . 97
3.3.6.3 Ethernet Coupling Elements and Coupling Ports . . 99
3.3.6.4 Ethernet Communication Controller . . . . . . . . . . 106
3.3.6.5 Ethernet Communication Connector . . . . . . . . . 107
3.3.6.6 Ethernet Switch Driver . . . . . . . . . . . . . . . . . 108
3.3.6.7 TcpIp stack configuration properties . . . . . . . . . 121
3.3.6.8 Ethernet wake-up and sleep on dataline . . . . . . . 134
3.3.7 10BASE-T1S Ethernet . . . . . . . . . . . . . . . . . . . . . 144
3.3.8 CDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
3.4 Mapping of Topology Entities onto Hardware Elements . . . . . . . . . 149
3.4.1 ECU Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . 150
3.4.2 Communication Controller Mapping . . . . . . . . . . . . . . 151
3.4.3 HW-Port Mapping . . . . . . . . . . . . . . . . . . . . . . . . 152
4 Top-level Software Composition 153

5 Mapping 155
5.1 Software Component Mapping . . . . . . . . . . . . . . . . . . . . . . . 160
5.1.1 SW Component to ECU Mapping . . . . . . . . . . . . . . . 161
5.1.2 Software Component to Implementation Mapping . . . . . . 165
5.1.3 SW Component to Partition Mapping . . . . . . . . . . . . . 166
5.1.4 Software Component Mapping Constraints . . . . . . . . . . 169
5.1.4.1 ComponentClustering . . . . . . . . . . . . . . . . . 170
5.1.4.2 ComponentSeparation . . . . . . . . . . . . . . . . . 171
5.1.5 J1939 Controller Application Mapping . . . . . . . . . . . . . 173
5.1.6 Affinity Constraints . . . . . . . . . . . . . . . . . . . . . . . . 174
5.1.6.1 RteEvent to OsTaskProxy mapping constraints in the
context of a Software Composition . . . . . . . . . . 177
5.1.6.2 RteEvent to OsTaskProxy mapping constraints in the
context of the System . . . . . . . . . . . . . . . . . 179
5.2 Data Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
5.2.1 Mapping of Variable Data Prototypes on System Signals . . 188
5.2.1.1 Mapping of Variable Data Prototypes with primi-
tive datatypes on System Signals (Sender-Receiver
Communication) . . . . . . . . . . . . . . . . . . . . 191

12 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

5.2.1.2 Mapping of Variable Data Prototypes with composite

datatypes (Sender-Receiver Communication) . . . . 197
5.2.1.3 Mapping of Client Server Operations to System Signals208
5.2.1.4 Mapping of a ApplicationCompositeElementDat-
aPrototype within a composite application data type
on a System Signal (Sender-Receiver Communication)212
5.2.1.5 Mapping of Trigger to SystemSignal . . . . . . . . . 214
5.2.2 Signal Path Constraint . . . . . . . . . . . . . . . . . . . . . . 217
5.2.2.1 CommonSignalPath . . . . . . . . . . . . . . . . . . 218
5.2.2.2 ForbiddenSignalPath . . . . . . . . . . . . . . . . . . 221
5.2.2.3 PermissibleSignalPath . . . . . . . . . . . . . . . . . 222
5.2.2.4 SeparateSignalPath . . . . . . . . . . . . . . . . . . 223
5.3 RTE and basic software resource estimations . . . . . . . . . . . . . . 224
5.4 Communication Management Mapping . . . . . . . . . . . . . . . . . . 227
5.4.1 Partial Networking . . . . . . . . . . . . . . . . . . . . . . . . 228
5.4.1.1 Partial Networking and managed Ethernet switch . . 234
5.4.1.2 Partial Network Gateway . . . . . . . . . . . . . . . . 237
5.4.1.3 Dynamic Partial Network Cluster Mapping . . . . . . 238
5.4.2 Com Management Mapping . . . . . . . . . . . . . . . . . . 241
5.5 Software Cluster Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 242
6 Communication 247
6.1 Triggerings and Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
6.2 ISignals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
6.2.1 Efficient COM for large data . . . . . . . . . . . . . . . . . . 281
6.2.2 Big Endian and Little Endian memory layout of Pdus and
Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
6.3 PDUs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
6.3.1 ContainerIPdu . . . . . . . . . . . . . . . . . . . . . . . . . . 301
6.3.2 SecuredIPdu . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
6.3.2.1 Crypto Infrastructure for SecuredIPdu . . . . . . . . 322
6.3.3 EndToEndProtection for ISignalGroups . . . . . . . . . . . . 329
6.3.4 GeneralPurposeConnection . . . . . . . . . . . . . . . . . . 336
6.4 IPdu Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
6.4.1 Data Filter configuration . . . . . . . . . . . . . . . . . . . . . 342
6.4.2 Cyclic Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . 344
6.4.3 EventControlled Timing . . . . . . . . . . . . . . . . . . . . . 345
6.4.4 Configuration of a trigger for COM_TriggerIPduSend API call 347
6.5 I-Pdu Multiplexer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
6.5.1 I-Pdu Multiplexer in System Extract/ECU Extract . . . . . . . 362
6.6 Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364
6.7 Specialized Attributes of the Communication Entities . . . . . . . . . . 366
6.7.1 FlexRay specific description . . . . . . . . . . . . . . . . . . 366
6.7.2 LIN specific description . . . . . . . . . . . . . . . . . . . . . 372
6.7.2.1 LIN Frames . . . . . . . . . . . . . . . . . . . . . . . 373
6.7.2.2 LIN Schedule Table . . . . . . . . . . . . . . . . . . . 377

13 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.7.2.3 Configuration Services . . . . . . . . . . . . . . . . . 380

6.7.3 CAN specific description . . . . . . . . . . . . . . . . . . . . 385
6.7.3.1 SAE J1939 Protocol specific description . . . . . . . 389
6.7.4 TTCAN specific description . . . . . . . . . . . . . . . . . . . 390
6.7.5 Ethernet specific description . . . . . . . . . . . . . . . . . . 392
6.7.5.1 ApplicationEndpoint . . . . . . . . . . . . . . . . . . 397
6.7.5.2 NetworkEndpoint . . . . . . . . . . . . . . . . . . . . 402
6.7.5.3 SOME/IP Service Instances . . . . . . . . . . . . . . 410
6.7.5.4 Multicast Subscription . . . . . . . . . . . . . . . . . 413
6.7.5.5 ProvidedServiceInstance . . . . . . . . . . . . . . . 417
6.7.5.6 ConsumedServiceInstance . . . . . . . . . . . . . . 431
6.7.5.7 Service Discovery Server Configuration . . . . . . . 443
6.7.5.8 Service Discovery Client Configuration . . . . . . . . 447
6.7.5.9 Group of ConsumedServiceInstances and Provid-
edServiceInstances . . . . . . . . . . . . . . . . . . 451
6.7.5.10 StaticSocketConnection . . . . . . . . . . . . . . . . 452
6.7.5.11 Service Discovery Message Configuration . . . . . . 457
6.7.5.12 NmPdu data exchange over StaticSocketConnection 460
6.7.5.13 Diagnostics over IP . . . . . . . . . . . . . . . . . . . 461
6.7.5.14 Transport Layer Security . . . . . . . . . . . . . . . . 467
6.7.5.15 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 478
6.7.5.16 EthernetFrameType based communication . . . . . . 486
6.7.5.17 Restriction in usage of ProvidedServiceIn-
stance.majorVersion . . . . . . . . . . . . . . . 488
6.8 Transport Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 490
6.8.1 Transport Layer Routing . . . . . . . . . . . . . . . . . . . . . 492
6.8.2 FlexRay ISO Transport Layer . . . . . . . . . . . . . . . . . . 492
6.8.3 FlexRay AUTOSAR Transport Layer . . . . . . . . . . . . . . 499
6.8.4 CAN Transport Layer . . . . . . . . . . . . . . . . . . . . . . 505
6.8.5 LIN Transport Layer . . . . . . . . . . . . . . . . . . . . . . . 510
6.8.6 Ethernet Transport Layer . . . . . . . . . . . . . . . . . . . . 515
6.8.7 SOME/IP segmenter . . . . . . . . . . . . . . . . . . . . . . . 516
6.8.8 SAE J1939 Transport Layer . . . . . . . . . . . . . . . . . . . 519
6.8.9 Unicast TP Example . . . . . . . . . . . . . . . . . . . . . . . 524
6.8.10 Multicast TP Example . . . . . . . . . . . . . . . . . . . . . . 525
6.8.11 Diagnostic Connection . . . . . . . . . . . . . . . . . . . . . 527
6.9 Network Management . . . . . . . . . . . . . . . . . . . . . . . . . . . 531
6.9.1 FlexRay Network Management . . . . . . . . . . . . . . . . . 540
6.9.2 CAN Network Management . . . . . . . . . . . . . . . . . . . 543
6.9.3 UDP Network Management . . . . . . . . . . . . . . . . . . . 546
6.9.4 J1939 Network Management . . . . . . . . . . . . . . . . . . 551
6.9.4.1 J1939SharedAddressCluster . . . . . . . . . . . . . 553
6.9.5 Managed Channels . . . . . . . . . . . . . . . . . . . . . . . 555
6.10 Bus Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 555
6.10.1 CAN Destination Channel . . . . . . . . . . . . . . . . . . . . 557
6.10.2 FlexRay Destination Channel . . . . . . . . . . . . . . . . . . 560

14 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.10.3 Ethernet Destination Channel . . . . . . . . . . . . . . . . . 562

6.10.4 User Defined Destination Channel . . . . . . . . . . . . . . . 563
6.11 Fan-out . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 564
6.11.1 Signal fan-out . . . . . . . . . . . . . . . . . . . . . . . . . . 564
6.11.1.1 RTE fan-out . . . . . . . . . . . . . . . . . . . . . . 564
6.11.1.2 COM Signal Gateway fan-out . . . . . . . . . . . . . 567
6.11.2 Pdu fan-out . . . . . . . . . . . . . . . . . . . . . . . . . . . . 569
6.11.2.1 Pdu Router fan-out . . . . . . . . . . . . . . . . . . 569
6.11.2.2 Flexray Interface fan-out . . . . . . . . . . . . . . . . 569
6.11.3 Frame fan-out . . . . . . . . . . . . . . . . . . . . . . . . . . 570
6.12 Fan-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 570
6.12.1 RTE fan-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . 571
6.12.2 Pdu fan-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . 573
6.12.3 IPdu Container fan-in . . . . . . . . . . . . . . . . . . . . . . 574
6.13 Log and Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 575
6.14 Support of Complex Drivers . . . . . . . . . . . . . . . . . . . . . . . . 579
6.15 MetaData in SenderReceiverInterface . . . . . . . . . . . . . . . . . . 580
6.16 Signal Service Translation . . . . . . . . . . . . . . . . . . . . . . . . . 581
6.16.1 Architectural setup . . . . . . . . . . . . . . . . . . . . . . . . 582
6.16.1.1 Method handling . . . . . . . . . . . . . . . . . . . . 584
6.16.2 Mapping description . . . . . . . . . . . . . . . . . . . . . . . 584
6.16.2.1 Filters and Transmission Triggers . . . . . . . . . . . 589
6.16.2.2 Mapping description from several sources . . . . . . 594
6.16.2.3 Mapping description and data conversion . . . . . . 596
6.16.2.4 Implementation of PassThroughSwConnectors . . 597
6.16.3 Service discovery control . . . . . . . . . . . . . . . . . . . . 598
6.16.3.1 Service control at ECU start . . . . . . . . . . . . . . 600
6.16.3.2 Service control due to availability of partial networks 600
6.16.3.3 Service control due to availability of related service
instance . . . . . . . . . . . . . . . . . . . . . . . . . 602
6.16.4 Translation behavior . . . . . . . . . . . . . . . . . . . . . . . 604
6.16.4.1 COM-Stack translation behavior . . . . . . . . . . . . 604
6.16.4.2 Translation Application Software Component transla-
tion behavior . . . . . . . . . . . . . . . . . . . . . . 605
6.16.5 End-to-End considerations . . . . . . . . . . . . . . . . . . . 606
6.16.5.1 Safety . . . . . . . . . . . . . . . . . . . . . . . . . . 606
6.16.5.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . 609
7 Data Transformation 611
7.1 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 611
7.1.1 Configuration of the Communication Layout . . . . . . . . . . 611
7.1.2 Data Transformation by Software . . . . . . . . . . . . . . . . 612
7.2 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613
7.2.1 Transmission of large composite data types over networks
with large PDUs (e.g Ethernet) . . . . . . . . . . . . . . . . . 613

15 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

7.2.2 Support of transmission from one sender to multiple re-

ceivers with Signal Fan-out . . . . . . . . . . . . . . . . . . . 614
7.2.3 Support of transmission from one sender to multiple re-
ceivers with PDU Fan-out . . . . . . . . . . . . . . . . . . . . 614
7.2.4 Transformer Chaining . . . . . . . . . . . . . . . . . . . . . . 615
7.2.5 Signal Group Based interaction of the transformer with the
Com module . . . . . . . . . . . . . . . . . . . . . . . . . . . 616
7.3 Transformer configuration . . . . . . . . . . . . . . . . . . . . . . . . . 616
7.3.1 Generic Transformer . . . . . . . . . . . . . . . . . . . . . . . 629
7.3.2 SOME/IP Transformer . . . . . . . . . . . . . . . . . . . . . . 630
7.3.2.1 Handling of Strings . . . . . . . . . . . . . . . . . . . 636
7.3.2.2 SOME/IP Transformation Properties on the level of
DataPrototypes . . . . . . . . . . . . . . . . . . . . . 637
7.3.2.3 Network Representation . . . . . . . . . . . . . . . . 646
7.3.3 COM Based Transformer . . . . . . . . . . . . . . . . . . . . 655
7.3.4 E2E Transformer . . . . . . . . . . . . . . . . . . . . . . . . . 658
7.3.4.1 E2E state machine settings . . . . . . . . . . . . . . 671
7.3.4.2 E2E recommended configuration settings . . . . . . 671
7.3.5 UserDefined Transformer . . . . . . . . . . . . . . . . . . . . 680
7.3.6 Support for TLV Encoding . . . . . . . . . . . . . . . . . . . . 681
7.3.6.1 Assignment of TLV Data Ids . . . . . . . . . . . . . . 681
7.3.6.2 Assignment of TLV Wire Type . . . . . . . . . . . . . 686
8 Gateways 688
8.1 Frame Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 690
8.2 IPdu Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 691
8.2.1 Usage of IPduMapping.pduMaxLength . . . . . . . . . . . 693
8.2.2 Routing and processing of Diagnostics Pdus . . . . . . . . . 696
8.3 Signal Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 697
8.3.1 Partial Signal Group Mapping . . . . . . . . . . . . . . . . . . 698
9 Global Time Synchronization 700
9.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 700
9.2 The big Picture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 701
9.3 Detailed Description of Global Time Synchronization . . . . . . . . . . 712
9.3.1 Time Synchronization over CAN . . . . . . . . . . . . . . . . 713
9.3.2 Time Synchronization over Ethernet . . . . . . . . . . . . . . 715
9.3.2.1 Time Synchronization and Ethernet propagation delay 719
9.3.2.2 Time Synchronization and Ethernet connection . . . 719
9.3.2.3 Time Synchronization and managed Ethernet switch 720
9.3.3 Time Synchronization over FlexRay . . . . . . . . . . . . . . 724
9.3.4 Time Synchronization by user defined Timebase Provider . . 726
9.3.5 Time Synchronization Common Properties . . . . . . . . . . 727
10 Description of Service Discovery Services in Classic Platform 729
10.1 Representation of Service Interfaces on VFB level . . . . . . . . . . . 729
10.1.1 Representation of Events . . . . . . . . . . . . . . . . . . . 730

16 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

10.1.2 Representation of Methods . . . . . . . . . . . . . . . . . . . 730

10.1.3 Representation of Fire and Forget Methods . . . . . . . . . 730
10.1.4 Representation of Fields . . . . . . . . . . . . . . . . . . . 731
10.2 Representation of Service Interfaces on network level . . . . . . . . . 733
11 Software Cluster 738
11.1 Big Picture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 738
11.2 Software Cluster Resources . . . . . . . . . . . . . . . . . . . . . . . . 746
11.3 Software Cluster Binary Manifest . . . . . . . . . . . . . . . . . . . . . 754
11.4 Software Cluster Extraction . . . . . . . . . . . . . . . . . . . . . . . . 769
11.4.1 Software Cluster Extraction and DataMappings . . . . . . . . 772
12 Usage of the System Template 774
12.1 System Constraint Description . . . . . . . . . . . . . . . . . . . . . . . 775
12.2 Abstract System Description . . . . . . . . . . . . . . . . . . . . . . . . 776
13 System Extract of the System Configuration Description 778
13.1 OEM/Supplier Collaboration Scenario . . . . . . . . . . . . . . . . . . 779
13.2 Data Mapping in the System Extract . . . . . . . . . . . . . . . . . . . 781
13.3 SW component inclusion and top level data mapping . . . . . . . . . . 784
13.4 Port-Interface Mapping in the System Extract . . . . . . . . . . . . . . 786
14 ECU Extract of the System Configuration Description 787
14.1 Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 789
14.2 Top-level Software Composition . . . . . . . . . . . . . . . . . . . . . . 789
14.2.1 ECU Flat view . . . . . . . . . . . . . . . . . . . . . . . . . . 792
14.2.2 Internal Communication . . . . . . . . . . . . . . . . . . . . . 792
14.2.3 External Communication . . . . . . . . . . . . . . . . . . . . 794
14.2.4 Port Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . 799
14.2.5 Service Needs . . . . . . . . . . . . . . . . . . . . . . . . . . 800
14.3 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 801
14.3.1 Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 801
14.3.2 PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 802
14.3.3 ISignals and ISignalGroups . . . . . . . . . . . . . . . . . . . 802
14.3.4 SystemSignal and SystemSignalGroup . . . . . . . . . . . . 803
14.3.5 Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 803
14.3.6 TP configuration . . . . . . . . . . . . . . . . . . . . . . . . . 804
14.3.7 NM configuration . . . . . . . . . . . . . . . . . . . . . . . . . 804
14.4 Naming Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 804
14.4.1 Package Structure . . . . . . . . . . . . . . . . . . . . . . . . 804
14.4.2 Naming of Measurement and Calibration Data . . . . . . . . 805
14.4.3 Naming of Derived Elements . . . . . . . . . . . . . . . . . . 806
14.4.4 Re-use of short names assigned in previous iterations . . . . 807
14.5 ECU Extract in subsequent Cycles of Iterative Development . . . . . . 807
14.5.1 Traceability of model elements created in ECU Extract . . . . 807
14.5.2 Mapping of AUTOSAR attributes to ASAM ASAP2 . . . . . . 812

17 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

14.5.3 Assigning communication graphs to RTE Implementation

Plug-Ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 813
14.6 Variant Handling in ECU Extract . . . . . . . . . . . . . . . . . . . . . . 816
14.6.1 System Constants . . . . . . . . . . . . . . . . . . . . . . . . 816
14.6.2 Nested Whole/Part class variants . . . . . . . . . . . . . . . 817
14.6.3 Multiple instances of calibration parameters in system scope 817
15 Supported special use-cases 819
15.1 Support of sending / receiving same Can/Flexray Frame on same chan-
nel (Pdu Gateway Use-Case) . . . . . . . . . . . . . . . . . . . . . . . 819
15.2 Support of sending / receiving same Can/Flexray Frame on same chan-
nel (bidirectional routing in COM) . . . . . . . . . . . . . . . . . . . . . 820
15.3 Support of dynamic CAN IDs . . . . . . . . . . . . . . . . . . . . . . . 823
15.4 N:1 Sender Receiver communication description in a System Extract
over one PhysicalChannel . . . . . . . . . . . . . . . . . . . . . . . 823
15.5 Description of MOST Functions . . . . . . . . . . . . . . . . . . . . . . 826
A Glossary 828

B Detailed Representation of InstanceRef Associations in the System Template 832

B.1 Usage of InstanceRefs in Data Mapping diagrams . . . . . . . . . . . . 832
B.2 Usage of InstanceRefs in SW Mapping diagrams . . . . . . . . . . . . 833
B.3 Usage of InstanceRefs in Signal Path Constraint diagrams . . . . . . . 834
B.4 Usage of InstanceRefs in PncMapping . . . . . . . . . . . . . . . . . . 834
B.5 Usage of InstanceRefs in ComManagementMapping . . . . . . . . . . 835
B.6 "SWC in System" InstanceRef . . . . . . . . . . . . . . . . . . . . . . . 836
B.7 "Operation in System" InstanceRef . . . . . . . . . . . . . . . . . . . . 838
B.8 "VariableDataPrototype" InstanceRef . . . . . . . . . . . . . . . . . . . 840
B.9 "PortGroup in System" InstanceRef . . . . . . . . . . . . . . . . . . . . 844
B.10 "DataPrototype in PortInterface" InstanceRef . . . . . . . . . . . . . . 846
C Harmonization between Upstream Templates and ECU Configuration 848
C.1 ComStack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 849
C.1.1 Com Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . 849
C.1.2 LdCom Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 917
C.1.3 IPduM Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 924
C.1.4 SecOc Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 971
C.1.5 PduR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1013
C.1.6 Nm Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 1033
C.1.7 EcuC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1051
C.1.8 ComM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1069
C.1.9 Xcp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1091
C.1.10 Bus Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . 1116
C.2 Can . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1154
C.2.1 Can Driver Mapping . . . . . . . . . . . . . . . . . . . . . . . 1154
C.2.2 Can Interface Mapping . . . . . . . . . . . . . . . . . . . . . 1190
C.2.3 Can Transceiver Mapping . . . . . . . . . . . . . . . . . . . . 1241

18 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

C.2.4 CanNm Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 1259

C.2.5 CanTp Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 1287
C.2.6 CanSm Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 1311
C.3 J1939 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1321
C.3.1 J1939Tp Mapping . . . . . . . . . . . . . . . . . . . . . . . . 1321
C.3.2 J1939Nm Mapping . . . . . . . . . . . . . . . . . . . . . . . . 1344
C.3.3 J1939Dcm Mapping . . . . . . . . . . . . . . . . . . . . . . . 1355
C.3.4 J1939Rm Mapping . . . . . . . . . . . . . . . . . . . . . . . . 1356
C.4 FlexRay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1362
C.4.1 FlexRay Driver Mapping . . . . . . . . . . . . . . . . . . . . . 1362
C.4.2 FlexRay Interface Mapping . . . . . . . . . . . . . . . . . . . 1386
C.4.3 FrNm Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . 1435
C.4.4 FrTp Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . 1463
C.4.5 FrArTp Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 1480
C.4.6 FrSM Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . 1498
C.5 Lin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1507
C.5.1 Lin Driver Mapping . . . . . . . . . . . . . . . . . . . . . . . . 1507
C.5.2 Lin Interface Mapping . . . . . . . . . . . . . . . . . . . . . . 1514
C.5.3 LinTp Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . 1547
C.6 Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1557
C.6.1 Ethernet Driver Mapping . . . . . . . . . . . . . . . . . . . . 1557
C.6.2 Ethernet Interface Mapping . . . . . . . . . . . . . . . . . . . 1585
C.6.3 Ethernet Switch Driver Mapping . . . . . . . . . . . . . . . . 1612
C.6.4 Service Discovery . . . . . . . . . . . . . . . . . . . . . . . . 1660
C.6.5 SoAd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1703
C.6.6 EthSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1742
C.6.7 EthTrcv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1746
C.6.8 TcpIp . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1775
C.6.9 DoIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1901
C.6.10 UdpNm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1934
C.6.11 SomeIpTp . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1961
C.6.12 Wireless Ethernet Driver Mapping . . . . . . . . . . . . . . . 1969
C.7 Diagnostic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1975
C.7.1 Dcm Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . 1975
C.8 Time management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1976
C.8.1 StbM Time Management . . . . . . . . . . . . . . . . . . . . 1976
C.8.2 CAN Time Management . . . . . . . . . . . . . . . . . . . . . 1994
C.8.3 Ethernet Time Management . . . . . . . . . . . . . . . . . . 2015
C.8.4 Flexray Time Management . . . . . . . . . . . . . . . . . . . 2043
C.9 Crypto Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2060
C.9.1 CryptoDriver . . . . . . . . . . . . . . . . . . . . . . . . . . . 2060
C.9.2 Crypto Service Manager . . . . . . . . . . . . . . . . . . . . 2089
C.10 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2232
C.10.1 Transformer General . . . . . . . . . . . . . . . . . . . . . . . 2232
C.11 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2234
C.11.1 Log and Trace . . . . . . . . . . . . . . . . . . . . . . . . . . 2234

19 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

C.11.2 ECU State Manager . . . . . . . . . . . . . . . . . . . . . . . 2242

D History of Constraints and Specification Items 2243
D.1 Constraint and Specification Item History of this document according
to AUTOSAR R4.0.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2243
D.1.1 Changed Constraints in R4.0.1 . . . . . . . . . . . . . . . . . 2243
D.1.2 Added Constraints in R4.0.1 . . . . . . . . . . . . . . . . . . 2243
D.1.3 Deleted Constraints in R4.0.1 . . . . . . . . . . . . . . . . . . 2243
D.2 Constraint and Specification Item History of this document according
to AUTOSAR R4.0.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2243
D.2.1 Changed Constraints in R4.0.2 . . . . . . . . . . . . . . . . . 2243
D.2.2 Added Constraints in R4.0.2 . . . . . . . . . . . . . . . . . . 2244
D.2.3 Deleted Constraints in R4.0.2 . . . . . . . . . . . . . . . . . . 2244
D.3 Constraint and Specification Item History of this document according
to AUTOSAR R4.0.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2244
D.3.1 Changed Constraints in R4.0.3 . . . . . . . . . . . . . . . . . 2244
D.3.2 Changed Traceables in R4.0.3 . . . . . . . . . . . . . . . . . 2244
D.3.3 Added Constraints in R4.0.3 . . . . . . . . . . . . . . . . . . 2244
D.3.4 Added Traceables in R4.0.3 . . . . . . . . . . . . . . . . . . . 2244
D.3.5 Deleted Constraints in R4.0.3 . . . . . . . . . . . . . . . . . . 2245
D.3.6 Deleted Traceables in R4.0.3 . . . . . . . . . . . . . . . . . . 2245
D.4 Constraint and Specification Item History of this document according
to AUTOSAR R4.1.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2245
D.4.1 Changed Constraints in R4.1.1 . . . . . . . . . . . . . . . . . 2245
D.4.2 Changed Traceables in R4.1.1 . . . . . . . . . . . . . . . . . 2245
D.4.3 Added Constraints in R4.1.1 . . . . . . . . . . . . . . . . . . 2245
D.4.4 Added Traceables in R4.1.1 . . . . . . . . . . . . . . . . . . . 2247
D.4.5 Deleted Constraints in R4.1.1 . . . . . . . . . . . . . . . . . . 2250
D.4.6 Deleted Traceables in R4.1.1 . . . . . . . . . . . . . . . . . . 2250
D.5 Constraint and Specification Item History of this document according
to AUTOSAR R4.1.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2250
D.5.1 Changed Traceables in R4.1.2 . . . . . . . . . . . . . . . . . 2250
D.5.2 Added Traceables in R4.1.2 . . . . . . . . . . . . . . . . . . . 2250
D.5.3 Added Constraints in R4.1.2 . . . . . . . . . . . . . . . . . . 2251
D.5.4 Changed Constraints in R4.1.2 . . . . . . . . . . . . . . . . . 2251
D.5.5 Deleted Constraints in R4.1.2 . . . . . . . . . . . . . . . . . . 2251
D.6 Constraint and Specification Item History of this document according
to AUTOSAR R4.1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2252
D.6.1 Changed Traceables in R4.1.3 . . . . . . . . . . . . . . . . . 2252
D.6.2 Added Traceables in R4.1.3 . . . . . . . . . . . . . . . . . . . 2252
D.6.3 Deleted Traceables in R4.1.3 . . . . . . . . . . . . . . . . . . 2252
D.6.4 Added Constraints in R4.1.3 . . . . . . . . . . . . . . . . . . 2252
D.6.5 Changed Constraints in R4.1.3 . . . . . . . . . . . . . . . . . 2253
D.6.6 Deleted Constraints in R4.1.3 . . . . . . . . . . . . . . . . . . 2253
D.7 Constraint and Specification Item History of this document according
to AUTOSAR R4.2.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2253

20 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

D.7.1 Added Traceables in R4.2.1 . . . . . . . . . . . . . . . . . . . 2253

D.7.2 Changed Traceables in R4.2.1 . . . . . . . . . . . . . . . . . 2255
D.7.3 Deleted Traceables in R4.2.1 . . . . . . . . . . . . . . . . . . 2255
D.7.4 Added Constraints in R4.2.1 . . . . . . . . . . . . . . . . . . 2256
D.7.5 Changed Constraints in R4.2.1 . . . . . . . . . . . . . . . . . 2259
D.7.6 Deleted Constraints in R4.2.1 . . . . . . . . . . . . . . . . . . 2259
D.8 Constraint and Specification Item History of this document according
to AUTOSAR R4.2.2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2259
D.8.1 Added Traceables in R4.2.2 . . . . . . . . . . . . . . . . . . . 2259
D.8.2 Changed Traceables in R4.2.2 . . . . . . . . . . . . . . . . . 2260
D.8.3 Deleted Traceables in R4.2.2 . . . . . . . . . . . . . . . . . . 2261
D.8.4 Added Constraints in R4.2.2 . . . . . . . . . . . . . . . . . . 2261
D.8.5 Changed Constraints in R4.2.2 . . . . . . . . . . . . . . . . . 2262
D.8.6 Deleted Constraints in R4.2.2 . . . . . . . . . . . . . . . . . . 2263
D.9 Constraint and Specification Item History of this document according
to AUTOSAR R4.3.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2263
D.9.1 Added Traceables in R4.3.0 . . . . . . . . . . . . . . . . . . . 2263
D.9.2 Changed Traceables in R4.3.0 . . . . . . . . . . . . . . . . . 2265
D.9.3 Deleted Traceables in R4.3.0 . . . . . . . . . . . . . . . . . . 2265
D.9.4 Added Constraints in R4.3.0 . . . . . . . . . . . . . . . . . . 2266
D.9.5 Changed Constraints in R4.3.0 . . . . . . . . . . . . . . . . . 2268
D.9.6 Deleted Constraints in R4.3.0 . . . . . . . . . . . . . . . . . . 2270
D.10 Constraint and Specification Item History of this document according
to AUTOSAR R4.3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2270
D.10.1 Added Traceables in R4.3.1 . . . . . . . . . . . . . . . . . . . 2270
D.10.2 Changed Traceables in R4.3.1 . . . . . . . . . . . . . . . . . 2271
D.10.3 Deleted Traceables in R4.3.1 . . . . . . . . . . . . . . . . . . 2271
D.10.4 Added Constraints in R4.3.1 . . . . . . . . . . . . . . . . . . 2272
D.10.5 Changed Constraints in R4.3.1 . . . . . . . . . . . . . . . . . 2272
D.10.6 Deleted Constraints in R4.3.1 . . . . . . . . . . . . . . . . . . 2273
D.11 Constraint and Specification Item History of this document according
to AUTOSAR R4.4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2273
D.11.1 Added Traceables in R4.4.0 . . . . . . . . . . . . . . . . . . . 2273
D.11.2 Changed Traceables in R4.4.0 . . . . . . . . . . . . . . . . . 2274
D.11.3 Deleted Traceables in R4.4.0 . . . . . . . . . . . . . . . . . . 2275
D.11.4 Added Constraints in R4.4.0 . . . . . . . . . . . . . . . . . . 2275
D.11.5 Changed Constraints in R4.4.0 . . . . . . . . . . . . . . . . . 2277
D.11.6 Deleted Constraints in R4.4.0 . . . . . . . . . . . . . . . . . . 2277
D.12 Constraint and Specification Item History of this document according
to AUTOSAR R19-11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2278
D.12.1 Added Traceables in R19-11 . . . . . . . . . . . . . . . . . . 2278
D.12.2 Changed Traceables in R19-11 . . . . . . . . . . . . . . . . . 2281
D.12.3 Deleted Traceables in R19-11 . . . . . . . . . . . . . . . . . 2282
D.12.4 Added Constraints in R19-11 . . . . . . . . . . . . . . . . . . 2283
D.12.5 Changed Constraints in R19-11 . . . . . . . . . . . . . . . . 2285
D.12.6 Deleted Constraints in R19-11 . . . . . . . . . . . . . . . . . 2286

21 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

D.13 Constraint and Specification Item History of this document according

to AUTOSAR R20-11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2287
D.13.1 Added Traceables in R20-11 . . . . . . . . . . . . . . . . . . 2287
D.13.2 Changed Traceables in R20-11 . . . . . . . . . . . . . . . . . 2291
D.13.3 Deleted Traceables in R20-11 . . . . . . . . . . . . . . . . . 2291
D.13.4 Added Constraints in R20-11 . . . . . . . . . . . . . . . . . . 2291
D.13.5 Changed Constraints in R20-11 . . . . . . . . . . . . . . . . 2296
D.13.6 Deleted Constraints in R20-11 . . . . . . . . . . . . . . . . . 2297
D.14 Constraint and Specification Item History of this document according
to AUTOSAR R21-11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2298
D.14.1 Added Traceables in R21-11 . . . . . . . . . . . . . . . . . . 2298
D.14.2 Changed Traceables in R21-11 . . . . . . . . . . . . . . . . . 2299
D.14.3 Deleted Traceables in R21-11 . . . . . . . . . . . . . . . . . 2301
D.14.4 Added Constraints in R21-11 . . . . . . . . . . . . . . . . . . 2301
D.14.5 Changed Constraints in R21-11 . . . . . . . . . . . . . . . . 2303
D.14.6 Deleted Constraints in R21-11 . . . . . . . . . . . . . . . . . 2304
E Mentioned Class Tables 2306

F Splitable Elements in the Scope of this Document 2385

G Variation Points in the Scope of this Document 2388

22 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

References
[1] Requirements on System Template
AUTOSAR_RS_SystemTemplate
[2] Generic Structure Template
AUTOSAR_TPS_GenericStructureTemplate
[3] AUTOSAR XML Schema Production Rules
AUTOSAR_TPS_XMLSchemaProductionRules
[4] Methodology for Classic Platform
AUTOSAR_TR_Methodology
[5] Software Component Template
AUTOSAR_TPS_SoftwareComponentTemplate
[6] Specification of ECU Resource Template
AUTOSAR_TPS_ECUResourceTemplate
[7] Standardization Template
AUTOSAR_TPS_StandardizationTemplate
[8] Specification of Timing Extensions
AUTOSAR_TPS_TimingExtensions
[9] ASAM Fibex – Field Bus Exchange Format, Version 3.1
http://www.asam.net
[10] ISO 17987:2016 (all parts), Road vehicles – Local Interconnect Network (LIN)
http://www.iso.org
[11] CAN specifications
http://www.can-cia.org
[12] MOST Specification, Version 2.5
http://www.mostnet.de
[13] FlexRay Protocol Specification
http://www.flexray.com
[14] Serial Data Communications between Microcomputer Systems in heavy-duty Ve-
hicle Applications
[15] Layered Software Architecture
AUTOSAR_EXP_LayeredSoftwareArchitecture
[16] Specification of LIN Interface
AUTOSAR_SWS_LINInterface
[17] OPEN Sleep/Wake-up Specification for Automotive Ethernet
http://www.opensig.org/Automotive-Ethernet-Specifications/

23 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[18] Specification of COM Based Transformer

AUTOSAR_SWS_COMBasedTransformer
[19] SOME/IP Protocol Specification
AUTOSAR_PRS_SOMEIPProtocol
[20] Basic Software Module Description Template
AUTOSAR_TPS_BSWModuleDescriptionTemplate
[21] ASAM MCD 2MC ASAP2 Interface Specification
http://www.asam.net
ASAP2-V1.51.pdf
[22] Specification of Communication
AUTOSAR_SWS_COM
[23] Specification of SW-C End-to-End Communication Protection Library
AUTOSAR_SWS_E2ELibrary
[24] Specification of I-PDU Multiplexer
AUTOSAR_SWS_IPDUMultiplexer
[25] SAE J1939-21 Data Link Layer
[26] SOME/IP Service Discovery Protocol Specification
AUTOSAR_PRS_SOMEIPServiceDiscoveryProtocol
[27] Specification of Service Discovery
AUTOSAR_SWS_ServiceDiscovery
[28] Specification of Diagnostic over IP
AUTOSAR_SWS_DiagnosticOverIP
[29] Transport Layer Security (TLS) Parameters
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
[30] Record Size Limit Extension for TLS
https://tools.ietf.org/html/rfc8449
[31] Specification of Cryptography
AUTOSAR_SWS_Cryptography
[32] Road vehicles – Diagnostics on Controller Area Networks (CAN) – Part2: Network
layer services
[33] Specification of Manifest
AUTOSAR_TPS_ManifestSpecification
[34] Specification of Communication Manager
AUTOSAR_SWS_COMManager
[35] Specification of Secure Onboard Communication
AUTOSAR_SWS_SecureOnboardCommunication

24 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[36] Specification of TCP/IP Stack

AUTOSAR_SWS_TcpIp
[37] Specification of RTE Software
AUTOSAR_SWS_RTE
[38] Specification of Module E2E Transformer
AUTOSAR_SWS_E2ETransformer
[39] Specification of CRC Routines
AUTOSAR_SWS_CRCLibrary
[40] E2E Protocol Specification
AUTOSAR_PRS_E2EProtocol
[41] Specification of Synchronized Time-Base Manager
AUTOSAR_SWS_SynchronizedTimeBaseManager
[42] Specification of Time Synchronization over Ethernet
AUTOSAR_SWS_TimeSyncOverEthernet
[43] Software Process Engineering Meta-Model Specification
http://www.omg.org/spec/SPEM/2.0/

25 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

1 Introduction

1.1 Abbreviations

26 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Table 1.1: Abbreviations used in the scope of this Document

27 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

1.2 Requirements Tracing

The following table references the requirements specified in [1] and links to the fulfill-
ment of these.
Requirement Description Satisfied by
[RS_SYST_00001] Mixed Systems (AUTOSAR/ [TPS_SYST_01063] [TPS_SYST_05000]
NON-AUTOSAR)
[RS_SYST_00002] Basic Software Resources and [TPS_SYST_01126]
RTE Resources
[RS_SYST_00003] Iterative Development [TPS_SYST_01000] [TPS_SYST_01002]
[TPS_SYST_01003]
[RS_SYST_00006] Compatibility between the [TPS_SYST_01017] [TPS_SYST_01019]
AUTOSAR Templates
[RS_SYST_00007] Mapping of Software Components [TPS_SYST_01001] [TPS_SYST_01020]
to ECUs [TPS_SYST_01021] [TPS_SYST_01022]
[TPS_SYST_02114]
[RS_SYST_00008] SWC Cluster [TPS_SYST_01024] [TPS_SYST_01025]
[RS_SYST_00009] SWC Separation [TPS_SYST_01026] [TPS_SYST_01045]
[RS_SYST_00013] Topology [TPS_SYST_01004] [TPS_SYST_01005]
[TPS_SYST_01006] [TPS_SYST_01007]
[TPS_SYST_01008] [TPS_SYST_01009]
[TPS_SYST_01010] [TPS_SYST_01011]
[TPS_SYST_01013] [TPS_SYST_01014]
[TPS_SYST_01015]
[RS_SYST_00014] Data Segmentation [TPS_SYST_01099] [TPS_SYST_01100]
[TPS_SYST_01101] [TPS_SYST_01102]
[TPS_SYST_01103] [TPS_SYST_01104]
[TPS_SYST_01105] [TPS_SYST_01106]
[TPS_SYST_02156] [TPS_SYST_02190]
[TPS_SYST_02191] [TPS_SYST_02192]
[TPS_SYST_02193]
[RS_SYST_00016] Dedicated physical connections [TPS_SYST_01043]
[RS_SYST_00017] Mapping of signals to the same [TPS_SYST_01041]
physical line
[RS_SYST_00018] Mapping of signals to different [TPS_SYST_01044]
physical lines
[RS_SYST_00019] Mapping of signals to a specific [TPS_SYST_01043]
physical line
[RS_SYST_00020] Exclusion of signals from a specific [TPS_SYST_01042]
physical line
[RS_SYST_00021] ECU Communication via CAN [TPS_SYST_01130]
[RS_SYST_00022] ECU Communication via LIN [TPS_SYST_01012] [TPS_SYST_01129]
[TPS_SYST_02101] [TPS_SYST_02257]
[TPS_SYST_05018] [TPS_SYST_05019]
[RS_SYST_00024] ECU Communication via FlexRay [TPS_SYST_01085] [TPS_SYST_01128]
[RS_SYST_00025] Derivation of COM Stack [TPS_SYST_01030]
Configuration Parameters from the
System Template
[RS_SYST_00027] ECU Extract generation rules [TPS_SYST_01000] [TPS_SYST_01002]
[TPS_SYST_01003] [TPS_SYST_01016]
[RS_SYST_00028] IPdu End-to-End Communication [TPS_SYST_01070] [TPS_SYST_01071]
Protection support [TPS_SYST_01072] [TPS_SYST_01073]
[TPS_SYST_01074]
[RS_SYST_00029] Dynamic length signals [TPS_SYST_01065]
5

28 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Requirement Description Satisfied by
[RS_SYST_00031] Distribution of Application and [TPS_SYST_01023]
Vehicle Mode Requests
[RS_SYST_00033] Software-to-ECU mapping variants [TPS_SYST_01001]
[RS_SYST_00037] Timing properties [TPS_SYST_01075] [TPS_SYST_01076]
[TPS_SYST_01077]
[RS_SYST_00038] Support of SAE J1939 Protocol [TPS_SYST_01106] [TPS_SYST_01132]
Features [TPS_SYST_02107] [TPS_SYST_02108]
[TPS_SYST_02109] [TPS_SYST_02190]
[TPS_SYST_02191] [TPS_SYST_02192]
[TPS_SYST_02193]
[RS_SYST_00039] ECU Communication via Ethernet [TPS_SYST_01086] [TPS_SYST_01088]
[TPS_SYST_01089] [TPS_SYST_01090]
[TPS_SYST_01091] [TPS_SYST_01094]
[TPS_SYST_01095] [TPS_SYST_01096]
[TPS_SYST_01097] [TPS_SYST_01098]
[TPS_SYST_01108] [TPS_SYST_01131]
[TPS_SYST_02156] [TPS_SYST_02217]
[TPS_SYST_02218] [TPS_SYST_02219]
[TPS_SYST_02220] [TPS_SYST_02221]
[TPS_SYST_02222] [TPS_SYST_02223]
[TPS_SYST_02224] [TPS_SYST_02225]
[TPS_SYST_02226] [TPS_SYST_02227]
[TPS_SYST_02228] [TPS_SYST_02229]
[TPS_SYST_02232] [TPS_SYST_02233]
[TPS_SYST_02234] [TPS_SYST_02235]
[TPS_SYST_02236] [TPS_SYST_02237]
[TPS_SYST_02238] [TPS_SYST_02239]
[TPS_SYST_02240] [TPS_SYST_02241]
[TPS_SYST_02242] [TPS_SYST_02243]
[TPS_SYST_02244] [TPS_SYST_02245]
[TPS_SYST_02247] [TPS_SYST_02248]
[TPS_SYST_02302]
[RS_SYST_00042] Support for Partial Networking [TPS_SYST_01133] [TPS_SYST_03073]
[RS_SYST_00043] Communication via Complex [TPS_SYST_01115]
Drivers
[RS_SYST_00044] Description of custom bus systems [TPS_SYST_01127]
[RS_SYST_00045] Co-existing System artifacts in the [TPS_SYST_03000]
same model
[RS_SYST_00047] Network and physical [TPS_SYST_01062] [TPS_SYST_01063]
representation on signal level
[RS_SYST_00048] CAN with Flexible Data-Rate [TPS_SYST_01154]
[RS_SYST_00049] Support of Efficient COM for large [TPS_SYST_02015] [TPS_SYST_02016]
data configuration [TPS_SYST_02017] [TPS_SYST_02018]
[TPS_SYST_02019] [TPS_SYST_02020]
[TPS_SYST_02021] [TPS_SYST_02022]
[TPS_SYST_02023] [TPS_SYST_02024]
[TPS_SYST_02025] [TPS_SYST_02026]
[TPS_SYST_02027] [TPS_SYST_02028]
[TPS_SYST_02164] [TPS_SYST_03001]
[RS_SYST_00050] Data transformation of inter-ECU [TPS_SYST_02030] [TPS_SYST_02031]
communication [TPS_SYST_02032] [TPS_SYST_02033]
[TPS_SYST_02034] [TPS_SYST_02035]
[TPS_SYST_02036] [TPS_SYST_02037]
[TPS_SYST_02038] [TPS_SYST_02039]
[TPS_SYST_02040] [TPS_SYST_02041]
[TPS_SYST_02042] [TPS_SYST_02044]
[TPS_SYST_02045] [TPS_SYST_02046]
[TPS_SYST_02047] [TPS_SYST_02048]
5

29 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Requirement Description Satisfied by
4
[TPS_SYST_02049] [TPS_SYST_02050]
[TPS_SYST_02051] [TPS_SYST_02052]
[TPS_SYST_02053] [TPS_SYST_02054]
[TPS_SYST_02055] [TPS_SYST_02056]
[TPS_SYST_02057] [TPS_SYST_02074]
[TPS_SYST_02075] [TPS_SYST_02080]
[TPS_SYST_02092] [TPS_SYST_02093]
[TPS_SYST_02094] [TPS_SYST_02121]
[TPS_SYST_02123] [TPS_SYST_02124]
[TPS_SYST_02125] [TPS_SYST_02126]
[TPS_SYST_02127] [TPS_SYST_02128]
[TPS_SYST_02129] [TPS_SYST_02130]
[TPS_SYST_02131] [TPS_SYST_02132]
[TPS_SYST_02156] [TPS_SYST_02195]
[TPS_SYST_02212] [TPS_SYST_02213]
[TPS_SYST_02214] [TPS_SYST_02359]
[TPS_SYST_02360]
[RS_SYST_00051] Support of COM Based Data [TPS_SYST_02058]
Transformation
[RS_SYST_00052] Ethernet Switch Configuration [TPS_SYST_03002] [TPS_SYST_03003]
[TPS_SYST_03004] [TPS_SYST_03005]
[TPS_SYST_03006] [TPS_SYST_03007]
[TPS_SYST_03008] [TPS_SYST_03009]
[TPS_SYST_03010] [TPS_SYST_03011]
[TPS_SYST_03013]
[RS_SYST_00053] The System Template shall provide [TPS_SYST_05015]
the ability to define naming
conventions for public symbols
[RS_SYST_00054] Support of Secured Pdus [TPS_SYST_02059] [TPS_SYST_02060]
[TPS_SYST_02148] [TPS_SYST_02149]
[TPS_SYST_02152] [TPS_SYST_02153]
[TPS_SYST_02154] [TPS_SYST_02171]
[TPS_SYST_02172] [TPS_SYST_02173]
[TPS_SYST_02189] [TPS_SYST_05020]
[TPS_SYST_05021] [TPS_SYST_05022]
[TPS_SYST_05023] [TPS_SYST_05024]
[TPS_SYST_05025] [TPS_SYST_05026]
[TPS_SYST_05027] [TPS_SYST_05028]
[RS_SYST_00055] Support of Container Pdus [TPS_SYST_01056] [TPS_SYST_02061]
[TPS_SYST_02062] [TPS_SYST_02063]
[TPS_SYST_02064] [TPS_SYST_02065]
[TPS_SYST_02066] [TPS_SYST_02097]
[TPS_SYST_02098] [TPS_SYST_02099]
[TPS_SYST_02100] [TPS_SYST_02196]
[TPS_SYST_03014]
[RS_SYST_00056] E2E-protected communication [TPS_SYST_02067] [TPS_SYST_02068]
[TPS_SYST_02069] [TPS_SYST_02070]
[TPS_SYST_02071] [TPS_SYST_02072]
[TPS_SYST_02073] [TPS_SYST_02134]
[TPS_SYST_02135] [TPS_SYST_02155]
[TPS_SYST_02275] [TPS_SYST_02349]
[TPS_SYST_02350]
[RS_SYST_00057] Assigning communication graphs [TPS_SYST_02197]
to particular RTE Implementation
Plug-Ins
[RS_SYST_00058] The System Template shall support [TPS_SYST_02211] [TPS_SYST_05016]
the usage of the TLV encoding in [TPS_SYST_05017]
SOME/IP messages
5

30 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Requirement Description Satisfied by
[RS_SYST_00059] The System Template shall support [TPS_SYST_03022] [TPS_SYST_03023]
the translation between [TPS_SYST_03024] [TPS_SYST_03025]
signal-based and service-oriented [TPS_SYST_03026] [TPS_SYST_03027]
communication. [TPS_SYST_03028] [TPS_SYST_03029]
[TPS_SYST_03030] [TPS_SYST_03031]
[TPS_SYST_03032] [TPS_SYST_03033]
[TPS_SYST_03034] [TPS_SYST_03036]
[TPS_SYST_03037] [TPS_SYST_03038]
[TPS_SYST_03039] [TPS_SYST_03040]
[TPS_SYST_03041] [TPS_SYST_03042]
[TPS_SYST_03043] [TPS_SYST_03044]
[TPS_SYST_03045] [TPS_SYST_03046]
[TPS_SYST_03047] [TPS_SYST_03048]
[TPS_SYST_03049] [TPS_SYST_03051]
[TPS_SYST_03056] [TPS_SYST_03057]
[TPS_SYST_03058] [TPS_SYST_03059]
[TPS_SYST_03060] [TPS_SYST_03061]
[TPS_SYST_03062] [TPS_SYST_03063]
[RS_SYST_00060] The System Template shall support [TPS_SYST_02315] [TPS_SYST_02316]
the modeling of Software Clusters [TPS_SYST_02317] [TPS_SYST_02318]
[TPS_SYST_02319] [TPS_SYST_02320]
[TPS_SYST_02321] [TPS_SYST_02322]
[TPS_SYST_02323] [TPS_SYST_02324]
[TPS_SYST_02325] [TPS_SYST_02326]
[TPS_SYST_02343] [TPS_SYST_02344]
[TPS_SYST_02345] [TPS_SYST_02346]
[RS_SYST_00061] The System Template shall provide [TPS_SYST_02327] [TPS_SYST_02328]
means to describe the interface of [TPS_SYST_02329] [TPS_SYST_02330]
the Software Clusters binary object [TPS_SYST_02331] [TPS_SYST_02332]
[TPS_SYST_02333] [TPS_SYST_02334]
[TPS_SYST_02335] [TPS_SYST_02336]
[TPS_SYST_02337] [TPS_SYST_02338]
[TPS_SYST_02339] [TPS_SYST_02340]
[TPS_SYST_02341] [TPS_SYST_02342]
[RS_SYST_00062] The System Template shall support [TPS_SYST_02320] [TPS_SYST_02321]
the modeling of Software Cluster [TPS_SYST_02322] [TPS_SYST_02323]
Resources [TPS_SYST_02324] [TPS_SYST_02325]
[TPS_SYST_02326] [TPS_SYST_02345]
[TPS_SYST_02346]

Table 1.2: RequirementsTracing

1.3 Requirements not fulfilled by TPS requirements

This section contains a list of requirements that are not yet fulfilled by TPS require-
ments.
Requirement Description Satisfied by
[RS_SYST_00015] The System Template shall support chapter Topology ( 3);
Bus bandwidth bandwidth calculation as a constraint for Communication (chapter 6)
the definition of the Communication
Matrix.
[RS_SYST_00023] The System Template has to cover the not covered
ECU Communica- system communication via MOST.
tion via MOST

31 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[RS_SYST_00025] The System Template shall enable the Harmonization between

Derivation of ECU configuration of the Com Stack of the Upstream Templates and ECU
Configuration Pa- ECU. It handles those parameters that Configuration (chapter C)
rameters from the are necessary to describe the inter-ECU
System Template communication. Configuration
parameters local to an ECU are not in the
scope of the System Template.
[RS_SYST_00026] Whenever there is a considerable overlap AUTOSAR System Template
Fibex compatibility between the System Template and the and ASAM FIBEX (chapter 1.8)
ASAM FIBEX Standard, the System
Template shall adopt the structures of the
ASAM FIBEX Standard.
[RS_SYST_00032] The System Template shall provide the chapter Variant Handling 1.7.2
Topology Variants means to describe topology variants with and chapter Topology 3.
optional/alternative ECUs and
communication clusters.
[RS_SYST_00033] The System Template shall provide the chapter 1.7.2 Variant Handling
Software-to-ECU means to describe alternative mappings and chapter 5.1 Software
mapping variants of software components to ECUs. Component Mapping.
[RS_SYST_00034] The System Template shall provide the chapter 1.7.2 Variant Handling
Timing variants means to describe alternative timing and chapter 6 Communication.
properties (e.g. trigger type, period,
priority) and timing constraints (e.g.
latency, age).
[RS_SYST_00035] The System Template shall provide the chapter 1.7.2 Variant Handling
Data mapping means to describe data mapping and chapter 5.2 Data Mapping.
variants Variants.
[RS_SYST_00036] The System Template shall provide the chapter 1.7.2 Variant Handling
Communication means to describe communication and chapter 6 Communication.
variants variants, such as alternative
signal-to-PDU mappings, alternative
communication paths, and alternative
signal and PDU properties (e.g. data
type, data length).
[RS_SYST_00040] The System Template shall provide the Timing Extensions
Timing constraints means to describe the timing constraints (chapter 1.7.3)
of a system’s dynamics, which are
determined by the consumption of
computation, communication, and other
hardware resources.
[RS_SYST_00041] The ECU Extract shall support variability Variant Handling in ECU
Variants in ECU of elements taken over or derived during Extract (chapter 14.6)
Extract the transformation from the System
Description.

32 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

1.4 Methodology for Defining Formal Template

Figure 1.1 illustrates the overall methodology used to define formal templates. As is
explained in the "Generic Structure Template" [2], it is important to separate
a precise and concise model of the information that needs to be captured from the
concrete XML-DTDs, XML-Schemas or other technology that is used to define the
actual templates.
«Text Document»
Generic Structure Template

+is partly
+is described in
described
in

«Text Document» +isGovernedBy UML and the Autosar

Requirements on System Template Profile
Template Model M2
Templates

specifiesSerialization

«Text Document» «Text Document»

+implements
SystemTemplate XML Schema Production
Schema Rules
Generator

+generates

«XML File» «XML Schema» «XML File»

System Configuration +instance of Data Exchange Format +instance of System Constraint
Description Description

Figure 1.1: Methodology to define templates in AUTOSAR

The following documents describe the various aspects of the methodology:

1. The document called System Template (this document) describes the informa-
tion that can be captured in the "system constraint" and "system configuration"
description, independently from the mapping of this model on XML-technology.
This document is based upon the AUTOSAR meta-model and contains an elabo-
rate description of the semantics (the precise meaning) of all the information that
can be captured within the relevant parts of this meta-model.
2. The UML and the AUTOSAR Template Profile [2] describes the basic
concepts that should be used when creating content of the meta-model.
3. The document called "XML Schema Production Rules" [3] describes how
XML is used and how the meta-model designed in the "System Template" should
be translated by the "Schema Generator" (MMT) into XML-Schema (XSD)
"Data Exchange Format". This "formalization strategy" is to be used for all
data that is formally described in the meta-model. In particular this document is
worth to read in order to understand the mapping of the meta-model and the XML
based System template.

33 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4. The "Generic Structure Template" [2] describes the top level structure
which is common to all AUTOSAR templates and provides AUTOSAR standard
mechanisms of modeling elements and patterns.
5. The concrete "Template", the "Data Exchange Format" is an XML schema
which is generated out of the meta-model described in the "System Template"
using the approach and the patterns defined in the "XML Schema Production
Rules". This schema is typically used as input to tools. The M1-level system
descriptions are XML files which can be validated against the schema. In that
sense they are instances of the schema defining the XML representation of the
template.

1.5 Scope
This document describes the system template and its use for the System Constraint
Description and the System Configuration Description. In general a filled system tem-
plate defines the relationship between the pure Software View on the System (repre-
sented by a top level SW Component Composition) and a Physical System Architec-
ture with networked ECU instances. The system template is used in two stages of the
"AUTOSAR Methodology" [4] (see Figure 1.2).
• As System Constraint Description it serves as input to the AUTOSAR system
generator
• As System Configuration Description it defines the output of the AUTOSAR Sys-
tem Configuration Generator and serves as input to the AUTOSAR ECU Config-
uration Generator for the different ECUs defined in the description.
• As ECU Extract of the System Configuration Description it describes the ECU
specific view on the System Description. It is individually generated for each of
the System’s ECU as the output of the AUTOSAR ECU Configuration Generator.

34 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Component
API ECU Configuration
Component e.g. decisions Description
(e.g. scheduling, AUTOSAR
API app.h RTE RTE
Generator ...)
Extract of Generator
System ECU Config
SW -
Component Configuration
Description Description Generator for
OS extract OS, COM, ...
of ECU config
ECU e.g.OIL
AUTOSAR ECU AUTOSAR
Resource System extract of ECU
Description Configuration System Configuration Other Basic
(HW only) Generator Configuration Generator SW Generator
Basic SW
Basic A
Module SW
ECU Basic
Module
extract SW
of A
System -
extract of ECU Module
extract of A
config
Constraint
System ECU extract of
config
Description decisions ECU config MCAL-
Configuration
(e.g. mapping) Generator

list of
inplementations
of SW
per ECU Components
Information / Database (no files)

Complex generation step:

complex algorithm or engineering work

Figure 1.2: AUTOSAR Methodology

The System Template defines five major elements: Topology, Software, Communica-
tion, Mapping and Mapping Constraints, which will be defined in detail in the following
chapters. Figure 1.3 gives an overview how these are used in the two different descrip-
tions.

35 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

SW-Components

System Configuration
ECU Resource

AUTOSAR ECU Config Generator (per ECU)

Topology (untouched by System Generator)
•which ECUs
System Constraints •how connected

AUTOSAR System Generator

Topology
• which ECUs Software (untouched by System Generator)
• how connected •which application SW Component

Software Communication
• which Application SW-C
SW -C • Communication Matrix
• Frames, Signals,
Signals Timing
•(optional) Communication • Gateway Tables
• Communication Matrix • Communication Protocols
Mapping
• Frames, Signals,
Signals Timing
• which SW on which ECU
Mapping
• Gateway tables
•• Which Data
which SW oninwhich
whichECU
Frame/Signal/Protocol
• Communication Protocols
(optional) Mapping • Which Data in which Frame/Signal/Protocol
Mapping Constraints
(optional)ifMapping
already defined
• what
Mapping must be mapped
Constraints – together, what separated
if already
• which SW-Cdefined
on which ECU etc (untouched,
• what not relevant
must be mapped for ECU
together, whatConfig
separated
which SW
•• Which data --C on which ECU
in which Generator)
etc (untouched, not relevant for ECU Config
Which data in which
• Frame/Signal
Frame/Signal Generator)
Mapping Constraints
Mapping• what must be mapped
Constraints
together,
§what mustwhat separated etc
be mapped

Figure 1.3: Scope of System Constraint Description and System Configuration Descrip-
tion

On Figure 1.3 some of the elements are marked optional for the System Constraint
Description. If one starts with a new AUTOSAR project, these elements may not be
present in the System Constraint Description. No (at least partial) functionality has
been mapped yet, thus the communication matrix is not populated. But in most cases,
many functional mappings are already predefined and contribute to the population of
the communication matrix with their associated signals, thus being present in the Sys-
tem Constraint Description.
Reasons for such a predefinition are manifold. In some cases, hardware setup dic-
tates where certain functionality resides, in some cases, a partial or complete commu-
nication matrix and/or completely configured ECUs (HW and SW) of another system
(vehicle) has to be taken over. This approach is eased by the fact that System Configu-
ration and System Constraint Description use the same format. That way it is possible
to reuse parts of a System Configuration Description of the other system/vehicle in the
actual System Constraint Description.
Furthermore, in the figure some of the elements are marked untouched for the Sys-
tem Configuration Description. This can have two reasons:
• The System Generator does not modify neither the Topology (networked ECUs)
nor the Software, so these parts are just moved from System Constraint Descrip-
tion to System Configuration Description during the generation step.
• In a completed System Configuration Description, all SW components and all
ECU-to-ECU communication have been mapped. Thus mapping constraints that
limit the flexibility in the mapping phase of the system generator are obsolete

36 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

and will not be used in subsequent generator steps. They may however still be
present for documentation and validation reasons.
Even if the communication matrix is determined as the result of the system configu-
ration, the ECUs still have to be configured. This is done by the ECU configuration
generator, which takes the System Configuration description as input and generates
the ECU configuration description. The following guiding principles have been used to
determine which information shall be part of the System Configuration Description and
which goes into the ECU Configuration Description:
• Information that is common for several ECUs and has to be agreed, shall be
part of the System Configuration Description and is thus covered by the System
Template.
• Information, that only has ECU-local relevance is part of the ECU Configuration
Description.
Thus the ECU Configuration Description will include the OS-schedule, the RTE-
configuration and last but not least the configuration of the ECU basic software in-
cluding the concrete communication drivers on that ECU.

1.6 UML Meta-Model

This chapter gives an overview of the AUTOSAR Unified Modeling Language (UML)
meta-model. All AUTOSAR templates use a common meta-model. The templates de-
scribe software components, ECU resources, the Basic Software Modules, the ECU
Configuration Parameters (ECU Configuration Description and ECU Configuration Pa-
rameter Definition) and the System.
The System Template defines all elements, their parameters and their relations, which
are necessary for the System Constraint Description and the System Configuration
Description.

37 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

AutosarTopLevelStructure CommonStructure

SWComponentTemplate EcuResourceTemplate

AdaptivePlatform

SystemTemplate

DiagnosticExtract

ECUCDescriptionTemplate

ECUCParameterDefTemplate

BswModuleTemplate

AbstractPlatform StandardizationTemplate GenericStructure FeatureModelTemplate

Figure 1.4: AUTOSAR Package Overview

Figure 1.4 shows the overall structure of the meta-model.

The dashed arrows in the diagram describe dependencies in terms of import-
relationships between the packages within the meta-model. For example, the package
SystemTemplate imports meta-classes defined in the packages GenericStruc-
ture [2], SWComponentTemplate [5] and ECUResourceTemplate [6].
For clarification, please note that the package GenericStructure contains some
fundamental infrastructure meta-classes and common patterns that are described in
[2]. As these are used by all other template specification the dependency associations
are not depicted in the diagram for the sake of clarity.
Generic Structure provides details about
• AUTOSAR Top level structure,
• Commonly used meta-classes and primitives
• Variant Handling

38 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• Documentation
The ECU Resource Template deals with the description of the hardware resources of
an ECU. The collection of all ECUs, which are integrated in the car, are described in
the topology part of the System Configuration Description/System Constraint Descrip-
tion. Each of these ECUInstances uses the ECU Resource Template to describe the
hardware resources. That’s the reason, why the topology part has references to the
ECU Resource Description.
The SW component description describes the SW components as well as their com-
munication by data elements. The top-level software composition (RootSwComposi-
tionPrototype) is part of the System Template (Software). This top-level software
composition contains the functionality of the full system and describes the complete
application software architecture of this system. The definition of the top level soft-
ware composition uses the elements defined in the SW Component Template, like
e.g. SwComponentType, PortInterface, AssemblySwConnector and Delega-
tionSwConnector. That’s why the System Description has references to the Soft-
ware Component Description. The top level software composition is described in more
detail in chapter 4.
Every template starts with an element AUTOSAR. While the models created in accor-
dance to this guide are independent of the used formalization, it may still help the
reader’s understanding to note that AUTOSAR would also typically be the root element
of a XML Schema generated from such a model. AUTOSAR can then contain one
or more nested packages, simply allowing to further structure the contents of the M1
model.

1.7 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:

39 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Please note that constraints are not supposed to be enforceable at any given time in an
AUTOSAR workflow. During the development of a model, constraints may legitimately
be violated because an incomplete model will obviously show inconsistencies.
However, at specific points in the workflow, constraints shall be enforced as a safeguard
against misconfiguration.
The points in the workflow where constraints shall be enforced, sometimes also known
as the "binding time" of the constraint, are different for each model category, e.g. on the
classic platform, the constraints defined for software-components are typically enforced
prior to the generation of the RTE while the constraints against the definition of an Ecu
extract shall be applied when the Ecu configuration for the Com stack is created.
For each document, possible binding times of constraints are defined and the binding
times are typically mentioned in the constraint themselves to give a proper orientation
for implementers of AUTOSAR authoring tools.
Let AUTOSAR be an example of a typical class table. The first rows in the table have
the following meaning:
Class: The name of the class as defined in the UML model.
Package: The UML package the class is defined in. This is only listed to help locating
the class in the overall meta model.
Note: The comment the modeler gave for the class (class note). Stereotypes and UML
tags of the class are also denoted here.
Base Classes: If applicable, the list of direct base classes.
The headers in the table have the following meaning:
Attribute: The name of an attribute of the class. Note that AUTOSAR does not distin-
guish between class attributes and owned association ends.
Type: The type of an attribute of the class.
Mul.: The assigned multiplicity of the attribute, i.e. how many instances of the given
data type are associated with the attribute.
Kind: Specifies, whether the attribute is aggregated in the class (aggr aggregation),
an UML attribute in the class (attr primitive attribute), or just referenced by it (ref
reference). Instance references are also indicated (iref instance reference) in this
field.
Note: The comment the modeler gave for the class attribute (role note). Stereotypes
and UML tags of the class are also denoted here.
Please note that the chapters that start with a letter instead of a numerical value rep-
resent the appendix of the document. The purpose of the appendix is to support the
explanation of certain aspects of the document and does not represent binding con-
ventions of the standard.

40 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

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

41 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

1.7.1 Detailed Representation of InstanceRef Associations

As a special type of association "instanceRef" refers to an exact instance of the refer-

enced class, requiring additional information of the target and the context. This is ex-
plained in detail in the AUTOSAR Generic Structure Template [2]. Each "instanceRef"
association can both be represented by the short form and by an detailed representa-
tion. For readability the diagrams in the main body of the specification use the short
form. The detailed descriptions can be found in the Appendix B.

1.7.2 Variant Handling

The System Template supports the creation of Variants in many of its model elements.
In the Metamodel all locations that may exhibit variability are marked with the stereo-
type atpVariation. This allows the definition of possible variation points. Tagged
Values are used to specify additional informations.
There are four types of locations in the metamodel which may exhibit variability:
• Aggregations
• Associations
• Attribute Values
• Classes providing property sets
The reasons for the attachment of the stereotype atpVariation to certain model
elements and the consequences for other model elements are explained in class tables
in the following chapters. More details about the AUTOSAR Variant Handling Concept
can be found in the AUTOSAR Generic Structure Template [2].

1.7.3 Timing Extensions

With AUTOSAR Release 4.0 a new set of concepts for the description and analysis of
end-to-end timing constraints is introduced by the Specification of Timing Extensions.
A subset of these extensions aims for the system level and can be used to enhance
the descriptions that are already available in the System Template.
A dedicated description of the timing extensions that can be used at system level is
given in chapter 3 (System timing) in the Specification of Timing Extensions [8].

1.7.4 Documentation Support

With AUTOSAR Release 4.0 the AUTOSAR XML schema provides support for inte-
grated and well structured documentation. More details about the AUTOSAR Docu-
mentation Support concept can be found in the AUTOSAR Generic Structure Tem-

42 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

plate [2]. An optional documentation block can be applied to any identifiable element.
Furthermore, as shown in figure 1.5, the System Template provides the possibility of
adding additional documentation to several non-identifiable elements. The documen-
tation of a System is composed of several chapters.
ARElement
AtpStructureElement
System Identifiable
Paginateable
+systemDocumentation
+ containerIPduHeaderByteOrder: ByteOrderEnum [0..1] Chapter
+ ecuExtractVersion: RevisionLabelString [0..1] «atpVariation,atpSplitable»
0..*
+ pncVectorLength: PositiveInteger [0..1] + helpEntry: String [0..1]
+ pncVectorOffset: PositiveInteger [0..1]
+ systemVersion: RevisionLabelString

«atpMixed» IPduMapping
DocumentationBlock +introduction
+ pduMaxLength: PositiveInteger [0..1]
0..1 + pdurTpChunkSize: PositiveInteger [0..1]

+introduction FrameMapping

0..1

ISignalMapping
+introduction

0..1

+introduction ScheduleTableEntry
0..1

DataMapping
+introduction

0..1

MappingConstraint
+introduction

0..1

EcuResourceEstimation
+introduction

0..1

SignalPathConstraint
+introduction

Figure 1.5: System Template Documentation Support

43 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

1.7.5 Stereotype atpSplitable in the System Template

The stereotype atpSplitable is used in the System Template to support step-

wise processes, where the System Configuration Description is completed incremen-
tally over a development process. Example:
1) Description of Communication only consists of interaction signals (ISignal). This
is enough information to create an individual ECU’s RTE, and even contains enough
information to configure an ECU where the actual Frame/Pdu communication is being
handled post-build.
2) In a second step, the communication matrix is being completed for a concrete ve-
hicle. Pdus and Frames, along with their Triggerings are being added to the previous
System Description. This model then contains the full information about an ECU’s
communication, especially containing the additional information to generate the post
build information.
So, in this 2-step approach, an OEM could deliver the incomplete ECU extract from
step (1) to the ECU integrator, who can then build a complete software image for the
ECU. In the 2nd step, the ECU extract will be completed by the previously missing
information, but as the first extract will still be valid due to the atpSplitable
construct, the ECU including the flashed image from step (1) can be (re)used as it is,
and just will be completed with the post build information, e.g. Frames and Pdus.
Further details about the atpSplitable stereotype can be found in the Generic
Structure Template [2].

1.8 AUTOSAR System Template and ASAM FIBEX

FIBEX (Field Bus Exchange Format) [9] is an XML exchange format proposed for
data exchange between tools that deal with bus communication Systems. The format
supports the most common automotive data buses: LIN [10], CAN [11], MOST [12],
FlexRay [13]. The covered areas of the exchange format are the functional network,
system topology and the communication level. The functional network describes the
software architecture of the system. In the system topology the logical layout of the
system is described. This means it is documented which ECU is connected to which
bus. The central purpose of a communication system is the exchange of frames with
certain properties. The format is able to describe frames and their timing properties.
In future versions of the System Template a common subset between ASAM FIBEX
and AUTOSAR will be harmonized. The current version of the System Template con-
tains already the ASAM FIBEX description for communication and topology. Due to
requirements of AUTOSAR some extensions were made to those descriptions. For
instance the communication part is extended by a concept for PDUs (I-Pdus and N-
Pdus). The harmonization between ASAM FIBEX and AUTOSAR System Template is
not finalized at this time.

44 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

In the UML Meta-Model the FIBEX contents are located in an own FIBEX UML Pack-
age. The top level FibexElement is referenced by the top level element System of
the System Template. Similar to the usage of the ARElement, specializations of the
FibexElement represent elementary building blocks within the FIBEX package. Each
of this elements will be described in more detail in the following chapters.
ARElement
AtpStructureElement
System

«atpVariation»

+fibexElement *

PackageableElement
FibexElement

«atpVariation» ISignalIPduGroup ISignal Frame NmConfig

CommunicationCluster

PdurIPduGroup Gateway EcuInstance Pdu TpConfig ISignalGroup

IPdu NmPdu

Figure 1.6: Fibex Elements

45 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

2 System
The top level element of the System Template is the class System, as shown in figure
2.1.
SwComponentType +component AtpPrototype
CompositionSwComponentType SwComponentPrototype
«atpVariation,atpSplitable» 0..*
ARElement
+swCluster
+swComposition CpSoftwareCluster
0..*
0..* «atpVariation,atpSplitable»
«atpSplitable,atpVariation»

+softwareComposition 1
{redefines atpType}
«isOfType»
AtpPrototype
ARElement Identifiable
Identifiable
+flatMap AtpBlueprint SystemMapping
RootSwCompositionPrototype
«atpSplitable» 0..1 AtpBlueprintable
FlatMap

+rootSoftwareComposition 0..1 +mapping 0..*

«atpVariation,atpSplitable» «atpVariation,atpSplitable»

ARElement
AtpStructureElement
System

+ containerIPduHeaderByteOrder: ByteOrderEnum [0..1]

+ ecuExtractVersion: RevisionLabelString [0..1]
+ pncVectorLength: PositiveInteger [0..1]
+ pncVectorOffset: PositiveInteger [0..1]
+ systemVersion: RevisionLabelString

«atpVariation»
«atpVariation,atpSplitable»
+interpolationRoutineMappingSet

+fibexElement * +clientIdDefinitionSet 0..* +j1939SharedAddressCluster 0..*

PackageableElement ARElement Identifiable

FibexElement ClientIdDefinitionSet J1939SharedAddressCluster

«atpVariation,atpSplitable»

+clientIdDefinition 0..* 0..*

AtpStructureElement Identifiable ARElement
Identifiable ClientIdDefinition InterpolationRoutineMappingSet
+clientServerOperation
ClientServerOperation
«instanceRef» + clientId: Numerical
1
+ diagArgIntegrity: Boolean [0..1]

Figure 2.1: System Template Overview

Class System
Package M2::AUTOSARTemplates::SystemTemplate
Note The top level element of the System Description. The System description defines five major elements:
Topology, Software, Communication, Mapping and Mapping Constraints.
The System element directly aggregates the elements describing the Software, Mapping and Mapping
Constraints; it contains a reference to an ASAM FIBEX description specifying Communication and
Topology.
Tags:atp.recommendedPackage=Systems
Base ARElement, ARObject, AtpClassifier , AtpFeature, AtpStructureElement, CollectableElement,
Identifiable, MultilanguageReferrable, PackageableElement, Referrable
Attribute Type Mult. Kind Note
clientId ClientIdDefinitionSet * ref Set of Client Identifiers that are used for inter-ECU
DefinitionSet client-server communication in the System.
5

46 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class System
containerIPdu ByteOrderEnum 0..1 attr Defines the byteOrder of the header in ContainerIPdus.
HeaderByte
Order
ecuExtract RevisionLabelString 0..1 attr Version number of the Ecu Extract.
Version
fibexElement FibexElement * ref Reference to ASAM FIBEX elements specifying
Communication and Topology.
All Fibex Elements used within a System Description shall
be referenced from the System Element.
atpVariation: In order to describe a product-line, all Fibex
Elements can be optional.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
interpolation InterpolationRoutine * ref This reference identifies the InterpolationRoutineMapping
Routine MappingSet Sets that are relevant in the context of the enclosing
MappingSet System.
j1939Shared J1939SharedAddress * aggr Collection of J1939Clusters that share a common
AddressCluster Cluster address space for the routing of messages.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=j1939SharedAddressCluster.shortName,
j1939SharedAddressCluster.variationPoint.shortLabel
vh.latestBindingTime=postBuild
mapping SystemMapping * aggr Aggregation of all mapping aspects (mapping of SW
components to ECUs, mapping of data elements to
signals, and mapping constraints).
In order to support OEM / Tier 1 interaction and shared
development for one common System this aggregation is
atpSplitable and atpVariation. The content of System
Mapping can be provided by several parties using
different names for the SystemMapping.
This element is not required when the System description
is used for a network-only use-case.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=mapping.shortName, mapping.variation
Point.shortLabel
vh.latestBindingTime=postBuild
pncVector PositiveInteger 0..1 attr Length of the partial networking request release
Length information vector (in bytes).
pncVectorOffset PositiveInteger 0..1 attr Absolute offset (with respect to the NM-PDU) of the
partial networking request release information vector that
is defined in bytes as an index starting with 0.
rootSoftware RootSwComposition 0..1 aggr Aggregation of the root software composition, containing
Composition Prototype all software components in the System in a hierarchical
structure. This element is not required when the System
description is used for a network-only use-case.
atpVariation: The RootSwCompositionPrototype can vary.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=rootSoftwareComposition.shortName, root
SoftwareComposition.variationPoint.shortLabel
vh.latestBindingTime=systemDesignTime
5

47 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class System
swCluster CpSoftwareCluster * ref CP Software Clusters of this System
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=swCluster.cpSoftwareCluster, sw
Cluster.variationPoint.shortLabel
atp.Status=draft
vh.latestBindingTime=systemDesignTime
system Chapter * aggr Possibility to provide additional documentation while
Documentation defining the System. The System documentation can be
composed of several chapters.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=systemDocumentation.shortName, system
Documentation.variationPoint.shortLabel
vh.latestBindingTime=systemDesignTime
xml.sequenceOffset=-10
systemVersion RevisionLabelString 1 attr Version number of the System Description.

Table 2.1: System

System has relationships to all elements that define a system constraint descrip-
tion or system configuration description. It aggregates the SystemMapping and
RootSwCompositionPrototype elements. SystemMapping deals with mapping
of software components to ECUs as well as with the mapping of data elements that
are to be exchanged between software components onto signals and frames. The
RootSwCompositionPrototype element contains a reference to the top level soft-
ware composition.
[TPS_SYST_02364] Scope of the System dThe System defines a vehicle represen-
tation and describes the software related parts of the vehicle. This includes the Soft-
ware Components that are deployed to ECUs of the vehicle but also the means for the
Software to communicate with each other, such as network topology and communica-
tion matrix.c()
[constr_3028] FibexElements dEach FibexElement that is used in the System
Description shall be referenced by the System element in the role FibexElement.c()
FibexElements can be defined in a stand alone and reusable way (hence they can
simply be created in any package like ARElements), but on the other hand it shall be
clear that a certain FibexElement actually belongs to a certain System Description.
Thus, all FibexElements used within a System Description (i.e. contributing to the
specification of the System communication and topology) shall be referenced from the
System element. More details about the integration of FIBEX into the System Template
will be given in chapter 1.8.
[TPS_SYST_01002] System Category dThe System shall have a category ele-
ment defined which indicates the role of this work product.c(RS_SYST_00003, RS_-
SYST_00027)

48 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_01003] Standardized System Category Definitions dThe

standardized System category definitions are defined in Table 2.2.c(RS_SYST_00003,
RS_SYST_00027)
category Meaning
The System class is used to describe System Constraints. In this usage, it
SYSTEM_
forms the core element of a System Constraints Description, serving as an
CONSTRAINTS
input to the AUTOSAR System Generator.
The System class is used to describe the System Configuration of a complete
SYSTEM_
AUTOSAR System. In this usage, it forms the core element of a System
DESCRIPTION
Description, the output of the AUTOSAR System Generator.
The System class is used to describe a subsystem specific view on the com-
plete System Description. The System Extract is not fully decomposed and
SYSTEM_EXTRACT
still contains compositions. The SYSTEM_EXTRACT is the basis for design-
ing subsystems.
The System class is used to describe the ECU specific view on the complete
System Description. In this usage, it forms the core element of ECU Extract,
ECU_EXTRACT the output of the AUTOSAR ECU Configuration Extractor. The ECU Extract is
fully decomposed and contains only atomic software components. The ECU
Extract is the basis for setting up the ECU Configuration.
This System is used to describe a functional (solution-independent/abstract)
ABSTRACT_ system design. It can be taken as basis for the development of the
SYSTEM_ SYSTEM_DESCRIPTION. No structural constraints are applied on the
DESCRIPTION transformation of the ABSTRACT_SYSTEM_DESCRIPTION to the SYS-
TEM_DESCRIPTION.
This System is used to describe the closed view on one ECU (note
that an AUTOSAR ECU is defined being one microprocessor running one
ECU_SYSTEM_ AUTOSAR Stack). It can be derived from a SYSTEM_EXTRACT or it
DESCRIPTION can be designed independently and mapped to a SYSTEM_EXTRACT. The
ECU_SYSTEM_DESCRIPTION is not fully decomposed and still may contain
compositions.
SW_CLUSTER_
SYSTEM_ System that describes the content of a single CpSoftwareCluster.
DESCRIPTION
System which describes the rapid prototyping algorithm in the format of
RPT_SYSTEM AUTOSAR Software Components. For more details see the Software Com-
ponent Template [5] and TR_Methodology [4].

Table 2.2: System class categories

Note: SYSTEM_EXTRACT does not prescribe the number of micro controllers / cores
for one ECU from the OEM perspective.
• Supplier decides to design one AUTOSAR ECU with multicore support leads to
one ECU_EXTRACT supporting one AUTOSAR stack
• Supplier decides to design two AUTOSAR ECUs (i.e., two micro-controllers) in
one box leads to two ECU_EXTRACTs supporting two AUTOSAR stacks
[constr_3027] Existence of ecuExtractVersion dIn case the category of the Sys-
tem is SYSTEM_EXTRACT or ECU_EXTRACT the ecuExtractVersion attribute
shall be defined.c()

49 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

2.1 Data interpretation of bus content in different contexts

A System Description can be used for different purposes:
• as input for the creation of the Base Ecu Configuration
• as input for bus monitoring and network analysis tools
In some cases the System Description is interpreted in a different way between Ecuc
tools and network analysis tools. This chapter collects such use cases and describes
the differences in the interpretation of the configuration data.

2.1.1 Nm NID/CBV

[TPS_SYST_02366] NID/CBV signals shall be ignored by Ecuc tools dIf NID/CBV

are enabled (nmCbvPosition and nmNidPosition are configured), the Signals that
are defined at the position of the respective NID/CBV bytes shall be ignored by Base
Ecuc generators since these signals are not processed by COM.c()
Please note that there may be the use case to define the Signals that represent the
NID and CBV in the NmPdu for bus monitoring or network analysis purposes.

2.2 ClientIdDefinitionSet
In the ClientIdDefinitionSet all Client Identifiers of the transaction handle used
for a inter-ECU client server communication can be defined that belong to the System
that refers the ClientIdDefinitionSet.
Class ClientIdDefinitionSet
Package M2::AUTOSARTemplates::SystemTemplate
Note Set of Client Identifiers that are used for inter-ECU client-server communication in the System.
Tags:atp.recommendedPackage=ClientIdDefinitionSets
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
clientId ClientIdDefinition * aggr Definition of a Client Identifier that will be used by the
Definition RTE in a inter-ECU client-server communication.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=clientIdDefinition.shortName, clientId
Definition.variationPoint.shortLabel
vh.latestBindingTime=postBuild

Table 2.3: ClientIdDefinitionSet

50 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class ClientIdDefinition
Package M2::AUTOSARTemplates::SystemTemplate
Note Several clients in one client-ECU can communicate via inter-ECU client-server communication with a
server on a different ECU, if a client identifier is used to distinguish the different clients. The Client
Identifier of the transaction handle that is used by the RTE can be defined by this element.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
clientId Numerical 1 attr The Client Identifier of the transaction handle used for an
inter-ECU client server communication is defined by this
attribute. If defined the RTE generator shall use this client
Id.
clientServer ClientServerOperation 1 iref Reference to the ClientServerOperation that is called by
Operation the client.
InstanceRef implemented by:OperationInSystem
InstanceRef
Table 2.4: ClientIdDefinition

[constr_3117] Allowed value of attribute clientId dWithin the context of one

ClientIdDefinition, the value of attribute clientId shall be in the range
of ClientIdRange.lowerLimit and ClientIdRange.upperLimit for the Cli-
entIdRange that is aggregated by the EcuInstance onto which the SwCompo-
nentPrototypes included in the ClientIdDefinition.clientServerOpera-
tion are mapped.c()
Please note that the clientId is bound to the ClientServer relationship and does not
represent a globally unique identifier of the Client call. ClientIds can be reused in the
context of a different ClientServer relationship.
[constr_3118] Valid reference target for ClientIdDefinition.clientServer-
Operation.contextPort dIn the context of the definition of a ClientIdDefini-
tion, the reference clientServerOperation.contextPort shall only refer to an
RPortPrototype.c()
Rationale: the definition of a client ID does only make sense in the context of a client
of a ClientServerOperation.

2.3 InterpolationRoutingMappingSet
The System defines with the interpolationRoutineMappingSet reference all
InterpolationRoutineMappingSets that are relevant in the context of the Sys-
tem. More details about the InterpolationRoutineMappingSets, Interpola-
tionRoutineMappings and InterpolationRoutines can be found in the Soft-
ware Component Template [5].

51 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class InterpolationRoutineMappingSet
Package M2::AUTOSARTemplates::SWComponentTemplate::MeasurementAndCalibration::InterpolationRoutine
MappingSet
Note This meta-class specifies a set of interpolation routine mappings.
Tags:atp.recommendedPackage=InterpolationRoutineMappingSets
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
interpolation InterpolationRoutine * aggr This specifies one particular mapping of recordlayout and
Routine Mapping its matching interpolationRoutines.
Mapping

Table 2.5: InterpolationRoutineMappingSet

Class InterpolationRoutineMapping
Package M2::AUTOSARTemplates::SWComponentTemplate::MeasurementAndCalibration::InterpolationRoutine
MappingSet
Note This meta-class provides a mapping between one record layout and its matching interpolation routines.
This allows to formally specify the semantics of the interpolation routines.
The use case is such that the curves/Maps define an interpolation method. This mapping table specifies
which interpolation routine implements methods for a particular record layout. Using this information, the
implementer of a software-component can select the appropriate interpolation routine.
Base ARObject
Attribute Type Mult. Kind Note
interpolation InterpolationRoutine * aggr This is one particular interpolation routine which is
Routine mapped to the record layout.
swRecord SwRecordLayout 0..1 ref This refers to the record layout which is mapped to
Layout interpolation routines.

Table 2.6: InterpolationRoutineMapping

Class InterpolationRoutine
Package M2::AUTOSARTemplates::SWComponentTemplate::MeasurementAndCalibration::InterpolationRoutine
MappingSet
Note This represents an interpolation routine taken to evaluate the contents of a curve or map against a
specific input value.
Base ARObject
Attribute Type Mult. Kind Note
interpolation BswModuleEntry 0..1 ref This specifies a BswModuleEntry which implements the
Routine current interpolation method for the given record layout.
Tags:xml.sequenceOffset=30
isDefault Boolean 0..1 attr This attribute specifies whether the enclosing
InterpolationRoutine is considered the default in the
context (defined by the System Template) of a given
collection InterpolationRoutineMapping that owns the
enclosing InterpolationRoutine.
Tags:xml.sequenceOffset=20
5

52 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class InterpolationRoutine
shortLabel Identifier 0..1 attr This is the name of the interpolation method which is
implemented by the referenced bswModuleEntry. It
corresponds to swInterpolationMethod in SwDataDef
Props.
Tags:xml.sequenceOffset=10

Table 2.7: InterpolationRoutine

[constr_5114] Semantics of InterpolationRoutine.isDefault dFor each

SwRecordLayout that is referenced by one or more InterpolationRoutineMap-
pings that are aggregated by InterpolationRoutineMappingSets that are ref-
erenced from a System in the role interpolationRoutineMappingSet, only one
of the collection of aggregated InterpolationRoutines shall have attribute isDe-
fault set to True.c()

53 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

3 Topology
This chapter explains how a vehicle’s physical System Topology is being modeled
in AUTOSAR (Example: Figure 3.1). A topology is formed by a number of EcuIn-
stances that are interconnected to each other in order to form ensembles of ECUs
and CommunicationClusters, which are further detailed by providing information
on bus-specific properties.
CAN CommunicationCluster:
1 PhysicalChannel

ECU1
ECU1 ECU2
ECU2 ECU3
ECU3 (GW)
(GW) ECU4
ECU4 ECU5
ECU5

Redundant FlexRay CommunicationCluster:

2 PhysicalChannels (bold line, thin line)

Figure 3.1: Example for a Communication Cluster within a physical network topology

In the AUTOSAR methodology [4] the topology description is one of the inputs for the
System Generator. It serves as constraints for mapping the Software Components
(see chapter 5.1) contained in the RootSwCompositionPrototype as well as for
defining the System Communication matrix (see chapter 6). Gateways which allow
the exchange of Signals between CommunicationClusters are covered in chapter
8.

54 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

FibexElement FibexElement
EcuInstance ClientIdRange
+clientIdRange «atpVariation»
+ comConfigurationGwTimeBase: TimeValue [0..1] «atpVariation» CommunicationCluster
0..1
+ comConfigurationRxTimeBase: TimeValue [0..1] + lowerLimit: Limit
+ baudrate: PositiveUnlimitedInteger [0..1]
+ comConfigurationTxTimeBase: TimeValue [0..1] + upperLimit: Limit
+ protocolName: String [0..1]
+ comEnableMDTForCyclicTransmission: Boolean [0..1]
+ protocolVersion: String [0..1]
+ ethSwitchPortGroupDerivation: Boolean [0..1]
+ pncPrepareSleepTimer: TimeValue [0..1]
+ pncSynchronousWakeup: Boolean [0..1]
+ pnResetTime: TimeValue [0..1]
+ sleepModeSupported: Boolean
+ v2xSupported: V2xSupportEnum [0..1]
+ wakeUpOverBusSupported: Boolean
«atpVariation,atpSplitable»

«atpVariation»
+commController
«atpVariation» +physicalChannel 1..*
+commController 1..* +connector * +commConnector Identifiable
Identifiable Identifiable PhysicalChannel
0..* «atpVariation»
«atpVariation» CommunicationConnector
CommunicationController 1 + createEcuWakeupSource: Boolean [0..1]
+ wakeUpByControllerSupported: Boolean [0..1] + dynamicPncToChannelMappingEnabled: Boolean [0..1] +managedPhysicalChannel 0..*
+ pncFilterArrayMask: PositiveInteger [0..*] {ordered}
+ pncGatewayType: PncGatewayTypeEnum [0..1]

«enumeration»
«atpVariation» PncGatewayTypeEnum

none
+ecuCommPortInstance 0..* active
«enumeration» Identifiable passive
V2xSupportEnum CommConnectorPort

v2xActiveSupported + communicationDirection: CommunicationDirectionType «enumeration»

v2xNotSupported CommunicationDirectionType

in
out

«enumeration»
IPduPort ISignalPort FramePort IPduSignalProcessingEnum
+ iPduSignalProcessing: IPduSignalProcessingEnum [0..1] + firstTimeout: TimeValue [0..1] deferred
+ rxSecurityVerification: Boolean [0..1] + handleInvalid: HandleInvalidEnum [0..1] immediate
+ timestampRxAcceptanceWindow: TimeValue [0..1] + timeout: TimeValue [0..1]
+ useAuthDataFreshness: Boolean [0..1]

Figure 3.2: Topology elements (Topology)

3.1 ECUs and their communication capabilities

Within a System Topology, the ECUs actually being connected with each other are
described in the form of EcuInstances. An EcuInstance needs to have one or
more CommunicationController, the actual hardware device by means of which
devices send and receive frames from the communication medium. Furthermore, the
EcuInstance has one or more CommunicationConnectors which describe the
bus interfaces of the ECUs and to specify the sending/receiving behavior.
[TPS_SYST_01004] Definition of AUTOSAR ECU dIn the AUTOSAR sense an ECU
means a microcontroller plus peripherals and the according software/configuration.
Therefore, each microcontroller requires its own ECU Configuration.c(RS_SYST_-
00013)

55 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

3.1.1 ECU Instance

[TPS_SYST_01005] Definition of EcuInstance dThe EcuInstance defines one

instance of the AUTOSAR stack.c(RS_SYST_00013)
The actual description of the ECU hardware resources is done by the means of the
ECU Resource Template [6]: It uses the HwElement class and its aggregated hard-
ware elements for defining a specific ECU type. In other words the Ecu Resource Tem-
plate “Ecu” is used to describe the physical box (HwElement of category Ecu) contain-
ing the electronics which may contain several microcontrollers with several AUTOSAR
Stack instances running.
[TPS_SYST_01006] Assign ECU type to EcuInstance dThe process of assigning
an ECU type to EcuInstance is a mapping step (see [TPS_SYST_01019]) and per-
formed latest in the System Generation step.c(RS_SYST_00013)
An EcuInstance can serve as a gateway if it is connected to two or more different
clusters by two or more of its CommunicationControllers.
Class EcuInstance
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreTopology
Note ECUInstances are used to define the ECUs used in the topology. The type of the ECU is defined by a
reference to an ECU specified with the ECU resource description.
Tags:atp.recommendedPackage=EcuInstances
Base ARObject, CollectableElement, FibexElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
associatedCom ISignalIPduGroup * ref With this reference it is possible to identify which ISignal
IPduGroup IPduGroups are applicable for which Communication
Connector/ ECU.
Only top level ISignalIPduGroups shall be referenced by
an EcuInstance. If an ISignalIPduGroup contains other
ISignalIPduGroups than these contained ISignalIPdu
Groups shall not be referenced by the EcuInstance.
Contained ISignalIPduGroups are associated to an Ecu
Instance via the top level ISignalIPduGroup.
associated ConsumedProvided * ref With this reference it is possible to identify which
Consumed ServiceInstanceGroup ConsumedProvidedServiceInstanceGroups are
Provided applicable for which ECUInstance.
ServiceInstance
Stereotypes: atpVariation
Group
Tags:vh.latestBindingTime=postBuild
associatedPdur PdurIPduGroup * ref With this reference it is possible to identify which PduR
IPduGroup IPdu Groups are applicable for which Communication
Connector/ ECU.
clientIdRange ClientIdRange 0..1 aggr Restriction of the Client Identifier for this Ecu to an
allowed range of numerical values. The Client Identifier of
the transaction handle is generated by the client RTE for
inter-Ecu Client/Server communication.
com TimeValue 0..1 attr The period between successive calls to Com_Main
Configuration FunctionRouteSignals of the AUTOSAR COM module in
GwTimeBase seconds.
com TimeValue 0..1 attr The period between successive calls to Com_Main
ConfigurationRx FunctionRx of the AUTOSAR COM module in seconds.
TimeBase
5

56 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class EcuInstance
com TimeValue 0..1 attr The period between successive calls to Com_Main
ConfigurationTx FunctionTx of the AUTOSAR COM module in seconds.
TimeBase
comEnable Boolean 0..1 attr Enables for the Com module of this EcuInstance the
MDTForCyclic minimum delay time monitoring for cyclic and repeated
Transmission transmissions (TransmissionModeTiming has cyclic
Timing assigned or eventControlledTiming with numberOf
Repetitions > 0).
commController Communication 1..* aggr CommunicationControllers of the ECU.
Controller
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
connector Communication * aggr All channels controlled by a single controller.
Connector
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
dltConfig DltConfig 0..1 aggr Describes the Dlt configuration on this EcuInstance.
doIpConfig DoIpConfig 0..1 aggr DoIp configuration on this EcuInstance.
Tags:atp.Status=draft
ecuTaskProxy OsTaskProxy * ref Reference to OsTaskProxies assigned to the Ecu
Instance.
Stereotypes: atpSplitable
Tags:atp.Splitkey=ecuTaskProxy
ethSwitchPort Boolean 0..1 attr Defines whether the derivation of SwitchPortGroups
Group based on VLAN and/or CouplingPort.pncMapping shall be
Derivation performed for this EcuInstance. If not defined the
derivation shall not be done.
partition EcuPartition * aggr Optional definition of Partitions within an Ecu.
pncPrepare TimeValue 0..1 attr Time in seconds the PNC state machine shall wait in
SleepTimer PNC_PREPARE_SLEEP.
pnc Boolean 0..1 attr If this parameter is available and set to true then all
Synchronous available PNCs will be woken up as soon as a channel
Wakeup wakeup occurs. This is ensured by adding all PNCs to all
channel wakeup sources during upstream mapping.
pnResetTime TimeValue 0..1 attr Specifies the runtime of the reset timer in seconds. This
reset time is valid for the reset of PN requests in the EIRA
and in the ERA.
sleepMode Boolean 1 attr Specifies whether the ECU instance may be put to a "low
Supported power mode"
• true: sleep mode is supported
• false: sleep mode is not supported
Note: This flag may only be set to "true" if the feature is
supported by both hardware and basic software.
tcpIpIcmpProps EthTcpIpIcmpProps 0..1 ref EcuInstance specific ICMP (Internet Control Message
Protocol) attributes
tcpIpProps EthTcpIpProps 0..1 ref EcuInstance specific TcpIp Stack attributes.
v2xSupported V2xSupportEnum 0..1 attr This attribute is used to control the existence of the V2X
stack on the given EcuInstance.
wakeUpOver Boolean 1 attr Driver support for wakeup over Bus.
BusSupported

Table 3.1: EcuInstance

[constr_3008] EcuInstance subelements dThe CommunicationConnector and

the CommunicationController that is referenced by the CommunicationCon-
nector shall be owned by the same EcuInstance.c()

57 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class ClientIdRange
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreTopology
Note With this element it is possible to restrict the Client Identifier of the transaction handle that is generated
by the client RTE for inter-Ecu Client/Server communication to an allowed range of numerical values.
Base ARObject
Attribute Type Mult. Kind Note
lowerLimit Limit 1 attr This specifies the lower limit of the ClientIdRange.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=preCompileTime
upperLimit Limit 1 attr This specifies the upper limit of the ClientIdRange.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=preCompileTime

Table 3.2: ClientIdRange

[constr_3116] Overlap of ClientIdRanges in the context of the enclosing Sys-

tem dThe ClientIdRange defined for an EcuInstance shall not overlap with the
ClientIdRange of any other EcuInstance in the context of the enclosing System.c
()

3.1.2 Communication Controller

[TPS_SYST_01007] Definition of CommunicationController dA Communication-

Controller is a dedicated hardware device by means of which hosts are sending
frames to and receiving frames from the communication medium.c(RS_SYST_00013)
[TPS_SYST_01008] Assign CommunicationController to the AUTOSAR Com-
munication Peripheral dIn order to illustrate the relationship of an Communi-
cationController to the HwElement with category CommunicationCon-
troller defined in the ECU Resource Description, a mapping between these two
classes may be specified using the CommunicationControllerMapping (see
[TPS_SYST_01014]).c(RS_SYST_00013)
Class <<atpVariation>> CommunicationController (abstract)
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreTopology
Note The communication controller is a dedicated hardware device by means of which hosts are sending
frames to and receiving frames from the communication medium.
Tags:vh.latestBindingTime=postBuild
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Subclasses AbstractCanCommunicationController , EthernetCommunicationController, FlexrayCommunication
Controller, LinCommunicationController , UserDefinedCommunicationController
Attribute Type Mult. Kind Note
5

58 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class <<atpVariation>> CommunicationController (abstract)
wakeUpBy Boolean 0..1 attr Defines whether the ECU shall be woken up by this
Controller CommunicationController.
Supported
TRUE: wake up is possible
FALSE: wake up is not supported
Note: If wakeUpByControllerSupported is set to TRUE
the feature shall be supported by both hardware and
basic software.
Table 3.3: CommunicationController

An EcuInstance may be connected to the same PhysicalChannel via two or more

CommunicationControllers. In most cases each of these CommunicationCon-
trollers will have a dedicated CommunicationConnector.
There may be rare use cases where an EcuInstance is connected to a Physi-
calChannel by one CommunicationController that in turn uses more than one
CommunicationConnector.

3.1.3 Communication Connector

[TPS_SYST_01009] Definition of CommunicationConnector dAn EcuInstance

uses CommunicationConnector elements in order to describe its bus interfaces and
to specify the sending/receiving behavior.c(RS_SYST_00013)
The relationship between an EcuInstance, a CommunicationController, and a
PhysicalChannel is expressed by letting a PhysicalChannel reference a Com-
municationConnector (which in turn is aggregated by EcuInstance) and which
also has the ability to reference a CommunicationController.
Class CommunicationConnector (abstract)
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreTopology
Note The connection between the referencing ECU and the referenced channel via the referenced controller.
Connectors are used to describe the bus interfaces of the ECUs and to specify the sending/receiving
behavior. Each CommunicationConnector has a reference to exactly one communicationController.
Note: Several CommunicationConnectors can be assigned to one PhysicalChannel in the scope of one
ECU Instance.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Subclasses AbstractCanCommunicationConnector , EthernetCommunicationConnector, FlexrayCommunication
Connector, LinCommunicationConnector, UserDefinedCommunicationConnector
Attribute Type Mult. Kind Note
5

59 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class CommunicationConnector (abstract)
commController Communication 1 ref Reference to the communication controller. The
Controller CommunicationConnector and referenced
CommunicationController shall be aggregated by the
same ECUInstance.
The communicationController can be referenced by
several CommunicationConnector elements. This is
important for the FlexRay Bus. FlexRay communicates
via two physical channels. But only one controller in an
ECU is responsible for both channels. Thus, two
connectors (for channel A and for channel B) shall
reference to the same controller.
createEcu Boolean 0..1 attr If this parameter is available and set to true then a
WakeupSource channel wakeup source shall be created for the Physical
Channel referencing this CommunicationConnector.
dynamicPncTo Boolean 0..1 attr Defines if this EcuInstance shall implement the dynamic
Channel PNC-to-channel-mapping functionality on this
Mapping CommunicationConnector and its respective Physical
Enabled Channel.
Tags:atp.Status=draft
ecuCommPort CommConnectorPort * aggr An ECUs reception or send ports.
Instance
atpVariation: If signals/PDUs/frames are variable, the
corresponding ports shall be variable, too.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
pncFilterArray PositiveInteger * attr Bit mask for NM-Pdu Payload used to configure the NM
Mask (ordered) filter mask for the Network Management.
Tags:atp.Status=draft
pncGateway PncGatewayTypeEnum 0..1 attr Defines if this EcuInstance shall implement the Pnc
Type Gateway functionality on this CommunicationConnector
and its respective PhysicalChannel. Several Ecu
Instances on the same PhysicalChannel can have the
PncGateway functionality enabled, but only one of them
shall have the pncGatewayType "active".

Table 3.4: CommunicationConnector

Enumeration PncGatewayTypeEnum
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreTopology
Note Defines the PncGateway roles.
Literal Description
active The active PncGateway functionality shall be performed
Tags:atp.EnumerationLiteralIndex=0
none No PncGateway functionality shall be performed
Tags:atp.EnumerationLiteralIndex=1
passive The passive PncGateway functionality shall be performed
Tags:atp.EnumerationLiteralIndex=2

Table 3.5: PncGatewayTypeEnum

Note: Use-case for the relation of several CommunicationConnectors assigned to

one PhysicalChannel in the scope of one EcuInstance: One safety measure for
a safety relevant ECU can be to have two transceivers (and two controllers) connected
to the same network (Bus). In case a safety violation is detected one transceiver can

60 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

be disabled and the respective Frames are blocked. The other transceiver stays active
and keeps the ECU alive for diagnostics.
The CommunicationConnector.pncFilterArrayMask is configured per commu-
nication connector. This data mask is calculated over the whole payload of the NmPdu
ignoring the leading bytes which do not contain pncVector information. The number of
leading bytes which shall be ignored is equivalent to the value of System.pncVecto-
rOffset.
The CommunicationConnector.pncFilterArrayMask is an ordered list of byte
(uint8) values which represent the PNC Vector layout.
The number of list elements corresponds to NmCluster.pncClusterVector-
Length, if defined, or System.pncVectorLength
[constr_3685] Allowed values for each element of pncFilterArrayMask dThe
value for each element of CommunicationConnector.pncFilterArrayMask shall
be in the range between 0 and 255.c()
[constr_3686] Allowed number of entries for pncFilterArrayMask dThe number
of CommunicationConnector.pncFilterArrayMask elements shall be:
• NmCluster.pncClusterVectorLength, if defined
• System.pncVectorLength, otherwise.
c()

3.2 Communication Clustering

3.2.1 Communication Cluster

[TPS_SYST_01010] Definition of CommunicationCluster dCommunication-

Cluster represents a formal way to express that a number of EcuInstances are
linked by an arbitrary topology (bus, star, ring, tree). Depending on the communication
standard, a CommunicationCluster may either have exactly one or more (redun-
dant) PhysicalChannels.c(RS_SYST_00013)
Note that all ECUs within a CommunicationCluster communicate within the same
address range.
Note that the same ECU can participate in more than one CommunicationCluster
if it has more than one CommunicationConnector being referenced by Physi-
calChannels owned by different CommunicationClusters.

61 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class <<atpVariation>> CommunicationCluster (abstract)

Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreTopology
Note The CommunicationCluster is the main element to describe the topological connection of communicating
ECUs.
A cluster describes the ensemble of ECUs, which are linked by a communication medium of arbitrary
topology (bus, star, ring, ...). The nodes within the cluster share the same communication protocol, which
may be event-triggered, time-triggered or a combination of both.
A CommunicationCluster aggregates one or more physical channels.
Tags:vh.latestBindingTime=postBuild
Base ARObject, CollectableElement, FibexElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Subclasses AbstractCanCluster , EthernetCluster, FlexrayCluster, LinCluster, UserDefinedCluster
Attribute Type Mult. Kind Note
baudrate PositiveUnlimitedInteger 0..1 attr Channels speed in bits/s.
physical PhysicalChannel 1..* aggr This relationship defines which channel element belongs
Channel to which cluster. A channel shall be assigned to exactly
one cluster, whereas a cluster may have one or more
channels.
Note: This atpSplitable property has no atp.Splitkey due
to atpVariation (PropertySetPattern).
Stereotypes: atpSplitable; atpVariation
Tags:vh.latestBindingTime=systemDesignTime
protocolName String 0..1 attr The name of the protocol used.
protocolVersion String 0..1 attr The version of the protocol used.

Table 3.6: CommunicationCluster

Some communication clusters need, additional to the general attributes which are valid
for all communication clusters, specialized attributes to describe the individual commu-
nication cluster properties. The bustype-specific specializations of Communication-
Cluster (Figure 3.3) are further detailed in chapter 3.3.

3.2.2 Physical Channel

[TPS_SYST_01011] Definition of PhysicalChannel dPhysicalChannel repre-

sents the communication medium that is used to send and receive information be-
tween communicating ECUs. Each CommunicationCluster has at least one Phys-
icalChannel.c(RS_SYST_00013)
[constr_3373] Limitation on the number of PhysicalChannels that are referenc-
ing a CommunicationConnector dA CommunicationConnector shall only be ref-
erenced by at most one PhysicalChannel.c()
Class PhysicalChannel (abstract)
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreTopology
5

62 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class PhysicalChannel (abstract)
Note A physical channel is the transmission medium that is used to send and receive information between
communicating ECUs. Each CommunicationCluster has at least one physical channel. Bus systems like
CAN and LIN only have exactly one PhysicalChannel. A FlexRay cluster may have more than one
PhysicalChannels that may be used in parallel for redundant communication.
An ECU is part of a cluster if it contains at least one controller that is connected to at least one channel of
the cluster.#
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Subclasses AbstractCanPhysicalChannel, EthernetPhysicalChannel, FlexrayPhysicalChannel, LinPhysicalChannel,
UserDefinedPhysicalChannel
Attribute Type Mult. Kind Note
comm Communication * ref Reference to the ECUInstance via a Communication
Connector Connector Connector to which the channel is connected.
atpVariation: Variable assignment of Physical Channels to
different CommunicationConnectors is expressed with
this variation.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
frameTriggering FrameTriggering * aggr One frame triggering is defined for exactly one channel.
Channels may have assigned an arbitrary number of
frame triggerings.
atpVariation: If signals/PDUs/frames are variable, the
corresponding triggerings shall be variable, too.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=frameTriggering.shortName, frame
Triggering.variationPoint.shortLabel
vh.latestBindingTime=postBuild
iSignal ISignalTriggering * aggr One ISignalTriggering is defined for exactly one channel.
Triggering Channels may have assigned an arbitrary number of
ISignaltriggerings.
atpVariation: If signals/PDUs/frames are variable, the
corresponding triggerings shall be variable, too.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=iSignalTriggering.shortName, iSignal
Triggering.variationPoint.shortLabel
vh.latestBindingTime=postBuild
managed PhysicalChannel * ref Reference between a channel with role managing
Physical channel and a channel with role managed channel.
Channel
pduTriggering PduTriggering * aggr One PduTriggering is defined for exactly one channel.
Channels may have assigned an arbitrary number of
I-Pdu triggerings.
atpVariation: If signals/PDUs/frames are variable, the
corresponding triggerings shall be variable, too.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=pduTriggering.shortName, pdu
Triggering.variationPoint.shortLabel
vh.latestBindingTime=postBuild

Table 3.7: PhysicalChannel

63 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

3.3 Specialized Attributes of the Topology Entities

According to their characteristic features, different communication standards like
FlexRay, CAN, TTCAN, LIN, J1939 and Ethernet have individual attributes that need to
be described additionally to the common topology classes. Figure 3.3 shows the spe-
cialization of the CommunicationCluster into the more specific FlexrayCluster,
CanCluster, TtcanCluster, J1939Cluster, LinCluster and EthernetClus-
ter.
FibexElement
«atpVariation»
CommunicationCluster

+ baudrate: PositiveUnlimitedInteger [0..1]

+ protocolName: String [0..1]
+ protocolVersion: String [0..1]

FlexrayCluster LinCluster EthernetCluster

+ actionPointOffset: Integer
+ couplingPortStartupActiveTime: TimeValue [0..1]
+ bit: TimeValue
+ couplingPortSwitchoffDelay: TimeValue [0..1]
+ casRxLowMax: Integer
+ coldStartAttempts: Integer
+ cycle: TimeValue
+ cycleCountMax: Integer AbstractCanCluster
+ detectNitError: Boolean
+ dynamicSlotIdlePhase: Integer + canFdBaudrate: PositiveUnlimitedInteger [0..1]
+ ignoreAfterTx: Integer
+ listenNoise: Integer
+ macroPerCycle: Integer
+ macrotickDuration: TimeValue
+ maxWithoutClockCorrectionFatal: Integer
+ maxWithoutClockCorrectionPassive: Integer
+ minislotActionPointOffset: Integer
+ minislotDuration: Integer
+ networkIdleTime: Integer CanCluster TtcanCluster
+ networkManagementVectorLength: Integer
+ basicCycleLength: Integer
+ numberOfMinislots: Integer
+ ntu: TimeValue
+ numberOfStaticSlots: Integer
+ operationMode: Boolean
+ offsetCorrectionStart: Integer
+ payloadLengthStatic: Integer
+ safetyMargin: Integer
+ sampleClockPeriod: TimeValue [0..1] J1939Cluster
+ staticSlotDuration: Integer
+ networkId: PositiveInteger [0..1]
+ symbolWindow: Integer
+ request2Support: Boolean [0..1]
+ symbolWindowActionPointOffset: Integer
+ usesAddressArbitration: Boolean [0..1]
+ syncFrameIdCountMax: Integer
+ tranceiverStandbyDelay: Float [0..1]
+ transmissionStartSequenceDuration: Integer
+ wakeupRxIdle: Integer
+ wakeupRxLow: Integer
+ wakeupRxWindow: Integer
+ wakeupTxActive: Integer
+ wakeupTxIdle: Integer

Figure 3.3: Specialized CommunicationCluster attributes (TopologyAttributeRefine-

ment)

64 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

3.3.1 CAN

Modeling of the CAN bus is supported in the System Template by the means of four
specialized meta-model classes: CanCluster, CanCommunicationController,
CanPhysicalChannel, CanCommunicationConnector (Figure 3.4).
Identifiable FibexElement

«atpVariation» «atpVariation»
CommunicationController CommunicationCluster

+ wakeUpByControllerSupported: Boolean [0..1] + baudrate: PositiveUnlimitedInteger [0..1]

+ protocolName: String [0..1]
+ protocolVersion: String [0..1]

AbstractCanCommunicationController
AbstractCanCluster

+ canFdBaudrate: PositiveUnlimitedInteger [0..1]

+canControllerAttributes 1
CanCommunicationController
AbstractCanCommunicationControllerAttributes
CanCluster

Identifiable +managedPhysicalChannel 0..* +busOffRecovery 0..1

PhysicalChannel
CanClusterBusOffRecovery

+ borCounterL1ToL2: PositiveInteger
+ borTimeL1: TimeValue
+ borTimeL2: TimeValue
+ borTimeTxEnsured: TimeValue [0..1]
CanControllerConfiguration
+ mainFunctionPeriod: TimeValue [0..1]
+ propSeg: Integer [0..1]
+ syncJumpWidth: Integer
AbstractCanPhysicalChannel + timeSeg1: Integer
+ timeSeg2: Integer
J1939Cluster

+ networkId: PositiveInteger [0..1]

CanControllerConfigurationRequirements
+ request2Support: Boolean [0..1]
+ maxNumberOfTimeQuantaPerBit: Integer [0..1] + usesAddressArbitration: Boolean [0..1]
+ maxSamplePoint: Float [0..1]
+ maxSyncJumpWidth: Float [0..1] Identifiable
+ minNumberOfTimeQuantaPerBit: Integer [0..1]
CommunicationConnector
+ minSamplePoint: Float [0..1]
CanPhysicalChannel + minSyncJumpWidth: Float [0..1] + createEcuWakeupSource: Boolean [0..1]
+ dynamicPncToChannelMappingEnabled: Boolean [0..1]
+canControllerFdAttributes 0..1 + pncFilterArrayMask: PositiveInteger [0..*] {ordered}
+ pncGatewayType: PncGatewayTypeEnum [0..1]
CanControllerFdConfiguration

+ paddingValue: PositiveInteger [0..1]

+ propSeg: PositiveInteger
+ sspOffset: PositiveInteger [0..1]
+ syncJumpWidth: PositiveInteger AbstractCanCommunicationConnector
+ timeSeg1: PositiveInteger
+ timeSeg2: PositiveInteger
+ txBitRateSwitch: Boolean

+canControllerFdRequirements 0..1
CanCommunicationConnector
CanControllerFdConfigurationRequirements
+ pncWakeupCanId: PositiveInteger [0..1]
+ maxNumberOfTimeQuantaPerBit: Integer [0..1] + pncWakeupCanIdExtended: Boolean [0..1]
+ maxSamplePoint: Float [0..1] + pncWakeupCanIdMask: PositiveInteger [0..1]
+ maxSyncJumpWidth: Float [0..1] + pncWakeupDataMask: PositiveUnlimitedInteger [0..1]
+ maxTrcvDelayCompensationOffset: TimeValue [0..1] + pncWakeupDlc: PositiveInteger [0..1]
+ minNumberOfTimeQuantaPerBit: Integer [0..1]
+ minSamplePoint: Float [0..1]
+ minSyncJumpWidth: Float [0..1]
+ minTrcvDelayCompensationOffset: TimeValue [0..1]
+ paddingValue: PositiveInteger [0..1]
+ txBitRateSwitch: Boolean [0..1]

Figure 3.4: CAN bus elements (Fibex4Can_Topology)

65 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

3.3.1.1 CAN Cluster

CanCluster specifies the existence of a CAN cluster in the system’s physical topol-
ogy. It contains additional CAN-specific cluster-wide attributes. The common CAN and
TTCAN attributes are collected in the AbstractCanCluster class.
Class <<atpVariation>> AbstractCanCluster (abstract)
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Can::CanTopology
Note Abstract class that is used to collect the common TtCAN, J1939 and CAN Cluster attributes.
Base ARObject, CollectableElement, CommunicationCluster , FibexElement, Identifiable, Multilanguage
Referrable, PackageableElement, Referrable
Subclasses CanCluster, J1939Cluster, TtcanCluster
Attribute Type Mult. Kind Note
busOffRecovery CanClusterBusOff 0..1 aggr CAN bus off monitoring / recovery at system level.
Recovery
canFdBaudrate PositiveUnlimitedInteger 0..1 attr Specifies the data segment baud rate of the controller in
bits/s.

Table 3.8: AbstractCanCluster

Class <<atpVariation>> CanCluster

Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Can::CanTopology
Note CAN bus specific cluster attributes.
Tags:atp.recommendedPackage=CommunicationClusters
Base ARObject, AbstractCanCluster , CollectableElement, CommunicationCluster , FibexElement, Identifiable,
MultilanguageReferrable, PackageableElement, Referrable
Attribute Type Mult. Kind Note
– – – – –
Table 3.9: CanCluster

Class CanClusterBusOffRecovery
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Can::CanTopology
Note This element contains the attributes that are used to configure the CAN bus off monitoring / recovery at
system level.
Base ARObject
Attribute Type Mult. Kind Note
borCounterL1To PositiveInteger 1 attr This threshold defines the count of bus-offs until the
L2 bus-off recovery switches from level 1 (short recovery
time) to level 2 (long recovery time).
borTimeL1 TimeValue 1 attr This attribute defines the duration of the bus-off recovery
time in level 1 (short recovery time) in seconds.
borTimeL2 TimeValue 1 attr This attribute defines the duration of the bus-off recovery
time in level 2 (long recovery time) in seconds.
borTimeTx TimeValue 0..1 attr This attribute defines the duration of the bus-off event
Ensured check in seconds.
mainFunction TimeValue 0..1 attr This attribute defines the cycle time of the function Can
Period SM_MainFunction in seconds.

Table 3.10: CanClusterBusOffRecovery

66 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

3.3.1.2 CAN Communication Controller

CanCommunicationController is a specialization of the abstract Communica-

tionController class. It contains the specific CAN controller attributes needed
for configuring the CAN stack in an ECU connected to a certain CAN cluster. The
common CAN and TTCAN attributes are collected in the AbstractCanCommunica-
tionController class. It is possible to specify the CAN Controller configuration
parameters as exact values or as requirements that have to be respected by the ECU
developer. Therefore the two elements CanControllerConfiguration and Can-
ControllerConfigurationRequirements were created.
Class <<atpVariation>> CanCommunicationController
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Can::CanTopology
Note CAN bus specific communication port attributes.
Base ARObject, AbstractCanCommunicationController , CommunicationController , Identifiable, Multilanguage
Referrable, Referrable
Attribute Type Mult. Kind Note
– – – – –
Table 3.11: CanCommunicationController

Class <<atpVariation>> AbstractCanCommunicationController (abstract)

Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Can::CanTopology
Note Abstract class that is used to collect the common TtCAN and CAN Controller attributes.
Base ARObject, CommunicationController , Identifiable, MultilanguageReferrable, Referrable
Subclasses CanCommunicationController, TtcanCommunicationController
Attribute Type Mult. Kind Note
canController AbstractCan 1 aggr CAN Bit Timing configuration
Attributes Communication
ControllerAttributes

Table 3.12: AbstractCanCommunicationController

Class AbstractCanCommunicationControllerAttributes (abstract)

Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Can::CanTopology
Note For the configuration of the CanController parameters two different approaches can be used:
1. Providing exact values which are taken by the ECU developer (CanControllerConfiguration).
2. Providing ranges of values which are taken as requirements and have to be respected by the
ECU developer (CanControllerConfigurationRequirements).
Base ARObject
Subclasses CanControllerConfiguration, CanControllerConfigurationRequirements
Attribute Type Mult. Kind Note
canControllerFd CanControllerFd 0..1 aggr Bit timing related configuration of a CAN controller for
Attributes Configuration payload and CRC of a CanFD frame. If this element
exists the controller supports CanFD frames and the ECU
developer shall take these values for the configuration of
the CanFD controller.
5

67 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class AbstractCanCommunicationControllerAttributes (abstract)
canControllerFd CanControllerFd 0..1 aggr Additional CanFD ranges of the bit timing related
Requirements Configuration configuration of a CanFD controller. If this element exists
Requirements the controller supports CanFD frames and the ECU
developer shall take these ranges as requirements for the
configuration of the CanFD controller.

Table 3.13: AbstractCanCommunicationControllerAttributes

Class CanControllerConfiguration
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Can::CanTopology
Note This element is used for the specification of the exact CAN Bit Timing configuration parameter values.
Base ARObject, AbstractCanCommunicationControllerAttributes
Attribute Type Mult. Kind Note
propSeg Integer 0..1 attr Specifies propagation delay in time quantas.
syncJumpWidth Integer 1 attr The number of quanta in the Synchronization Jump
Width, SJW. The (Re-)Synchronization Jump Width
(SJW) defines how far a resynchronization may move the
Sample Point inside the limits defined by the Phase Buffer
Segments to compensate for edge phase errors.
timeSeg1 Integer 1 attr Specifies phase segment 1 in time quantas.
timeSeg1 = Phase_Seg1
timeSeg2 Integer 1 attr Specifies phase segment 2 in time quantas.
timeSeg2 = Phase_Seg2

Table 3.14: CanControllerConfiguration

Class CanControllerConfigurationRequirements
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Can::CanTopology
Note This element allows the specification of ranges for the CAN Bit Timing configuration parameters. These
ranges are taken as requirements and have to be respected by the ECU developer.
Base ARObject, AbstractCanCommunicationControllerAttributes
Attribute Type Mult. Kind Note
maxNumberOf Integer 0..1 attr Maximum number of time quanta in the bit time.
TimeQuantaPer
Bit
maxSample Float 0..1 attr The max. value of the sample point as a percentage of
Point the total bit time.
maxSyncJump Float 0..1 attr The max. Synchronization Jump Width value as a
Width percentage of the total bit time. The (Re-)Synchronization
Jump Width (SJW) defines how far a resynchronization
may move the Sample Point inside the limits defined by
the Phase Buffer Segments to compensate for edge
phase errors.
minNumberOf Integer 0..1 attr Minimum number of time quanta in the bit time.
TimeQuantaPer
Bit
minSamplePoint Float 0..1 attr The min. value of the sample point as a percentage of the
total bit time.
5

68 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class CanControllerConfigurationRequirements
minSyncJump Float 0..1 attr The min. Synchronization Jump Width value as a
Width percentage of the total bit time. The (Re-)Synchronization
Jump Width (SJW) defines how far a resynchronization
may move the Sample Point inside the limits defined by
the Phase Buffer Segments to compensate for edge
phase errors.

Table 3.15: CanControllerConfigurationRequirements

[TPS_SYST_01154] CAN Controller support of CAN FD frames dThe bit timing

configuration of CAN controllers for CAN FD frames is supported by the CanCon-
trollerFdConfiguration element that is aggregated by AbstractCanCommu-
nicationControllerAttributes.c(RS_SYST_00048)
[constr_3095] canControllerFdAttributes and canControllerFdRequirements are
mutually exclusive dThe existence of canControllerFdAttributes and can-
ControllerFdRequirements is mutually exclusive.c()
[constr_3518] Range of CanControllerFdConfiguration.paddingValue and Can-
ControllerFdConfigurationRequirements.paddingValue dThe value given for Can-
ControllerFdConfiguration.paddingValue and CanControllerFdConfig-
urationRequirements.paddingValue shall be in the range from 0 to 255.c()
Class CanControllerFdConfiguration
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Can::CanTopology
Note Bit timing related configuration of a CAN controller for payload and CRC of a CAN FD frame.
Base ARObject
Attribute Type Mult. Kind Note
paddingValue PositiveInteger 0..1 attr Specifies the value which is used to pad unused data in
CAN FD frames which are bigger than 8 byte if the length
of a Pdu which was requested to be sent does not match
the allowed DLC values of CAN FD.
propSeg PositiveInteger 1 attr Specifies propagation delay in time quantas.
sspOffset PositiveInteger 0..1 attr Specifies the Transmitter Delay Compensation Offset in
minimum time quanta. Transmitter Delay Compensation
Offset is used to adjust the position of the Secondary
Sample Point (SSP), relative to the beginning of the
received bit. If this parameter is configured, the
Transmitter Delay Compensation is done by
measurement of the CAN controller. If not specified
Transmitter Delay Compensation is disabled.
syncJumpWidth PositiveInteger 1 attr Specifies the synchronization jump width for the controller
in time quantas.
timeSeg1 PositiveInteger 1 attr Specifies phase segment 1 in time quantas.
timeSeg2 PositiveInteger 1 attr Specifies phase segment 2 in time quantas.
5

69 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class CanControllerFdConfiguration
txBitRateSwitch Boolean 1 attr Specifies if the bit rate switching shall be used for
transmissions.
TRUE: CAN FD frames shall be sent with bit rate
switching.
FALSE: CAN FD frames shall be sent without bit rate
switching.

Table 3.16: CanControllerFdConfiguration

Class CanControllerFdConfigurationRequirements
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Can::CanTopology
Note This element allows the specification of ranges for the CanFD bit timing configuration parameters. These
ranges are taken as requirements and shall be respected by the ECU developer.
Base ARObject
Attribute Type Mult. Kind Note
maxNumberOf Integer 0..1 attr Maximum number of time quanta in the bit time.
TimeQuantaPer
Bit
maxSample Float 0..1 attr The max. value of the sample point as a percentage of
Point the total bit time.
maxSyncJump Float 0..1 attr The max. Synchronization Jump Width value as a
Width percentage of the total bit time. The (Re-)Synchronization
Jump Width (SJW) defines how far a resynchronization
may move the Sample Point inside the limits defined by
the Phase Buffer Segments to compensate for edge
phase errors.
maxTrcvDelay TimeValue 0..1 attr Specifies the maximum Transceiver Delay Compensation
Compensation Offset in seconds. If not specified Transceiver Delay
Offset Compensation is disabled.
minNumberOf Integer 0..1 attr Minimum number of time quanta in the bit time.
TimeQuantaPer
Bit
minSamplePoint Float 0..1 attr The min. value of the sample point as a percentage of the
total bit time.
minSyncJump Float 0..1 attr The min. Synchronization Jump Width value as a
Width percentage of the total bit time. The (Re-)Synchronization
Jump Width (SJW) defines how far a resynchronization
may move the Sample Point inside the limits defined by
the Phase Buffer Segments to compensate for edge
phase errors.
minTrcvDelay TimeValue 0..1 attr Specifies the minimum Transceiver Delay Compensation
Compensation Offset in seconds. If not specified Transceiver Delay
Offset Compensation is disabled.
paddingValue PositiveInteger 0..1 attr Specifies the value which is used to pad unused data in
CAN FD frames which are bigger than 8 byte if the length
of a Pdu which was requested to be sent does not match
the allowed DLC values of CAN FD.
txBitRateSwitch Boolean 0..1 attr Specifies if the bit rate switching shall be used for
transmissions.
TRUE: CAN FD frames shall be sent with bit rate
switching.
FALSE: CAN FD frames shall be sent without bit rate
switching.

Table 3.17: CanControllerFdConfigurationRequirements

70 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

3.3.1.3 CAN Physical Channel

CanPhysicalChannel is a specialization of the abstract PhysicalChannel class.

It contains the specific CAN PhysicalChannel attributes. The common CAN and
TTCAN attributes are collected in the AbstractCanPhysicalChannel class.
Class AbstractCanPhysicalChannel (abstract)
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Can::CanTopology
Note Abstract class that is used to collect the common TtCAN and CAN PhysicalChannel attributes.
Base ARObject, Identifiable, MultilanguageReferrable, PhysicalChannel, Referrable
Subclasses CanPhysicalChannel, TtcanPhysicalChannel
Attribute Type Mult. Kind Note
– – – – –
Table 3.18: AbstractCanPhysicalChannel

Class CanPhysicalChannel
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Can::CanTopology
Note CAN bus specific physical channel attributes.
Base ARObject, AbstractCanPhysicalChannel, Identifiable, MultilanguageReferrable, PhysicalChannel,
Referrable
Attribute Type Mult. Kind Note
– – – – –
Table 3.19: CanPhysicalChannel

[constr_3003] Number of CAN channels dCAN clusters shall aggregate exactly one
PhysicalChannel.c()

3.3.1.4 CAN Communication Connector

CanCommunicationConnector is a specialization of the abstract Communication-

Connector class. It contains the specific CAN CommunicationConnector at-
tributes. The common CAN and TTCAN attributes are collected in the Abstract-
CanCommunicationConnector class.
Class AbstractCanCommunicationConnector (abstract)
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Can::CanTopology
Note Abstract class that is used to collect the common TtCAN and CAN CommunicationConnector attributes.
Base ARObject, CommunicationConnector , Identifiable, MultilanguageReferrable, Referrable
Subclasses CanCommunicationConnector, TtcanCommunicationConnector
Attribute Type Mult. Kind Note
– – – – –
Table 3.20: AbstractCanCommunicationConnector

71 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class CanCommunicationConnector
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Can::CanTopology
Note CAN bus specific communication connector attributes.
Base ARObject, AbstractCanCommunicationConnector , CommunicationConnector , Identifiable,
MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
pncWakeupCan PositiveInteger 0..1 attr CAN Identifier used to configure the CAN Transceiver for
Id partial network wakeup.
pncWakeupCan Boolean 0..1 attr Defines whether pncWakeupCanId and pncWakeupCanId
IdExtended Mask shall be interpreted as extended or standard CAN
ID.
pncWakeupCan PositiveInteger 0..1 attr Bit mask for CAN Identifier used to configure the CAN
IdMask Transceiver for partial network wakeup.
pncWakeup PositiveUnlimitedInteger 0..1 attr Bit mask for CAN Payload used to configure the CAN
DataMask Transceiver for partial network wakeup.
pncWakeupDlc PositiveInteger 0..1 attr Data Length of the remote data frame used to configure
the CAN Transceiver for partial network wakeup in Bytes.

Table 3.21: CanCommunicationConnector

3.3.2 TTCAN

Modeling of TTCAN clusters is supported in the System Template by the means of

four specialized meta-model classes: TtcanCluster, TtcanCommunicationCon-
troller, TtcanCommunicationConnector, TtcanPhysicalChannel (figure
3.5).
CommunicationController CommunicationCluster
AbstractCanCommunicationController AbstractCanCluster

+ canFdBaudrate: PositiveUnlimitedInteger [0..1]

TtcanCommunicationController CanCommunicationController TtcanCluster CanCluster

+ applWatchdogLimit: Integer + basicCycleLength: Integer

+ expectedTxTrigger: Integer + ntu: TimeValue
+ externalClockSynchronisation: Boolean + operationMode: Boolean
+ initialRefOffset: Integer
+ master: Boolean
+ timeMasterPriority: Integer
+ timeTriggeredCanLevel: Integer
+ txEnableWindowLength: Integer

PhysicalChannel CommunicationConnector
AbstractCanPhysicalChannel AbstractCanCommunicationConnector

TtcanPhysicalChannel CanPhysicalChannel TtcanCommunicationConnector CanCommunicationConnector

+ pncWakeupCanId: PositiveInteger [0..1]

+ pncWakeupCanIdExtended: Boolean [0..1]
+ pncWakeupCanIdMask: PositiveInteger [0..1]
+ pncWakeupDataMask: PositiveUnlimitedInteger [0..1]
+ pncWakeupDlc: PositiveInteger [0..1]

Figure 3.5: TTCAN bus elements (Fibex4Ttcan_Topology)

72 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

3.3.2.1 TTCAN Cluster

TtcanCluster specifies the existence of a TTCAN cluster in the system’s physical

topology. Additionally to the common CAN and TTCAN attributes it contains TTCAN-
specific cluster-wide attributes.

73 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class <<atpVariation>> TtcanCluster

Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ttcan::TtcanTopology
Note TTCAN bus specific cluster attributes.
Tags:atp.recommendedPackage=CommunicationClusters
Base ARObject, AbstractCanCluster , CollectableElement, CommunicationCluster , FibexElement, Identifiable,
MultilanguageReferrable, PackageableElement, Referrable
Attribute Type Mult. Kind Note
basicCycle Integer 1 attr Length of a basic-cycle. Unit: NTUs
Length
ntu TimeValue 1 attr Unit measuring all times and providing a constant of the
whole network. For level 1, this is always the CAN bit
time. Unit: seconds.
operationMode Boolean 1 attr Possible operation modes
True: Time-Triggered
False: Event-Synchronised-Time-Triggered

Table 3.22: TtcanCluster

3.3.2.2 TTCAN Communication Controller

TtcanCommunicationController is a specialization of the AbstractCanCommu-

nicationController class. Additionally to the common CAN and TTCAN attributes
it contains the specific TTCAN Controller attributes.
Class <<atpVariation>> TtcanCommunicationController
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ttcan::TtcanTopology
Note TTCAN bus specific communication port attributes.
Base ARObject, AbstractCanCommunicationController , CommunicationController , Identifiable, Multilanguage
Referrable, Referrable
Attribute Type Mult. Kind Note
applWatchdog Integer 1 attr The Appl_Watchdog_Limit shall be an 8-bit value
Limit specifying the period for the application watchdog in
Appl_Watchdog_Limit times 256 NTUs.
expectedTx Integer 1 attr The Expected_Tx_Trigger shall be an eight (8) bit value
Trigger which limits the number of messages the FSE may try to
transmit in one matrix cycle.
externalClock Boolean 1 attr One bit shall be used to configure whether or not external
Synchronisation clock synchronisation will be allowed during runtime (only
Level 2).
initialRefOffset Integer 1 attr The Initial_Ref_Offset shall be an eight (8) bit value for
the initialisation of Ref_Trigger_Offset.
master Boolean 1 attr One bit shall be used to distinguish between (potential)
time masters and time slaves. This can be derived from
the frame-triggering’s triggers.
timeMaster Integer 1 attr The time master priority shall contain a three bit value for
Priority the priority of the current time master (the last three bits
of the identifier of the reference message). This can be
derived from the frame-triggering’s triggers.
5

74 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class <<atpVariation>> TtcanCommunicationController
timeTriggered Integer 1 attr One bit shall be used to distinguish between Level 1 and
CanLevel Level 2.
txEnable Integer 1 attr The length of the Tx_Enable window shall be a four (4) bit
WindowLength value specifying the length of the time period (1-16
nominal CAN bit times) in which a transmission may be
started.
Table 3.23: TtcanCommunicationController

3.3.2.3 TTCAN Physical Channel

TtcanPhysicalChannel is a specialization of the AbstractCanPhysicalChan-

nel class. Additionally to the common CAN and TTCAN attributes it contains the
specific TTCAN Physical Channel attributes.
Class TtcanPhysicalChannel
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ttcan::TtcanTopology
Note TTCAN bus specific physical channel attributes.
Base ARObject, AbstractCanPhysicalChannel, Identifiable, MultilanguageReferrable, PhysicalChannel,
Referrable
Attribute Type Mult. Kind Note
– – – – –
Table 3.24: TtcanPhysicalChannel

3.3.2.4 TTCAN Communication Connector

TtcanCommunicationConnector is a specialization of the AbstractCanCommu-

nicationConnector class. Additionally to the common CAN and TTCAN attributes
it contains the specific TTCAN CommunicationConnector attributes.
Class TtcanCommunicationConnector
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ttcan::TtcanTopology
Note TTCAN bus specific communication connector attributes.
Base ARObject, AbstractCanCommunicationConnector , CommunicationConnector , Identifiable,
MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
– – – – –
Table 3.25: TtcanCommunicationConnector

75 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

3.3.3 SAE J1939

Modeling of J1939 Communication Clusters is supported in the System Template with

the J1939Cluster element that is derived from AbstractCanCluster (see figure
3.4).
Class <<atpVariation>> J1939Cluster
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Can::CanTopology
Note J1939 specific cluster attributes.
Tags:atp.recommendedPackage=CommunicationClusters
Base ARObject, AbstractCanCluster , CollectableElement, CommunicationCluster , FibexElement, Identifiable,
MultilanguageReferrable, PackageableElement, Referrable
Attribute Type Mult. Kind Note
networkId PositiveInteger 0..1 attr This represents the network ID for the J1939 cluster.
re- Boolean 0..1 attr Enables support for the Request2 PGN (RQST2).
quest2Support
usesAddress Boolean 0..1 attr Defines whether the nodes attached to this channel use
Arbitration an initial address claim, and whether they react to
contending address claims of other nodes.
True: The initial address claim is sent, and the node
reacts to address claims of other nodes.
False: The node only sends an address claim upon
request, and does not care for contending address claims.

Table 3.26: J1939Cluster

To describe the communication on a J1939Cluster CanFrameTriggerings are

used that are aggregated by a CanPhysicalChannel.
[constr_3050] J1939Cluster uses exactly one CanPhysicalChannel dA
J1939Cluster shall aggregate exactly one CanPhysicalChannel.c()
[constr_1463] Applicable values for J1939Cluster.networkId dThe values of the
attribute J1939Cluster.networkId shall always be within the interval 1..4.c()
Please note that AUTOSAR supports only the four mentioned bus types. Still, an im-
plementation could e.g. support J1708 [14] by means of a complex driver and would
then need to assign the corresponding bus type.

76 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

3.3.4 FlexRay

Modeling of FlexRay clusters is supported in the System Template by the means

of four specialized meta-model classes: FlexrayCluster, FlexrayCommuni-
cationConnector, FlexrayPhysicalChannel, FlexrayCommunicationCon-
troller (Figure 3.6).

FibexElement +managedPhysicalChannel 0..* Identifiable

«atpVariation» Identifiable «atpVariation»
+physicalChannel CommunicationController
CommunicationCluster PhysicalChannel
+ 1..*
baudrate: PositiveUnlimitedInteger [0..1] «atpVariation,atpSplitable» + wakeUpByControllerSupported: Boolean [0..1]
+ protocolName: String [0..1]
+ protocolVersion: String [0..1]
+commController 1

FlexrayPhysicalChannel

+ channelName: FlexrayChannelName

FlexrayCluster FlexrayCommunicationController

+ actionPointOffset: Integer 0..1 «atpVariation» + acceptedStartupRange: Integer

+ bit: TimeValue +channel + allowHaltDueToClock: Boolean
+ casRxLowMax: Integer +commConnector 0..* + allowPassiveToActive: Integer [0..1]
+ coldStartAttempts: Integer Identifiable + clusterDriftDamping: Integer
+ cycle: TimeValue + decodingCorrection: Integer
CommunicationConnector
+ cycleCountMax: Integer + delayCompensationA: Integer [0..1]
+ detectNitError: Boolean + createEcuWakeupSource: Boolean [0..1] + delayCompensationB: Integer [0..1]
+ dynamicSlotIdlePhase: Integer + dynamicPncToChannelMappingEnabled: Boolean [0..1] + externalSync: Boolean [0..1]
+ ignoreAfterTx: Integer + pncFilterArrayMask: PositiveInteger [0..*] {ordered} + externOffsetCorrection: Integer [0..1]
+ listenNoise: Integer + pncGatewayType: PncGatewayTypeEnum [0..1] + externRateCorrection: Integer [0..1]
+ macroPerCycle: Integer + fallBackInternal: Boolean [0..1]
+ macrotickDuration: TimeValue + keySlotID: PositiveInteger [0..1]
+ maxWithoutClockCorrectionFatal: Integer + keySlotOnlyEnabled: Boolean
+ maxWithoutClockCorrectionPassive: Integer + keySlotUsedForStartUp: Boolean
FlexrayCommunicationConnector
+ minislotActionPointOffset: Integer + keySlotUsedForSync: Boolean
+ minislotDuration: Integer + nmReadySleepTime: Float [0..1] + latestTX: Integer
+ networkIdleTime: Integer + pncFilterDataMask: PositiveUnlimitedInteger [0..1] + listenTimeout: Integer
+ networkManagementVectorLength: Integer + wakeUpChannel: Boolean + macroInitialOffsetA: Integer [0..1]
+ numberOfMinislots: Integer + macroInitialOffsetB: Integer [0..1]
+ numberOfStaticSlots: Integer + maximumDynamicPayloadLength: Integer
+ offsetCorrectionStart: Integer + microInitialOffsetA: Integer [0..1]
+ payloadLengthStatic: Integer FlexrayFifoConfiguration + microInitialOffsetB: Integer [0..1]
+ safetyMargin: Integer + microPerCycle: Integer
+ sampleClockPeriod: TimeValue [0..1] + admitWithoutMessageId: Boolean + microtickDuration: TimeValue [0..1]
+flexrayFifo
+ staticSlotDuration: Integer + baseCycle: Integer + nmVectorEarlyUpdate: Boolean [0..1]
+ symbolWindow: Integer + cycleRepetition: Integer 0..* + offsetCorrectionOut: Integer
+ symbolWindowActionPointOffset: Integer + fifoDepth: Integer + rateCorrectionOut: Integer
+ syncFrameIdCountMax: Integer + msgIdMask: Integer + samplesPerMicrotick: Integer [0..1]
+ tranceiverStandbyDelay: Float [0..1] + msgIdMatch: Integer + secondKeySlotId: PositiveInteger [0..1]
+ transmissionStartSequenceDuration: Integer + twoKeySlotMode: Boolean [0..1]
+ wakeupRxIdle: Integer + wakeUpPattern: Integer
+ wakeupRxLow: Integer
+fifoRange 2..*
+ wakeupRxWindow: Integer
+ wakeupTxActive: Integer «enumeration»
FlexrayFifoRange
+ wakeupTxIdle: Integer FlexrayChannelName
+ rangeMax: Integer
+ rangeMin: Integer channelA
channelB

Figure 3.6: FlexRay cluster elements (Fibex4FlexRay_Topology)

3.3.4.1 FlexRay Cluster

FlexrayCluster specifies the existence of a FlexRay cluster in the system’s physical

topology. It contains additional FlexRay-specific cluster-wide attributes.
Class <<atpVariation>> FlexrayCluster
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Flexray::FlexrayTopology
Note FlexRay specific attributes to the physicalCluster
Tags:atp.recommendedPackage=CommunicationClusters
5

77 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class <<atpVariation>> FlexrayCluster
Base ARObject, CollectableElement, CommunicationCluster , FibexElement, Identifiable, Multilanguage
Referrable, PackageableElement, Referrable
Attribute Type Mult. Kind Note
actionPoint Integer 1 attr The offset of the action point in networks
Offset
bit TimeValue 1 attr Nominal bit time (= 1 / fx:SPEED). gdBit = cSamplesPer
Bit * gdSampleClockPeriod. Unit: seconds (gdBit)
casRxLowMax Integer 1 attr Upper limit of the Collision Avoidance Symbol (CAS)
acceptance window. Unit:bitDuration
coldStart Integer 1 attr The maximum number of times that a node in this cluster
Attempts is permitted to attempt to start the cluster by initiating
schedule synchronization
cycle TimeValue 1 attr Length of the cycle. Unit: seconds
cycleCountMax Integer 1 attr Maximum cycle counter value in a given cluster. Remark:
Set to 63 for FlexRay Protocol 2.1 Rev. A compliance.
detectNitError Boolean 1 attr Indicates whether NIT error status of each cluster shall be
detected or not.
dynamicSlotIdle Integer 1 attr The duration of the dynamic slot idle phase in minislots.
Phase
ignoreAfterTx Integer 1 attr Duration for which the bitstrobing is paused after
transmission [gdBit].
listenNoise Integer 1 attr Upper limit for the start up and wake up listen timeout in
the presence of noise. Expressed as a multiple of the
cluster constant pdListenTimeout. Unit microticks
macroPerCycle Integer 1 attr The number of macroticks in a communication cycle
macrotick TimeValue 1 attr Duration of the cluster wide nominal macrotick, expressed
Duration in s.
maxWithout Integer 1 attr Threshold concerning vClockCorrectionFailedCounter.
ClockCorrection Defines the number of consecutive even/odd Cycle pairs
Fatal with missing clock correction terms that will cause the
protocol to transition from the POC:normal active or
POC:normal passive state into the POC:halt state.
maxWithout Integer 1 attr Threshold concerning vClockCorrectionFailedCounter.
ClockCorrection Defines the number of consecutive even/odd Cycle pairs
Passive with missing clock correction terms that will cause the
protocol to transition from the POC:normal active state to
the POC:normal passive state.
minislotAction Integer 1 attr The Offset of the action point within a minislot. Unit:
PointOffset macroticks
minislotDuration Integer 1 attr The duration of a minislot (dynamic segment). Unit:
macroticks.
networkIdle Integer 1 attr The duration of the network idle time in macroticks
Time
network Integer 1 attr Length of the Network Management vector in a cluster
Management [bytes]
VectorLength
numberOf Integer 1 attr Number of Minislots in the dynamic segment.
Minislots
numberOfStatic Integer 1 attr The number of static slots in the static segment.
Slots
offsetCorrection Integer 1 attr Start of the offset correction phase within the Network
Start Idle Time (NIT), expressed as the number of macroticks
from the start of cycle. Unit: macroticks
payloadLength Integer 1 attr Globally configured payload length of a static frame. Unit:
Static 16-bit WORDS.
5

78 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class <<atpVariation>> FlexrayCluster
safetyMargin Integer 1 attr Additional timespan in macroticks which takes jitter into
account to be able to set the JobListPointer to the next
possible job which can be executed in case the FlexRay
Job List Execution Function has be resynchronized.
sampleClock TimeValue 0..1 attr Sample clock period. Unit: seconds
Period
staticSlot Integer 1 attr The duration of a slot in the static segment. Unit:
Duration macroticks
symbolWindow Integer 1 attr The duration of the symbol window. Unit: macroticks
symbolWindow Integer 1 attr Number of macroticks the action point offset is from the
ActionPoint beginning of the symbol window [Macroticks].
Offset
syncFrameId Integer 1 attr Maximum number of distinct syncframe identifiers present
CountMax in a given cluster. This parameter maps to FlexRay
Protocol 2.1 Rev. A parameter gSyncNodeMax.
tranceiver Float 0..1 attr The duration of timer t_TrcvStdbyDelay in seconds. The
StandbyDelay granularity of this parameter shall be restricted to full Flex
Ray cycles (cycle). The transceiver status setting to
STANDBY shall be delayed by this value.
Not specifying a value or a value of 0 shall imply that the
timer is not used.
transmission Integer 1 attr Number of bits in the Transmission Start Sequence [gd
StartSequence Bits].
Duration
wakeupRxIdle Integer 1 attr Number of bits used by the node to test the duration of
the ’idle’ or HIGH phase of a received wakeup. Unit:bit
Duration
Remarks: This parameter maps to FlexRay Protocol 2.1
Rev. A parameter gdWakeupSymbolRxIdle.
wakeupRxLow Integer 1 attr Number of bits used by the node to test the duration of
the LOW phase of a received wakeup. Unit:bitDuration
Remarks: This parameter maps to FlexRay Protocol 2.1
Rev. A parameter gdWakeupSymbolRxLow.
wakeupRx Integer 1 attr The size of the window used to detect wakeups [gdBit].
Window
Remarks: This parameter maps to FlexRay Protocol 2.1
Rev. A parameter gdWakeupSymbolRxWindow.
wakeupTxActive Integer 1 attr Number of bits used by the node to transmit the LOW
phase of awakeup symbol and the HIGH and LOW
phases of a WUDOP. Unit:bitDuration
wakeupTxIdle Integer 1 attr Number of bits used by the node to transmit the ’idle’ part
of a wakeup symbol. Unit: gDbit

Table 3.27: FlexrayCluster

3.3.4.2 FlexRay Communication Controller

FlexrayCommunicationController is a specialization of the Communication-

Controller class. It contains the specific FlexRay controller attributes needed for
configuring the FlexRay stack in an ECU connected to a certain FlexRay cluster.

79 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class <<atpVariation>> FlexrayCommunicationController

Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Flexray::FlexrayTopology
Note FlexRay bus specific communication port attributes.
Base ARObject, CommunicationController , Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
accepted Integer 1 attr Expanded range of measured clock deviation allowed for
StartupRange startup frames during integration. Unit:microtick
allowHaltDueTo Boolean 1 attr Boolean flag that controls the transition to the POC:halt
Clock state due to a clock synchronization errors. If set to true,
the Communication Controller is allowed to transition to
POC:halt. If set to false, the Communication Controller
will not transition to the POC:halt state but will enter or
remain in the normal POC (passive State).
allowPassiveTo Integer 0..1 attr Number of consecutive even/odd cycle pairs that shall
Active have valid clock correction terms before the
Communication Controller will be allowed to transition
from the POC:normal passive state to POC:normal active
state. If set to 0, the Communication Controller is not
allowed to transition from POC:norm
clusterDrift Integer 1 attr The cluster drift damping factor used in clock
Damping synchronization rate correction in microticks
decoding Integer 1 attr Value used by the receiver to calculate the difference
Correction between primary time reference point and secondary time
reference point. Unit: Microticks (pDecodingCorrection)
delay Integer 0..1 attr Value used to compensate for reception delays on
CompensationA channel A Unit: Microticks. This optional parameter shall
only be filled out if channel A is used.
delay Integer 0..1 attr Value used to compensate for reception delays on
CompensationB channel B. Unit: Microticks. This optional parameter shall
only be filled out if channel B is used.
externalSync Boolean 0..1 attr Flag indicating whether the node is externally
synchronized (operating as Time Gateway Sink in an
TT-E Time Triggered External Sync cluster) or locally
synchronized.
externOffset Integer 0..1 attr Fixed amount added or subtracted to the calculated offset
Correction correction term to facilitate external offset correction,
expressed in node-local microticks.
externRate Integer 0..1 attr Fixed amount added or subtracted to the calculated rate
Correction correction term to facilitate external rate correction,
expressed in node-local microticks.
fallBackInternal Boolean 0..1 attr Flag indicating whether a Time Gateway Sink node will
switch to local clock operation when synchronization with
the Time Gateway Source node is lost (pFallBackInternal
= true) or will instead go to POC:ready (pFallBackInternal
= false).
flexrayFifo FlexrayFifo * aggr One First In First Out (FIFO) queued receive structure,
Configuration defining the admittance criteria to the FIFO.
keySlotID PositiveInteger 0..1 attr ID of the slot used to transmit the startup frame, sync
frame, or designated single slot frame. If the attributes
keySlotUsedForStartUp, keySlotUsedForSync, or keySlot
OnlyEnabled are set to true the key slot value is
mandatory.
keySlotOnly Boolean 1 attr Flag indicating whether or not the node shall enter key
Enabled slot only mode following startup.
keySlotUsedFor Boolean 1 attr Flag indicating whether the Key Slot is used to transmit a
StartUp startup frame.
5

80 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class <<atpVariation>> FlexrayCommunicationController
keySlotUsedFor Boolean 1 attr Flag indicating whether the Key Slot is used to transmit a
Sync sync frame.
latestTX Integer 1 attr The number of the last minislot in which a transmission
can start in the dynamic segment for the respective node
listenTimeout Integer 1 attr Value for the startup listen timeout and wakeup listen
timeout. Although this is a node local parameter, the real
time equivalent of this value should be the same for all
nodes in the cluster. Unit: Microticks
macroInitial Integer 0..1 attr Integer number of macroticks between the static slot
OffsetA boundary and the closest macrotick boundary of the
secondary time reference point based on the nominal
macrotick duration. (pMacroInitialOffset). This optional
parameter shall only be filled out if channel A is used.
macroInitial Integer 0..1 attr Integer number of macroticks between the static slot
OffsetB boundary and the closest macrotick boundary of the
secondary time reference point based on the nominal
macrotick duration. (pMacroInitialOffset). This optional
parameter shall only be filled out if channel B is used.
maximum Integer 1 attr Maximum payload length for the dynamic channel of a
Dynamic frame in 16 bit WORDS.
PayloadLength
microInitial Integer 0..1 attr Number of microticks between the closest macrotick
OffsetA boundary described by gMacroInitialOffset and the
secondary time reference point. The parameter depends
on pDelayCompensationA and therefore it has to be set
independently for each channel. This optional parameter
shall only be filled out if channel A is used.
microInitial Integer 0..1 attr Number of microticks between the closest macrotick
OffsetB boundary described by gMacroInitialOffset and the
secondary time reference point. The parameter depends
on pDelayCompensationB and therefore it has to be set
independently for each channel. This optional parameter
shall only be filled out if channel B is used.
microPerCycle Integer 1 attr The nominal number of microticks in a communication
cycle
microtick TimeValue 0..1 attr Duration of a microtick. This attribute can be derived from
Duration samplePerMicrotick and gdSampleClockPeriod. Unit:
seconds
nmVectorEarly Boolean 0..1 attr Flag indicating when the update of the Network
Update Management Vector in the CHI shall take place. If set to
false, the update shall take place after the NIT. If set to
true, the update shall take place after the end of the static
segment.
offsetCorrection Integer 1 attr Magnitude of the maximum permissible offset correction
Out value. Unit:microtick (pOffsetCorrectionOut)
rateCorrection Integer 1 attr Magnitude of the maximum permissible rate correction
Out value and the maximum drift offset between two nodes
operating with unsynchronized clocks for one
communication cycle. Unit:Microticks (pRateCorrection
Out)
Remarks: This parameter maps to FlexRay Protocol 2.1
Rev. A parameter pdMaxDrift.
samplesPer Integer 0..1 attr Number of samples per microtick
Microtick
5

81 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class <<atpVariation>> FlexrayCommunicationController
secondKeySlot PositiveInteger 0..1 attr ID of the second Key slot, in which a second startup
Id frame shall be sent in TT-L Time Triggered Local Master
Sync or TT-E Time Triggered External Sync mode. If this
parameter is set to zero the node does not have a second
key slot.
twoKeySlot Boolean 0..1 attr Flag indicating whether node operates as a startup node
Mode in a TT-E Time Triggered External Sync or TT-L Time
Triggered Local Master Sync cluster.
wakeUpPattern Integer 1 attr Number of repetitions of the Tx-wakeup symbol to be sent
during the CC_WakeupSend state of this Node in the
cluster
Table 3.28: FlexrayCommunicationController

82 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class FlexrayFifoConfiguration
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Flexray::FlexrayTopology
Note One First In First Out (FIFO) queued receive structure, defining the admittance criteria to the FIFO, and
mandating the ability to admit messages into the FIFO based on Message Id filtering criteria.
Base ARObject
Attribute Type Mult. Kind Note
admitWithout Boolean 1 attr Boolean configuration which determines whether or not
MessageId frames received in the dynamic segment that don’t
contain a message ID will be admitted into the FIFO.
baseCycle Integer 1 attr FIFO cycle counter acceptance criteria.
channel FlexrayPhysicalChannel 0..1 ref Fifo channel admittance criteria.
cycleRepetition Integer 1 attr FIFO cycle counter acceptance criteria.
fifoDepth Integer 1 attr FrFifoDepth configures the maximum number of
rx-frames which can be contained in the FIFO.
fifoRange FlexrayFifoRange 2..* aggr FIFO Frame Id range acceptance criteria.
msgIdMask Integer 1 attr FIFO message identifier acceptance criteria (Mask filter).
msgIdMatch Integer 1 attr FIFO message identifier acceptance criteria (Match filter).

Table 3.29: FlexrayFifoConfiguration

Class FlexrayFifoRange
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Flexray::FlexrayTopology
Note FIFO Frame Id range acceptance criteria.
Base ARObject
Attribute Type Mult. Kind Note
rangeMax Integer 1 attr Max Range.
rangeMin Integer 1 attr Min Range.

Table 3.30: FlexrayFifoRange

83 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

3.3.4.3 FlexRay Communication Connector

FlexrayCommunicationConnector adds the FlexRay specific attributes to the

CommunicationConnector.
Class FlexrayCommunicationConnector
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Flexray::FlexrayTopology
Note FlexRay specific attributes to the CommunicationConnector
Base ARObject, CommunicationConnector , Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
nmReadySleep Float 0..1 attr The value of this attribute influences the shutdown
Time behavior of the FlexRay NM. FrNm switches to bus sleep
mode nmReadySleepTime seconds after the completion
of the last repetition cycle containing a NM vote.
pncFilterData PositiveUnlimitedInteger 0..1 attr Bit mask for FlexRay Payload used to configure the NM
Mask filter mask for the Network Management.
Tags:atp.Status=obsolete
wakeUp Boolean 1 attr Referenced channel used by the node to send a wakeup
Channel pattern. (pWakeupChannel)

Table 3.31: FlexrayCommunicationConnector

[constr_3508] Value of nmReadySleepTime dThe nmReadySleepTime value shall

be a multiple of cycle * nmRepetitionCycle.c()

3.3.4.4 FlexRay Physical Channel

FlexrayPhysicalChannel adds the FlexRay specific attributes to the Physi-

calChannel.
Class FlexrayPhysicalChannel
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Flexray::FlexrayTopology
Note FlexRay specific attributes to the physicalChannel
Base ARObject, Identifiable, MultilanguageReferrable, PhysicalChannel, Referrable
Attribute Type Mult. Kind Note
channelName FlexrayChannelName 1 attr Name of the channel (Channel A or Channel B).

Table 3.32: FlexrayPhysicalChannel

Enumeration FlexrayChannelName
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Flexray::FlexrayTopology
Note Name of the channel.
Literal Description
channelA Channel A
Tags:atp.EnumerationLiteralIndex=0
5

84 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Enumeration FlexrayChannelName
channelB Channel B
Tags:atp.EnumerationLiteralIndex=1

Table 3.33: FlexrayChannelName

[constr_3018] Number of FlexRay channels dA FlexrayCluster shall use ei-

ther one FlexrayPhysicalChannel with channelName set to either channelA or
channelB or else two FlexrayPhysicalChannels with one channelName chan-
nelA and one channelName channelB.c()

85 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

3.3.5 LIN

A LinCluster consists of exactly one master node connected to several slave nodes.
The master is responsible for providing the frame headers on the bus according to a
predefined schedule, whereas the slaves send or receive the actual frame information
([10]).
[TPS_SYST_01012] Different Properties of LinMaster and LinSlave dIn the Sys-
tem Template the different properties of master and slave nodes are handled by de-
riving the LIN-specific subclasses LinMaster and LinSlave as specializations of
LinCommunicationController.c(RS_SYST_00022)
AUTOSAR supports the stand-alone definition of both LIN masters and LIN slaves.
+managedPhysicalChannel 0..*

FibexElement Identifiable
«atpVariation» +physicalChannel PhysicalChannel
CommunicationCluster «atpVariation,atpSplitable» 1..*
+ baudrate: PositiveUnlimitedInteger [0..1]
+ protocolName: String [0..1]
+ protocolVersion: String [0..1]

LinPhysicalChannel
«atpVariation» + busIdleTimeoutPeriod: TimeValue [0..1]

+commConnector 0..*
Identifiable
Identifiable
«atpVariation» CommunicationConnector
CommunicationController +commController
+ createEcuWakeupSource: Boolean [0..1]
+ wakeUpByControllerSupported: Boolean [0..1] 1 + dynamicPncToChannelMappingEnabled: Boolean [0..1]
+ pncFilterArrayMask: PositiveInteger [0..*] {ordered}
+ pncGatewayType: PncGatewayTypeEnum [0..1]

LinCluster LinCommunicationController
LinCommunicationConnector
+ protocolVersion: String
+ initialNad: Integer [0..1]
+ scheduleChangeNextTimeBase: Boolean [0..1]

«atpVariation,atpSplitable»

+linConfigurableFrame 0..* +linOrderedConfigurableFrame 0..*

LinMaster LinSlave LinConfigurableFrame LinOrderedConfigurableFrame

+ timeBase: TimeValue [0..1] + assignNad: Boolean [0..1] + messageId: PositiveInteger [0..1] + index: Integer
+ timeBaseJitter: TimeValue [0..1] + configuredNad: Integer
+ functionId: PositiveInteger
+linConfigurableFrame

+ initialNad: Integer [0..1]

+linOrderedConfigurableFrame

0..* 0..*
+ nasTimeout: TimeValue [0..1]
+ supplierId: PositiveInteger
+ variantId: PositiveInteger

+linSlave 0..* +frame 1 +frame 1

Frame
LinSlaveConfig
LinFrame
+ configuredNad: Integer
+ functionId: PositiveInteger
+ initialNad: Integer [0..1]
+ protocolVersion: String [0..1]
+ supplierId: PositiveInteger
+ variantId: PositiveInteger

+ident 0..1 +linErrorResponse 0..1 +linErrorResponse 1 +iSignalTriggering 0..*

Referrable LinErrorResponse Identifiable

LinSlaveConfigIdent +responseError ISignalTriggering

0..1

Figure 3.7: Specialized LinCommunicationController attributes

(Fibex4Lin_Topology)

86 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_5252] LinSlaveConfig.protocolVersion shall exist dThe attribute

LinSlaveConfig.protocolVersion shall be defined at the time the Base EcuC
is created.c()
Note that the AUTOSAR BSW only supports LIN masters. LIN slaves are seen as
non AUTOSAR ECUs. They can be described in the System Template in order to
configure the LIN Interface for the master correctly, but AUTOSAR does not support
the development of LIN slaves as of AUTOSAR release 4.0 ([15], [16]).

3.3.5.1 LIN Cluster

LinCluster specifies the existence of a LIN cluster in the system’s physical topology.
Class <<atpVariation>> LinCluster
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Lin::LinTopology
Note LIN specific attributes
Tags:atp.recommendedPackage=CommunicationClusters
Base ARObject, CollectableElement, CommunicationCluster , FibexElement, Identifiable, Multilanguage
Referrable, PackageableElement, Referrable
Attribute Type Mult. Kind Note
– – – – –
Table 3.34: LinCluster

3.3.5.2 LIN Communication Controller

LinCommunicationController is a specialization of the CommunicationCon-

troller class. It is an abstract class, to be further specialized by LinMaster and
LinSlave.
Class <<atpVariation>> LinCommunicationController (abstract)
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Lin::LinTopology
Note LIN bus specific communication controller attributes.
Base ARObject, CommunicationController , Identifiable, MultilanguageReferrable, Referrable
Subclasses LinMaster, LinSlave
Attribute Type Mult. Kind Note
protocolVersion String 1 attr Version specifier for a communication protocol.

Table 3.35: LinCommunicationController

[TPS_SYST_02257] Standardized values of LinCommunicationController.

protocolVersion and LinSlaveConfig.protocolVersion dThe following
values of attributes LinCommunicationController.protocolVersion and
LinSlaveConfig.protocolVersion are standardized by AUTOSAR:
• LIN13

87 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• LIN20
• LIN21
• LIN22
• ISO17987
c(RS_SYST_00022)

3.3.5.3 LIN Master

LinMaster describes the existence of a LIN master task in a LIN topology node. As
such it contains the attributes specific to a LIN master task.
Class <<atpVariation>> LinMaster
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Lin::LinTopology
Note Describing the properties of the refering ecu as a LIN master.
Base ARObject, CommunicationController , Identifiable, LinCommunicationController , Multilanguage
Referrable, Referrable
Attribute Type Mult. Kind Note
linSlave LinSlaveConfig * aggr LinSlaves that are handled by the LinMaster.
timeBase TimeValue 0..1 attr Time base is mandatory for the master. It is not used for
slaves.
LIN 2.0 Spec states: "The time_base value specifies the
used time base in the master node to generate the
maximum allowed frame transfer time."
The time base shall be specified AUTOSAR conform in
seconds.
timeBaseJitter TimeValue 0..1 attr The attribute timeBaseJitter is a mandatory attribute for
the master and not used for slaves.
LIN 2.0 Spec states: "The jitter value specifies the
differences between the maximum and minimum delay
from time base start point to the frame header sending
start point (falling edge of BREAK signal)."
The jitter shall be specified AUTOSAR conform in
seconds.
Table 3.36: LinMaster

Class LinSlaveConfig
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Lin::LinTopology
Note Node attributes of LIN slaves that are handled by the LinMaster.
In the System Description LIN slaves may be described in the context of the Lin Master.
In an ECU Extract of the LinMaster the LinSlave Ecus shall not be available.
The information that is described here is necessary in the ECU Extract for the configuration of the Lin
Master.
The values of attributes of LinSlaveConfig and the corresponding LinSlave shall be identical (if both are
defined in a System Description).
Base ARObject
5

88 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class LinSlaveConfig
Attribute Type Mult. Kind Note
configuredNad Integer 1 attr To distinguish LIN slaves that are used twice or more
within the same cluster.
functionId PositiveInteger 1 attr LIN function ID.
ident LinSlaveConfigIdent 0..1 aggr This adds the ability to become referrable to LinSlave
Config.
initialNad Integer 0..1 attr Initial NAD of the LIN slave.
linConfigurable LinConfigurableFrame * aggr List of all frames that are processed by the slave node
Frame
linError LinErrorResponse 0..1 aggr Each slave node shall publish one response error in one
Response of its transmitted unconditional frames.
linOrdered LinOrderedConfigurable * aggr List of all frames (unconditional frames, event-triggered
Configurable Frame frames and sporadic frames) processed by the slave
Frame node. This element is necessary for the LIN 2.1
Assign-Frame-PID-Range command.
protocolVersion String 0..1 attr Version specifier for a communication protocol. Protocol
version of the LinMaster and the LinSlaves may be
different.
supplierId PositiveInteger 1 attr LIN Supplier ID.
variantId PositiveInteger 1 attr Specifies the Variant ID.

Table 3.37: LinSlaveConfig

Class LinSlaveConfigIdent
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Lin::LinTopology
Note This meta-class is created to add the ability to become the target of a reference to the non-Referrable Lin
SlaveConfig.
Base ARObject, Referrable
Attribute Type Mult. Kind Note
– – – – –
Table 3.38: LinSlaveConfigIdent

[constr_3219] The mutual existence of LinSlaves in the LinMaster EcuExtract

dLinSlaves shall not be part of the EcuExtract of the corresponding LinMaster.c()
[constr_1655] The mutual existence of LinMasters in the LinSlave EcuExtract
dA LinMaster shall not be part of the EcuExtract of a corresponding LinSlave.c()
[TPS_SYST_02101] Usage of LinSlaveConfig in Ecu Extract dIn order to config-
ure LinMaster in a System with category ECU_EXTRACT the LinSlaveConfig
aggregated by the LinMaster shall be used.c(RS_SYST_00022)
Please note that, in concordance with [TPS_SYST_02101], even if the LinSlave can
be modeled independently of the LinMaster it still makes sense that the the config-
uration of the LinMaster positively contains the aggregation of the LinSlave-
Config in the role linSlave.
In other words, the configuration of a LinMaster is not affected by the question of
whether or not the LinSlave is explicitly modeled.

89 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

This statement is valid for both the existence of the LinMaster in a System of cat-
egory SYSTEM_DESCRIPTION or in a System of category ECU_EXTRACT.
The actual correspondence between a Lin slave described by means of the
LinSlaveConfig and the actual model of the LinSlave shall be determined by
identifying pairs of LinSlaveConfig and LinSlave with an identical set of the at-
tributes that are equally named in both meta-classes. This rule does not apply for the
shortName.
Another relevant condition for finding pairs of corresponding LinSlaveConfig and
LinSlave is obviously that the LinMaster that aggregates the LinSlaveConfig
shall be connected to the same LinCluster to which the corresponding LinSlave
is connected.
Of course, this condition can only be checked in the context of a System of category
SYSTEM_DESCRIPTION or perhaps SYSTEM_EXTRACT.

3.3.5.4 LIN Slave

AUTOSAR supports the definition of a stand-alone LIN slave1 . In other words, it is pos-
sible to define an ECU Extract that contains the modeling of a LIN slave independently
of the modeling of the LIN master.
That said, the ability to define properties of the LIN slave in the context of the LIN mas-
ter in the form of LinMaster.linSlave still exists and can be used where applicable.
[TPS_SYST_05018] Semantics of meta-class LinSlave dMeta-class LinSlave
describes the existence of a LIN slave task in a LIN topology node. It describes the
attributes of a single LIN slave node.c(RS_SYST_00022)
[TPS_SYST_05019] Semantics of LinErrorResponse.responseError dEach Lin
slave has the ability to set an error bit in the response part of one specific LinUn-
conditionalFrame in the event of errors occurring on frame level. The error bit is
modeled by means of a reference to an ISignalTriggering in the role LinError-
Response.responseError.c(RS_SYST_00022)
Please note that because the response error bit applies for frame errors the responsi-
bility for setting the response error bit lies exclusively at the LinIf.
In the event of such an error, the LinIf on the Lin slave Ecu calls Com_SendSignal
() to set the value of the response error bit if applicable2 and thus the system model
needs to foresee the existence of an ISignalTriggering for this purpose.

1
In former versions of this specification document the properties of a LIN slave could only be defined
in the context of the corresponding LIN master
2
In principle, the LinIf on the Lin slave Ecu could directly patch the value of the response error bit
into a Tx Pdu before sending but in this case the LinIf would have to pick the correct Pdu and patch it
accordingly. In other words, the LinIf would replicate a certain amount of Com functionality. the usage
of an ISignalTriggering significantly simplifies the implementation of the LinIf.

90 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Aside: on the Lin master, typically a piece of application software picks up the received
error bit and uses it to e.g. increment a counter for debouncing purposes. If the counter
exceeds a certain value in e.g. a given time interval the Lin master has to assume
that a serious problem exists in the communication with this specific slave and react
accordingly.
In terms of modeling, this means that if formally modeled application software on the
Lin master exists that processes the error response bit (the receiving side of the error
response bit) then a DataMapping to a SystemSignal that carries the response
error bit needs to be defined.
It is important to understand that application software on a Lin slave positively has no
business of setting the value of the response error bit. In other words: on the sending
side (i.e. the Lin slave), the application software is not affected and therefore there shall
not be a DataMapping on the sending side. This relation motivates the existence of
[constr_1656].
[constr_1656] No application-level write access to LinErrorResponse.respon-
seError on Lin slave dThe SystemSignal referenced in the role systemSig-
nal by the ISignal referenced by the ISignalTriggering that in turn is refer-
enced in the role LinErrorResponse.responseError shall not be referenced by a
DataMapping that allows for writing to the SystemSignal.c()
Class <<atpVariation>> LinSlave
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Lin::LinTopology
Note Describing the properties of the referring ecu as a LIN slave.
Base ARObject, CommunicationController , Identifiable, LinCommunicationController , Multilanguage
Referrable, Referrable
Attribute Type Mult. Kind Note
assignNad Boolean 0..1 attr This attribute has the ability to control whether the node
configuration command ’Assign NAD’ is supported.
configuredNad Integer 1 attr To distinguish LIN slaves that are used twice or more
within the same cluster.
functionId PositiveInteger 1 attr LIN function ID
initialNad Integer 0..1 attr This attribute represents the initial NAD.
linError LinErrorResponse 1 aggr Each slave node shall publish one response error in one
Response of its transmitted unconditional frames.
nasTimeout TimeValue 0..1 attr Value of the N_AS timeout. Unit: seconds.
supplierId PositiveInteger 1 attr LIN Supplier ID
variantId PositiveInteger 1 attr Specifies the Variant ID

Table 3.39: LinSlave

Class LinErrorResponse
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Lin::LinCommunication
5

91 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class LinErrorResponse
Note Each slave node shall publish a one bit signal, named response_error, to the master node in one of its
transmitted unconditional frames. The response_error signal shall be set whenever a frame (except for
event triggered frame responses) that is transmitted or received by the slave node contains an error in
the frame response. The response_error signal shall be cleared when the unconditional frame containing
the response_error signal is successfully transmitted.
Base ARObject
Attribute Type Mult. Kind Note
responseError ISignalTriggering 0..1 ref This ISignal shall be taken to transport the responseError
bit.
Table 3.40: LinErrorResponse

3.3.5.5 LIN Communication Connector

LinCommunicationConnector is a specialization of the CommunicationConnec-

tor class. The LinCommunicationConnector element contains lists of frames pro-
cessed by the slave node.
[constr_3029] Assign-Frame command usage dFor the LIN 2.0 Assign-Frame com-
mand the LinConfigurableFrame list shall be used. For the LIN 2.1 Assign-Frame-
PID-Range command the LinOrderedConfigurableFrame list shall be used.c()
[constr_5030] Uniqueness of LinOrderedConfigurableFrame.index d
LinOrderedConfigurableFrame.index shall always be set and be unique
in the context of the aggregating LinCommunicationConnector.c()
Class LinCommunicationConnector
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Lin::LinTopology
Note LIN bus specific communication connector attributes.
Base ARObject, CommunicationConnector , Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
initialNad Integer 0..1 attr Initial NAD of the LIN slave.
linConfigurable LinConfigurableFrame * aggr LinConfigurableFrames shall list all frames (unconditional
Frame frames, event-triggered frames and sporadic frames)
processed by the slave node. This element is necessary
for the LIN 2.0 Assign-Frame command.
linOrdered LinOrderedConfigurable * aggr LinOrderedConfigurableFrames shall list all frames
Configurable Frame (unconditional frames, event-triggered frames and
Frame sporadic frames) processed by the slave node. This
element is necessary for the LIN 2.1
Assign-Frame-PID-Range command.
schedule Boolean 0..1 attr This attribute defines the point in time where a schedule
ChangeNext table switch is performed. If this attribute is set to false or
TimeBase not present, the schedule table shall be switched after the
current entry of the active schedule table is ended. If this
attribute is enabled, the schedule table shall be switched
when message transmission or reception within an entry
has been completed, ensured by status checks for
transmission and reception.

Table 3.41: LinCommunicationConnector

92 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class LinConfigurableFrame
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Lin::LinTopology
Note Assignment of messageIds to Frames. This element shall be used for the LIN 2.0 Assign-Frame
command.
Base ARObject
Attribute Type Mult. Kind Note
frame LinFrame 1 ref Reference to a Frame that is processed by the slave
node.
messageId PositiveInteger 0..1 attr MessageId for the referenced frame

Table 3.42: LinConfigurableFrame

Class LinOrderedConfigurableFrame
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Lin::LinTopology
Note With the assignment of the index to a frame a mapping of Pids to Frames is possible. This element shall
be used for the LIN 2.1 Assign-Frame-PID-Range command.
Base ARObject
Attribute Type Mult. Kind Note
frame LinFrame 1 ref Reference to a Frame that is processed by the slave
node.
index Integer 1 attr This attribute is used to order the elements and allows an
assignment of Pids to ConfigurableFrames that are
defined in the slave.
Table 3.43: LinOrderedConfigurableFrame

3.3.5.6 LIN Physical Channel

LinPhysicalChannel is a specialization of the PhysicalChannel class. It con-

tains additional Lin-specific PhysicalChannel attributes.
Class LinPhysicalChannel
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Lin::LinTopology
Note LIN specific attributes to the physicalChannel
Base ARObject, Identifiable, MultilanguageReferrable, PhysicalChannel, Referrable
Attribute Type Mult. Kind Note
busIdleTimeout TimeValue 0..1 attr This attribute shall be used to set an idle timeout period
Period for the enclosing LinPhysicalChannel.
scheduleTable LinScheduleTable * aggr Schedule tables organize the timings of the frames for
LIN.
atpVariation: If the transmitted frames are variable, the
corresponding ScheduleTables shall be variable, too.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild

Table 3.44: LinPhysicalChannel

[constr_3015] Number of LIN channels dLIN clusters shall aggregate exactly one
LinPhysicalChannel.c()

93 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

3.3.6 Ethernet

The EthernetCluster represents an Ethernet network which may consist of several

ECUs connected.
An essential aspect of modern Ethernet is the possibility to introduce Ethernet switches
in order to partition the EthernetCluster into segments which are used for point-
to-point communication between the respective partners. It is possible to define the
Example
behavior of such Ethernet switches, this is described in chapter 3.3.6.6.
EthernetCluster
Router CouplingElement

CouplingPort CouplingPortConnection

Switch Switch Switch

ECU ECU ECU

Figure 3.8: Example of an EthernetCluster

Figure 3.8 illustrates an example of an EthernetCluster. In this figure the focus is

on the Link Layer and represents the wiring of ECUs, their communication connectors,
- AUTOSAR Confidential -
switches, hubs, routers, and how these elements are connected electrically.
1

To describe the Ethernet at the data link- and physical layer the following System
Template meta-model classes are used: EthernetCluster, EthernetCommu-
nicationController, EthernetCommunicationConnector, EthernetPhys-
icalChannel, CouplingElement, CouplingPort and CouplingPortConnec-
tion (see Figure 3.9).
AUTOSAR supports the wake-up and sleep mechanism complying with the Open Al-
liance TC10 specification (OA TC10, see [17]), which is used for a switched Ethernet
network. The details are described in chapter 3.3.6.8.

94 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

FibexElement +managedPhysicalChannel
0..*
«atpVariation»
Identifiable
CommunicationCluster +physicalChannel
PhysicalChannel
+ baudrate: PositiveUnlimitedInteger [0..1] «atpVariation,atpSplitable» 1..*
+ protocolName: String [0..1]
+ protocolVersion: String [0..1]

FibexElement
EthernetPhysicalChannel
EcuInstance
EthernetCluster

+ couplingPortStartupActiveTime: TimeValue [0..1]

+vlanModifier
+ couplingPortSwitchoffDelay: TimeValue [0..1] «atpVariation»
+defaultVlan 0..1 0..1 +vlan 1 +ecuInstance 0..1
+vlan 0..1
1
Identifiable
+communicationCluster VlanConfig
«atpVariation»
+macMulticastGroup 0..*

Identifiable
+connector * +commConnector 0..*
MacMulticastGroup
VlanMembership Identifiable
+ macMulticastAddress: MacAddressString
CommunicationConnector

+macMulticastAddress 0..*

FibexElement +vlanMembership 0..* «atpVariation»

CouplingElement +commController 1..* +commController 1

+ couplingType: CouplingElementEnum Identifiable

«atpVariation»
CommunicationController

+ wakeUpByControllerSupported: Boolean [0..1]

«atpVariation,atpSplitable»
+couplingPort
Identifiable
0..* CouplingPort

+plcaProps + connectionNegotiationBehavior: EthernetConnectionNegotiationEnum [0..1]

+ couplingPortRole: CouplingPortRoleEnum [0..1]
PlcaProps
0..1 + macLayerType: EthernetMacLayerTypeEnum [0..1]
+ plcaLocalNodeId: PositiveInteger [0..1] + physicalLayerType: EthernetPhysicalLayerTypeEnum [0..1]
+ plcaMaxBurstCount: PositiveInteger [0..1] + receiveActivity: EthernetSwitchVlanIngressTagEnum [0..1]
+ plcaMaxBurstTimer: PositiveInteger [0..1]
+firstPort

+secondPort

+nodePort

+couplingPort
0..1 0..1 0..* 0..*
+wakeupSleepOnDatalineConfig 0..1

Identifiable
EthernetWakeupSleepOnDatalineConfig
«atpVariation,atpSplitable»
+couplingPortConnection «atpVariation,atpSplitable»
0..*

CouplingPortConnection EthernetCommunicationController

+ plcaLocalNodeCount: PositiveInteger [0..1] + macLayerType: EthernetMacLayerTypeEnum [0..1]

+ plcaTransmitOpportunityTimer: PositiveInteger [0..1] + macUnicastAddress: MacAddressString [0..1]
+ maximumReceiveBufferLength: Integer [0..1]
+ maximumTransmitBufferLength: Integer [0..1]
«enumeration» «enumeration» «enumeration»
+ slaveActAsPassiveCommunicationSlave: Boolean [0..1]
CouplingElementEnum EthernetPhysicalLayerTypeEnum EthernetConnectionNegotiationEnum
+ slaveQualifiedUnexpectedLinkDownTime: TimeValue [0..1]
switch 100BASE-TX master
hub 1000BASE-T slave
router 100BASE-T1 auto
1000BASE-T1 EthernetCommunicationConnector

«enumeration» iEEE802-11P «enumeration» + maximumTransmissionUnit: PositiveInteger [0..1]

CouplingPortRoleEnum 10BASE-T1S EthernetMacLayerTypeEnum + neighborCacheSize: PositiveInteger [0..1]
+ pathMtuEnabled: Boolean [0..1]
hostPort xMII
+ pathMtuTimeout: TimeValue [0..1]
upLinkPort xGMII
+ pncFilterDataMask: PositiveUnlimitedInteger [0..1]
standardPort xXGMII

«enumeration»
EthernetSwitchVlanIngressTagEnum

forwardAsIs
dropUntagged

Figure 3.9: Ethernet topology elements (Fibex4Ethernet_Topology)

[constr_5251] CouplingPort.connectionNegotiationBehavior shall exist

dThe attribute CouplingPort.connectionNegotiationBehavior shall be de-
fined at the time the Base EcuC is created.c()

95 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

3.3.6.1 Ethernet Cluster

Each EthernetCluster may have globally defined MacMulticast-

Groups. MacMulticastGroups have a macMulticastAddress (for example
01:00:5E:7F:FF:FF). One sender can handle many receivers simultaneously, if the
receivers have all the same macMulticastAddress.
[constr_3047] Uniqueness of macMulticastAddresses dA macMulticastAd-
dress shall be unique in a particular EthernetCluster.c()
For details on CouplingPort specific attributes of EthernetCluster in relation with
Partial Networks please refer to chapter 5.4.1.1.
Class <<atpVariation>> EthernetCluster
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Ethernet-specific cluster attributes.
Tags:atp.recommendedPackage=CommunicationClusters
Base ARObject, CollectableElement, CommunicationCluster , FibexElement, Identifiable, Multilanguage
Referrable, PackageableElement, Referrable
Attribute Type Mult. Kind Note
couplingPort CouplingPort * aggr Specification of connections between CouplingElements
Connection Connection and EcuInstances.
Note: This atpSplitable property has no atp.Splitkey due
to atpVariation (PropertySetPattern).
Stereotypes: atpSplitable; atpVariation
Tags:vh.latestBindingTime=postBuild
couplingPort TimeValue 0..1 attr The attribute specifies the time in second a coupling port
StartupActive is switched on to enable the host ECU (ECU that
Time maintains an Ethernet switch) to listen to the network for
potential network management requests.
couplingPort TimeValue 0..1 attr Switch off delay for CouplingPorts in seconds. It denotes
SwitchoffDelay the delay of switching off couplingPorts after the request
to switch off a couplingPort was issued. (e.g. switch off of
Ethernet switch ports).
macMulticast MacMulticastGroup * aggr MacMulticastGroup that is defined for the Subnet
Group (EthernetCluster).

Table 3.45: EthernetCluster

Class MacMulticastGroup
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Per EthernetCluster globally defined MacMulticastGroup. One sender can handle many receivers
simultaneously if the receivers have all the same macMulticastAddress. The addresses need to be
unique for the particular EthernetCluster.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
macMulticast MacAddressString 1 attr A multicast MAC address (Media Access Control
Address address) is a identifier for a group of hosts in a network.

Table 3.46: MacMulticastGroup

96 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_02362] Relevance of attribute EthernetCluster.baudrate dThe

value of the attribute baudrate in the context of an EthernetCluster has no mean-
ing and shall be ignored.c()
The communication speed is defined by the attribute CouplingPort.physicalLay-
erType of the involved CouplingPorts.

3.3.6.2 Ethernet Physical Channel

The EthernetPhysicalChannel represents a VLAN. VLANs (IEEE 802.1q) divide

physical Ethernet networks in logical subnets. Their realization requires switches with
VLAN support. VLANs are defined on a switch on a port-by-port basis.
The term EthernetPhysicalChannel may be misleading because it actually does
not defined the physical (electrical) attributes of the communication but the Ether-
netPhysicalChannel defines the VLANs as logical broadcast domains in which the
communication partners can interact.
Regardless whether the Ethernet communication uses tagged [TPS_SYST_01095] or
untagged [TPS_SYST_01096] VLANs all communication needs to be defined within
respective EthernetPhysicalChannels as defined in chapter 6.1.
[TPS_SYST_01095] tagged VLANs dIn the System Description a VLAN is repre-
sented by an EthernetPhysicalChannel and is identified by its vlanIdenti-
fier.c(RS_SYST_00039)
[TPS_SYST_01096] untagged VLANs dIf the VlanConfig and the vlanIdenti-
fier are not defined for an EthernetPhysicalChannel than the channel is called
“untagged”.c(RS_SYST_00039)
Every Frame that is sent over a “tagged” VLAN is tagged with a VLAN Tag. With this
tag every receiving switch has the information about the VLAN that the Frame belongs
to. The VLAN Tag that is attached to a Frame contains the user priority for the Frame
that is described with the defaultPriority and the vlanIdentifier.
Class EthernetPhysicalChannel
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note The EthernetPhysicalChannel represents a VLAN or an untagged channel. An untagged channel is
modeled as an EthernetPhysicalChannel without an aggregated VLAN.
Base ARObject, Identifiable, MultilanguageReferrable, PhysicalChannel, Referrable
Attribute Type Mult. Kind Note
network NetworkEndpoint * aggr Collection of NetworkEndpoints that are used in the VLan.
Endpoint
Stereotypes: atpSplitable
Tags:atp.Splitkey=networkEndpoint.shortName
soAdConfig SoAdConfig 0..1 aggr SoAd Configuration for one specific Physical Channel.
vlan VlanConfig 0..1 aggr VLAN Configuration.

Table 3.47: EthernetPhysicalChannel

97 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_3333] Standardized values for the attribute category of meta-class Eth-

ernetPhysicalChannel dThe following values of the attribute category of meta-
class EthernetPhysicalChannel are reserved by the AUTOSAR standard:
• WIRED: This represents the usage of the EthernetPhysicalChannel in case
of a wired ethernet connection
• WIRELESS: This represents the usage of the EthernetPhysicalChannel in
case of a wireless ethernet connection
c()
[TPS_SYST_02159] Default value for the attribute category of meta-class Eth-
ernetPhysicalChannel dThe default value for the category of an Ethernet-
PhysicalChannel shall be WIRED.c()
[constr_3334] Allowed references between EthernetPhysicalChannel and
EthernetCommunicationConnector dAn EthernetPhysicalChannel is only
allowed to reference EthernetCommunicationConnectors in the role commCon-
nector that have the same category value as the referencing EthernetPhysi-
calChannel.c()
[constr_3365] EthernetPhysicalChannels with different category values are
not allowed within an EthernetCluster dA mix of EthernetPhysicalChannels
with different category values within an EthernetCluster is currently not sup-
ported by AUTOSAR.c()
[constr_3336] EthernetPhysicalChannel.soAdConfig in case of WIRELESS
EthernetPhysicalChannel dIf EthernetPhysicalChannel has the category
WIRELESS then the EthernetPhysicalChannel shall not aggregate the SoAd-
Config.c()
[TPS_SYST_01086] Number of Ethernet channels dEach EthernetCluster may
aggregate up to 4096 EthernetPhysicalChannels.c(RS_SYST_00039)
Class VlanConfig
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note VLAN Configuration attributes
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
vlanIdentifier PositiveInteger 1 attr A VLAN is identified by this attribute according to IEEE
802.1Q. The allowed values range is from 0..4095.

Table 3.48: VlanConfig

[constr_3048] Range of vlanIdentifier dThe allowed values of vlanIdenti-

fier range from 0 to 4095.c()

98 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

3.3.6.2.1 VLAN Priority

The Priority is a 3-bit field which refers to the IEEE 802.1Q priority. It indicates the
frame priority level. Values are from 0 (best effort) to 7 (highest); 1 represents the
lowest priority. These values can be used to prioritize different classes of traffic (voice,
video, data, etc.). The priority is contained in the Ethernet Header together with the
vlanIdentifier.
The defaultPriority can be overwritten on different levels:
1. NetworkEndpoint
2. ApplicationEndpoint
3. ProvidedServiceInstance or ConsumedEventGroup
If a priority on an ApplicationEndpoint is defined the priorities in the Network-
Endpoint and the defaultPriority in the VlanMembership would be ignored.
The following table shows two CouplingPorts. Both have two NetworkEndpoints
and for each NetworkEndpoint two ApplicationEndpoints are defined. This
means that per Port two IP Addresses and four Tcp-Ports are used. On each level a
priority may be defined.
For NEP1.1 no priority is defined. This means that the Default-Priority from Coupling-
Port1 is valid. On CouplingPort1 all messages have the Priority 0 ("‘best effort"’) except
for messages that are going over ApplicationEndpoint AEP1.1.2 and AEP 1.2.2.
These messages have the priority 1 (higher priority). On CouplingPort2 the priority is
overwritten on several levels. Please note that AEP 2.2.1 and AEP 2.2.2 are reducing
the priority that is defined on the NEP2.2.
Port (Default-Prio) NetworkEndpoint (e.g. IpAd- ApplicationEndpoint (e.g. Tcp
dress) Port)
AEP 1.1.1: Prio. —
CouplingPort1: Prio.0 NEP1.1: Prio. — AEP 1.1.2: Prio. 1
AEP 1.2.1: Prio. —
NEP1.2: Prio. 0 AEP 1.2.2: Prio. 1
AEP 2.1.1: Prio. 2
CouplingPort2: Prio.0 NEP2.1: Prio. 1 AEP 2.1.2: Prio. 3
AEP 2.2.1: Prio. 1
NEP2.2: Prio. 2 AEP 2.2.2: Prio. 0

Table 3.49: VLAN Priority Example

3.3.6.3 Ethernet Coupling Elements and Coupling Ports

A CouplingElement is used to connect EcuInstances via CouplingPorts to

EthernetPhysicalChannels (VLANs) that are defined within an EthernetClus-
ter.

99 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

CouplingElements can reach from a simple hub to a complex managed switch or

even devices with functionalities in higher layers. A CouplingElement references
the EthernetCluster and contains a collection of available CouplingPorts. The
couplingType identifies the CouplingElement as a switch, hub or router.
Class CouplingElement
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note A CouplingElement is used to connect EcuInstances to the VLAN of an EthernetCluster. Coupling
Elements can reach from a simple hub to a complex managed switch or even devices with functionalities
in higher layers. A CouplingElement that is not related to an EcuInstance occurs as a dedicated single
device.
Tags:atp.recommendedPackage=CouplingElements
Base ARObject, CollectableElement, FibexElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
communication EthernetCluster 1 ref This relationship defines to which cluster the Coupling
Cluster Element belongs.
couplingPort CouplingPort * aggr Hardware Port of the CouplingElement that is used to
connect this CouplingPort to EcuInstances or other
CouplingElements.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=couplingPort.shortName, coupling
Port.variationPoint.shortLabel
vh.latestBindingTime=postBuild
couplingType CouplingElementEnum 1 attr Describes the coupling type of this CouplingElement.
ecuInstance EcuInstance 0..1 ref Optional reference to the ECU where the Coupling
Element is located.
Table 3.50: CouplingElement

Enumeration CouplingElementEnum
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Identifies the Coupling type.
Literal Description
hub A device that is used to connect segments of a LAN. In Hubs frames are "broadcasted" to every one
of its ports.
Tags:atp.EnumerationLiteralIndex=0
router A device that routes frames between different networks.
Tags:atp.EnumerationLiteralIndex=1
switch A device that filters and forwards frames between different LAN segments.
Tags:atp.EnumerationLiteralIndex=2

Table 3.51: CouplingElementEnum

[constr_3062] The EcuInstance that is referenced from a specific Couplin-

gElement shall be connected to the same EthernetCluster as the specific
CouplingElement dThe EcuInstance referenced from a specific CouplingEle-
ment in the role ecuInstance shall be connected via the CommunicationConnec-
tor and a EthernetPhysicalChannel that refers the CommunicationConnec-
tor to the EthernetCluster referenced by the specific CouplingElement in the
role communicationCluster.c()

100 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class CouplingPort
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note A CouplingPort is used to connect a CouplingElement with an EcuInstance or two CouplingElements with
each other via a CouplingPortConnection. Optionally, the CouplingPort may also have a reference to a
macMulticastGroup and a defaultVLAN.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
connection EthernetConnection 0..1 attr Specifies the connection negotiation of the CouplingPort.
Negotiation NegotiationEnum
Behavior
couplingPort CouplingPortDetails 0..1 aggr Defines more details of a CouplingPort in case a more
Details specific configuration is required.
couplingPort CouplingPortRoleEnum 0..1 attr Defines the role this CouplingPort takes in the context of
Role the CouplingElement.
defaultVlan EthernetPhysical 0..1 ref The vLanIdentifier of the referenced VLAN is the
Channel Default-PVID (port VLAN ID). A Port VLAN ID is a default
VLAN ID that is assigned to an access CouplingPort to
designate the VLAN segment to which this port is
connected. Also, if a CouplingPort has not been
configured with any VLAN memberships, the virtual
switch’s Port VLAN ID (pvid) becomes the default VLAN
ID for the ports connection.
This identifier/tag is added for incoming untagged
messages at the port (ingress tagging). For outgoing
messages with this identifier, the tag is removed at the
port (egress untagging, depending on the Vlan
Membership.sendActivity).
macLayerType EthernetMacLayerType 0..1 attr Specifies the mac layer type of the CouplingPort.
Enum
macMulticast MacMulticastGroup * ref Assigns a set of MAC-Multicast-Addresses which are
Address addressable via this CouplingPort. This is a static
pre-configuration and further addresses may be learned
during runtime.
physicalLayer EthernetPhysicalLayer 0..1 attr Specifies the physical layer type of the CouplingPort.
Type TypeEnum
plcaProps PlcaProps 0..1 aggr Optional properties for configuration of PLCA (Physical
Layer Collision Avoidance) in case 10-BASE-T1S
Ethernet is used and PLCA is enabled on the Coupling
Port (PHY).
pncMapping PncMappingIdent * ref Reference to the partial networks this CouplingPort
participates in.
receiveActivity EthernetSwitchVlan 0..1 attr Defines the handling of frames at the ingress port.
IngressTagEnum
vlan VlanMembership * aggr Messages of VLANs that are defined here can be
Membership communicated via the CouplingPort.
vlanModifier EthernetPhysical 0..1 ref All incoming messages at this CouplingPort shall be
Channel tagged with this VLAN Id. This tagging is performed
regardless whether the message already has a VLAN tag
or is untagged, an existing VLAN tag will be overwritten.
This feature is XOR with CoupligPort.defaultVlan.
wakeupSleep EthernetWakeupSleep 0..1 ref Optional reference to EthernetWakeupSleepOnDataline
OnDataline OnDatalineConfig Config.
Config

Table 3.52: CouplingPort

101 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Enumeration EthernetConnectionNegotiationEnum
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Specifies connection negotiation types of Ethernet transceiver links.
Literal Description
auto Automatic Negotiation
Tags:atp.EnumerationLiteralIndex=0
master Master
Tags:atp.EnumerationLiteralIndex=1
slave Slave
Tags:atp.EnumerationLiteralIndex=2

Table 3.53: EthernetConnectionNegotiationEnum

Enumeration EthernetMacLayerTypeEnum
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Specifies MAC (Media Access Control) Layer types.
Literal Description
xGMII Mac layer interface (data) bandwith class 1Gbit/s (e.g. GMII, RGMII, SGMII, RvGMII, USGMII)
Tags:
atp.EnumerationLiteralIndex=1
xml.name=XG-MII
xMII Mac layer interface (data) bandwith class 100Mbit/s and 10Mbit/s (e.g. RMII, RvMII, SMII, RvMII)
Tags:
atp.EnumerationLiteralIndex=0
xml.name=X-MII
xXGMII Mac layer interface (data) bandwith class 10Gbit/s
Tags:
atp.EnumerationLiteralIndex=2
xml.name=XXG-MII

Table 3.54: EthernetMacLayerTypeEnum

Enumeration EthernetPhysicalLayerTypeEnum
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Specifies physical layer types of Ethernet transceiver links.
Literal Description
_1000BASE_T Ethernet Standard (IEEE 802.3ab) to support 1Gbit/s over 4 twisted pairs.
Tags:
atp.EnumerationLiteralIndex=6
xml.name=1000BASE-T
_1000BASE_T1 Ethernet Standard (IEEE 802.3bp) to support 1Gbit/s over a single twisted pair cable.
Tags:
atp.EnumerationLiteralIndex=8
xml.name=1000BASE-T1
_100BASE_T1 Ethernet Standard (IEEE 802.3bw) to support 100Mbit/s over a single twisted pair cable.
100BASE-T1 is the IEEE Standardized version of BroadRReach.
Tags:
atp.EnumerationLiteralIndex=7
xml.name=100BASE-T1
5

102 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Enumeration EthernetPhysicalLayerTypeEnum
_100BASE_TX Ethernet Standard (IEEE 802.3u) to support 100Mbit/s over two twisted pairs.
Tags:
atp.EnumerationLiteralIndex=5
xml.name=100BASE-TX
_10BASE_T1S Physical layer interface 10BASE-T1S (10Mbit/s, 2 pairs). Used for automotive.
Tags:
atp.EnumerationLiteralIndex=10
atp.Status=draft
xml.name=10BASE-T1S
iEEE802_11P Ethernet Standard (IEEE 802.11p) to support wireless communication in vehicular environments.
Tags:
atp.EnumerationLiteralIndex=9
xml.name=IEEE802-11P

Table 3.55: EthernetPhysicalLayerTypeEnum

Enumeration EthernetSwitchVlanIngressTagEnum
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Defines the possible tagging behavior at an ingress port.
Literal Description
dropUntagged Drop if untagged.
Tags:atp.EnumerationLiteralIndex=1
forwardAsIs Forward with the same VLAN as received. Also untagged frames will be forwarded as untagged.
Tags:atp.EnumerationLiteralIndex=0

Table 3.56: EthernetSwitchVlanIngressTagEnum

Class VlanMembership
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Static logical channel or VLAN binding to a switch-port.
The reference to an EthernetPhysicalChannel without a VLAN defined represents the handling of
untagged frames.
Base ARObject
Attribute Type Mult. Kind Note
defaultPriority PositiveInteger 1 attr Standard output-priority outgoing Frames will be tagged
with.
Defines the priority that received frames are assigned
together with the VLAN Id (defaultVlan). The values from
0 (best effort) to 7 (highest) are allowed.
In case modifyVlan and an already tagged received
frame, the actual priority of the received frame is not
modified.
dhcpAddress DhcpServer 0..1 aggr Specifies the IP Address which will be assigned to a
Assignment Configuration DHCP Client at this SwitchPort. If no dhcpAddress
Assignment is provided all DHCP-Discover messages
received at this Port will be discarded by the DHCP
Server.
5

103 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class VlanMembership
sendActivity EthernetSwitchVlan 0..1 attr Attribute denotes whether a VLAN tagged ethernet frame
EgressTaggingEnum will be
1. sent with its VLAN tag (sentTagged)
2. sent without a VLAN tag (sentUntagged)
3. will be dropped at this port (notSent or VLAN not
member of this list)
vlan EthernetPhysical 1 ref References a channel that represents a VLAN or an
Channel untagged channel.

Table 3.57: VlanMembership

Class CouplingPortConnection
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Connection between two CouplingPorts (firstPort and secondPort) or between a collection of Ports that
are all referenced by the portCollection reference.
Base ARObject
Attribute Type Mult. Kind Note
firstPort CouplingPort 0..1 ref Reference to the first CouplingPort that is connected via
the CouplingPortConnection.
nodePort CouplingPort * ref Reference to a number of CouplingPorts that are
connected via the CouplingPortConnection. This
reference shall be used to describe a 10BASE-T1S
topology architecture where several CouplingPorts of
EthernetCommunicationControllers are connected via
one CouplingPortConnection.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=nodePort.couplingPort, nodePort.variation
Point.shortLabel
vh.latestBindingTime=postBuild
plcaLocalNode PositiveInteger 0..1 attr Defines the number of communication participants in
Count case 10BASE-T1S and the nodePort reference is used.
plcaTransmit PositiveInteger 0..1 attr Timer for the transmission in bit time to evaluate if a
Opportunity Transmission Opportunity is yield or not.
Timer
secondPort CouplingPort 0..1 ref Reference to the second CouplingPort that is connected
via the CouplingPortConnection.

Table 3.58: CouplingPortConnection

CouplingPorts are hardware ports of CouplingElements and EcuInstances.

Connections between CouplingPorts are realized through CouplingPortCon-
nections.
Optionally the CouplingPort of a CouplingElement may also have one or several
VlanMemberships, a defaultVlan reference and a reference to a MacMulticas-
tGroup.
[constr_3521] defaultVlan and vlanMembership dIf a CouplingPort refers to
an EthernetPhysicalChannel in the role defaultVlan the CouplingPort shall
also have a vlanMembership defined. This VlanMembership shall point to the
same EthernetPhysicalChannel in the role vlan as the defaultVlan.c()

104 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_3522] vlanModifier and vlanMembership dIf a CouplingPort refers

to an EthernetPhysicalChannel in the role vlanModifier the CouplingPort
shall also have a vlanMembership defined. This VlanMembership shall point to
the same EthernetPhysicalChannel in the role vlan as the vlanModifier.c()
[constr_3435] Applicability of CouplingPort.macMulticastAddress dThe ref-
erence CouplingPort.macMulticastAddress is only applicable if the Coupling-
Port is aggregated by a CouplingElement with couplingType = switch.c()
[constr_3133] physicalLayerType of connected CouplingPorts dThe physi-
calLayerType of two CouplingPorts which are connected via a CouplingPort-
Connection shall be equal.c()
[constr_3134] The connection of two CouplingPorts with connectionNegoti-
ationBehavior set to master is forbidden dThe connectionNegotiationBe-
havior of two CouplingPorts which are connected via a CouplingPortConnec-
tion shall not be both set to master.c()
[constr_3135] The connection of two CouplingPorts with connectionNegoti-
ationBehavior set to slave is forbidden dThe connectionNegotiationBe-
havior of two CouplingPorts which are connected via a CouplingPortConnec-
tion shall not be both set to slave.c()
[TPS_SYST_01097] Assignment of CouplingPorts to a VLAN dCouplingPorts
of CouplingElements can be assigned to VLANs (EthernetPhysicalChannels)
with the vlanMembership aggregation.c(RS_SYST_00039)
[TPS_SYST_01098] Assignment of CouplingPorts to an “untagged” VLAN dA
CouplingPort may be assigned to several VLANs, but only one of those assignments
can be “untagged”.c(RS_SYST_00039)
[constr_3534] EthernetPhysicalChannel shall only be referenced by one
VlanMembership dAn EthernetPhysicalChannel shall only be referenced by
one VlanMembership in the role VlanMembership.vlan in the scope of one Cou-
plingPort.c()
Figure 3.10 shows a CouplingElement with two CouplingPorts.
In this example Port 0 is assigned to three VLANs and one “untagged” Ethernet-
PhysicalChannel. VLAN3 is marked as the defaultVlan. With the combination
of the defaultVlan and the VlanMembership to the “untagged” EthernetPhysi-
calChannel the Frames that are transmitted over Port 0 on VLAN3 are “untagged” on
the wire in both directions (Tx and Rx). The switch adds the tag for incoming untagged
messages at the port (ingress tagging) and for outgoing messages the tag is removed
at the port (egress untagging).
Port 1 is assigned to three VLANs. But the VlanMembership to the “untagged”
EthernetPhysicalChannel is not defined here. For this reason, Frames that are
transmitted over Port 1 on VLAN3 are “tagged”.

105 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

If a defaultVlan is defined for a CouplingPort but the defaultVlan is not ref-

erenced by the VlanMembership then “untagged” Frames can be received via the
CouplingPort. But a response can not be send back.

Switch
VLanMember: Vlan1
Vlan1, Vlan2, Vlan3,
untagged
Vlan2 Wire
Untagged
Default:
VLAN3 Port0

VLanMember: Vlan1
Vlan1, Vlan2, Vlan3,
Vlan2 Wire
Vlan3
Default:
VLAN3 Port1

Figure 3.10: Default Vlan Example

3.3.6.4 Ethernet Communication -Controller

AUTOSAR Confidential -
3

EthernetCommunicationController is a specialization of the Communication-

Controller class. It contains the specific Ethernet controller attributes needed for
configuring an EcuInstance connected to a certain Ethernet cluster.
Class <<atpVariation>> EthernetCommunicationController
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Ethernet specific communication port attributes.
Base ARObject, CommunicationController , Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
couplingPort CouplingPort * aggr Optional CouplingPort that can be used to connect the
ECU to a CouplingElement (e.g. a switch).
macLayerType EthernetMacLayerType 0..1 attr Specifies the mac layer type of the ethernet controller.
Enum
macUnicast MacAddressString 0..1 attr Media Access Control address (MAC address) that
Address uniquely identifies each EthernetCommunication
Controller in the network.
maximum Integer 0..1 attr Determines the maximum receive buffer length (frame
ReceiveBuffer length) in bytes.
Length
maximum Integer 0..1 attr Determines the maximum transmit buffer length (frame
TransmitBuffer length) in bytes.
Length
5

106 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class <<atpVariation>> EthernetCommunicationController
slaveActAs Boolean 0..1 attr This attribute specifies if the EcuInstance is acting as a
Passive passive communication slave on the connected Physical
Communication Channel. This is used for EthernetCommunication
Slave Controllers that use Ethernet hardware which supports
wake-up and sleep on the network (e.g. Open Alliance
TC10 compliant Ethernet hardware).
Tags:atp.Status=draft
slaveQualified TimeValue 0..1 attr This attribute specifies time when an unexpected link
UnexpectedLink down is evaluated as link down and indicated to the
DownTime AUTOSAR communication stack.
Tags:atp.Status=draft

Table 3.59: EthernetCommunicationController

[constr_3535] EthernetCommunicationController shall aggregate at most

one CouplingPort dAn EthernetCommunicationController is allowed to ag-
gregate at most one CouplingPort.c()
[constr_3332] Standardized values for the attribute category of meta-class
EthernetCommunicationController dThe following values of the attribute cat-
egory of meta-class EthernetCommunicationController are reserved by the
AUTOSAR standard:
• WIRED: This represents the usage of the EthernetCommunicationCon-
troller in case of a wired ethernet connection
• WIRELESS: This represents the usage of the EthernetCommunicationCon-
troller in case of a wireless ethernet connection
c()
[TPS_SYST_02158] Default value for the attribute category of meta-class Eth-
ernetCommunicationController dThe default value for the category of an
EthernetCommunicationController shall be WIRED.c()
The EthernetCommunicationController has the additional information of a ma-
cUnicastAddress. This is a globally unique MAC-address for the Communication-
Controller.

3.3.6.5 Ethernet Communication Connector

EthernetCommunicationConnector adds the Ethernet specific attributes to the

CommunicationConnector.
Class EthernetCommunicationConnector
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Ethernet specific attributes to the CommunicationConnector.
5

107 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class EthernetCommunicationConnector
Base ARObject, CommunicationConnector , Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
ethIpProps EthIpProps 0..1 ref EcuInstance specific IP attributes.
maximum PositiveInteger 0..1 attr This attribute specifies the maximum transmission unit in
Transmission bytes.
Unit
neighborCache PositiveInteger 0..1 attr This attribute specifies the size of neighbor cache or ARP
Size table in units of entries.
pathMtu Boolean 0..1 attr If enabled the IPv4/IPv6 processes incoming ICMP
Enabled "Packet Too Big" messages and stores a MTU value for
each destination address.
pathMtuTimeout TimeValue 0..1 attr If this value is >0 the IPv4/IPv6 will reset the MTU value
stored for each destination after n seconds.
pncFilterData PositiveUnlimitedInteger 0..1 attr Bit mask for Ethernet Payload used to configure the NM
Mask filter mask for the Network Management.
Tags:atp.Status=obsolete

Table 3.60: EthernetCommunicationConnector

[constr_3331] Standardized values for the attribute category of meta-class Eth-

ernetCommunicationConnector dThe following values of the attribute category
of meta-class EthernetCommunicationConnector are reserved by the AUTOSAR
standard:
• WIRED: This represents the usage of the EthernetCommunicationConnec-
tor in case of a wired ethernet connection
• WIRELESS: This represents the usage of the EthernetCommunicationCon-
nector in case of a wireless ethernet connection
c()
[TPS_SYST_02157] Default value for the attribute category of meta-class Eth-
ernetCommunicationConnector dThe default value for the category of an Eth-
ernetCommunicationConnector shall be WIRED.c()
[constr_3335] Allowed references between EthernetCommunicationConnec-
tor and EthernetCommunicationController dAn EthernetCommunication-
Connector is only allowed to reference an EthernetCommunicationController
in the role commController that has the same category value as the referencing
EthernetCommunicationConnector.c()

3.3.6.6 Ethernet Switch Driver

Ethernet networks in an automotive environment consist basically of ECUs with a single

port PHY and switch ECUs with several ports. Different to consumer networks, where
switches are typically stand-alone devices, switches in automotive networks may be
integrated and connected to a CPU via MII and other interfaces. The configuration of
these switches does influence the communication behavior within the network.

108 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

3.3.6.6.1 Ethernet switch port structure

In order to describe switched Ethernet networks it is essential to describe some parts

of an Ethernet switch. Examples are scheduling and forwarding mechanisms within a
switch as well as the switch structure within its ports.
As shown in figure 3.11, the switch consists of a certain number of ports. Each port
has its own set of egress FIFOs in which the incoming packets are buffered. How
the messages in the FIFOs will be forwarded depends mainly on the shaping and port
Concept
scheduling mechanisms. Thus, the parametrization of the egress port influences the
“Ethernet Configuration and System Description for Manageable Switched Systems”
latency of messages within the network.
Version 0.1
Please note that the egress port structures in figure 3.11 are meant as an example.
Other structures with different FIFO numbers are possible as well.
As shown in Figure 13.2

Fig. 5, the switch consists

Figure 3.11: of a certain
Example number
egress of ports.
switch port Each port has its own set of
configurations
egress FIFOs in which the incoming packets are buffered. How the messages in the
FIFOs will be forwarded depends mainly on the shaping and port scheduling
mechanisms. Thus, the parameterization of the egress port influences the latency of
messages within the network.

Please note that the egress port structures in Figure 13.2

Fig. 5 are meant as an example. Other structures with different FIFO numbers are
possible as well.

109 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

Figure 13.2: Example egress port configurations

System Template
AUTOSAR CP R21-11

«enumeration» FibexElement
VlanMembership
CouplingElementEnum CouplingElement
+ defaultPriority: PositiveInteger
switch + couplingType: CouplingElementEnum + sendActivity: EthernetSwitchVlanEgressTaggingEnum [0..1]
hub
router
+vlanMembership 0..*
«atpVariation,atpSplitable»
+couplingPort 0..*

Identifiable +vlan 1
CouplingPort
+defaultVlan PhysicalChannel
+ connectionNegotiationBehavior: EthernetConnectionNegotiationEnum [0..1] EthernetPhysicalChannel
+ couplingPortRole: CouplingPortRoleEnum [0..1] 0..1
+ macLayerType: EthernetMacLayerTypeEnum [0..1]
+ physicalLayerType: EthernetPhysicalLayerTypeEnum [0..1] +vlanModifier
+ receiveActivity: EthernetSwitchVlanIngressTagEnum [0..1]
0..1

+vLan 0..*
+couplingPortDetails 0..1

CouplingPortDetails +ratePolicy CouplingPortRatePolicy

0..* + dataLength: PositiveInteger
+ policyAction: CouplingPortRatePolicyActionEnum
+ priority: PositiveInteger [0..1]
+ timeInterval: TimeValue
+couplingPortStructuralElement 1..*

+predecessor Identifiable «enumeration»

CouplingPortStructuralElement CouplingPortRatePolicyActionEnum
1..*
{ordered} dropFrame
blockSource

+lastEgressScheduler 0..1

CouplingPortScheduler CouplingPortShaper

+ portScheduler: EthernetCouplingPortSchedulerEnum + idleSlope: PositiveInteger [0..1]

+predecessorFifo 1
«enumeration»
EthernetCouplingPortSchedulerEnum
CouplingPortFifo
deficitRoundRobin
+ assignedTrafficClass: PositiveInteger [0..8]
strictPriority
+ minimumFifoLength: PositiveInteger [0..1]
weightedRoundRobin

«enumeration»
EthernetSwitchVlanIngressTagEnum

forwardAsIs
dropUntagged

Figure 3.12: Egress switch port structure

The structural description of an Ethernet switch is based on the already existing Cou-
plingElement in the System Template. Each CouplingElement can already have
a set of CouplingPorts.
In case a detailed Switch configuration is required, there is the configuration option to
add to the CouplingPort a CouplingPortDetails element which encapsulates
the structural description of one switch port.
The elements which one switch port consists of are (egress side):
• CouplingPortFifo
• CouplingPortShaper
• CouplingPortScheduler
The model allows to collect the egress parts of one switch port in the CouplingPort-
Details.couplingPortStructuralElements.

110 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_03006] Ethernet switch egress port setup dTwo setups can be defined
at an egress port of a switch:
• The switch port has only one Fifo:
– the CouplingPortFifo element is aggregated at the CouplingPortDe-
tails.couplingPortStructuralElements
– no CouplingPortDetails.lastEgressScheduler is defined.
• The switch port has at least one scheduler
– the various switch port elements are all aggregated at the CouplingPort-
Details.couplingPortStructuralElements
– the CouplingPortScheduler which is the last scheduler in a chain of
structural elements is additionally referenced in the role CouplingPort-
Details.lastEgressScheduler
c(RS_SYST_00052)
The modeling approach is based on a predecessor chain model where the chain is
started by the last scheduler in the switch port and defines where the input to this
scheduler comes from. The input to a scheduler can come from several predecessor
elements which might be
• another CouplingPortScheduler
• a CouplingPortShaper
• a CouplingPortFifo.
[TPS_SYST_03007] Ethernet port scheduler algorithm dThe scheduler performs a
prioritization of the incoming frames based on the algorithm defined in the Coupling-
PortScheduler.portScheduler.c(RS_SYST_00052)
[TPS_SYST_03008] Ethernet port scheduler priority dThe first element in Cou-
plingPortScheduler.predecessor has the highest priority.Therefore, it is impor-
tant to have the predecessor definition of the scheduler ordered.c(RS_SYST_00052)
Another restriction is that a CouplingPortShaper can only have a CouplingPort-
Fifo as predecessorFifo, which is given by the model.
[TPS_SYST_03009] Ethernet port shaper idleSlope dThe idleSlope is defined
in the IEEE802.1Qav standard as a parameter for an increase of credit in bits per
second. The idleSlope can never exceed the maximal transmit rate of a port, e.g.
100MBits for BroadR-Reach and 1GBits for RTPGE. The idleSlope determines the
maximum fraction of the port transmit rate that is available for the queue associated
with the shaper: bandwidthFraction = idleSlope/portTransmitRate.c(RS_SYST_00052)

111 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class CouplingPortDetails
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Defines details of a CouplingPort.
May be used to configure the structures of a switch.
Base ARObject
Attribute Type Mult. Kind Note
couplingPort CouplingPortStructural 1..* aggr Collects all the structural parts at which a CouplingPort
Structural Element may be configurable.
Element
ethernetPriority EthernetPriority 0..8 aggr Defines a priority regeneration where the ingress priority
Regeneration Regeneration is replaced by regenerated priority.
ethernetTraffic CouplingPortTraffic 0..8 aggr Defines the ingress port to EthernetTrafficClass
Class ClassAssignment assignment.
Assignment
globalTime GlobalTimeCoupling 0..1 aggr Specifies properties for the usage of the CouplingPort in
Props PortProps the scope of Global Time Sync.
lastEgress CouplingPortScheduler 0..1 ref Defines which CouplingPortScheduler is the last in the
Scheduler egress port structure.
ratePolicy CouplingPortRatePolicy * aggr Rate policies to be applied for this CouplingPort.

Table 3.61: CouplingPortDetails

Class CouplingPortStructuralElement (abstract)

Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note General class to define structural elements a CouplingPort may consist of.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Subclasses CouplingPortFifo, CouplingPortScheduler, CouplingPortShaper
Attribute Type Mult. Kind Note
– – – – –
Table 3.62: CouplingPortStructuralElement

112 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class CouplingPortScheduler
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Defines a scheduler for the CouplingPort egress structure.
Base ARObject, CouplingPortStructuralElement, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
portScheduler EthernetCouplingPort 1 attr Defines the schedule algorithm to be used.
SchedulerEnum
predecessor CouplingPortStructural 1..* ref Ordered List of predecessor inputs. The first element has
(ordered) Element the highest priority. The following elements have
decreasing priorities.

Table 3.63: CouplingPortScheduler

Enumeration EthernetCouplingPortSchedulerEnum
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Defines the schedule algorithm to be used.
Literal Description
deficitRoundRobin Schedule algorithm "deficit round robin"
Tags:atp.EnumerationLiteralIndex=0
strictPriority Schedule algorithm "strict priority"
Tags:atp.EnumerationLiteralIndex=1
weightedRound Schedule algorithm "weighted round robin"
Robin
Tags:atp.EnumerationLiteralIndex=2

Table 3.64: EthernetCouplingPortSchedulerEnum

Class CouplingPortShaper
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Defines a shaper for the CouplingPort egress structure.
Base ARObject, CouplingPortStructuralElement, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
idleSlope PositiveInteger 0..1 attr Defines the increase of credit in bits per second for the
AVB shaper.
predecessorFifo CouplingPortFifo 1 ref Defines the CouplingPortFifo which provides the input to
this shaper.

Table 3.65: CouplingPortShaper

Class CouplingPortFifo
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Defines a Fifo for the CouplingPort egress structure.
Base ARObject, CouplingPortStructuralElement, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
assignedTraffic PositiveInteger 0..8 attr Defines a set of Traffic Classes which shall be handled by
Class this Fifo.
range: 0-7
5

113 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class CouplingPortFifo
minimumFifo PositiveInteger 0..1 attr FIFO minimum length in Byte. An actual configuration/
Length hardware may use a bigger value.

Table 3.66: CouplingPortFifo

3.3.6.6.2 Ethernet switch rate policy

A CouplingPort may define a CouplingPortRatePolicy via the Coupling-

PortDetails.ratePolicy.
Class CouplingPortRatePolicy
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Defines a rate policy on a CouplingPort.
Base ARObject
Attribute Type Mult. Kind Note
dataLength PositiveInteger 1 attr Amount of data in bytes (excluding header information)
that can be received to define the rate policy.
policyAction CouplingPortRatePolicy 1 attr Defines the action to be performed when this rate policy
ActionEnum is violated.
priority PositiveInteger 0..1 attr Defines the priority which this rate policy shall be limited
on. If no priority is given this rate policy is not considering
priority.
timeInterval TimeValue 1 attr Time interval used to define the base of the rate policy.
vLan EthernetPhysical * ref Defines the VLANs this rate policy shall be limited on. If
Channel no VLAN is given this rate policy is not considering VLAN
tags.

Table 3.67: CouplingPortRatePolicy

Enumeration CouplingPortRatePolicyActionEnum
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Defines the action to be performed when a rate policy is violated.
Literal Description
blockSource If the rate policy is violated the CouplingPort this CouplingPortRatePolicy is defined on shall block all
frames from the MAC-Address the violation was caused by.
Tags:atp.EnumerationLiteralIndex=1
dropFrame If the rate policy is violated the frame shall be dropped.
Tags:atp.EnumerationLiteralIndex=0

Table 3.68: CouplingPortRatePolicyActionEnum

114 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

3.3.6.6.3 Ethernet packet forwarding

Besides the modeling of egress ports, it is necessary to specify how incoming packets
are forwarded to the egress ports. For this purpose, different assignment policies of
packets to egress port FIFOs are implemented in switches.
As an example, the Ethernet priority field can be evaluated and remapped into an re-
generated priority: Within the VLAN-tag, the PCP-field (priority code point) is a param-
eter which can be modified at an ingress port of an Ethernet switch. For this purpose
a priority regeneration table can be defined.
The CouplingPortDetails.ethernetPriorityRegeneration is optional in
case the feature of priority regeneration is not be used.
[TPS_SYST_03003] Ethernet priority regeneration dThe CouplingPortDetails.
ethernetPriorityRegeneration specifies which ingressPriority is mapped
to which regeneratedPriority.c(RS_SYST_00052)
[constr_3515] Fully filled EthernetPriorityRegeneration table dIn case
the CouplingPortDetails.ethernetPriorityRegeneration is defined it shall
contain exactly 8 elements of EthernetPriorityRegeneration, one for each
value of ingressPriority (0-7).c()
The (potentially remapped) Ethernet priority field can be evaluated and mapped to a
traffic class. Such a traffic class is again mapped to an egress FIFO. Other header
information of the Ethernet frame can be also used for the assignment of Ethernet
frames to egress FIFOs. For the mapping to a certain traffic class, the following tables
are necessary.
PORT-based Mapping Traffic Class
Port2, Port3, Port4 7
Port1 6
– 5
– 4
– 3
– 2
– 1
– 0

Table 3.69: Port to Traffic Class mapping

PCP-based Mapping Traffic Class

Prio 0 7
Prio 1 6
Prio 2-7 5
– 4
– 3
– 2
– 1
– 0

Table 3.70: PCP-field to Traffic Class mapping

115 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

While the first table shows the mapping of ingress-ports to traffic classes, the second
table shows the priority-based mapping which can be defined per ingress port. Both
tables are in conflict with each other, i.e. it has to be decided which mapping is applied.
Also the mapping of a traffic class to a FIFO shall be done on a per port basis. An
example is shown in the following table.
Traffic Class FIFO (if 4 FIFOs available)
7 3
6 2
0-5 1
– 0

Table 3.71: Traffic Class to FIFO mapping

In order to model the relationship between the ingress port and the egress port, the
CouplingPortTrafficClassAssignment elements are used.
[TPS_SYST_03010] Ethernet switch packet to traffic class assignment dFirst the
ingress packets are assigned to traffic classes. The two use-cases from above are both
supported by this model:
• Port to traffic class mapping (only one traffic class per port possible) from table
3.69
– CouplingPortDetails has exactly one ethernetTrafficClassAs-
signment defined
– the CouplingPortTrafficClassAssignment has no priority de-
fined
• PCP-field to Traffic Class Mapping from table 3.70
– for each traffic class the CouplingPortDetails aggregate one ether-
netTrafficClassAssignment
– each CouplingPortTrafficClassAssignment element has a set of
prioritys defined which shall be mapped to the given trafficClass
c(RS_SYST_00052)
[constr_5049] Ethernet switch packet to traffic class assignment restriction dFor
one CouplingPortDetails there exists either
• one ethernetTrafficClassAssignment with no priority attribute or
• up to 8 ethernetTrafficClassAssignment elements with a set of prior-
ity attributes
c()
[TPS_SYST_03011] Ethernet switch traffic class to FIFO assignment dSecond, the
traffic classes are assigned to the switch egress FIFOs. The CouplingPortFifo has

116 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

a set of assignedTrafficClass elements. These defined traffic classes shall be

forwarded to this FIFO.c(RS_SYST_00052)
Referrable
CouplingPortDetails
+ethernetPriorityRegeneration EthernetPriorityRegeneration

0..8 + ingressPriority: PositiveInteger

+ regeneratedPriority: PositiveInteger

Referrable
+ethernetTrafficClassAssignment CouplingPortTrafficClassAssignment

0..8 + priority: PositiveInteger [0..8]

+ trafficClass: PositiveInteger

+couplingPortStructuralElement 1..*

Identifiable
CouplingPortStructuralElement

CouplingPortFifo

+ assignedTrafficClass: PositiveInteger [0..8]

+ minimumFifoLength: PositiveInteger [0..1]

Figure 3.13: Ethernet Priority Regeneration and Ethernet Traffic Class Assignment

Class EthernetPriorityRegeneration
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Defines a priority regeneration where the ingressPriority is replaced by regeneratedPriority.
The ethernetPriorityRegeneration is optional in case no priority regeneration shall be performed.
In case a ethernetPriorityRegeneration is defined it shall have 8 mappings, one for each priority.
Base ARObject, Referrable
Attribute Type Mult. Kind Note
ingressPriority PositiveInteger 1 attr Message priority of the incoming message.
range: 0-7
regenerated PositiveInteger 1 attr Regenerated message priority.
Priority
range: 0-7

Table 3.72: EthernetPriorityRegeneration

Class CouplingPortTrafficClassAssignment
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Defines the assignment of Traffic Class to a frame.
Base ARObject, Referrable
Attribute Type Mult. Kind Note
priority PositiveInteger 0..8 attr Defines a priority which is mapped onto a Traffic Class.
trafficClass PositiveInteger 1 attr Defines the Traffic Class which is assigned.
range: 0-7

Table 3.73: CouplingPortTrafficClassAssignment

117 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

3.3.6.6.4 Ethernet VLAN Configuration

For each VLAN identifier a table is necessary which stores at which egress port the
corresponding VLAN is tagged or untagged. For an 8-port switch, this table could look
like the following example where T stands for tagging and U for untagging:
Port number
VLAN-Id 1 2 3 4 5 6 7 8
1 T T - U - - - T
2 T U - T - - - T
...
4094

Table 3.74: VLAN Forwarding table

Incoming packets which contain a VLAN-ID of e.g. 1 can be forwarded to the ports 1,
2, 4, and 8. At ports 1, 2, and 8 these packets will be transmitted with the VLAN tag
and at port 4 the tag will be removed. If a broadcast message with e.g. VLAN-ID 2 will
be received at port 2 it will be forwarded to port 1, 4, and 8. The other ports 3, 5, 6, and
7 are not in the same VLAN. Thus, the packet will not be forwarded to these egress
ports. The table considers only messages which contain a VLAN-ID within the switch.
CouplingPort.vlanMembership defines specific attributes to the behavior a packet
with a specific VLAN-ID shall have on this CouplingPort.
[TPS_SYST_03004] VLAN specific sending behavior dThe VlanMembership.
sendActivity defines for a CouplingPort and VLAN the sending behavior:
• sentTagged: packet is sent at this CouplingPort with the defined VLAN-ID
• sentUntagged: packet is sent at this CouplingPort but the VLAN-ID is re-
moved before sending
• notSent: packet is not sent at this CouplingPort
c(RS_SYST_00052)
Another table specifies a port-based modification of the VLAN-ID or an insertion of the
VLAN-ID into the Ethernet message:
Port number 1 2 3 4 5 6 7 8
VLAN-Id 2 - - 6 - - - -

Table 3.75: Ingress VLAN Modification/Insertion Table

In this example, all incoming messages at port one will get the VLAN-Id 2 no matter
whether they already had one before. At port 4, all incoming messages will get a 6 as
their VLAN-Id. At the remaining ports, no VLAN-Ids will be inserted and an existing
VLAN-Id in the Ethernet-message will remain without modification.

118 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_03005] VLAN re-tagging dAll incoming messages at a CouplingPort

where the CouplingPort.vlanModifier is defined shall be tagged with the VLAN-
Id defined in CouplingPort.vlanModifier. This tagging is performed regardless
whether the message already has a VLAN tag or is untagged, an existing VLAN tag
shall be overwritten.c(RS_SYST_00052)
PhysicalChannel Identifiable
+vlan
EthernetPhysicalChannel VlanConfig
0..1
+ vlanIdentifier: PositiveInteger

+defaultVlan 0..1 +vlanModifier 0..1 +vlan 1

VlanMembership

+ defaultPriority: PositiveInteger
+ sendActivity: EthernetSwitchVlanEgressTaggingEnum [0..1]

+vlanMembership 0..*

«enumeration»
EthernetSwitchVlanEgressTaggingEnum

Identifiable notSent
sentTagged
CouplingPort sentUntagged
+ connectionNegotiationBehavior: EthernetConnectionNegotiationEnum [0..1]
+ couplingPortRole: CouplingPortRoleEnum [0..1]
+ macLayerType: EthernetMacLayerTypeEnum [0..1]
+ physicalLayerType: EthernetPhysicalLayerTypeEnum [0..1]
+ receiveActivity: EthernetSwitchVlanIngressTagEnum [0..1]

Figure 3.14: VLAN Modification

Enumeration EthernetSwitchVlanEgressTaggingEnum
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Defines the VLAN tag sending behavior.
Literal Description
notSent will not be sent
Tags:atp.EnumerationLiteralIndex=0
sentTagged sent with its VLAN tag
Tags:atp.EnumerationLiteralIndex=1
sentUntagged sent without a VLAN tag
Tags:atp.EnumerationLiteralIndex=2

Table 3.76: EthernetSwitchVlanEgressTaggingEnum

3.3.6.6.5 Semi-static DHCP server configuration

The ECU which manages the Ethernet switch may run a semi-static DHCP server.
[TPS_SYST_03013] Semi-static DHCP server configuration dIn order to be able
to assign always the same IP-address to a dedicated DHCP client, the DHCP server
needs the information at which switch port the DHCP request with the specific MAC ad-
dress has been received. With this switch port information the DHCP server will assign
the IP-address according to the VlanMembership.dhcpAddressAssignment.

119 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

This allows the assignment of MAC addresses by the Tier 1 and assignment of IP
addresses by the OEM. With this mechanism it is also possible to assign different IP
addresses to several VLANs at the same port.c(RS_SYST_00052)
CommunicationController
FibexElement
EthernetCommunicationController
CouplingElement
+ macLayerType: EthernetMacLayerTypeEnum [0..1]
+ couplingType: CouplingElementEnum
+ macUnicastAddress: MacAddressString [0..1]
+ maximumReceiveBufferLength: Integer [0..1]
+ maximumTransmitBufferLength: Integer [0..1]
+ slaveActAsPassiveCommunicationSlave: Boolean [0..1]
+ slaveQualifiedUnexpectedLinkDownTime: TimeValue [0..1]
«atpVariation,atpSplitable»

+couplingPort 0..* +couplingPort 0..*

Identifiable
CouplingPort
+defaultVlan PhysicalChannel
+ connectionNegotiationBehavior: EthernetConnectionNegotiationEnum [0..1]
+ couplingPortRole: CouplingPortRoleEnum [0..1] 0..1 EthernetPhysicalChannel
+ macLayerType: EthernetMacLayerTypeEnum [0..1] +vlanModifier
+ physicalLayerType: EthernetPhysicalLayerTypeEnum [0..1]
+ receiveActivity: EthernetSwitchVlanIngressTagEnum [0..1] 0..1
+vlan 1

+vlanMembership 0..* +vlan 0..1

+couplingPortDetails 0..1
Identifiable
VlanMembership
CouplingPortDetails VlanConfig
+ defaultPriority: PositiveInteger
+ sendActivity: EthernetSwitchVlanEgressTaggingEnum [0..1] + vlanIdentifier: PositiveInteger

+dhcpAddressAssignment 0..1

DhcpServerConfiguration

+ipv4DhcpServerConfiguration 0..1 +ipv6DhcpServerConfiguration 0..1

Describable Describable
Ipv4DhcpServerConfiguration Ipv6DhcpServerConfiguration

+ addressRangeLowerBound: Ip4AddressString [0..1] + addressRangeLowerBound: Ip6AddressString [0..1]

+ addressRangeUpperBound: Ip4AddressString [0..1] + addressRangeUpperBound: Ip6AddressString [0..1]
+ defaultGateway: Ip4AddressString [0..1] + defaultGateway: Ip6AddressString [0..1]
+ defaultLeaseTime: TimeValue [0..1] + defaultLeaseTime: TimeValue [0..1]
+ dnsServerAddress: Ip4AddressString [0..*] + dnsServerAddress: Ip6AddressString [0..*]
+ networkMask: Ip4AddressString [0..1] + networkMask: Ip6AddressString [0..1]

Figure 3.15: Semi-static DHCP configuration

Class DhcpServerConfiguration
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Defines the configuration of DHCP servers that are running on the network endpoint. It is possible that an
Ipv4DhcpServer and an Ipv6DhcpServer run on the same Ecu.
Base ARObject
Attribute Type Mult. Kind Note
ipv4DhcpServer Ipv4DhcpServer 0..1 aggr Configuration of a IPv4 DHCP server that runs on the
Configuration Configuration network endpoint.
ipv6DhcpServer Ipv6DhcpServer 0..1 aggr Configuration of a IPv6 DHCP server that runs on the
Configuration Configuration network endpoint.

Table 3.77: DhcpServerConfiguration

Class Ipv4DhcpServerConfiguration
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
5

120 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class Ipv4DhcpServerConfiguration
Note Defines the configuration of a IPv4 DHCP server that runs on the network endpoint.
Base ARObject, Describable
Attribute Type Mult. Kind Note
addressRange Ip4AddressString 0..1 attr Lower range of IP addresses to be issued to DHCP
LowerBound clients. IPv4 Address. Notation: 255.255.255.255.
addressRange Ip4AddressString 0..1 attr Upper range of IP addresses to be issued to DHCP
UpperBound clients. Pv4 Address. Notation: 255.255.255.255.
defaultGateway Ip4AddressString 0..1 attr IP address of the default gateway. Notation
255.255.255.255
defaultLease TimeValue 0..1 attr Amount of time in seconds that a client may keep the IP
Time address.
dnsServer Ip4AddressString * attr IP addresses of preconfigured DNS servers. Notation
Address 255.255.255.255
Tags:xml.namePlural=DNS-SERVER-ADDRESSES
networkMask Ip4AddressString 0..1 attr Default network mask to be used by DHCP clients.
Notation 255.255.255.255

Table 3.78: Ipv4DhcpServerConfiguration

Class Ipv6DhcpServerConfiguration
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Defines the configuration of a IPv6 DHCP server that runs on the network endpoint.
Base ARObject, Describable
Attribute Type Mult. Kind Note
addressRange Ip6AddressString 0..1 attr Lower range of IP addresses to be issued to DHCP
LowerBound clients. IPv6 Address. Notation: FFFF:...:FFFF.
addressRange Ip6AddressString 0..1 attr Upper range of IP addresses to be issued to DHCP
UpperBound clients. IPv6 Address. Notation: FFFF:...:FFFF.
defaultGateway Ip6AddressString 0..1 attr IP address of the default gateway. Notation
255.255.255.255
defaultLease TimeValue 0..1 attr Amount of time in seconds that a client may keep the IP
Time address.
dnsServer Ip6AddressString * attr IP addresses of preconfigured DNS servers. Notation:
Address FFFF:...:FFFF.
Tags:xml.namePlural=DNS-SERVER-ADDRESSES
networkMask Ip6AddressString 0..1 attr Default network mask to be used by DHCP clients.
Notation 255.255.255.255

Table 3.79: Ipv6DhcpServerConfiguration

3.3.6.7 TcpIp stack configuration properties

The EcuInstance references the following elements and allows to set Ecu specific
TcpIp stack configuration options in the System Description:
• EthIpProps - used to configure IPv4 and IPv6
• EthTcpIpProps - used to configure TCP and UDP
• EthTcpIpIcmpProps - used to configure ICMP

121 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

3.3.6.7.1 IP configuration properties

CommunicationConnector
EthernetCommunicationConnector

+ maximumTransmissionUnit: PositiveInteger [0..1]

+ neighborCacheSize: PositiveInteger [0..1]
+ pathMtuEnabled: Boolean [0..1]
+ pathMtuTimeout: TimeValue [0..1]
+ pncFilterDataMask: PositiveUnlimitedInteger [0..1]

Ipv4ArpProps
Ipv4Props +arpProps + tcpIpArpNumGratuitousArpOnStartup: PositiveInteger [0..1]
+ethIpProps 0..1 + tcpIpArpPacketQueueEnabled: Boolean [0..1]
0..1
+ tcpIpArpRequestTimeout: TimeValue [0..1]
ARElement + tcpIpArpTableEntryTimeout: TimeValue [0..1]
EthIpProps

Ipv4AutoIpProps
+autoIpProps
+ tcpIpAutoIpInitTimeout: TimeValue [0..1]
+ipv4Props 0..1

0..1
Ipv4FragmentationProps
+fragmentationProps + tcpIpIpFragmentationRxEnabled: Boolean [0..1]
0..1 + tcpIpIpNumFragments: PositiveInteger [0..1]
+ tcpIpIpNumReassDgrams: PositiveInteger [0..1]
+ tcpIpIpReassTimeout: TimeValue [0..1]

Ipv6FragmentationProps

Ipv6Props +fragmentationProps + tcpIpIpReassemblyBufferCount: PositiveInteger [0..1]

+ tcpIpIpReassemblyBufferSize: PositiveInteger [0..1]
0..1 + tcpIpIpReassemblySegmentCount: PositiveInteger [0..1]
+ tcpIpIpReassemblyTimeout: TimeValue [0..1]
+ tcpIpIpTxFragmentBufferCount: PositiveInteger [0..1]
+ tcpIpIpTxFragmentBufferSize: PositiveInteger [0..1]

Dhcpv6Props

+ tcpIpDhcpV6CnfDelayMax: TimeValue [0..1]

+dhcpProps
+ tcpIpDhcpV6CnfDelayMin: TimeValue [0..1]
+ipv6Props
0..1 + tcpIpDhcpV6InfDelayMax: TimeValue [0..1]
+ tcpIpDhcpV6InfDelayMin: TimeValue [0..1]
0..1 + tcpIpDhcpV6SolDelayMax: TimeValue [0..1]
+ tcpIpDhcpV6SolDelayMin: TimeValue [0..1]

Ipv6NdpProps

+ tcpIpNdpDefaultReachableTime: TimeValue [0..1]

+ tcpIpNdpDefaultRetransTimer: TimeValue
+ tcpIpNdpDefaultRouterListSize: PositiveInteger [0..1]
+ tcpIpNdpDefensiveProcessing: Boolean [0..1]
+ndpProps + tcpIpNdpDelayFirstProbeTime: PositiveInteger [0..1]
+ tcpIpNdpDestinationCacheSize: PositiveInteger [0..1]
0..1 + tcpIpNdpDynamicHopLimitEnabled: Boolean [0..1]
+ tcpIpNdpDynamicMtuEnabled: Boolean [0..1]
+ tcpIpNdpDynamicReachableTimeEnabled: Boolean [0..1]
+ tcpIpNdpDynamicRetransTimeEnabled: Boolean [0..1]
+ tcpIpNdpMaxRandomFactor: PositiveInteger [0..1]
+ tcpIpNdpMaxRtrSolicitationDelay: TimeValue [0..1]
+ tcpIpNdpMaxRtrSolicitations: PositiveInteger [0..1]
+ tcpIpNdpMinRandomFactor: PositiveInteger [0..1]
+ tcpIpNdpNeighborUnreachabilityDetectionEnabled: Boolean [0..1]
+ tcpIpNdpNumMulticastSolicitations: PositiveInteger [0..1]
+ tcpIpNdpNumUnicastSolicitations: PositiveInteger [0..1]
+ tcpIpNdpPacketQueueEnabled: Boolean [0..1]
+ tcpIpNdpPrefixListSize: PositiveInteger [0..1]
+ tcpIpNdpRandomReachableTimeEnabled: Boolean [0..1]
+ tcpIpNdpRndRtrSolicitationDelayEnabled: Boolean [0..1]
+ tcpIpNdpRtrSolicitationInterval: TimeValue [0..1]
+ tcpIpNdpSlaacDadNumberOfTransmissions: PositiveInteger [0..1]
+ tcpIpNdpSlaacDadRetransmissionDelay: TimeValue [0..1]
+ tcpIpNdpSlaacDelayEnabled: Boolean [0..1]
+ tcpIpNdpSlaacOptimisticDadEnabled: Boolean [0..1]

Figure 3.16: Ecu specific IP configuration options

122 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class EthIpProps
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note This meta-class is used to configure the EcuInstance specific IP attributes.
Tags:atp.recommendedPackage=EthIpProps
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
ipv4Props Ipv4Props 0..1 aggr Configuration options for IPv4.
ipv6Props Ipv6Props 0..1 aggr Configuration options for IPv6.

Table 3.80: EthIpProps

Class Ipv4Props
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note This meta-class specifies the configuration options for IPv4.
Base ARObject
Attribute Type Mult. Kind Note
arpProps Ipv4ArpProps 0..1 aggr Configuration properties for the ARP (Address Resolution
Protocol).
autoIpProps Ipv4AutoIpProps 0..1 aggr Configuration options for Auto-IP (automatic private IP
addressing).
fragmentation Ipv4Fragmentation 0..1 aggr Configuration options for IPv4 packet fragmentation/
Props Props reassembly.

Table 3.81: Ipv4Props

Class Ipv4ArpProps
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Specifies the configuration options for the ARP (Address Resolution Protocol).
Base ARObject
Attribute Type Mult. Kind Note
tcpIpArpNum PositiveInteger 0..1 attr This attribute specifies the number of gratuitous ARP
GratuitousArp replies which shall be sent on assignment of a new IP
OnStartup address.
tcpIpArpPacket Boolean 0..1 attr This attribute enables (TRUE) or disables (FALSE)
QueueEnabled support of the ARP Packet Queue according to IETF RFC
1122, section 2.3.2.2.
tcpIpArp TimeValue 0..1 attr This attribute specifies a timeout in seconds for the
Request validity of ARP requests. After the transmission of an
Timeout ARP request the TcpIp shall skip the transmission of any
further ARP requests to the same destination within a
duration of tcpIpArpRequestTimeout seconds. (IETF RFC
1122, section 2.3.2.1).
tcpIpArpTable TimeValue 0..1 attr This attribute specifies the timeout in seconds after which
EntryTimeout an unused ARP entry is removed.

Table 3.82: Ipv4ArpProps

[constr_5126] Value range of Ipv4ArpProps.tcpIpArpNumGratuitousArpOn-

Startup dIf defined, the value of Ipv4ArpProps.tcpIpArpNumGratuitousAr-
pOnStartup shall be in the range of 0..255.c()

123 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class Ipv4AutoIpProps
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Specifies the configuration options for Auto-IP (automatic private IP addressing).
Base ARObject
Attribute Type Mult. Kind Note
tcpIpAutoIpInit TimeValue 0..1 attr This attribute specifies the time in seconds Auto-IP waits
Timeout at startup, before beginning with ARP probing. This delay
is used to give DHCP time to acquire a lease in case a
DHCP server is present.

Table 3.83: Ipv4AutoIpProps

Class Ipv4FragmentationProps
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Specifies the configuration options for IPv4 packet fragmentation/reassembly.
Base ARObject
Attribute Type Mult. Kind Note
tcpIpIp Boolean 0..1 attr Enables (TRUE) or disables (FALSE) support for
Fragmentation reassembling of incoming datagrams that are fragmented
RxEnabled according to IETF RFC 815 (IP Datagram Reassembly
Algorithms).
tcpIpIpNum PositiveInteger 0..1 attr Specifies the maximum number of IP fragments per
Fragments datagram.
tcpIpIpNum PositiveInteger 0..1 attr Specifies the maximum number of fragmented IP
ReassDgrams datagrams that can be reassembled in parallel.
tcpIpIpReass TimeValue 0..1 attr Specifies the timeout in [s] after which an incomplete
Timeout datagram gets discarded.

Table 3.84: Ipv4FragmentationProps

[constr_5127] Value range of Ipv4FragmentationProps.tcpIpIpNumFrag-

ments dIf defined, the value of Ipv4FragmentationProps.tcpIpIpNumFrag-
ments shall be in the range of 0..255.c()
[constr_5128] Value range of Ipv4FragmentationProps.tcpIpIpNumReassD-
grams dIf defined, the value of Ipv4FragmentationProps.tcpIpIpNumReassD-
grams shall be in the range of 0..65535.c()
Class Ipv6Props
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note This meta-class specifies the configuration options for IPv6.
Base ARObject
Attribute Type Mult. Kind Note
dhcpProps Dhcpv6Props 0..1 aggr Configuration properties for DHCPv6.
fragmentation Ipv6Fragmentation 0..1 aggr Configuration properties for IPv6 packet fragmentation/
Props Props reassembly.
ndpProps Ipv6NdpProps 0..1 aggr Configuration properties for the Neighbor Discovery
Protocol for IPv6.

Table 3.85: Ipv6Props

124 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class Ipv6FragmentationProps
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note This meta-class specifies the configuration options for IPv6 packet fragmentation/reassembly.
Base ARObject
Attribute Type Mult. Kind Note
tcpIpIp PositiveInteger 0..1 attr Number of buffers that can be used for fragment
Reassembly reassembly. In case of a reassembly error or if not all
BufferCount fragments are received in time this buffer will be blocked
until the specified "Fragment Reassembly Timeout" has
been exceeded.
A value of 0 disables fragment reassembly.
tcpIpIp PositiveInteger 0..1 attr Size of each fragment tx buffer in bytes.
Reassembly
BufferSize
tcpIpIp PositiveInteger 0..1 attr Specifies the maximum number of consecutive data
Reassembly segments that can be managed in each reassembly
SegmentCount buffer. If all fragments are received in order, only one
segment will be needed.
To deal with fragments received out of order this value
should be configured bigger than 1.
tcpIpIp TimeValue 0..1 attr Specifies the timeout in seconds after which an
Reassembly incomplete datagram gets discarded.
Timeout
tcpIpIpTx PositiveInteger 0..1 attr These buffers will be used if the IpV6 receives packets
FragmentBuffer from the upper layer that do not fit into the MTU and thus
Count must be fragmented.
A value of 0 disables tx fragmentation.
tcpIpIpTx PositiveInteger 0..1 attr Size of each fragment tx buffer in bytes.
FragmentBuffer
Size

Table 3.86: Ipv6FragmentationProps

[constr_5129] Value range of Ipv6FragmentationProps.tcpIpIpReassem-

blyBufferCount dIf defined, the value of Ipv6FragmentationProps.tcpIp-
IpReassemblyBufferCount shall be in the range of 0..255.c()
[constr_5130] Value range of Ipv6FragmentationProps.tcpIpIpReassem-
blyBufferSize dIf defined, the value of Ipv6FragmentationProps.tcpIp-
IpReassemblyBufferSize shall be in the range of 1500..65535.c()
[constr_5131] Value range of Ipv6FragmentationProps.tcpIpIpReassembly-
Timeout dIf defined, the value of Ipv6FragmentationProps.tcpIpIpReassem-
blyTimeout shall be in the range of 0.001..100.c()
[constr_5132] Value range of Ipv6FragmentationProps.tcpIpIpReassembl-
ySegmentCount dIf defined, the value of Ipv6FragmentationProps.tcpIp-
IpReassemblySegmentCount shall be in the range of 1..255.c()
[constr_5133] Value range of Ipv6FragmentationProps.tcpIpIpTxFragment-
BufferCount dIf defined, the value of Ipv6FragmentationProps.tcpIpIp-
TxFragmentBufferCount shall be in the range of 1..1000.c()

125 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_5134] Value range of Ipv6FragmentationProps.tcpIpIpTxFragment-

BufferSize dIf defined, the value of Ipv6FragmentationProps.tcpIpIp-
TxFragmentBufferSize shall be in the range of 1500..65535.c()
Class Dhcpv6Props
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note This meta-class specifies the configuration options for DHCPv6.
Base ARObject
Attribute Type Mult. Kind Note
tcpIpDhcp TimeValue 0..1 attr Maximum delay in seconds before sending the first
V6CnfDelayMax Confirm message. If this value is bigger than the previous
minimum delay value a random delay will be chosen from
the interval.
tcpIpDhcp TimeValue 0..1 attr Minimum delay in seconds before the first Confirm
V6CnfDelayMin message will be sent.
tcpIpDhcpV6Inf TimeValue 0..1 attr Maximum delay in seconds before sending the first
DelayMax Information Request message. If this value is bigger than
the previous minimum delay value a random delay will be
chosen from the interval.
tcpIpDhcpV6Inf TimeValue 0..1 attr Minimum delay (s) before the first Information Request
DelayMin message will be sent.
tcpIpDhcpV6Sol TimeValue 0..1 attr Maximum delay in seconds before sending the first Solicit
DelayMax message. If this value is bigger than the previous
minimum delay value a random delay will be chosen from
the interval.
tcpIpDhcpV6Sol TimeValue 0..1 attr Minimum delay (s) before the first Solicit message will be
DelayMin sent.

Table 3.87: Dhcpv6Props

[constr_5135] Value range of Dhcpv6Props.tcpIpDhcpV6CnfDelayMin

and Dhcpv6Props.tcpIpDhcpV6CnfDelayMax dIf defined, the value of
Dhcpv6Props.tcpIpDhcpV6CnfDelayMin and the value of Dhcpv6Props.
tcpIpDhcpV6CnfDelayMax shall be in the range of 0..100 and the value of
Dhcpv6Props.tcpIpDhcpV6CnfDelayMax shall be greater than the value of
Dhcpv6Props.tcpIpDhcpV6CnfDelayMin.c()
[constr_5136] Value range of Dhcpv6Props.tcpIpDhcpV6InfDelayMin
and Dhcpv6Props.tcpIpDhcpV6InfDelayMax dIf defined, the value of
Dhcpv6Props.tcpIpDhcpV6InfDelayMin and the value of Dhcpv6Props.
tcpIpDhcpV6InfDelayMax shall be in the range of 0..100 and the value of
Dhcpv6Props.tcpIpDhcpV6InfDelayMax shall be greater than the value of
Dhcpv6Props.tcpIpDhcpV6InfDelayMin.c()
[constr_5137] Value range of Dhcpv6Props.tcpIpDhcpV6SolDelayMin
and Dhcpv6Props.tcpIpDhcpV6SolDelayMax dIf defined, the value of
Dhcpv6Props.tcpIpDhcpV6SolDelayMin and the value of Dhcpv6Props.
tcpIpDhcpV6SolDelayMax shall be in the range of 0..100 and the value of
Dhcpv6Props.tcpIpDhcpV6SolDelayMax shall be greater than the value of
Dhcpv6Props.tcpIpDhcpV6SolDelayMin.c()

126 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class Ipv6NdpProps
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note This meta-class specifies the configuration options for the Neighbor Discovery Protocol for IPv6.
Base ARObject
Attribute Type Mult. Kind Note
tcpIpNdpDefault TimeValue 0..1 attr Configuration of the ReachableTime (s) specified in
ReachableTime [RFC4861 6.3.2. Host Variables].
tcpIpNdpDefault TimeValue 1 attr Configures the default value (s) for the RetransTimer
RetransTimer variable specified in [RFC4861 6.3.2. Host Variables].
tcpIpNdpDefault PositiveInteger 0..1 attr Maximum number of default router entries.
RouterListSize
tcpIpNdp Boolean 0..1 attr If enabled the NDP shall only process Neighbor
Defensive Advertisements which are received in reaction to a
Processing previously transmitted Neighbor Solicitation as well as
skipping updates to the Neighbor Cache based on
received Neighbor Solicitations. If disabled all Neighbor
Advertisements and Solicitations shall be processed as
specified in RFC4861.
tcpIpNdpDelay PositiveInteger 0..1 attr Delay before sending the first NUD probe in (s).
FirstProbeTime
tcpIpNdp PositiveInteger 0..1 attr Maximum number of entries in the destination cache.
Destination
CacheSize
tcpIpNdp Boolean 0..1 attr If enabled the default hop limit may be reconfigured
DynamicHop based on received Router Advertisements.
LimitEnabled
tcpIpNdp Boolean 0..1 attr Allow dynamic reconfiguration of link MTU via Router
DynamicMtu Advertisements.
Enabled
tcpIpNdp Boolean 0..1 attr If enabled the default Reachable Time value may be
Dynamic reconfigured based on received Router Advertisements.
ReachableTime
Enabled
tcpIpNdp Boolean 0..1 attr If enabled the default Retransmit Timer value may be
Dynamic reconfigured based on received Router Advertisements.
RetransTime
Enabled
tcpIpNdpMax PositiveInteger 0..1 attr Maximum random factor used for randomization
RandomFactor
tcpIpNdpMaxRtr TimeValue 0..1 attr Maximum delay before the first Router Solicitation will be
Solicitation sent after interface initialization in (s).
Delay
tcpIpNdpMaxRtr PositiveInteger 0..1 attr Maximum number of Router Solicitations that will be sent
Solicitations before the first Router Advertisement has been received.
tcpIpNdpMin PositiveInteger 0..1 attr Minimum random factor used for randomization
RandomFactor
tcpIpNdp Boolean 0..1 attr Neighbor Unreachability Detection is used to remove
Neighbor unused entries from the neighbor cache. This feature is a
Unreachability basic feature of NDP and should be turned on.
Detection
Enabled
tcpIpNdpNum PositiveInteger 0..1 attr Maximum number of multicast solicitations that will be
Multicast sent when performing address resolution.
Solicitations
tcpIpNdpNum PositiveInteger 0..1 attr Maximum number of unicast solicitations that will be sent
Unicast when performig Neighbor Unreachability Detection.
Solicitations
5

127 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class Ipv6NdpProps
tcpIpNdpPacket Boolean 0..1 attr Enables (TRUE) or disables (FALSE) support of a NDP
QueueEnabled Packet Queue according to IETF RFC 4861, section
7.2.2.
tcpIpNdpPrefix PositiveInteger 0..1 attr Maximum number of entries in the on-link prefix list.
ListSize
tcpIpNdp Boolean 0..1 attr If enabled the value of ReachableTime will be multiplied
Random with a random value between MIN_RANDOM_FACTOR
ReachableTime and MAX_RANDOM_FACTOR in order to prevent
Enabled multiple nodes from transmitting at exactly the same time.
tcpIpNdpRndRtr Boolean 0..1 attr If enabled the first router solicitation will be delayed
Solicitation randomly from [0...MAX_RTR_SOLICITATION_DELAY].
DelayEnabled Otherwise the first router solicitation will be sent after
exactly MAX_RTR_SOLICITATION_DELAY milliseconds.
tcpIpNdpRtr TimeValue 0..1 attr Interval between consecutive Router Solicitations in (s).
Solicitation
Interval
tcpIpNdpSlaac PositiveInteger 0..1 attr Number of Neighbor Solicitations that have to be
DadNumberOf unanswered in order to set an autoconfigurated address
Transmissions to PREFERRED (usable) state.
tcpIpNdpSlaac TimeValue 0..1 attr Sets the maximum value for the address configuration
Dad delay (s).
Retransmission
Delay
tcpIpNdpSlaac Boolean 0..1 attr If enabled transmission of the first DAD Neighbor
DelayEnabled Solicitation will be delayed by a random value from
[0...MAX_DAD_DELAY].
tcpIpNdpSlaac Boolean 0..1 attr Enable Optimistic Duplicate Address Detection (DAD)
OptimisticDad according to RFC4429.
Enabled
Table 3.88: Ipv6NdpProps

[constr_5138] Value range of Ipv6NdpProps.tcpIpNdpSlaacDadNumberOf-

Transmissions dIf defined, the value of Ipv6NdpProps.tcpIpNdpSlaacDadNum-
berOfTransmissions shall be in the range of 0..254.c()
[constr_5139] Value range of Ipv6NdpProps.tcpIpNdpSlaacDadRetransmis-
sionDelay dIf defined, the value of Ipv6NdpProps.tcpIpNdpSlaacDadRetrans-
missionDelay shall be in the range of 0..10.c()
[constr_5140] Value range of Ipv6NdpProps.tcpIpNdpDefaultReachableTime
dIf defined, the value of Ipv6NdpProps.tcpIpNdpDefaultReachableTime shall
be in the range of 0..120.c()
[constr_5141] Value range of Ipv6NdpProps.tcpIpNdpDefaultRetransTimer
dIf defined, the value of Ipv6NdpProps.tcpIpNdpDefaultRetransTimer shall be
in the range of 0..60.c()
[constr_5142] Value range of Ipv6NdpProps.tcpIpNdpNumUnicastSolicita-
tions dIf defined, the value of Ipv6NdpProps.tcpIpNdpNumUnicastSolicita-
tions shall be in the range of 0..255.c()

128 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_5143] Value range of Ipv6NdpProps.tcpIpNdpNumMulticastSolici-

tations dIf defined, the value of Ipv6NdpProps.tcpIpNdpNumMulticastSolic-
itations shall be in the range of 0..255.c()
[constr_5144] Value range of Ipv6NdpProps.tcpIpNdpDelayFirstProbeTime
dIf defined, the value of Ipv6NdpProps.tcpIpNdpDelayFirstProbeTime shall be
in the range of 0..60.c()
[constr_5145] Value range of Ipv6NdpProps.tcpIpNdpMinRandomFactor dIf de-
fined, the value of Ipv6NdpProps.tcpIpNdpMinRandomFactor shall be in the
range of 0..100.c()
[constr_5146] Value range of Ipv6NdpProps.tcpIpNdpMaxRandomFactor dIf de-
fined, the value of Ipv6NdpProps.tcpIpNdpMaxRandomFactor shall be in the
range of 0..100.c()
[constr_5147] Value range of Ipv6NdpProps.tcpIpNdpDestinationCacheSize
dIf defined, the value of Ipv6NdpProps.tcpIpNdpDestinationCacheSize shall
be in the range of 1..254.c()
[constr_5148] Value range of Ipv6NdpProps.tcpIpNdpPrefixListSize dIf de-
fined, the value of Ipv6NdpProps.tcpIpNdpPrefixListSize shall be in the range
of 1..254.c()
[constr_5149] Value range of Ipv6NdpProps.tcpIpNdpDefaultRouterList-
Size dIf defined, the value of Ipv6NdpProps.tcpIpNdpDefaultRouterListSize
shall be in the range of 2..254.c()
[constr_5151] Value range of Ipv6NdpProps.tcpIpNdpMaxRtrSolicitations
dIf defined, the value of Ipv6NdpProps.tcpIpNdpMaxRtrSolicitations shall be
in the range of 0..255.c()
[constr_5152] Value range of Ipv6NdpProps.tcpIpNdpMaxRtrSolicitation-
Delay dIf defined, the value of Ipv6NdpProps.tcpIpNdpMaxRtrSolicitation-
Delay shall be in the range of 0.001..60.c()
[constr_5153] Value range of Ipv6NdpProps.tcpIpNdpRtrSolicitationIn-
terval dIf defined, the value of Ipv6NdpProps.tcpIpNdpRtrSolicitationIn-
terval shall be in the range of 0.001..60.c()

129 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

3.3.6.7.2 TCP and UDP configuration properties

FibexElement
EcuInstance

+ comConfigurationGwTimeBase: TimeValue [0..1]

+ comConfigurationRxTimeBase: TimeValue [0..1]
+ comConfigurationTxTimeBase: TimeValue [0..1]
+ comEnableMDTForCyclicTransmission: Boolean [0..1]
+ ethSwitchPortGroupDerivation: Boolean [0..1]
+ pncPrepareSleepTimer: TimeValue [0..1]
+ pncSynchronousWakeup: Boolean [0..1]
+ pnResetTime: TimeValue [0..1]
+ sleepModeSupported: Boolean
+ v2xSupported: V2xSupportEnum [0..1]
+ wakeUpOverBusSupported: Boolean

+tcpIpProps 0..1
+udpProps
UdpProps
ARElement
0..1
EthTcpIpProps + udpTtl: PositiveInteger [0..1]

TcpProps

+ tcpCongestionAvoidanceEnabled: Boolean [0..1]

+ tcpDelayedAckTimeout: TimeValue [0..1]
+ tcpFastRecoveryEnabled: Boolean [0..1]
+ tcpFastRetransmitEnabled: Boolean [0..1]
+ tcpFinWait2Timeout: TimeValue [0..1]
+ tcpKeepAliveEnabled: Boolean [0..1]
+tcpProps + tcpKeepAliveInterval: TimeValue [0..1]
+ tcpKeepAliveProbesMax: PositiveInteger [0..1]
0..1 + tcpKeepAliveTime: TimeValue [0..1]
+ tcpMaxRtx: PositiveInteger [0..1]
+ tcpMsl: TimeValue [0..1]
+ tcpNagleEnabled: Boolean [0..1]
+ tcpReceiveWindowMax: PositiveInteger [0..1]
+ tcpRetransmissionTimeout: TimeValue [0..1]
+ tcpSlowStartEnabled: Boolean [0..1]
+ tcpSynMaxRtx: PositiveInteger [0..1]
+ tcpSynReceivedTimeout: TimeValue [0..1]
+ tcpTtl: PositiveInteger [0..1]
+tcpIpIcmpProps 0..1

ARElement +icmpV4Props TcpIpIcmpv4Props

EthTcpIpIcmpProps
0..1 + tcpIpIcmpV4EchoReplyEnabled: Boolean [0..1]
+ tcpIpIcmpV4Ttl: PositiveInteger [0..1]

TcpIpIcmpv6Props

+icmpV6Props + tcpIpIcmpV6EchoReplyAvoidFragmentation: Boolean [0..1]

+ tcpIpIcmpV6EchoReplyEnabled: Boolean [0..1]
0..1 + tcpIpIcmpV6HopLimit: PositiveInteger [0..1]
+ tcpIpIcmpV6MsgDestinationUnreachableEnabled: Boolean [0..1]
+ tcpIpIcmpV6MsgParameterProblemEnabled: Boolean [0..1]

Figure 3.17: Ecu specific TCP/UDP and ICMP configuration options

Class EthTcpIpProps
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note This meta-class is used to configure the EcuInstance specific TcpIp Stack attributes.
Tags:atp.recommendedPackage=EthTcpIpProps
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
tcpProps TcpProps 0..1 aggr TCP configuration properties
udpProps UdpProps 0..1 aggr UDP configuration properties

Table 3.89: EthTcpIpProps

130 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class UdpProps
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note This meta-class specifies the configuration options for UDP (User Datagram Protocol).
Base ARObject
Attribute Type Mult. Kind Note
udpTtl PositiveInteger 0..1 attr Default Time-to-live value of outgoing UDP packets.

Table 3.90: UdpProps

[constr_5118] Value range of UdpProps.udpTtl dIf defined, the value of UdpProps.

udpTtl shall be in the range of 1..255.c()
Class TcpProps
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note This meta-class specifies the configuration options for TCP (Transmission Control Protocol).
Base ARObject
Attribute Type Mult. Kind Note
tcpCongestion Boolean 0..1 attr Enables (TRUE) or disables (FALSE) support of TCP
Avoidance congestion avoidance algorithm according to IETF RFC
Enabled 5681.
tcpDelayedAck TimeValue 0..1 attr The maximal time an acknowledgement is delayed for
Timeout transmission in seconds.
tcpFast Boolean 0..1 attr Enables (TRUE) or disables (FALSE) support of TCP Fast
Recovery Recovery according to IETF RFC 5681.
Enabled
tcpFast Boolean 0..1 attr Enables (TRUE) or disables (FALSE) support of TCP Fast
Retransmit Retransmission according to IETF RFC 5681.
Enabled
tcpFin TimeValue 0..1 attr Timeout in [s] to receive a FIN from the remote node
Wait2Timeout (after this node has initiated connection termination), i.e.
maximum time waiting in FINWAIT-2 for a connection
termination request from the remote TCP.
tcpKeepAlive Boolean 0..1 attr Enables (TRUE) or disables (FALSE) TCP Keep Alive
Enabled Probes according to IETF RFC 1122 chapter 4.2.3.6.
tcpKeepAlive TimeValue 0..1 attr Specifies the interval in seconds between subsequent
Interval keepalive probes.
tcpKeepAlive PositiveInteger 0..1 attr Maximum number of times that a TCP Keep Alive is
ProbesMax retransmitted before the connection is closed.
tcpKeepAlive TimeValue 0..1 attr Specifies the time in [s] between the last data packet sent
Time (simple ACKs are not considered data) and the first
keepalive probe.
tcpMaxRtx PositiveInteger 0..1 attr Maximum number of times that a TCP segment is
retransmitted before the TCP connection is closed. This
parameter is only valid if tcpRetransmissionTimeout is
configured. Note: This parameter also applies for FIN
retransmissions.
tcpMsl TimeValue 0..1 attr Maximum segment lifetime in [s].
tcpNagle Boolean 0..1 attr Enables (TRUE) or disables (FALSE) support of Nagle’s
Enabled algorithm according to IETF RFC 1122 (chapter 4.2.3.4
When to Send Data). If enabled the Nagle’s algorithm is
activated per default for all TCP sockets, but can be
deactivated per Socket (with the attribute TcpTp.nagle
Algorithm).
5

131 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class TcpProps
tcpReceive PositiveInteger 0..1 attr Default value of maximum receive window in bytes.
WindowMax
tcp TimeValue 0..1 attr Timeout in [s] before an unacknowledged TCP segment
Retransmission is sent again. If the timeout is disabled, no TCP segments
Timeout shall be retransmitted.
tcpSlowStart Boolean 0..1 attr Enables (TRUE) or disables (FALSE) support of TCP
Enabled slow start algorithm according to IETF RFC 5681.
tcpSynMaxRtx PositiveInteger 0..1 attr Maximum number of times that a TCP SYN is
retransmitted.
tcpSynReceived TimeValue 0..1 attr Timeout in [s] to complete a remotely initiated TCP
Timeout connection establishment, i.e. maximum time waiting in
SYN-RECEIVED for a confirming connection request
acknowledgement after having both received and sent a
connection request.
tcpTtl PositiveInteger 0..1 attr Default Time-to-live value of outgoing TCP packets.

Table 3.91: TcpProps

[constr_5119] Value range of TcpProps.tcpTtl dIf defined, the value of TcpProps.

tcpTtl shall be in the range of 1..255.c()
[constr_5120] Value range of TcpProps.tcpDelayedAckTimeout dIf defined, the
value of TcpProps.tcpDelayedAckTimeout shall be in the range of 0..0.5.c()
[constr_5121] Value range of TcpProps.tcpSynMaxRtx dIf defined, the value of
TcpProps.tcpSynMaxRtx shall be in the range of 0..255.c()
[constr_5122] Value range of TcpProps.tcpMaxRtx dIf defined, the value of Tcp-
Props.tcpMaxRtx shall be in the range of 0..255.c()
[constr_5123] Value range of TcpProps.tcpKeepAliveProbesMax dIf defined, the
value of TcpProps.tcpKeepAliveProbesMax shall be in the range of 0..65535.c()
[constr_5124] Value range of TcpProps.tcpReceiveWindowMax dIf defined, the
value of TcpProps.tcpReceiveWindowMax shall be in the range of 0..65535.c()

3.3.6.7.3 ICMP configuration properties

Class EthTcpIpIcmpProps
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note This meta-class is used to configure the EcuInstance specific ICMP (Internet Control Message Protocol)
attributes
Tags:atp.recommendedPackage=EthTcpIcmpProps
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
icmpV4Props TcpIpIcmpv4Props 0..1 aggr ICMPv4 configuration properties
5

132 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class EthTcpIpIcmpProps
icmpV6Props TcpIpIcmpv6Props 0..1 aggr ICMPv6 configuration properties

Table 3.92: EthTcpIpIcmpProps

Class TcpIpIcmpv4Props
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note This meta-class specifies the configuration options for ICMPv4 (Internet Control Message Protocol).
Base ARObject
Attribute Type Mult. Kind Note
tcpIpIcmp Boolean 0..1 attr This attribute enables or disables transmission of ICMP
V4EchoReply echo reply message in case of a ICMP echo reception.
Enabled
tcpIpIcmpV4Ttl PositiveInteger 0..1 attr This attribute is only relevant in case that ICMP (Internet
Control Message Protocol) is used. It specifies the default
Time-to-live value of outgoing ICMP packets.

Table 3.93: TcpIpIcmpv4Props

Class TcpIpIcmpv6Props
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note This meta-class specifies the configuration options for ICMPv6 (Internet Control Message Protocol).
Base ARObject
Attribute Type Mult. Kind Note
tcpIpIcmp Boolean 0..1 attr This attribute defines whether the echo reply is only
V6EchoReply transmitted in case that the incoming ICMPv6 Echo
Avoid Request (Pings) fits the MTU of the respective interface,
Fragmentation i.e. can be transmitted without IPv6 fragmentation.
tcpIpIcmp Boolean 0..1 attr This attribute enables or disables transmission of ICMP
V6EchoReply echo reply message in case of a ICMP echo reception.
Enabled
tcpIpIcmp PositiveInteger 0..1 attr Default Hop-Limit value of outgoing ICMPv6 packets.
V6HopLimit
tcpIpIcmp Boolean 0..1 attr This attribute Enables/Disables the transmission of
V6Msg Destination Unreachable Messages.
Destination
Unreachable
Enabled
tcpIpIcmp Boolean 0..1 attr If enabled an ICMPv6 parameter problem message will
V6Msg be sent if a received packet has been dropped due to
Parameter unknown options or headers that are found in the packet.
Problem
Enabled
Table 3.94: TcpIpIcmpv6Props

[constr_5125] Value range of TcpIpIcmpv4Props.tcpIpIcmpV4Ttl dIf defined,

the value of TcpIpIcmpv4Props.tcpIpIcmpV4Ttl shall be in the range of 1..255.c
()

133 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_5154] Value range of TcpIpIcmpv6Props.tcpIpIcmpV6HopLimit dIf de-

fined, the value of TcpIpIcmpv6Props.tcpIpIcmpV6HopLimit shall be in the
range of 1..255.c()

3.3.6.8 Ethernet wake-up and sleep on dataline

AUTOSAR supports the wake-up and sleep mechanism that complies with the Open
Alliance TC10 specification (OA TC10, see [17]).
[TPS_SYST_03052] Enabling of wake-up and sleep mechanism dThe wake-up
and sleep mechanism that complies with the Open Alliance TC10 specification (OA
TC10) is enabled by defining the reference from CouplingPort to EthernetWake-
upSleepOnDatalineConfig in the role wakeupSleepOnDatalineConfig.c()
FibexElement
EthernetWakeupSleepOnDatalineConfigSet

+ethernetWakeupSleepOnDatalineConfig 0..*

CommunicationController Identifiable
EthernetCommunicationController EthernetWakeupSleepOnDatalineConfig

+ macLayerType: EthernetMacLayerTypeEnum [0..1] + sleepModeExecutionDelay: TimeValue [0..1]

+ macUnicastAddress: MacAddressString [0..1] + sleepRepetitionDelayOfSleepRequest: TimeValue [0..1]
+ maximumReceiveBufferLength: Integer [0..1] + sleepRepetitionsOfSleepRequest: PositiveInteger [0..1]
+ maximumTransmitBufferLength: Integer [0..1] + wakeupForwardLocalEnabled: Boolean [0..1]
+ slaveActAsPassiveCommunicationSlave: Boolean [0..1] + wakeupForwardRemoteEnabled: Boolean [0..1]
+ slaveQualifiedUnexpectedLinkDownTime: TimeValue [0..1] + wakeupLocalDetectionTime: TimeValue [0..1]
+ wakeupLocalDurationTime: TimeValue [0..1]
+ wakeupLocalEnabled: Boolean [0..1]
+ wakeupRemoteEnabled: Boolean [0..1]
+ wakeupRepetitionDelayOfWakeupRequest: TimeValue [0..1]
+ wakeupRepetitionsOfWakeupRequest: PositiveInteger [0..1]

+wakeupSleepOnDatalineConfig 0..1
+couplingPort 0..*
Identifiable
CouplingPort

FibexElement +couplingPort + connectionNegotiationBehavior: EthernetConnectionNegotiationEnum [0..1]

CouplingElement + couplingPortRole: CouplingPortRoleEnum [0..1]
0..* + macLayerType: EthernetMacLayerTypeEnum [0..1]
«atpVariation,atpSplitable» + physicalLayerType: EthernetPhysicalLayerTypeEnum [0..1]
+ couplingType: CouplingElementEnum
+ receiveActivity: EthernetSwitchVlanIngressTagEnum [0..1]

Figure 3.18: Wake on dataline model elements

The OA TC10 specifies service primitives to abstract the Ethernet hardware for ECUs
connected via Automotive Ethernet (<bandwith>Base-T1). Drivers use the service
primitives to trigger a wake-up and sleep on dataline and react on appropriate indi-
cations: Sleep.request, Sleep.indication, Wakeup.indication, Wakeup.request, Sleep-
Fail.indication, and SleepAbort.request.
Note:
• SleepAbort.request is not considered by AUTOSAR, as the AUTOSAR Network
Management ensures a synchronized shutdown on the network. Thus, there is
no need for an ECU to reject a Sleep.request upon the Network Management.
• Inhibit.Indication is not a service primitive, but an optional interface. This optional
interface is not considered in AUTOSAR.

134 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class EthernetWakeupSleepOnDatalineConfig
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note EthernetWakeupSleepOnDatalineConfigSet is the main element that aggregates different config set
regarding the wakeup and sleep on data line.
An EthernetWakeupSleepOnDatalineConfigSet could aggregate multiple different configurations
regarding the wakeup and sleep on dataline (EthernetWakeupSleepOnDatalineConfig).
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
sleepMode TimeValue 0..1 attr Delay in seconds to perform a sleep request if the
ExecutionDelay Ethernet hardware (PHY) detect a pending wake-up. This
is used to avoid the race condition, if a sleep was
requested while a wake-up of a neighboring PHY was
received via a local wake-up connection (e.g. I/O pin).
sleepRepetition TimeValue 0..1 attr Delay in seconds for a repetition of a sleep request. This
DelayOfSleep is used to retry a synchronized shutdown of the
Request connected Ethernet hardware (PHY) of the link partner.
sleep PositiveInteger 0..1 attr Count of repetitions for a sleep on dataline. If a sleep is
RepetitionsOf rejected by the linked communication partner, the sleep is
SleepRequest repeated until the count of repetitions exceed. If count of
repetitions exceed, the Ethernet hardware (PHY) transit
to sleep without acknowledgement of the connected link
partner.
wakeupForward Boolean 0..1 attr If enabled, then a remote wake-up received on the
LocalEnabled physical dataline (e.g. 100BASE-T1) is forwarded as local
wake-up (e.g. via an I/O pin). If disabled, then a remote
wake-up is not forwarded as local wake-up.
wakeupForward Boolean 0..1 attr If enabled, then a local wake-up is forwarded to the
RemoteEnabled physical dataline (e.g. 100BASE-T1). If disabled, then a
local wake-up is not forwarded to the physical dataline.
wakeupLocal TimeValue 0..1 attr Specify the detection time if a local wake-up in seconds is
DetectionTime present on the local wake-up connection (e.g. I/O pin). A
local wake-up has to be present at least for wakeupLocal
DetectionTime to be detected a valid local wake-up.
wakeupLocal TimeValue 0..1 attr Specify the duration of a local wake-up in seconds to be
DurationTime present on the local wake-up connection (e.g. I/O pin).
wakeupLocal Boolean 0..1 attr If enabled, then a local wake-up received via a local
Enabled connection (e.g. I/O pin) shall be detected by the Ethernet
hardware (PHY). If disabled, Ethernet hardware is not
reacting on a local wake-up.
wakeupRemote Boolean 0..1 attr If enabled, then a remote wake-up received via the
Enabled physical dataline (e.g. 100BASE-T1) shall be detected by
the Ethernet hardware (PHY). If disabled, Ethernet
hardware is not reaction on a remote wake-up.
wakeup TimeValue 0..1 attr Delay in seconds for a repetition of a wake-up. This is
RepetitionDelay used to increase the reliability in the network, such that
OfWakeup an ECU which initiates the wake-up does repeat the
Request wake-up and increase the probability that affected ECUs
receive the wake-up.
wakeup PositiveInteger 0..1 attr Count of repetitions for a wake-up. This is used to
RepetitionsOf increase the reliability in the network, such that an ECU
Wakeup which initiates the wake-up does repeat the wake-up and
Request increase the probability that affected ECUs receive the
wake-up.

Table 3.95: EthernetWakeupSleepOnDatalineConfig

135 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class EthernetWakeupSleepOnDatalineConfigSet
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note This meta-class is the main element that aggregates different config set regarding the ethernet wakeup
and sleep on data line.
Tags:atp.recommendedPackage=EthernetWakeupSleepOnDatalineConfigSets
Base ARObject, CollectableElement, FibexElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
ethernet EthernetWakeupSleep * aggr The relationship defines a collection of EthernetWakeup
WakeupSleep OnDatalineConfig SleepOnDatalineConfig configurations which are
OnDataline available.
Config

Table 3.96: EthernetWakeupSleepOnDatalineConfigSet

[constr_3601] Mandatory attributes of EthernetWakeupSleepOnDatalineCon-

fig dThe following attributes of EthernetWakeupSleepOnDatalineConfig shall
be defined at the time when the COM Stack is generated:
• wakeupLocalEnabled
• wakeupRemoteEnabled
c()
[constr_3602] Existence of wakeupForwardLocalEnabled dThe attribute wake-
upForwardLocalEnabled shall be defined if wakeupRemoteEnabled is set to
TRUE.c()
[constr_3603] Existence of wakeupLocalDurationTime dThe attribute wakeu-
pLocalDurationTime shall be defined if wakeupForwardLocalEnabled is set to
TRUE.c()
[constr_3604] Existence of wakeupForwardRemoteEnabled dThe attribute wake-
upForwardRemoteEnabled shall be defined if wakeupLocalEnabled is set to
TRUE.c()
[constr_3605] Existence of wakeupLocalDetectionTime dThe attribute wakeu-
pLocalDetectionTime shall be defined if wakeupForwardRemoteEnabled is set
to TRUE.c()
[constr_3606] Values of wakeupLocalDurationTime and wakeupLocalDetec-
tionTime dIf defined, then the value of wakeupLocalDurationTime shall be
greater than the value of wakeupLocalDetectionTime.c()
[constr_3609] Values of wakeupLocalDurationTime in the context of a Cou-
plingElement dAll CouplingPorts which have the reference wakeupSleepOn-
DatalineConfig defined and
• where the CouplingPorts are aggregated by the same CouplingElement
and

136 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• where the referenced EthernetWakeupSleepOnDatalineConfig has the at-

tribute wakeupLocalDurationTime defined
shall refer to EthernetWakeupSleepOnDatalineConfigs where the value of
wakeupLocalDurationTime is identical for all referencing CouplingPorts.c()
[constr_3610] Values of wakeupLocalDetectionTime in the context of a Cou-
plingElement dAll CouplingPorts which have the reference wakeupSleepOn-
DatalineConfig defined and
• where the CouplingPorts are aggregated by the same CouplingElement
and
• where the referenced EthernetWakeupSleepOnDatalineConfig has the at-
tribute wakeupLocalDetectionTime defined
shall refer to EthernetWakeupSleepOnDatalineConfigs where the value of
wakeupLocalDetectionTime is identical for all referencing CouplingPorts.c()
Note: [constr_3609] and [constr_3610] ensure the same timing behavior within the
used Ethernet hardware (e.g. Ethernet switch), if those CouplingPorts reference
different EthernetWakeupSleepOnDatalineConfigs.
[constr_3607] Existence of sleepRepetitionDelayOfSleepRequest dThe at-
tribute sleepRepetitionDelayOfSleepRequest shall be defined if sleepRepe-
titionsOfSleepRequest is defined and has a value greater than 0.c()
[constr_3608] Existence of wakeupRepetitionDelayOfWakeupRequest dThe
attribute wakeupRepetitionDelayOfWakeupRequest shall only be defined if
wakeupRepetitionsOfWakeupRequest is defined and has a value greater than
0.c()
Note: The OA TC10 [17] wake-up on dataline feature can be used instead of a wake-up
line. The different timing behavior has to be considered. If using a wake-up line, the
wake-up pulse is present for all connected ECUs at the same point in time. If using
wake-up on dataline, the wake-up (WUP / WUR) has to be forwarded by the receiving
Ethernet hardware (PHY). The wake-up is propagated over the network and therefore
it is sequentially present for the receiving ECUs.
The following chapters describe the behavior in detail with respect to the OA TC10
service primitives and their modelling in the System Template.

3.3.6.8.1 Ethernet Communication Controller

[constr_3600] Setting of EthernetCommunicationController.slaveActAs-

PassiveCommunicationSlave dThe attribute EthernetCommunicationCon-
troller.slaveActAsPassiveCommunicationSlave may only be set to TRUE,
if the following conditions apply:

137 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• the EthernetCommunicationController is not referenced by any NmNode

in the role controller
• the EthernetCommunicationController aggregates at least one Cou-
plingPort
• the couplingPortRole of that CouplingPort is set to standardPort
• the physicalLayerType of that CouplingPort is set to either _100BASE_T1
or _1000BASE_T1
In all other cases the attribute slaveActAsPassiveCommunicationSlave shall be
set to FALSE or shall not be defined.c()
Note: An Ethernet ECU which aggregates an EthernetCommunicationCon-
troller that is acting as a passive slave is not using Nm frames for a synchronized
shutdown. A synchronized shutdown has to be provided by the used Ethernet hard-
ware. E.g. Ethernet hardware compliant with Open Alliance TC10.
Note further: It is only allowed for Ethernet ECUs which are NOT maintaining an Eth-
ernet switch on the corresponding communication channel to act as a passive slave. A
passive slave follows the communication request of the corresponding communication
master.
[constr_3611] Existence of EthernetCommunicationController.slaveQual-
ifiedUnexpectedLinkDownTime dThe attribute slaveQualifiedUnexpect-
edLinkDownTime shall be defined if slaveActAsPassiveCommunicationSlave
is set to TRUE.c()
[TPS_SYST_03053] Semantics of EthernetCommunicationController.
slaveQualifiedUnexpectedLinkDownTime dEthernetCommunicationCon-
troller.slaveQualifiedUnexpectedLinkDownTime specifies the time when
an unexpected link down is evaluated as link down and indicated to the AUTOSAR
communication stack.
If slaveActAsPassiveCommunicationSlave is set to FALSE or not defined, then
the communication channel is not acting as a passive communication slave.c()
The link down time qualification is used for an EthernetCommunicationCon-
troller where slaveActAsPassiveCommunicationSlave is set to TRUE. The
time should cover an error scenario where the corresponding communication master
was not able to release the communication by triggering an Sleep.Request (e.g. com-
munication master was unexpectedly reset).

3.3.6.8.2 Service primitives for wake-up

An Ethernet ECU which wants to communicate with other ECUs within the Ether-
net switched network topology has to trigger a wake-up on the network to propagate
the communication request to the communication partners. The ECU which triggers

138 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

the wake-up is the requesting ECU. The requesting ECU calls the service primitive
Wakeup.request to trigger a wake-up. The wake-up is transmitted via the physical
dataline (e.g. 100BASE-T1) to the connected link partner. The wake-up could be a
wake-up pulse (WUP), Figure
if the 4link
PHYtoofthe connected
requesting ECUlink partner
transmit is down,
a wake-up or a
on the wake-up
network
request (WUR), if the link is up (link is already established).

Switch1 Switch2

ECU3 ECU6
ECU2 ECU5

requesting

ECU1 ECU4

Link down Propag. Sleep command PHY active

Link active Progag. local wake up
PHY sleep
Propag. WUP
Propag. WUR ECU normal mode
ECU power down 1

Figure 3.19: While the link is down on the connected dataline, the PHY of ECU1
<< sublinetransmit
>>
22 October
2020
1
a wake-up on the network

If a WUP is transmitted by ECU1 and received by the Ethernet hardware (PHY) of

Switch1, the receiving Ethernet hardware of Switch1 is woken up. After the receiv-
ing Ethernet hardware is initialized, the Switch1 is powered up (INHIBIT pin of power
supply is set by the PHY (see OA TC10)) and a Wakeup.indication is generated.
(Note: If a WUR is transmitted, the receiving Ethernet hardware (PHY) generates im-
mediately a Wakeup.indication, because the receiving Ethernet hardware is already
initialized and in normal mode). Simultaneously the received wake-up could be for-
warded as local wake-up to the
Figure neighboring
5 The PHY of the PHYs of ECU
receiving Switch1, if the
is woken up PHYs are up
and power config-
the Switch
ured accordingly.
receiving

Switch1 Switch2

ECU3 ECU6
ECU2 ECU5

requesting

ECU1 ECU4

Link down Propag. Sleep command PHY active

Link active Progag. local wake up
PHY sleep
Propag. WUP
Propag. WUR ECU normal mode
ECU power down 2

Figure 3.20: Switch1 is woken up by the PHY that received the wake-up. <<
The
sublinereceived
>>
22 October
2020
2
wake-up on the network is forwarded as local wake-up to the neighboring PHYs

139 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

In multi-PHY and Ethernet switch scenarios, a received wake-up is most likely for-
warded to all connected link partners (other datalines) without host ECU (ECU that
maintain a Ethernet switch) involvement
Figure 6 to fulfill
The propagated wake-upis propagation
local wake-up time
forwarded by the require- PHYs as
neighboring
ments. WUP to the connected ECUs
receiving

Switch1 Switch2

ECU3 ECU6
ECU2 ECU5

requesting

ECU1 ECU4

Link down Propag. Sleep command PHY active

Link active Progag. local wake up
PHY sleep
Propag. WUP
Propag. WUR ECU normal mode
ECU power down 3

Figure 3.21: The propagated local wake-up is forwarded by the neighboring PHYs
<< subline >>
22as
October
2020
3
WUP to the connected ECUs (ECU2, ECU3 and Switch2)

The forwarding behavior of each PHY can be modelled in the SystemTemplate. Each
PHY is modelled as CouplingPort. Each CouplingPort could enable the OA
TC10 compliant wake-up and sleep on dataline by defining a wakeupSleepOn-
DatalineConfig reference.

3.3.6.8.3 Service primitives for sleep

An ECU which is ready to go to sleep calls the service primitive Sleep.request (ECU1).
The sleep request is transmitted via the physical dataline (e.g. 100BASE-T1) to the
connected communication partner as LPS (low power sleep signal), here Switch1.
Please note: LPS are send as continues burst with respect to the specified timing
in OA TC10.

140 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
Figure 7 Sleep.request AUTOSAR CP R21-11

receiving

Switch1 Switch2

ECU3 ECU6
ECU2 ECU5

requesting

ECU1 ECU4

Link down Propag. Sleep command PHY active

Link active Progag. local wake up
PHY sleep
Propag. WUP
Propag. WUR ECU normal mode
ECU power down 4

Figure 3.22: ECU1 triggers a Sleep.request and the Ethernet hardware of <<ECU1 23 October
subline >> sends
2020
4
LPS on the dataline

The receiving Ethernet hardware (PHY) generates a Sleep.indication to notify the re-
ceiving ECU (here Switch1) that the Ethernet hardware (PHY) of the requesting ECU1
is requesting to go to sleep. The receiving Ethernet hardware (PHY) of the connected
communication partner follow the defined PHY power mode sequence described in
OA TC10 and acknowledge Figurethe received Sleep.request
7 Sleep.request with a Sleep.request back to
ackknowledgement
requesting ECU (ECU1) with respect to the specified timings in OA TC10.
receiving

Switch1 Switch2

ECU3 ECU6
ECU2 ECU5

requesting

ECU1 ECU4

Link down Propag. Sleep command PHY active

Link active Progag. local wake up
PHY sleep
Propag. WUP
Propag. WUR ECU normal mode
ECU power down 5

Figure 3.23: Ethernet hardware (PHY) of Switch1 receives LPS and acknowledges
<< subline >> the 22 October
2020
5
indicated Sleep.request of ECU1 by sending back LPS to ECU1

If the requesting ECU (ECU1) received a Sleep.request from the receiving ECU
(Switch1) within the specified time of OA TC10 the Ethernet hardware of both ECUs
(requesting and receiving ECU) transit to sleep state, i.e. the Ethernet hardware of
both, ECU1 and Switch1 transit to a low power down mode and the link connection is
down.

141 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP isR21-11
Figure 7 Sleep state reached, PHYs are in sleep state and link down

receiving

Switch1 Switch2

ECU3 ECU6
ECU2 ECU5

requesting

ECU1 ECU4

Link down Propag. Sleep command PHY active

Link active Progag. local wake up
PHY sleep
Propag. WUP
Propag. WUR ECU normal mode
ECU power down 6

Figure 3.24: ECU1 send and receive LPS with respect to the specified timings
<< subline >> in OA
22 October
2020
6
TC10 and therefore the Etherent hardware (PHY) of ECU1 and Switch1 transit to a low
power sleep mode and the link of the dataline is down

ECUs which participate in an AUTOSAR network management (NM), switch off their
communication hardware according to already defined NM shutdown process. Thus,
an additional handling in the AUTOSAR stack for an Ethernet communication chan-
nel to react on a Sleep.indication upon the network management shutdown process is
superfluous. The Sleep.indication is only evaluated by ECUs which have Ethernet-
CommunicationController.slaveActAsPassiveCommunicationSlave set to
TRUE (see details in chapter 3.3.6.8.4).
If the NM decides to go to sleep, then the linked ECUs may switch off their connected
hardware at slightly different points in time (e.g. Ethernet switches switch off their Eth-
ernet switch ports with a configured time delay (see couplingPortSwitchoffDe-
lay)). The ECU which earlier switches off the communication hardware will trigger a
Sleep.request. The connected Ethernet hardware (PHY) of the communication partner
will go to sleep according to the defined PHY power mode sequence described in OA
TC10. Afterwards the ECU which later switches off its Ethernet hardware has to check
the power mode of its Ethernet hardware (PHY). If the Ethernet hardware is already in
sleep mode, then the ECU will leave the hardware state as it is and do not trigger a
Sleep.request. Otherwise the ECU will trigger a Sleep.request.

142 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
Figure 8 ECU1 transit to sleep a bit earlier AUTOSAR CP R21-11

receiving

Switch1 Switch2

ECU3 ECU6
ECU2 ECU5

requesting

ECU1 ECU4

Link down Propag. Sleep command PHY active

Link active Progag. local wake up
PHY sleep
Propag. WUP
Propag. WUR ECU normal mode
ECU power down 7

Figure 3.25: ECU1 (requesting ECU) is already in power down mode, << subline >> while
22 October
2020
7
Switch1 is waiting until couplingPortSwitchoffDelay has expired. If coupling-
PortSwitchoffDelay has expired, Switch1 will detect that the Ethernet hardware is
already in sleep state and therefore will NOT trigger a Sleep.request

According to the specified service primitive Sleep.AbortRequest, the receiving ECU

could decide to reject a Sleep.request via Sleep.AbortRequest. AUTOSAR does NOT
support the service primitive Sleep.AbortRequest, since the AUTOSAR network man-
agement (NM) provide a synchronized shut down of the ECUs. Thus, there is no need
to enable an explicit reject of a received Sleep.request.
Even though the explicit rejection of a Sleep.request is NOT supported, the ECU which
requested the Sleep.request could be indicated that the Sleep.request was NOT ac-
cepted by the Ethernet hardware (PHY) of the receiving ECU. If the Sleep.request was
not acknowledge by Ethernet hardware (PHY) of the receiving ECU, the requesting
ECU is signalled via the service primitive SleepFail.indication. Reason is an error sce-
nario, where the Sleep.request was not received by Ethernet hardware of the receiving
ECU or the acknowledgement of the Sleep.request back to the requesting ECU was
lost on the network (e.g. disturbance of the LPS by a EMC pulse, loose contact of
the dataline ... a.s.o.). The ECUs are always evaluating if a SleepFail.indication was
indicated.
The handling of a detected SleepFail.indication is modelled by defining the repetition of
a Sleep.request (sleepRepetitionsOfSleepRequest) and the delay to re-trigger
a Sleep.request (sleepRepetitionDelayOfSleepRequest). If the count of repe-
titions is exceed and SleepFail.indication is still signalled, the Ethernet hardware (PHY)
is forced to transit to a sleep state and indicate the upper layer of the AUTOSAR com-
munication stack a Sleep.indication. This should prevent the requesting ECU to be
kept awake if no Sleep.request was acknowledged by the receiving ECU.

143 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

3.3.6.8.4 Ethernet communication channel that act as passive communication

slave

ECUs which are connected to communication channels that do not participate in

the AUTOSAR network management can be controlled by a master / slave relation-
ship. The connected Ethernet communication channel is controlled by using the
following service primitives: Wakeup.request, Wakeup.indication, Sleep.request, and
Sleep.indication.
A host ECU (Ethernet ECU which maintains an Ethernet switch) requests to
wake-up an Ethernet communication channel of a connected ECU where the
corresponding EthernetCommunicationController has set slaveActAsPas-
siveCommunicationSlave to TRUE (passive communication slave) by triggering a
Wakeup.request. The wake-up brings the Ethernet hardware (PHY) of the receiving
ECU from a sleep mode to a normal mode. The receiving ECU is powered on and its
application may provide data which is consumed by the requesting ECU (communica-
tion master).
If the requesting ECU (communication master) decides to shutdown the communica-
tion channel, the host ECU request the communication channel to go to sleep by trig-
gering a Sleep.request. The requested Sleep.request is received by the connected
ECU on the communication channel with acts as a communication slave. The received
Sleep.request will be acknowledged by the Ethernet hardware (PHY) of the receiving
ECU (passive communication slave) and simultaneously a Sleep.indication is signalled.
The receiving ECU evaluates the Sleep.indication.
If a Sleep.indication is detected, this indication is forwarded to the communication stack
and the affected communication channel is released. Additionally the application could
be indicated about the communication release to execute some shut down actions.
Thus, an Ethernet communication channel which acts as passive communication slave,
always follows the Wakeup.indication/Sleep.indication of the corresponding communi-
cation master. To cover an error scenario where the communication master could not
trigger a Sleep.request, due to unexpected reset, the receiving ECU, where an Ethernet
channel is acting as passive communication slave, has to detect a link down. If an un-
expected link down last longer than slaveQualifiedUnexpectedLinkDownTime,
the Ethernet channel, which is acting as passive communication slave, is released
autonomously by the receiving ECU.

3.3.7 10BASE-T1S Ethernet

10BASE-T1S is a 10Mbps Single pair Ethernet physical layer technology that is spec-
ified by IEEE 802.3cg. The multi-drop feature of 10BASE-T1S allows the usage of
a single bus-line to connect ECUs. The PLCA (Physical Layer Collision Avoidance)
mechanism avoids collision on PHY level and offers a fair medium access to every
participant.

144 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

All nodes are identified on the bus via nodeIDs (plcaLocalNodeId) starting from
0 (standardized as the referenced head-node). The Head-Node on the PLCA based
network controls the traffic on the bus.
[TPS_SYST_02299] Modeling of 10Base-T1S networks dThe modeling of a
10BASE-T1S bus in a System Description is done with a CouplingPortConnec-
tion that points with the nodePort reference to CouplingPorts that represent the
10Base-T1S PHYs connected to the network.c()
[constr_5157] Mixing of Point-To-Point and Multi-Drop is not allowed in a Cou-
plingPortConnection dThe CouplingPortConnection is allowed to reference
a CouplingPort either:
• in the role firstPort and/or secondPort or
• in the role nodePort
c()
In other words a CouplingPortConnection shall not use the firstPort and/or
secondPort reference (Point-to-Point) and the nodePort reference (Multi-Drop) at
the same time.
The PLCA runs cycles on the network. Within each cycle each node with a unique
plcaLocalNodeId is assigned with a transmit opportunity. The plcaTransmitOp-
portunityTimer is identical for all nodes and is therefore configured in the Cou-
plingPortConnection.
The cycle starts with a BEACON that is sent by the head node. During the transmit
opportunity the node is able to transmit data or to skip its transmit opportunity. If a node
does not need to transmit data the next node is allowed to start its transmit opportunity
earlier.
At each BEACON reception client nodes restart their currentNodeID counter and in-
crement it every time a Transmit Opportunity is used or yield. If the currentNodeID
matches the plcaLocalNodeId, the corresponding node is allowed to transmit an
Ethernet frame for this Transmit Opportunity. The plcaTransmitOpportunity-
Timer is reset for every Transmit Opportunity once the transceiver detects activity
on the bus and recognizes the transmission of data. At each Transmit Opportunity no
more than one single Ethernet frame will be sent. On the other hand, if a node has the
necessity to sent more packets in one Transmit Opportunity, a burst mode can be used.
The burst mode is configured by plcaMaxBurstTimer and plcaMaxBurstCount.
[TPS_SYST_02300] Enabling of PLCA on a CouplingPort dThe PLCA (Physi-
cal Layer Collision Avoidance) mechanism is enabled on a CouplingPort if the
plcaProps are aggregated by the same CouplingPort.c()

145 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class PlcaProps
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note This meta-class allows to configure the PLCA (Physical Layer Collision Avoidance) in case 10-BASE-T1S
Ethernet is used and PLCA is enabled on the CouplingPort (PHY).
Base ARObject
Attribute Type Mult. Kind Note
plcaLocalNode PositiveInteger 0..1 attr This attribute defines the node ID when the PLCA mode
Id for 10BASE-T1S is used.
plcaMaxBurst PositiveInteger 0..1 attr Defines maximum packets allowed to be transmitted
Count within a TO. This configuration can be different from one
ECU to another within the PLCA mixed segment.
plcaMaxBurst PositiveInteger 0..1 attr Limits the burst frames in bit time. This configuration can
Timer be different from one ECU to another within the PLCA
mixed segment. For PLCA burst mode to work properly
this timer should be set greater than one IPG.

Table 3.97: PlcaProps

[constr_5158] Usage of plcaProps only allowed on 10BASE-T1S networks dA

CouplingPort is allowed to aggregate plcaProps only if:
• the CouplingPort.physicalLayerType is set to 10BASE-T1S
• the CouplingPort.macLayerType is set to xMII
• the CouplingPort is referenced by a CouplingPortConnection with the
nodePort reference.
c()
Please note that it is possible to have a mix network with PLCA and CSMA/CD config-
ured nodes.
[TPS_SYST_02301] CSMA/CD configured nodes on a 10BASE-T1S network dIf a
CouplingPort is referenced by a CouplingPortConnection with the nodePort
reference and the CouplingPort.physicalLayerType is set to 10BASE-T1S and
this CouplingPort does not aggregate plcaProps then this CouplingPort repre-
sents a CSMA/CD configured node in a 10BASE-T1S network.c()
The following example shows a configured 10BASE-T1S network with four nodes in a
System Description.

146 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Ecu1: EcuInstance Ecu2: EcuInstance Ecu3: EcuInstance

Ecu4: EcuInstance

+commController +commController +commController +commController

Ecu1EthernetController: Ecu2EthernetController: Ecu3EthernetController: Ecu4EthernetController:

EthernetCommunicationController EthernetCommunicationController EthernetCommunicationController EthernetCommunicationController

+couplingPort +couplingPort +couplingPort +couplingPort

Ecu1PHY: CouplingPort Ecu2PHY: CouplingPort Ecu3PHY: CouplingPort Ecu4PHY: CouplingPort

physicalLayerType = 10BASE-T1S macLayerType = xMII physicalLayerType = 10BASE-T1S physicalLayerType = 10BASE-T1S

macLayerType = xMII physicalLayerType = 10BASE-T1S macLayerType = xMII macLayerType = xMII
+nodePort +nodePort +nodePort +nodePort

+plcaProps +plcaProps +plcaProps +plcaProps

:PlcaProps :PlcaProps :PlcaProps :PlcaProps

plcaLocalNodeId = 0 plcaLocalNodeId = 1 plcaLocalNodeId = 2 plcaLocalNodeId = 3

plcaMaxBurstTimer = 128 plcaMaxBurstCount = 15 plcaMaxBurstCount = 25 plcaMaxBurstTimer = 200
plcaMaxBurstCount = 10 plcaMaxBurstTimer = 128 plcaMaxBurstTimer = 200 plcaMaxBurstCount = 30

:CouplingPortConnection

plcaLocalNodeCount = 4
plcaTransmitOpportunityTimer = 20

+couplingPortConnection

:EthernetCluster

Figure 3.26: Example for a 10BASE-T1S network description

[constr_5159] Mandatory CouplingPortConnection settings if multi-drop fea-

ture is used dIf a CouplingPortConnection uses the nodePort reference then
the attribute CouplingPortConnection.plcaLocalNodeCount and the attribute
CouplingPortConnection.plcaTransmitOpportunityTimer shall be set to a
value.c()
[constr_5160] Mandatory PlcaProps settings if multi-drop feature is used dIf a
CouplingPort is referenced by a CouplingPortConnection in the role node-
Port then the CouplingPort shall aggregate the PlcaProps and the following at-
tributes shall be set to a value:
• plcaMaxBurstCount
• plcaMaxBurstTimer
• plcaLocalNodeId
c()

147 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

3.3.8 CDD

The System Template allows the integration of custom bus systems on the topology
level.
[TPS_SYST_01127] CDD Topology support dThe elements UserDefinedClus-
ter, UserDefinedPhysicalChannel, UserDefinedCommunicationConnec-
tor and UserDefinedCommunicationController can be used to describe al-
ternative communication technologies (e.g. I2C, USB, serial line) that are integrated in
AUTOSAR as Complex Drivers.c(RS_SYST_00044)
The Pdu-based communication via Complex Drivers is described in chapter 6.14.
+managedPhysicalChannel 0..*
FibexElement
«atpVariation» Identifiable
CommunicationCluster +physicalChannel PhysicalChannel

+ baudrate: PositiveUnlimitedInteger [0..1] «atpVariation,atpSplitable» 1..*

+ protocolName: String [0..1]
+ protocolVersion: String [0..1]

«atpVariation»

+commConnector 0..*

Identifiable Identifiable
+commController CommunicationConnector
«atpVariation»
CommunicationController + createEcuWakeupSource: Boolean [0..1]
1
+ wakeUpByControllerSupported: Boolean [0..1] + dynamicPncToChannelMappingEnabled: Boolean [0..1]
+ pncFilterArrayMask: PositiveInteger [0..*] {ordered}
+ pncGatewayType: PncGatewayTypeEnum [0..1]

UserDefinedCluster UserDefinedCommunicationController UserDefinedCommunicationConnector UserDefinedPhysicalChannel

Figure 3.27: User defined topology elements

Class <<atpVariation>> UserDefinedCluster

Package M2::AUTOSARTemplates::SystemTemplate::Fibex::CddSupport
Note This element allows the modeling of arbitrary Communication Clusters (e.g. bus systems that are not
supported by AUTOSAR).
Tags:atp.recommendedPackage=CommunicationClusters
Base ARObject, CollectableElement, CommunicationCluster , FibexElement, Identifiable, Multilanguage
Referrable, PackageableElement, Referrable
Attribute Type Mult. Kind Note
– – – – –
Table 3.98: UserDefinedCluster

Class UserDefinedPhysicalChannel
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::CddSupport
Note This element allows the modeling of arbitrary Physical Channels.
Base ARObject, Identifiable, MultilanguageReferrable, PhysicalChannel, Referrable
5

148 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class UserDefinedPhysicalChannel
Attribute Type Mult. Kind Note
– – – – –
Table 3.99: UserDefinedPhysicalChannel

Class UserDefinedCommunicationConnector
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::CddSupport
Note This element allows the modeling of arbitrary Communication Connectors.
Base ARObject, CommunicationConnector , Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
– – – – –
Table 3.100: UserDefinedCommunicationConnector

Class <<atpVariation>> UserDefinedCommunicationController

Package M2::AUTOSARTemplates::SystemTemplate::Fibex::CddSupport
Note This element allows the modeling of arbitrary Communication Controllers.
Base ARObject, CommunicationController , Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
– – – – –
Table 3.101: UserDefinedCommunicationController

3.4 Mapping of Topology Entities onto Hardware Elements

As explained in the previous sections, the System Template contains all classes nec-
essary to describe the physical topology in an AUTOSAR system. Based on this de-
scription, the communication matrix can be realized as explained in chapter 6.
[TPS_SYST_01019] Mapping of topology elements to elements of the ECU Re-
source Template dIt is possible to map the hardware related topology elements onto
their counterpart definitions in the ECU Resource Template.c(RS_SYST_00006)
It can be specified which HwElement is realizing each given EcuInstance, provid-
ing the means for algorithms to map software components onto the systems EcuIn-
stance. By specifying which hwCommunicationPort3 on a hwCommunication-
Controller4 implements the topology’s CommunicationConnector on a Com-
municationController, the hardware-oriented parameters in the Communication-
drivers may be derived in ECU configuration phase.
Please note that this is a rather specific type of mapping, optionally binding ECU-local
topology elements to specific hardware resources. It should not be confused with the

3
HwPinGroup which is of category Communication Port
4
HwElement which is of category Communication Controller

149 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

System Mapping part of the System Description, where system-wide mapping deci-
sions are described, like e.g. the the mapping of Software Components onto ECUs or
the mapping of Data Element Prototypes onto System Signals (for the System Map-
ping, see chapter 5).
Identifiable
CommunicationControllerMapping
+communicationController «atpVariation»
CommunicationController +commController
1
+ wakeUpByControllerSupported: Boolean [0..1] 1

+commControllerMapping 1..*
+commController 1..*
«atpVariation»

FibexElement
EcuInstance

+hwCommunicationController 1 + comConfigurationGwTimeBase: TimeValue [0..1]

+ comConfigurationRxTimeBase: TimeValue [0..1]
ARElement Identifiable + comConfigurationTxTimeBase: TimeValue [0..1]
HwDescriptionEntity +ecu ECUMapping +ecuInstance + comEnableMDTForCyclicTransmission: Boolean [0..1]
HwElement + ethSwitchPortGroupDerivation: Boolean [0..1]
1 1 + pncPrepareSleepTimer: TimeValue [0..1]
+ pncSynchronousWakeup: Boolean [0..1]
+ pnResetTime: TimeValue [0..1]
+ sleepModeSupported: Boolean
+ v2xSupported: V2xSupportEnum [0..1]
+ wakeUpOverBusSupported: Boolean

«atpVariation»

«atpVariation»
+connector *
+hwPinGroup 0..* +hwPortMapping 1..* Identifiable
HwDescriptionEntity CommunicationConnector
HwPortMapping
Identifiable +hwCommunicationPort +communicationConnector
HwPinGroup + createEcuWakeupSource: Boolean [0..1]
1 1 + dynamicPncToChannelMappingEnabled: Boolean [0..1]
+ pncFilterArrayMask: PositiveInteger [0..*] {ordered}
+ pncGatewayType: PncGatewayTypeEnum [0..1]

Figure 3.28: Mapping of topology description elements in the System Template onto
hardware elements defined in the ECU Resource Template (ECUResourceMapping)

[constr_3006] valid EcuMapping dThe referenced hwCommunicationController

and hwCommunicationPort shall be part of the referenced ecu.
ECUMapping.ecu.nestedElement contains ECUMapping.commControllerMap-
ping.hwCommunicationController
ECUMapping.ecu.nestedElement contains ECUMapping.hwPortMapping.hwCom-
municationPortc()

3.4.1 ECU Mapping

ECUMapping allows to assign a HwElement to an EcuInstance used in a physical

topology.
[TPS_SYST_01013] EcuInstance stands for its own dAn EcuInstance can be
defined in a stand alone and reusable way without a need to have an ECUMapping.c
(RS_SYST_00013)
[constr_3030] valid relationship between ECUMapping and EcuInstance dIf an
EcuInstance is assigned to a HwElement the EcuInstance shall belong to the
same System as the ECUMapping.c()

150 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_3248] Category of HwElement for ECUMapping dThe HwElement which

is referenced from ECUMapping in the role ecu shall be of category MicroCon-
trollerc()
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 (HwElement of
category Ecu) containing the electronics which may contain several processing units
with several AUTOSAR Stack instances running.
Class ECUMapping
Package M2::AUTOSARTemplates::SystemTemplate::ECUResourceMapping
Note ECUMapping allows to assign an ECU hardware type (defined in the ECU Resource Template) to an
ECUInstance used in a physical topology.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
commController Communication 1..* aggr The ECUMapping contains the mapping of all
Mapping ControllerMapping CommunicationControllers of the ECU.
ecu HwElement 1 ref Reference to a HwElement of category ECU in the ECU
Resource Template.
ecuInstance EcuInstance 1 ref Reference to the EcuInstance in the System Template
hwPortMapping HwPortMapping 1..* aggr The ECUMapping contains the mapping of all HW
Communication Ports of the ECU.

Table 3.102: ECUMapping

3.4.2 Communication Controller Mapping

[TPS_SYST_01014] Semantics of CommunicationControllerMapping dCom-

municationControllerMapping specifies the HwElement to realize the specified
CommunicationController in a physical topology. The information may e.g. be
used during ECU configuration for configuring the hardware related parameters in the
communication drivers.c(RS_SYST_00013)
Class CommunicationControllerMapping
Package M2::AUTOSARTemplates::SystemTemplate::ECUResourceMapping
Note CommunicationControllerMapping specifies the CommunicationPeripheral hardware (defined in the ECU
Resource Template) to realize the specified CommunicationController in a physical topology.
Base ARObject
Attribute Type Mult. Kind Note
communication Communication 1 ref Reference to the CommunicationController in the System
Controller Controller Template
hw HwElement 1 ref Reference to a HwElement of category Communication
Communication Controller in the ECU Resource Template.
Controller

Table 3.103: CommunicationControllerMapping

151 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

3.4.3 HW-Port Mapping

[TPS_SYST_01015] Semantics of HwPortMapping dHwPortMapping specifies the

hardware to realize the specified CommunicationConnector in a physical topology.
The information may e.g. be used during ECU configuration for configuring the hard-
ware related parameters in the communication drivers.c(RS_SYST_00013)
Class HwPortMapping
Package M2::AUTOSARTemplates::SystemTemplate::ECUResourceMapping
Note HWPortMapping specifies the hwCommunicationPort (defined in the ECU Resource Template) to realize
the specified CommunicationConnector in a physical topology.
Base ARObject
Attribute Type Mult. Kind Note
communication Communication 1 ref Reference to the CommunicationConnector in the System
Connector Connector Template
hw HwPinGroup 1 ref Reference to the HwPinPortGroup of category
Communication CommunicationPort. The connection to the Hw
Port CommunicationController is described in the Ecu
Resource Description.

Table 3.104: HwPortMapping

152 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4 Top-level Software Composition

One of the most important inputs for the System Generator is the knowledge about the
Application Software Components, their communication capabilities and the connec-
tions between them: Each SystemSignal (chapter 6.2) that is going to be exchanged
between mapped Software Components onto different ECUs is a consequence of a
connection between such application Software Components.
In AUTOSAR, Software Components can either be atomic (AtomicSwComponent-
Type) or may consist of a composition of other Software Components Composition-
SwComponentType [5]. In order to assemble non-trivial applications from AUTOSAR
components, such compositions can be built up hierarchically, until the outermost Com-
positionSwComponentType forms a kind of top-level composition.
[constr_3031] Complete System Description does not have ports on
the outermost composition dIn a complete System with category AB-
STRACT_SYSTEM_DESCRIPTION or System with category SYSTEM_DESCRIPTION
this outermost CompositionSwComponentType has the unique feature that it
doesn’t have any outside ports, but all the SWC contained in it are connected to each
other and fully specified by their SwComponentTypes, PortPrototypes, PortIn-
terfaces, VariableDataPrototypes, InternalBehavior etc.c()
[TPS_SYST_01016] System Extract, Ecu System Description and Ecu Extract
may have ports dIn a System with category SYSTEM_EXTRACT and a Sys-
tem with category ECU_SYSTEM_DESCRIPTION and a System with category
ECU_EXTRACT outside ports for the outermost composition are allowed.c(RS_SYST_-
00027)
[TPS_SYST_02312]{DRAFT} Ports for outermost composition of a
SW_CLUSTER_SYSTEM_DESCRIPTION dIn a System with category
SW_CLUSTER_SYSTEM_DESCRIPTION outside ports for the outermost composi-
tion are allowed.c()
Since the System/Ecu Extract represents the view on one Ecu, there may be the need
to define the communication of this extract with the outside world.
Two approaches are available how the external communication of an ECU in the Sys-
tem Extract is described. In section 13.2 the communication mapping is performed
in the hierarchical structure of software components. In section 13.3 external com-
munication delegation ports are added to the System extract outermost composition.
Each delegated port is connected via a DelegationSwConnector with ports of the
included components that are used for the external communication.
A System considers such a top-level CompositionSwComponentType as its appli-
cation software system input by owning exactly one RootSwCompositionProto-
type class, which points to the CompositionSwComponentType forming the input
via its isOfType relationship as shown in Figure 2.1.

153 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_01017] The role of the top-level software composition dAn AUTOSAR

System uses the specialized prototype class RootSwCompositionPrototype in
order to designate the referenced CompositionSwComponentType as the top-level
software composition.c(RS_SYST_00006)
Class RootSwCompositionPrototype
Package M2::AUTOSARTemplates::SystemTemplate
Note The RootSwCompositionPrototype represents the top-level-composition of software components within a
given System.
According to the use case of the System, this may for example be a more or less complete VFB
description, the software of a System Extract or the software of a flat ECU Extract with only atomic SWCs.
Therefore the RootSwComposition will only occasionally contain all atomic software components that are
used in a complete VFB System. The OEM is primarily interested in the required functionality and the
interfaces defining the integration of the Software Component into the System. The internal structure of
such a component contains often substantial intellectual property of a supplier. Therefore a top-level
software composition will often contain empty compositions which represent subsystems.
The contained SwComponentPrototypes are fully specified by their SwComponentTypes (including Port
Prototypes, PortInterfaces, VariableDataPrototypes, SwcInternalBehavior etc.), and their ports are
interconnected using SwConnectorPrototypes.
Base ARObject, AtpFeature, AtpPrototype, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
calibration CalibrationParameter * ref Used CalibrationParameterValueSet for instance specific
ParameterValue ValueSet initialization of calibration parameters.
Set
Stereotypes: atpSplitable
Tags:atp.Splitkey=calibrationParameterValueSet
flatMap FlatMap 0..1 ref The FlatMap used in the scope of this RootSw
CompositionPrototype.
Stereotypes: atpSplitable
Tags:atp.Splitkey=flatMap
software CompositionSw 1 tref We assume that there is exactly one top-level composition
Composition ComponentType that includes all Component instances of the system.
Stereotypes: isOfType

Table 4.1: RootSwCompositionPrototype

154 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

5 Mapping
A central part of the system generation process is the mapping of software components
(SwComponentPrototypes) to ECUs, and the subsequent mapping of the commu-
nication between these software components to bus frames. Input to the software
component mapping is the RootSwCompositionPrototype, which describes which
software components have to be mapped, and the System Topology, which defines the
ECU instances that are available as mapping targets. Once this mapping is done, also
the communication matrix has to be taken into account for the next mapping step, the
mapping of data elements exchanged between software components to bus frames.
This communication matrix may either be predefined, or may be generated as part of
this second mapping step. In the metamodel, different aspects of these mapping are
aggregated by the meta class SystemMapping, as shown in Figure 5.1.
Identifiable Identifiable
CpSoftwareClusterResourceToApplicationPartitionMapping ApplicationPartitionToEcuPartitionMapping

+resourceToApplicationPartitionMapping 0..* 0..* +applicationPartitionToEcuPartitionMapping

Identifiable Identifiable Identifiable

SwcToApplicationPartitionMapping CpSoftwareClusterToResourceMapping CpSoftwareClusterToEcuInstanceMapping
+softwareClusterToResourceMapping

+swcToApplicationPartitionMapping 0..* +swClusterMapping 0..*

0..* Identifiable

«atpVariation,atpSplitable» ComManagementMapping
«atpVariation,atpSplitable»
+comManagementMapping 0..*
«atpVariation,atpSplitable»
«atpVariation,atpSplitable»
Identifiable «atpVariation»
«atpVariation,atpSplitable» CryptoServiceMapping Identifiable
+cryptoServiceMapping 0..* SwcToImplMapping
+swImplMapping *

«atpVariation,atpSplitable»
«atpVariation»

Identifiable
SystemMapping

«atpVariation»

«atpVariation» «atpVariation»
+dataMapping * «atpVariation»

DataMapping +ecuResourceMapping * «atpVariation»

+resourceEstimation *
Identifiable
EcuResourceEstimation
+j1939ControllerApplicationToJ1939NmNodeMapping

ECUMapping
+pncMapping *
+swCompToEcuMapping

Describable +mappingConstraint *
«atpVariation» PncMapping «atpVariation,atpSplitable»
MappingConstraint

«atpVariation»

0..* +swMapping *
ComponentSeparation ComponentClustering
Identifiable
SwcToEcuMapping

0..* +portElementToComResourceMapping 0..*

+signalPathConstraint *
Identifiable
J1939ControllerApplicationToJ1939NmNodeMapping SignalPathConstraint PortElementToCommunicationResourceMapping

Figure 5.1: Mapping Overview (Mapping)

155 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

The following mappings are defined:

• The SwcToEcuMapping meta-class maps one or several SwComponentProto-
types to ECUs. In the System Constraint Description it is possible to predefine
the mapping of SwComponentPrototypes to ECUs. The predefinition limits
the system architect’s freedom to map software components to arbitrary ECUs.
After the system generation in the System Configuration Description, all atomic
software components that are directly or indirectly part of the top level compo-
sition shall be mapped with this mapping rule. Software component mapping is
described in detail in chapter 5.1.
• The meta-class EcuResourceEstimation specifies the resource estimation
for RTE and basic software (see chapter 5.3).
• The ECUMapping meta-class is used to map the hardware related topology el-
ements onto their counterpart definitions in the ECU Resource Template (see
chapter 3.4).
• The DataMapping meta-class is used to map VariableDataPrototypes and
ClientServerOperations in software component ports (i.e. the data ex-
changes between software components) to signals. The data mapping is de-
scribed in detail in chapter 5.2.
• The ComManagementMapping defines the mapping of one or several Mode
Management PortGroups and communication channels (see chapter 5.4.2).
• The PncMapping defines the Partial Network behavior (see chapter 5.4.1).
• The SignalPathConstraint meta-class is used to define which specific way a
signal (data element or client server operation arguments) between two Software
Components should take in the network without defining in which frame and with
which timing it is transmitted. This Signal Path Constraint is introduced in chapter
5.2.2.
• The MappingConstraint meta-class is used to define constraints that con-
strain the mapping of software components. It’s sub-classes allow to constraint
which SwComponentPrototypes shall be mapped together on the same ECU
(ComponentClustering) and which shall not be mapped to the same ECU (
ComponentSeparation). The mapping constraints are described in detail in
chapter 5.1.4.
• The J1939ControllerApplicationToJ1939NmNodeMapping maps a Soft-
ware Component to which a standardized function id is assigned to a
J1939NmNode (see chapter 5.1.5)
• The CpSoftwareClusterToEcuInstanceMapping meta-class maps a Cp-
SoftwareCluster to an EcuInstance (see chapter 5.5)
• The CpSoftwareClusterToResourceMapping meta-class maps a CpSoft-
wareClusterServiceResource to CpSoftwareClusters (see chapter
11.2)

156 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• The CpSoftwareClusterResourceToApplicationPartitionMapping
meta-class maps a Software Cluster resource to an Application Partition (see
chapter 5.5)
• Finally, the SwcToImplMapping meta-class is used to assign one Implemen-
tation to one or more SwComponentPrototypes (see chapter 5.1.2).

157 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class SystemMapping
Package M2::AUTOSARTemplates::SystemTemplate
Note The system mapping aggregates all mapping aspects (mapping of SW components to ECUs, mapping of
data elements to signals, and mapping constraints).
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
application ApplicationPartitionTo * aggr Mapping of ApplicationPartitions to EcuPartitions
PartitionToEcu EcuPartitionMapping
Stereotypes: atpSplitable; atpVariation
Partition
Tags:
Mapping
atp.Splitkey=applicationPartitionToEcuPartition
Mapping.shortName, applicationPartitionToEcuPartition
Mapping.variationPoint.shortLabel
vh.latestBindingTime=postBuild
appOsTask AppOsTaskProxyToEcu * aggr Mapping of an OsTaskProxy that was created in the
ProxyToEcu TaskProxyMapping context of a SwComponent to an OsTaskProxy that was
TaskProxy created in the context of an Ecu.
Mapping
com ComManagement * aggr Mappings between Mode Management PortGroups and
Management Mapping communication channels.
Mapping
Stereotypes: atpVariation
Tags:vh.latestBindingTime=systemDesignTime
cryptoService CryptoServiceMapping * aggr This aggregation represents the collection of crypto
Mapping service mappings in the context of the enclosing System
Mapping.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=cryptoServiceMapping.shortName, crypto
ServiceMapping.variationPoint.shortLabel
vh.latestBindingTime=postBuild
dataMapping DataMapping * aggr The data mappings defined.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
ecuResource ECUMapping * aggr Mapping of hardware related topology elements onto their
Mapping counterpart definitions in the ECU Resource Template.
atpVariation: The ECU Resource type might be variable.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=systemDesignTime
j1939Controller J1939Controller * aggr Mapping of a J1939ControllerApplication to a J1939Nm
ApplicationTo ApplicationToJ1939Nm Node.
J1939NmNode NodeMapping
Mapping
mapping MappingConstraint * aggr Constraints that limit the mapping freedom for the
Constraint mapping of SW components to ECUs.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=systemDesignTime
pncMapping PncMapping * aggr Mappings between Virtual Function Clusters and Partial
Network Clusters.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=systemDesignTime
5

158 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class SystemMapping
portElementTo PortElementTo * aggr maps a communication resource to CP Software Clusters
ComResource Communication
Stereotypes: atpSplitable; atpVariation
Mapping ResourceMapping
Tags:
atp.Splitkey=portElementToComResourceMapping.short
Name, portElementToComResourceMapping.variation
Point.shortLabel
atp.Status=draft
vh.latestBindingTime=postBuild
resource EcuResourceEstimation * aggr Resource estimations for this set of mappings, zero or
Estimation one per ECU instance.
atpVariation: Used ECUs are variable.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=systemDesignTime
resourceTo CpSoftwareCluster * aggr Maps a Software Cluster resource to an Application
Application ResourceToApplication Partition to restrict the usage.
Partition PartitionMapping
Stereotypes: atpSplitable; atpVariation
Mapping
Tags:
atp.Splitkey=resourceToApplicationPartition
Mapping.shortName, resourceToApplicationPartition
Mapping.variationPoint.shortLabel
atp.Status=draft
vh.latestBindingTime=systemDesignTime
rteEvent RteEventInSystem * aggr Separation constraint that limits the mapping freedom for
Separation Separation the mapping of RteEvents to OsTasks in the System
context.
rteEventToOs RteEventInSystemToOs * aggr Constraint that enforces a mapping of RteEvent to a
TaskProxy TaskProxyMapping particular OsTask in the System context.
Mapping
signalPath SignalPathConstraint * aggr Constraints that limit the mapping freedom for the
Constraint mapping of data elements to signals.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=systemDesignTime
softwareCluster CpSoftwareClusterTo * aggr maps a service resource to CP Software Clusters
ToResource ResourceMapping
Stereotypes: atpSplitable; atpVariation
Mapping
Tags:
atp.Splitkey=softwareClusterToResourceMapping.short
Name, softwareClusterToResourceMapping.variation
Point.shortLabel
atp.Status=draft
vh.latestBindingTime=preCompileTime
swCluster CpSoftwareClusterTo * aggr The mappings of SW cluster to ECUs.
Mapping EcuInstanceMapping
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=swClusterMapping.shortName, swCluster
Mapping.variationPoint.shortLabel
atp.Status=draft
vh.latestBindingTime=systemDesignTime
swcTo SwcToApplication * aggr Allows to map a given SwComponentPrototype to a
Application PartitionMapping formally defined partition at a point in time when the
Partition corresponding EcuInstance is not yet known or defined.
Mapping
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=swcToApplicationPartitionMapping.short
Name, swcToApplicationPartitionMapping.variation
Point.shortLabel
vh.latestBindingTime=postBuild
5

159 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class SystemMapping
swImplMapping SwcToImplMapping * aggr The mappings of AtomicSoftwareComponent Instances to
Implementations.
atpVariation: Derived, because SwcToEcuMapping is
variable.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=preCompileTime
swMapping SwcToEcuMapping * aggr The mappings of SW components to ECUs.
atpVariation: SWC shall be mapped to other ECUs.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=preCompileTime

Table 5.1: SystemMapping

5.1 Software Component Mapping

A fundamental concept of AUTOSAR is that SW components may be developed inde-
pendently of a specific ECU hardware, and can be mapped to an ECU in the AUTOSAR
System Generation Process. The System Constraint Description acts as an input to
this System Generation Phase. Nevertheless, there may be some SW components
which are already mapped due to previous iterations of the system generation step,
and there may be system constraints that limit the system architect’s freedom to map
SW components to arbitrary ECUs. In the following, the individual elements are de-
scribed in more detail.
Please note that the purpose of [constr_5116] is to support the unambiguous mapping
of symbols in memory sections. In the AUTOSAR Basic Software, the namespace of a
Bsw Module is allocated case insensitive in order to support the definition of symbols
in solely upper case notation.
[constr_5116] Uniqueness of the symbols of software-components and BSW
modules dFor all SwComponentPrototypes typed by an ApplicationSwCompo-
nentType, NvBlockSwComponentType or SensorActuatorSwComponentType
mapped to a given EcuInstance by means of SwcToEcuMapping respectively Swc-
ToApplicationPartitionMapping and ApplicationPartitionToEcuPar-
titionMapping the following restriction applies:
The symbolic name of an AtomicSwComponentType referenced by a respective
SwComponentPrototype in the role type shall not overlap with the module imple-
mentation prefix (MIP) of any of the basic software-modules existing on the EcuIn-
stance.
The symbolic name of an AtomicSwComponentType is derived from the value of
• AtomicSwComponentType.symbol, or if this attribute does not exist
• AtomicSwComponentType.shortName.

160 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

c()
More information about the nature and usage of the symbolic name of a software-
component can be found in [TPS_SWCT_01110], [TPS_SWCT_01000], and [TPS_-
SWCT_01635].
The restriction in [constr_5116] does not apply for ServiceSwComponentTypes,
ComplexDeviceDriverSwComponentTypes, and EcuAbstractionSwCompo-
nentTypes. The reason is that for the Basic Software that utilizes standardized In-
terfaces and AUTOSAR Interfaces needs a SwComponentType and a Basic Software
Description to describe both kinds of Interfaces but only one header file for memory
allocation is expected. So for example the definition of a “Dem” Service SWC and a
“Dem” Basic Module Description defines a legal naming in AUTOSAR.

5.1.1 SW Component to ECU Mapping

[TPS_SYST_01001] Definition of SwcToEcuMapping dWith the SwcToEcuMapping

element it is possible to express the mapping of SwComponentPrototypes to one
EcuInstance or optional to individual HwElements with category Processing
Unit residing in this ECU. An optional assignment of Sensor/Actuator SwComponent-
Prototypes to Sensor/Actuator HwElements is also possible.c(RS_SYST_00007,
RS_SYST_00033)
ARElement
AtpStructureElement
System

+ containerIPduHeaderByteOrder: ByteOrderEnum [0..1]

+ ecuExtractVersion: RevisionLabelString [0..1]
+ pncVectorLength: PositiveInteger [0..1]
+ pncVectorOffset: PositiveInteger [0..1]
+ systemVersion: RevisionLabelString

«atpVariation,atpSplitable»
+mapping 0..*

Identifiable
SystemMapping

«atpVariation»

+swMapping 0..*

AtpPrototype Identifiable FibexElement

SwComponentPrototype +component SwcToEcuMapping +ecuInstance EcuInstance
1..* «instanceRef» 1

+partition 0..*
ARElement +processingUnit Identifiable
HwDescriptionEntity EcuPartition
0..1
HwElement
+controlledHwElement + execInUserMode: Boolean

0..1

Figure 5.2: SW component to ECU mapping (SwcToEcuMapping)

161 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

The SwcToEcuMapping collects a list of all SwComponentPrototypes that shall be

deployed onto the associated SwcToEcuMapping targets.
[TPS_SYST_02114] Mapping of SwComponentPrototypes onto SwcToEcuMap-
ping targets dThe SwcToEcuMapping of SwComponentPrototypes to
• EcuInstance
• processingUnit
• controlledHwElement
is arbitrary.
It is equivalent to either
• have several SwcToEcuMappings which map a set of SwcToEcuMapping.com-
ponents to a SwcToEcuMapping.ecuInstance, SwcToEcuMapping.pro-
cessingUnit, SwcToEcuMapping.controlledHwElement,
• or one SwcToEcuMapping which maps the set of SwcToEcuMapping.compo-
nents at once.
c(RS_SYST_00007)
[constr_3263] Restriction of usage of SwcToEcuMapping in a System dFor all
SwcToEcuMappings in a System the following restriction applies: No two SwcToE-
cuMappings shall have the exact same reference to
• SwComponentPrototype
• EcuInstance
• processingUnit
• controlledHwElement
c()
SwcToEcuMapping may map either prototypes of AtomicSwComponentType or
those of CompositionSwComponentType.
[TPS_SYST_01020] Unconditional mapping of atomic Software Components dIn
case a prototype of an atomic Software Components is mapped, the mapping is un-
conditional.c(RS_SYST_00007)
[TPS_SYST_01021] Mapping of CompositionSwComponentType dIn case a
mapped SwComponentPrototype refers to a CompositionSwComponentType,
the mapping is applied to any inner SwComponentPrototype recursively; however, it
may be overwritten by additional SwcToEcuMapping mapping inner SwComponent-
Prototype to different EcuInstances.c(RS_SYST_00007)
Usually a particular component prototype can be mapped explicitly to at most one ECU
in a given system (leaving aside variant handling and the implicit mapping of "inner"
prototypes mentioned above) but there are two exceptions:

162 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• [TPS_SYST_01022] Prototype of a ParameterSwComponentType can be

mapped to more than one ECU dA prototype of a ParameterSwComponent-
Type can be mapped to more than one ECU. This is required, because this
special component does not communicate over the network, so that a copy of the
prototype has to be created on each ECU were it is required.c(RS_SYST_00007)
• [TPS_SYST_01023] Prototype of an ServiceProxySwComponentType can
be mapped to more than one ECU dA prototype of an ServiceProxySwCom-
ponentType can be mapped to more than one ECU even if it appears only once
in the VFB system, because a prototype of this special component is required on
each ECU, for which local Services are addressed via the proxy.c(RS_SYST_-
00031)
[constr_3021] Mapping of SensorActuatorSwComponents to SensorActuator
HwElements dOnly SwComponentPrototypes that are typed by SensorActua-
torSwComponentType shall be mapped to a HwElement with category Senso-
rActuator via the controlledHwElement relation.c()
[constr_3249] Category of HwElement for SwcToEcuMapping dThe HwElement
which is referenced from SwcToEcuMapping in the role processingUnit shall be
of category "ProcessingUnit".c()
The following table describes the SwcToEcuMapping in detail.

163 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class SwcToEcuMapping
Package M2::AUTOSARTemplates::SystemTemplate::SWmapping
Note Map software components to a specific ECU Instance and optionally to a processing unit and to an Ecu
Partition. For each combination of ECUInstance and the optional ProcessingUnit and the optional Ecu
Partition and the optional SensorActuator only one SwcToEcuMapping shall be used.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
component SwComponent 1..* iref References to the software component instances that are
Prototype mapped to the referenced ECUInstance. If the
component prototype referenced is a composition, this
indicates that all atomic software components within the
composition are mapped to the ECU.
If there is aditionally a mapping of some SwComponent
Prototype INSIDE the Composition to another ECU
Instance the inner mapping overrides the outer mapping.
InstanceRef implemented by:ComponentInSystem
InstanceRef
controlledHw HwElement 0..1 ref Optional mapping of SwComponentPrototypes that are
Element typed by SensorActuatorSwComponentType to a Hw
Element with category SensorActuator.
ecuInstance EcuInstance 1 ref Reference to a specific ECU Instance description.
processingUnit HwElement 0..1 ref Optional mapping of software components to individual
microcontroller cores residing in one ECU. A
microcontroller core is described in the ECU Resource
Template by the HwElement of HwCategory Processing
Unit.

Table 5.2: SwcToEcuMapping

164 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

5.1.2 Software Component to Implementation Mapping

As several implementations may exist for the same AtomicSwComponentType, it

needs to be decided on and specified which instances of a given AtomicSwCom-
ponentType are mapped to which Implementation. According to the AUTOSAR
Methodology this information can either be added within the Configure System ac-
tivity, or later when the RTE part is configured during Configure ECU phase. If the
mapping is done in System Configuration, a SwcToImplMapping is being used for
assigning one Implementation to one or more instances of SwComponentProto-
type relating to the same AtomicSwComponentType. This is illustrated in Figure
5.3.
ARElement
AtpStructureElement
System

+ containerIPduHeaderByteOrder: ByteOrderEnum [0..1]

+ ecuExtractVersion: RevisionLabelString [0..1]
+ pncVectorLength: PositiveInteger [0..1]
+ pncVectorOffset: PositiveInteger [0..1]
+ systemVersion: RevisionLabelString

«atpVariation,atpSplitable»

+mapping 0..*
Identifiable
SystemMapping

«atpVariation»

+swImplMapping *

Identifiable
SwcToImplMapping

«instanceRef»

+component 1..* +componentImplementation 1

AtpPrototype Implementation
SwComponentPrototype SwcImplementation

+ requiredRTEVendor: String [0..1]

Figure 5.3: SW Component to Implementation mapping (SwcToImplMapping)

[constr_3002] valid swcToImplMapping dThe referenced SwcImplementation

refers to a SwcInternalBehavior that is part of a AtomicSwComponentType. The
same AtomicSwComponentType shall be the type of the referenced SwComponent-
Prototype.
SwcToImplMapping.componentImplementation.behavior.component == SwcToIm-
plMapping.component.typec()

165 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

The following table contains the detailed description of SwcToImplMapping:

Class SwcToImplMapping
Package M2::AUTOSARTemplates::SystemTemplate::SWmapping
Note Map instances of an AtomicSwComponentType to a specific Implementation.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
component SwComponent 1..* iref Reference to the software component instances that are
Prototype being mapped to the specified Implementation. The
targeted SwComponentPrototype needs be of the Atomic
SwComponentType being implemented by the referenced
Implementation.
InstanceRef implemented by:ComponentInSystem
InstanceRef
component SwcImplementation 1 ref Reference to a specific Implementation description.
Implementation
Implementation to be used by the specified SW
component instance. This allows to achieve more precise
estimates for the resource consumption that results from
mapping the instance of an atomic SW component onto
an ECU.

Table 5.3: SwcToImplMapping

5.1.3 SW Component to Partition Mapping

With the SwcToApplicationPartitionMapping and the ApplicationParti-

tionToEcuPartitionMapping an OEM has the option to predefine an allocation to
memory partitions in the System Design phase. The final and complete assignment
is described in the OS Configuration. The SwcToApplicationPartitionMapping
defines a mapping to ApplicationPartitions that allows an allocation to a for-
mally defined partition at a point in time when the EcuInstance is not yet known or
defined. In a later methodology step this assignment can be refined with the Appli-
cationPartitionToEcuPartitionMapping to an EcuPartition defined in the
context of an EcuInstance.

166 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Identifiable
SystemMapping

«atpVariation,atpSplitable» «atpVariation,atpSplitable»

+swcToApplicationPartitionMapping 0..* +applicationPartitionToEcuPartitionMapping 0..*

Identifiable ARElement Identifiable
SwcToApplicationPartitionMapping +applicationPartition ApplicationPartition +applicationPartition
ApplicationPartitionToEcuPartitionMapping
0..1 0..*

«instanceRef»

+swComponentPrototype 0..1 +ecuPartition 0..1

AtpPrototype Identifiable
EcuPartition +partition
SwComponentPrototype
+ execInUserMode: Boolean 0..*

Figure 5.4: SW Component to Application Partition mapping

Class SwcToApplicationPartitionMapping
Package M2::AUTOSARTemplates::SystemTemplate::SWmapping
Note Allows to map a given SwComponentPrototype to a formally defined partition at a point in time when the
corresponding EcuInstance is not yet known or defined.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
application ApplicationPartition 0..1 ref Reference to an ApplicationPartition to which a Sw
Partition ComponentPrototype is mapped.
swComponent SwComponent 0..1 iref References to the software component instances that are
Prototype Prototype mapped to the referenced ApplicationPartition. If the
component prototype referenced is a composition, this
indicates that all atomic software components within the
composition are mapped to the ApplicationPartition.
If there is additionally a mapping of some SwComponent
Prototype INSIDE the Composition to another Application
Partition the inner mapping overrides the outer mapping.
InstanceRef implemented by:ComponentInSystem
InstanceRef
Table 5.4: SwcToApplicationPartitionMapping

Class ApplicationPartition
Package M2::AUTOSARTemplates::SystemTemplate::SWmapping
Note ApplicationPartition to which SwComponentPrototypes are mapped at a point in time when the
corresponding EcuInstance is not yet known or defined. In a later methodology step the Application
Partition can be assigned to an EcuPartition.
Tags:atp.recommendedPackage=ApplicationPartitions
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
– – – – –
Table 5.5: ApplicationPartition

167 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class ApplicationPartitionToEcuPartitionMapping
Package M2::AUTOSARTemplates::SystemTemplate::SWmapping
Note Maps ApplicationPartitions to EcuPartitions. With this mapping an OEM has the option to predefine an
allocation of Software Components to EcuPartitions in the System Design phase. The final and complete
assignment is described in the OS Configuration.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
application ApplicationPartition * ref Reference to ApplicationPartitions that are mapped to an
Partition EcuPartition.
ecuPartition EcuPartition 0..1 ref Reference to EcuPartition to which the Application
Partitions are assigned.

Table 5.6: ApplicationPartitionToEcuPartitionMapping

Class EcuPartition
Package M2::AUTOSARTemplates::SystemTemplate::SWmapping
Note Partitions are used as error containment regions. They permit the grouping of SWCs and resources and
allow to describe recovery policies individually for each partition. Partitions can be terminated or
restarted during run-time as a result of a detected error.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
execInUser Boolean 1 attr A partition can execute either in CPU user mode (execIn
Mode UserMode = TRUE) or supervisor mode (execInUser
Mode = FALSE). In user mode, the partition has a limited
access to memory, to memory mapped hardware and to
CPU. In user mode, the partition is mapped to a
non-trusted OS-Application.

Table 5.7: EcuPartition

[constr_3232] ApplicationPartition is allowed to be mapped to only one

EcuPartition dEach ApplicationPartition shall be mapped at most once to
an EcuPartition via the ApplicationPartitionToEcuPartitionMapping.c()
[constr_3229] SwComponentPrototype mapped to an ApplicationPartition
and EcuInstance dIf the SwcToEcuMapping.ecuInstance exists then a SwCom-
ponentPrototype that is mapped to an ApplicationPartition via the Swc-
ToApplicationPartitionMapping shall only be mapped by an Application-
PartitionToEcuPartitionMapping to an EcuPartition that is aggregated by
the EcuInstance referenced by means of SwcToEcuMapping.ecuInstance.c()

168 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

5.1.4 Software Component Mapping Constraints

In contrast to the mapping description described in the previous chapters, mapping

constraints allow to define invariants that have to be fulfilled by a valid mapping. They
are aggregated in the MappingConstraint element as introduced in chapter 5 and
depicted Figure 5.1. This chapter describes which mapping constraints can be de-
scribed in the System Constraint Description. The description of this meta-class can
be found in the following table:
Class MappingConstraint (abstract)
Package M2::AUTOSARTemplates::SystemTemplate::SWmapping
Note Different constraints that may be used to limit the mapping of SW components to applicable ECUs,
Partitions or Cores depending on the mappingScope attribute.
Base ARObject
Subclasses ComponentClustering, ComponentSeparation
Attribute Type Mult. Kind Note
introduction DocumentationBlock 0..1 aggr This represents introductory documentation about the
mapping constraint.

Table 5.8: MappingConstraint

The two constraints (ComponentClustering and ComponentSeparation) shown

in Figure 5.5 express the restrictions that Software Components impose on each other
when performing the mapping onto the ECUs, Cores or Partitions. In fact, before the
mapping process begins, it can be useful to impose the allocation of a predefined set
of SW components onto the same ECU, especially if such a set is tightly linked from
a functional point of view. In the same way, two critical SW components, performing
some kind of redundancy, may be not suitable to run both on the same ECU. Thus,
we call these two kinds of mapping constraints, respectively, ComponentClustering
and ComponentSeparation.
MappingConstraint «atpMixed»
+introduction DocumentationBlock

0..1

ComponentClustering ComponentSeparation

+ mappingScope: MappingScopeEnum [0..1] + mappingScope: MappingScopeEnum [0..1]

* *

«instanceRef» «instanceRef»

+clusteredComponent 1..* +separatedComponent 2

«enumeration» AtpPrototype
MappingScopeEnum
SwComponentPrototype
mappingScopeEcu
mappingScopePartition
mappingScopeCore

Figure 5.5: Details on ComponentClustering and ComponentSeparation (SwcClustering)

169 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

5.1.4.1 ComponentClustering

[TPS_SYST_01024] Component Clustering dThe ComponentClustering con-

straint (also, clustering) is to be used for expressing that a certain set of SW compo-
nents (atomic or not) shall be mapped (allocated) onto the same ECU, Core, Partition
depending on the defined mappingScope attribute.c(RS_SYST_00008)
This is some kind of "execute together on same ECU" constraint.
The semantic of the clustering constraint is straightforward if all referenced SW com-
ponents are atomic. Otherwise, it shall be interpreted as follows:
[TPS_SYST_01025] Clustering of Compositions dAll of the atomic SW components
making up the composition shall be mapped onto the same ECU, Core, Partition de-
pending on the defined mappingScope attribute together with all other SW compo-
nents (atomic or not) referenced by the constraint.c(RS_SYST_00008)
This also means that a clustering constraint can also refer to only a single composition.
A clustering constraint is part of a MappingConstraint element and it shall refer to
one or more SwComponentPrototype elements, representing the instances of the
SW component(s) that shall be mapped together.
Class ComponentClustering
Package M2::AUTOSARTemplates::SystemTemplate::SWmapping
Note Constraint that forces the mapping of all referenced SW component instances to the same ECU, Core,
Partition depending on the defined mappingScope attribute. If mappingScope is not specified then
mappingScopeEcu shall be assumed.
Base ARObject, MappingConstraint
Attribute Type Mult. Kind Note
clustered SwComponent 1..* iref Reference to the components that have to be mapped
Component Prototype together.
InstanceRef implemented by:ComponentInSystem
InstanceRef
mappingScope MappingScopeEnum 0..1 attr This attribute indicates whether the ComponentClustering
mapping constraint applies to different ECUs, partitions or
cores. If this attribute is not specified then mappingScope
Ecu shall be assumed.
Table 5.9: ComponentClustering

Enumeration MappingScopeEnum
Package M2::AUTOSARTemplates::SystemTemplate::SWmapping
Note Defines the scope for the mapping constraints.
Literal Description
mappingScopeCore The mapping constraint applies to different Cores.
Tags:atp.EnumerationLiteralIndex=0
mappingScopeEcu The mapping constraint applies to different Ecus.
Tags:atp.EnumerationLiteralIndex=1
5

170 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Enumeration MappingScopeEnum
mappingScope The mapping constraint applies to different Partitions.
Partition
Tags:atp.EnumerationLiteralIndex=2

Table 5.10: MappingScopeEnum

5.1.4.2 ComponentSeparation

[TPS_SYST_01045] Component Seperation dThe ComponentSeparation con-

straint (also, separation) is to be used for expressing that two SW components (atomic
or not) shall not be mapped (allocated) onto the same ECU, Core, Partition depending
on the defined mappingScope attribute.c(RS_SYST_00009)
This is some kind of “do not execute together on same ECU” constraint.
The semantic of the separation constraint is straightforward if one or both SW compo-
nents are atomic. Otherwise, it shall be interpreted as follows:
[TPS_SYST_01026] Separation of Compositions dAny of the atomic SW compo-
nents making up the first composition, shall not be mapped onto the same ECU, Core,
Partition depending on the defined mappingScope attribute with any atomic SW com-
ponent from the second composition.c(RS_SYST_00009)
As a consequence, and to preserve consistency, an atomic SW component instance
cannot be part of two compositions concerned by the same separation constraint, i.e.
the two compositions have to be disjoint with regards to component instances1 .
A separation constraint is part of a MappingConstraint element and it shall refer
to two SwComponentPrototype elements, representing the two SW component in-
stances that shall not be allocated together.

1
The only case where a component instance could be in both sets is if the ComponentSeparation
refers to two elements where one of them is a substructure of the other. Consider the case that Atomic
SW Component A is aggregated by composition B, which in turn is aggregated by composition C. Then
instance A is both in B and C. It is not a good idea to formulate a separation constraint stating that B and
C should not be on the same ECU.

171 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class ComponentSeparation
Package M2::AUTOSARTemplates::SystemTemplate::SWmapping
Note Constraint that forces the two referenced SW components (called A and B in the following) not to be
mapped to the same ECU, Core, Partition depending on the defined mappingScope attribute. If mapping
Scope is not specified then mappingScopeEcu shall be assumed.
If a SW component (e.g. A) is a composition, none of the atomic SW components making up the A
composition shall be mapped together with any of the atomic SW components making up the B
composition. Furthermore, A and B shall be disjoint.
Base ARObject, MappingConstraint
Attribute Type Mult. Kind Note
mappingScope MappingScopeEnum 0..1 attr This attribute indicates whether the Component
Separation mapping constraint applies to different ECUs,
partitions or cores. If this attribute is not specified then
mappingScopeEcu shall be assumed.
separated SwComponent 2 iref The two components that have to be mapped to different
Component Prototype ECUs
InstanceRef implemented by:ComponentInSystem
InstanceRef
Table 5.11: ComponentSeparation

[constr_3004] Clustering and separation shall be exclusive dClustering and sep-

aration shall be exclusive, i.e. it SHALL NOT be possible that two SwComponent-
Prototypes A and B are associated both by a ComponentClustering and by a
ComponentSeparation at the same time.c()
Please note that it is possible that one SwComponentPrototype is referenced by both
the ComponentClustering and ComponentSeparation, so the [constr_3004] is
about the pair of SwComponentPrototypes and not about a single one.
For example it shall be possible to associate ComponentClustering and Compo-
nentSeparation at the same time, e.g.
• A and B have a ComponentClustering_1 association
• B and C have a ComponentSeparation_2 association
• A and D have a ComponentSeparation_3 association
In this setup A and B are associated by a ComponentClustering and by a Compo-
nentSeparation without violating [constr_3004].

172 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

5.1.5 J1939 Controller Application Mapping

J1939 is not restricted to mere communication protocols. It also specifies the com-
munication of software functions (a.k.a. J1939 Controller Applications) and thus has
a very dedicated view on the software of an automotive ECU. The approach taken by
J1939 with respect to software is very similar to the way AUTOSAR specifies software-
components.
However, J1939 uses a different terminology and associates such a software-
component with a predefined function. In addition, every function in J1939 has a stan-
dardized id. This function id is distributed by the Controller Application to the network
as part of the so-called "name" which is a unique identifier representing a Controller
Application within the J1939 network management.
Controller Applications, to some extent, fulfill the role of a "virtual ECU" since they are
visible as independent entities on a J1939 network. In terms of AUTOSAR modeling,
the role of a "virtual ECU" for J1939 Controller Applications is fulfilled by the meta-class
J1939NmNode.
In order to make use of the AUTOSAR modeling approach for J1939 it is very helpful to
associate a standardized function id with a software-component during an early phase
of a development project. This function id shall later be mapped to a J1939NmNode
with the identical J1939NmNode.nodeName.function.
Identifiable
SystemMapping

+j1939ControllerApplicationToJ1939NmNodeMapping 0..*

J1939ControllerApplicationToJ1939NmNodeMapping

+j1939ControllerApplication 0..1 +j1939NmNode 0..1

ARElement NmNode
J1939ControllerApplication J1939NmNode

+ functionId: PositiveInteger

«instanceRef»

+swComponentPrototype 0..1

AtpPrototype
SwComponentPrototype

Figure 5.6: J1939 Controller Application to J1939NmNode Mapping

173 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class J1939ControllerApplicationToJ1939NmNodeMapping
Package M2::AUTOSARTemplates::SystemTemplate::SWmapping
Note This meta-class represents the ability to map a J1939ControllerApplication to a J1939NmNode. Note that
this is similar but not identical to the mapping of SwComponentPrototypes to EcuInstances; for J1939 the
semantics of an EcuInstance itself is basically replaced by a J1939NmNode.
Base ARObject
Attribute Type Mult. Kind Note
j1939Controller J1939Controller 0..1 ref Reference to the J1939 Controller Application that is
Application Application mapped to the referenced J1939NmNode.
j1939NmNode J1939NmNode 0..1 ref J1939NmNode that is the target of the J1939Controller
ApplicationTo1939NmNodeMapping.

Table 5.12: J1939ControllerApplicationToJ1939NmNodeMapping

Class J1939ControllerApplication
Package M2::AUTOSARTemplates::SystemTemplate::SWmapping
Note This element represents a J1939 controller application.
Tags:atp.recommendedPackage=J1939ControllerApplications
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
functionId PositiveInteger 1 attr This attribute represents the numerical function id of the
J1939 controller application.
swComponent SwComponent 0..1 iref This represents the SwComponentPrototype (which is
Prototype Prototype typically typed by a CompositionSwComponentType) that
corresponds to the J1939ControllerApplication.
InstanceRef implemented by:ComponentInSystem
InstanceRef
Table 5.13: J1939ControllerApplication

[constr_3239] Consistent mapping of software-component to J1939NmNode dThe

value of attribute J1939NmNode.nodeName.function of a J1939NmNode refer-
enced by J1939ControllerApplicationToJ1939NmNodeMapping in the role
j1939NmNode shall be identical to the value of J1939ControllerApplication.
functionId.c()
[constr_3240] Consistent mapping of J1939ControllerApplication
to EcuInstance dA SwComponentPrototype that is referenced by a
J1939ControllerApplication mapped to a specific J1939NmNode shall
only be mapped to an EcuInstance that in turn owns the same J1939NmNode.c()

5.1.6 Affinity Constraints

This chapter defines the possibility to describe constraints for the mapping of
RTEEvents to OsTasks. The meta-class OsTaskProxy is used in the System De-
scription to represent an OsTask that is defined in the Ecu Configuration of the OS.

174 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

The mapping of an RTEEvent to an OsTaskProxy can be defined in the context of the

System (see chapter 5.1.6.2) or in the context of a Software Composition (see chapter
5.1.6.1).
Class RTEEvent (abstract)
Package M2::AUTOSARTemplates::SWComponentTemplate::SwcInternalBehavior::RTEEvents
Note Abstract base class for all RTE-related events
Base ARObject, AbstractEvent, AtpClassifier , AtpFeature, AtpStructureElement, Identifiable, Multilanguage
Referrable, Referrable
Subclasses AsynchronousServerCallReturnsEvent, BackgroundEvent, DataReceiveErrorEvent, DataReceivedEvent,
DataSendCompletedEvent, DataWriteCompletedEvent, ExternalTriggerOccurredEvent, InitEvent,
InternalTriggerOccurredEvent, ModeSwitchedAckEvent, OperationInvokedEvent, OsTaskExecutionEvent,
SwcModeManagerErrorEvent, SwcModeSwitchEvent, TimingEvent, TransformerHardErrorEvent
Attribute Type Mult. Kind Note
disabledMode ModeDeclaration * iref Reference to the Modes that disable the Event.
Stereotypes: atpSplitable
Tags:atp.Splitkey=disabledMode.contextPort, disabled
Mode.contextModeDeclarationGroupPrototype, disabled
Mode.targetModeDeclaration
InstanceRef implemented by:RModeInAtomicSwc
InstanceRef
startOnEvent RunnableEntity 0..1 ref The referenced RunnableEntity starts when the
corresponding RTEEvent is raised.

Table 5.14: RTEEvent

Class OsTaskProxy
Package M2::AUTOSARTemplates::SystemTemplate::RteEventToOsTaskMapping
Note This meta-class represents a proxy for an OsTask in the System Description.
Tags:atp.recommendedPackage=OsTaskProxies
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
period TimeValue 0..1 attr This attribute specifies the period in seconds of this task
in case of a cyclically activated task. Please note that this
attribute is informative and not directly relevant for the
AUTOSAR OS. But the attribute value can be mapped
into the OS configuration to support configuration work
flows using a fixed set of OsTasks.
preemptability OsTaskPreemptability 0..1 attr This attribute defines the preemptability of the task.
Enum
priority PositiveInteger 0..1 attr This attribute defines the priority of a task as a relative
value, i.e. the values show only the relative ordering of
the tasks.
Table 5.15: OsTaskProxy

Enumeration OsTaskPreemptabilityEnum
Package M2::AUTOSARTemplates::SystemTemplate::RteEventToOsTaskMapping
Note Enumeration that defines the possible preemptability values for OsTask.
Literal Description
5

175 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Enumeration OsTaskPreemptabilityEnum
full Task is preemptable.
Tags:atp.EnumerationLiteralIndex=1
none Task is not preemptable.
Tags:atp.EnumerationLiteralIndex=0

Table 5.16: OsTaskPreemptabilityEnum

The software component specific OsTaskProxy definitions can be mapped to Os-

TaskProxy definitions that are defined for a specific EcuInstance with the Ap-
pOsTaskProxyToEcuTaskProxyMapping. OsTaskProxy elements that are re-
lated to an EcuInstance are referenced by the EcuInstance in the role ecu-
TaskProxy.
[TPS_SYST_02367] Execution Order of RTEEvents on a EcuInstance dSoftware
component specific OsTaskProxy elements (appTaskProxy) that are mapped by
AppOsTaskProxyToEcuTaskProxyMappings to the same ecuTaskProxy shall be
mapped together to the same OsTask. Optionally the execution order of software com-
ponent related OsTaskProxy elements in the ecuTaskProxy can be defined with the
offset attribute.c()
Class AppOsTaskProxyToEcuTaskProxyMapping
Package M2::AUTOSARTemplates::SystemTemplate::RteEventToOsTaskMapping
Note This meta-class is used to map an OsTaskProxy that was created in the context of a SwComponent to an
OsTaskProxy that was created in the context of an Ecu.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
appTaskProxy OsTaskProxy 0..1 ref Reference to an OsTaskProxy that is created in the
context of a SwComponent.
ecuTaskProxy OsTaskProxy 0..1 ref Reference to an OsTaskProxy that is created in the
context of an EcuInstance.
offset Integer 0..1 attr This attribute is used to describe the position of the app
TaskProxy in an ecuTaskProxy as a relative value, i.e. the
values show only the relative position of the appTask
Proxy in the ecuTaskProxy.

Table 5.17: AppOsTaskProxyToEcuTaskProxyMapping

The following figure shows the mapping approach where RTEEvents of Software Com-
ponent A are mapped to TaskProxy1 with offset 1 and 4 and RTEEvents of Software
Component B are mapped to TaskProxy2 with offset 2 and 3.
Both Software Components are mapped to the same EcuInstance and
AppOsTaskProxyToEcuTaskProxyMappings that are referencing the ecu-
TaskProxy are defining the execution order on the EcuInstance with the offset
attribute. According to the definition the RTEEvents of Software Component A (with
offset 1 and 4) are executed first. And the RTEEvents of Software Component B (with
offset 2 and 3) are executed afterwards.

176 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

AppOsTaskProxyTo EcuTaskProxy AppOsTaskProxyTo

EcuTaskProxyMapping EcuTaskProxyMapping

offset = 1 offset = 2
SwcToEcuMapping EcuInstance

RteEventInCompositionTo RteEventInCompositionTo
OsTaskProxyMapping OsTaskProxyMapping

offset = 1 Swc_A Swc_B offset = 2

TaskProxy1 Re_a10 Re_b10 TaskProxy2

RteEventInCompositionTo RteEventInCompositionTo
OsTaskProxyMapping Re_a50 Re_b50 OsTaskProxyMapping

offset = 4 Offset = 3

Figure 5.7: AppOsTaskProxyToEcuTaskProxyMapping example

5.1.6.1 RteEvent to OsTaskProxy mapping constraints in the context of a Soft-

ware Composition

This section describes constraints for the mapping of RTEEvents to OsTasks in the
context of a Software Composition.
[TPS_SYST_02368] RTEEvent pairing constraint in Software Composition con-
text dRTEEvents defined in the context of a CompositionSwComponentType that
are mapped by RteEventInCompositionToOsTaskProxyMappings to the same
OsTaskProxy shall be mapped together to the same OsTask. Optionally an order of
the RTEEvents in the OsTaskProxy can be defined with the offset attribute.c()
[TPS_SYST_02369] RTEEvent separation constraint in Software Composition
context dRTEEvents defined in the context of a CompositionSwComponentType
that are referenced by RteEventInCompositionSeparation are not allowed to be
mapped to the same OsTask.c()

177 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

ARElement
ARElement AtpBlueprint
SwComponentMappingConstraints AtpBlueprintable
AtpType
+swcMappingConstraint
SwComponentType
0..*

+rteEventToOsTaskProxyMapping 0..*

Identifiable
RteEventInCompositionToOsTaskProxyMapping FibexElement
EcuInstance
+ offset: PositiveInteger [0..1]

«atpSplitable»

+rteEvent 0..1 +osTaskProxy 0..1 +ecuTaskProxy 0..*

AbstractEvent ARElement
AtpStructureElement
OsTaskProxy
RTEEvent
+ period: TimeValue [0..1]
+ preemptability: OsTaskPreemptabilityEnum [0..1]
+rteEvent 0..* + priority: PositiveInteger [0..1]

+appTaskProxy 0..1 +ecuTaskProxy 0..1

Identifiable Identifiable
+rteEventSeparation RteEventInCompositionSeparation AppOsTaskProxyToEcuTaskProxyMapping
0..* + offset: Integer [0..1]

0..* +appOsTaskProxyToEcuTaskProxyMapping

Identifiable «enumeration»
OsTaskPreemptabilityEnum
SystemMapping

none
full

Figure 5.8: Mapping of Rte Events to Os Tasks in Software Composition context

Class RteEventInCompositionToOsTaskProxyMapping
Package M2::AUTOSARTemplates::SystemTemplate::RteEventToOsTaskMapping
Note This meta-class is used to map an RteEvent to an OsTaskProxy in the context of a SwComposition.
Several RteEventInCompositionToOsTaskProxyMappings can be used to define a pairing constraint that
describes which RteEvents shall be mapped together into an OsTask. Optionally the relative position of
the RteEvents in the OsTask can be defined in the mapping.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
offset PositiveInteger 0..1 attr This attribute is used to describe the position of the Rte
Event in the OsTask as a relative value, i.e. the values
show only the relative position of the RteEvent in the Os
Task.
5

178 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class RteEventInCompositionToOsTaskProxyMapping
osTaskProxy OsTaskProxy 0..1 ref Reference to OsTaskProxy to which the RteEvent is
mapped.
rteEvent RTEEvent 0..1 iref Reference to RteEvent that is mapped to the OsTask
Proxy.
InstanceRef implemented by:RteEventInComposition
InstanceRef
Table 5.18: RteEventInCompositionToOsTaskProxyMapping

Class RteEventInCompositionSeparation
Package M2::AUTOSARTemplates::SystemTemplate::RteEventToOsTaskMapping
Note This meta-class is used to define a separation constraint in the context of a SwComposition. The
referenced RteEvents are not allowed to be mapped into the same OsTask.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
rteEvent RTEEvent * iref Reference to RteEvents that are not allowed to be
mapped into the same OsTask.
InstanceRef implemented by:RteEventInComposition
InstanceRef
Table 5.19: RteEventInCompositionSeparation

5.1.6.2 RteEvent to OsTaskProxy mapping constraints in the context of the Sys-

tem

[TPS_SYST_02370] RTEEvent pairing constraint in System context dRTEEvents

defined in the context of a System that are mapped by RteEventInSystemToOsT-
askProxyMappings to the same OsTaskProxy shall be mapped together to the
same OsTask. Optionally an order of the RTEEvents in the OsTaskProxy can be
defined with the offset attribute.c()
[TPS_SYST_02371] RTEEvent separation constraint in System context d
RTEEvents defined in the context of a System that are referenced by RteEventIn-
SystemSeparation are not allowed to be mapped to the same OsTask.c()

179 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Identifiable FibexElement
RteEventInSystemToOsTaskProxyMapping EcuInstance
+ offset: Integer [0..1]

+rteEventToOsTaskProxyMapping 0..*

«atpSplitable»
«instanceRef»

+rteEvent 0..1 +osTaskProxy 0..1 +ecuTaskProxy 0..*

AbstractEvent ARElement
AtpStructureElement
OsTaskProxy
RTEEvent
+ period: TimeValue [0..1]
+ preemptability: OsTaskPreemptabilityEnum [0..1]
+rteEvent 0..* + priority: PositiveInteger [0..1]

+appTaskProxy 0..1 +ecuTaskProxy 0..1

Identifiable Identifiable
RteEventInSystemSeparation AppOsTaskProxyToEcuTaskProxyMapping

+ offset: Integer [0..1]

+rteEventSeparation 0..* 0..* +appOsTaskProxyToEcuTaskProxyMapping

«enumeration»
Identifiable
OsTaskPreemptabilityEnum
SystemMapping

none
full

Figure 5.9: Mapping of Rte Events to Os Tasks in System context

Class RteEventInSystemToOsTaskProxyMapping
Package M2::AUTOSARTemplates::SystemTemplate::RteEventToOsTaskMapping
Note This meta-class is used to map an RteEvent to an OsTaskProxy in the context of the System. Several Rte
EventToOsTaskProxyMappings can be used to define a pairing constraint that describes which Rte
Events shall be mapped together into an OsTask. Optionally the position of the RteEvents in the OsTask
can be defined.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
offset Integer 0..1 attr This attribute is used to describe the position of the Rte
Event in the OsTask as a relative value, i.e. the values
show only the relative position of the RteEvent in the Os
Task.
osTaskProxy OsTaskProxy 0..1 ref Reference to OsTaskProxy to which the RteEvent is
mapped.
5

180 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class RteEventInSystemToOsTaskProxyMapping
rteEvent RTEEvent 0..1 iref Reference to RteEvent that is mapped to the OsTask
Proxy.
InstanceRef implemented by:RteEventInSystem
InstanceRef
Table 5.20: RteEventInSystemToOsTaskProxyMapping

Class RteEventInSystemSeparation
Package M2::AUTOSARTemplates::SystemTemplate::RteEventToOsTaskMapping
Note This meta-class is used to define a separation constraint in the context of the System. The referenced
RteEvents are not allowed to be mapped into the same OsTask.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
rteEvent RTEEvent * iref Reference to RteEvents that are not allowed to be
mapped into the same OsTask.
InstanceRef implemented by:RteEventInSystem
InstanceRef
Table 5.21: RteEventInSystemSeparation

5.2 Data Mapping

The data mapping description may either be mapping of client server communication
or sender receiver communication (see Figure 5.10). It is used to map VariableDat-
aPrototypes or ClientServerOperations of SW Component Ports to System-
Signals.

181 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

ARElement
AtpStructureElement
System

+ containerIPduHeaderByteOrder: ByteOrderEnum [0..1]

+ ecuExtractVersion: RevisionLabelString [0..1]
+ pncVectorLength: PositiveInteger [0..1]
+ pncVectorOffset: PositiveInteger [0..1]
+ systemVersion: RevisionLabelString

«atpVariation,atpSplitable»

+mapping 0..*

Identifiable
SystemMapping

«atpVariation»

+dataMapping *

«enumeration» DataMapping
CommunicationDirectionType

in
out

SenderReceiverToSignalMapping SenderReceiverToSignalGroupMapping
TriggerToSignalMapping

SenderReceiverCompositeElementToSignalMapping ClientServerToSignalMapping

Figure 5.10: Overview: Data Mapping Description (DataMappingOverview)

[TPS_SYST_01030] Representation of VariableDataPrototypes and

ClientServerOperations in System Description dSystemSignals represent
VariableDataPrototypes and ClientServerOperations in the communication
description.c(RS_SYST_00025)
[constr_5055] DataMapping of elements of PRPortPrototypes is not supported
dA DataMapping shall not map elements of PRPortPrototypes to SystemSig-
nalsc()
In other words the usage of PRPortPrototypes for inter-Ecu communication is not
supported by AUTOSAR.
[constr_5266] VariableDataPrototype of NvDataInterface shall not be
mapped to a SystemSignal dA VariableDataPrototype that is aggregated by a
NvDataInterface shall not be referenced by
• SenderReceiverToSignalGroupMapping in the role dataElement and
• SenderReceiverToSignalMapping in the role dataElement.
c()
[constr_5267] VariableDataPrototype of NvDataInterface shall not be
mapped to a SystemSignal via a delegation to a PortPrototype with a

182 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

SenderReceiverInterface dIf a VariableDataPrototype that is aggregated

by a
• SenderReceiverInterface and that SenderReceiverInterface is refer-
enced by a PortPrototype of a Composition and
• that PortPrototype is connected by a delegation connector with an inner
PortPrototype of a NvBlockSwComponentType and
• that PortPrototype is typed by a NvDataInterface
then this PortPrototype shall not be referenced by:
• SenderReceiverToSignalGroupMapping in the role dataElement and
• SenderReceiverToSignalMapping in the role dataElement.
c()

ECU Root Composition SystemSignal

SenderReceiverTo SenderReceiverTo
ApplicationSwComponentType
SignalMapping SignalMapping

ECU Root Composition

SenderReceiverInterface

ApplicationSwComponentType
SenderReceiver
Interface

NvDataInterface
ApplicationSwComponentType NvBlockSwComponentType NvBlockSwComponentType

Figure 5.11: Mapping scenario that is forbidden by constr_5267

The figure 5.11 shows the scenario that is forbidden by [constr_5267]. The Port of
the NvBlockSwComponentType is delegated to the Ecu Root Composition by the
red connector. The VariableDataPrototype of the outer Port that is typed by
a SenderReceiverInterface is mapped to a SystemSignal for communication
over the network.
A scenario that would be allowed is shown in figure 5.12. Here the NvBlockSwCom-
ponentType is connected to an ApplicationSwComponentType in the same Ecu
Root Composition. Data that is communicated over the network is contained in an
additional Port of the ApplicationSwComponentType that is delegated to the outer
Port of the Composition for the definition of the DataMapping. In this scenario [con-
str_5266] and [constr_5267] are not violated.

183 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

ECU Root Composition SystemSignal

ApplicationSwComponentType SenderReceiverTo SenderReceiverTo

SignalMapping SignalMapping

ECU Root Composition

SenderReceiver
Interface
ApplicationSwComponentType

SenderReceiver
Interface

ApplicationSwComponentType NvBlockSwComponentType NvBlockSwComponentType

NvDataInterface

Figure 5.12: Supported mapping scenario

[constr_4000] Local communication of mode switches dPorts with ModeSwitch-

Interfaces cannot be connected across ECU boundaries.c()
In other words a DataMapping for ModeDeclarationGroupPrototypes is not
supported.
[TPS_SYST_01032] Independence of SystemSignals from Communication-
Clusters dThe SystemSignals can be defined independently of Communication-
Clusters.c()
This chapter describes how the VariableDataPrototypes and ClientServer-
Operations are mapped onto SystemSignals. The Communication chapter ( 6)
describes how the SystemSignals are mapped into Pdus and Frames, implementing
the actual inter-ECU communication.
Class DataMapping (abstract)
Package M2::AUTOSARTemplates::SystemTemplate::DataMapping
Note Mapping of port elements (data elements and parameters) to frames and signals.
Base ARObject
Subclasses ClientServerToSignalMapping, SenderReceiverCompositeElementToSignalMapping, SenderReceiverTo
SignalGroupMapping, SenderReceiverToSignalMapping, TriggerToSignalMapping
Attribute Type Mult. Kind Note
introduction DocumentationBlock 0..1 aggr This represents introductory documentation about the
data mapping.

Table 5.22: DataMapping

Class SystemSignal
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note The system signal represents the communication system’s view of data exchanged between SW
components which reside on different ECUs. The system signals allow to represent this communication
in a flattened structure, with exactly one system signal defined for each data element prototype sent and
received by connected SW component instances.
Tags:atp.recommendedPackage=SystemSignals
5

184 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class SystemSignal
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
dynamicLength Boolean 1 attr The length of dynamic length signals is variable in
run-time. Only a maximum length of such a signal is
specified in the configuration (attribute length in ISignal
element).
physicalProps SwDataDefProps 0..1 aggr Specification of the physical representation.

Table 5.23: SystemSignal

A SystemSignal is used to represent VariableDataPrototypes for network

transport.
The motivation for SystemSignals is to represent (physical) data which is exchanged
between ECUs as a design element. The SystemSignal gives data an identity and
allows to refer to that information from different context.
SystemSignals are part of the communication matrix and are used as the binding
blocks between the Software Component data access and the communication stack
infrastructure.
The SystemSignals are mapped to the PortPrototypes of Software Components,
and the SystemSignals are referenced by ISignals of the communication stack
(see section 6.2). ISignals are placed in ISignalIPdus and Pdus are transported
on networks.
The creation of the relation between elements of a PortPrototype and correspond-
ing SystemSignals has valuable on its own as the bus-independent communication
matrix and a milestone in the workflow towards further downstream processing where
the focus changes to bus-specific descriptions. In other words, if you throw away the
bus specific description, you don’t have to start from scratch thanks to the existence of
a stable bus-independent baseline from which the bus-specific part could be derived
again.

185 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

SWC1 SWC2

SenderReceiverTo SenderReceiverTo
SignalMapping SignalMapping

SystemSignal

ISignal ISignal

ISignalToIPdu ISignalToIPdu
Mapping Mapping

CAN FlexRay

Figure 5.13: Example for a SystemSignal and a DataMapping

[TPS_SYST_01144] Physical properties of a SystemSignal dWith the aggregation

of SwDataDefProps in the role physicalProps the physical properties of the Sys-
temSignal can be specified.c()
[TPS_SYST_05000] System Description doesn’t use a complete Software Com-
ponent Description dIf the System Description doesn’t use a complete Software
Component Description (VFB View) the data mapping of VariableDataPrototypes
or ArgumentDataPrototypes owned by ClientServerOperations on System-
Signals does not need to be defined. This supports the inclusion of legacy signals.c
(RS_SYST_00001)
[constr_3501] Role of SystemSignal in 1:n communication dIn case of 1:n com-
munication the VariableDataPrototype in the PPortPrototype of the SwCom-
ponentPrototype shall be mapped to only one SystemSignal.c()
[constr_3086] Role of SystemSignal in n:1 sender-receiver communication dIn
case of n:1 communications
• if DataTransformation is used each sender shall be mapped to the same
SystemSignal
• if DataTransformation is not used each sender shall be mapped

186 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

– to the same SystemSignal in case of a primitive DataType on the sender

side,
– to the same SystemSignalGroup in case of a composite DataType on the
sender side.
c()
[constr_5117] Client-Server communication over Ethernet dA SystemSignal that
is referenced by a ClientServerToSignalMapping in the role callSignal or
returnSignal shall only be referenced by an ISignal that in turn is referenced by
an ISignalTriggering aggregated by an EthernetPhysicalChannel.c()
In other words, the client-server communication is only supported by AUTOSAR on the
Ethernet communication channel.
[TPS_SYST_02150] Role of SystemSignal in inter-ECU client server communi-
cation over Ethernet with clients located on different ECUs dIn case of a n:1 inter-
ECU client server communication over Ethernet with clients located on different ECUs
exactly one SystemSignal per communication direction shall be used to define the
client server interaction between the server and all clients since the relationship be-
tween the call and return is achieved by means of meta data items attached to the
Pdus by the Socket Adapter.c()
[TPS_SYST_02151] MetaData support required for inter-ECU client server com-
munication over Ethernet with clients located on different ECUs dThe modeling of
client server interaction over Ethernet with clients located on different ECUs requires
the support of COM Stack MetaData. The relationship between the call and return is
achieved by means of meta data items attached to the Pdus by the Socket Adapter.c()
[TPS_SYST_01087] Role of SystemSignal in inter-ECU client server communi-
cation with clients located on the same ECU dIn case of n:1 inter-ECU client server
communication it is allowed to use the same SystemSignal for several clients on the
same Ecu, if the client identifier is used to distinguish the different clients.c()
[TPS_SYST_02011] initValues of receivers that are mapped to the same Ecu
dAll receivers of a given SystemSignal on the same EcuInstance shall have iden-
tical initValues.c()
[constr_3112] Invalidation support for partial mapping of a data element typed
by composite data type dIf a VariableDataPrototype with a composite data type
in a PPortPrototype is mapped to a SystemSignalGroup and only a subset of
elements of the composite data type that are primitives is mapped to separate Sys-
temSignals of the SystemSignalGroup then at least one mapped primitive shall
have an invalidValue defined.c()
[constr_3074] No TransmissionAcknowledgementRequest for multiple senders
dIf more than one SenderComSpec exist (in different PortPrototypes on atomic
level) that refer to data elements effectively mapped to the same SystemSignal it is
not allowed that any SenderComSpec aggregates transmissionAcknowledge.c()

187 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Please note that the term “effectively mapped” refers to the fact that the DataMapping
can refer to a dataElement in a "delegation" PortPrototype on the surface of a
rootSoftwareComposition of an Ecu Extract OR to PortPrototypes inside the
rootSoftwareComposition. Both ways shall be considered.

Figure 5.14: Example for data elements that are effectively mapped to the same System-
Signal

The different kinds of data mapping are described in the following sections in detail.
Please note that the usage of ImplementationDataTypes within an AnyIn-
stanceRef is described in detail in [2].

5.2.1 Mapping of Variable Data Prototypes on System Signals

This section describes how VariableDataPrototypes are mapped onto System-

Signals. For a detailed description of the interconnection of software components
refer to [5].
It is the task of system configuration to map VariableDataPrototype,
ClientServerOperation, or Trigger contained in PortPrototypes referenced
by the SwConnector onto a SystemSignal.

188 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_01033] DataMapping and SwConnector dFor the purpose of creating

DataMappings PortPrototypes may or may not be connected by SwConnectors.c
()
The same SystemSignal may satisfy more than one SwConnector (1:n commu-
nication), and one SwConnector may be implemented by several SystemSignals
(e.g. one per VariableDataPrototype in the PortInterface being connected),
so there is no 1:1 mapping between SwConnectors and SystemSignals.
In the following sections, each reference to a VariableDataPrototype, Argu-
mentDataPrototype, or Trigger is of type AtpInstanceRef [2]. This means
it not only references the actual VariableDataPrototype, but additionally contains
contextual references to the PortPrototype and the hierarchy of SwComponent-
Prototypes forming the individual instance context of the VariableDataProto-
type.
In a complete System with category SYSTEM_DESCRIPTION, it is sufficient to refer
to the VariableDataPrototype in the PPortPrototype or the RPortPrototype
to define the mapping of the communication between a provider and its receivers.
This is possible since the connectors implicitly define which RPortPrototype are
connected to which PPortPrototype. In case the System with category SYS-
TEM_DESCRIPTION does not use a complete Software Component Description (VFB
View) the data mapping needs not to be defined. This supports the inclusion of legacy
signals.
[TPS_SYST_01137] Several DataMappings may be defined for the same Sys-
temSignal dFor a SystemSignal which is
• part in several SystemSignalGroups
• part in at least one SystemSignalGroup and at the same time is transmitted
additionally as standalone SystemSignal
• used in N:1 sender-receiver communication where the same SystemSignal is
used in DataMappings on the different senders
• used in a ClientServer communication where the same SystemSignal is used
for a compatible ClientServerOperation in DataMappings on the different
clients
several DataMappings may be defined.c()
As the SystemSignal represents a specific information this information may appear
in different delivery units, but it is still the same information.
One example could be the tire pressure sensor value. At first each wheel’s tire pressure
value exists alone, as they are captured at each wheel individually. So there are 4
SystemSignals defined for a 4 wheel vehicle. If now some Software Component
receives all 4 tire pressure values and puts them inside a SystemSignalGroup for
consistent handling, then those 4 tire pressure values are still represented by the same

189 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4 SystemSignals. Thus each individual tire pressure SystemSignal may appear

as stand-alone as well as part of a SystemSignalGroup.
[TPS_SYST_01050] SystemSignal in the System Extract and ECU Extract dIn the
System with category SYSTEM_EXTRACT or ECU_EXTRACT the missing DataMap-
pings on the complementary Sender/Receiver side needs to be supplemented.c()
In the System with category SYSTEM_EXTRACT or ECU_EXTRACT, where only the
relevant parts of the rootSoftwareComposition are defined, it is necessary to uti-
lize the information from the complementary PortPrototype if the corresponding
PortPrototype is located on another ECU and thus is not part of the extract. This is
described in more detail in chapter 13.2 and chapter 14.2.3.
Therefore in a System with category ECU_EXTRACT the DataMappings are pro-
vided on both, PPortPrototypes and RPortPrototypes.
[TPS_SYST_01034] Data Mappings can be applied to compositions and atomic
software components dDataMappings can be applied to CompositionSwCompo-
nentTypes and on AtomicSwComponentTypes.c()
[TPS_SYST_01035] Transformation of Data Mappings during flattening dDuring
the creation of the System with category ECU_EXTRACT (flattening) the existing
DataMappings that refer to CompositionSwComponentTypes shall be transformed
to refer to AtomicSwComponentTypes instead.c()
[TPS_SYST_01036] No additional Data Mappings in composition substructure
dWhen a CompositionSwComponentType is refined by a supplier the already exist-
ing DataMappings that refer to the CompositionSwComponentType shall not be
copied to the internal substructure.c()
Suppliers who add substructure to a CompositionSwComponentType by adding
SwComponentPrototypes and SwConnectors shall respect the predefined
DataMappings on the CompositionSwComponentType.
The OEM/Supplier Collaboration Scenario is described in chapter 13.1.
[TPS_SYST_05034] DataMapping of ImplementationDataType of category
UNION, DATA_REFERENCE, or FUNCTION_REFERENCE dSenderReceiverIn-
terface.dataElement that is typed by an ImplementationDataType of cate-
gory UNION, DATA_REFERENCE, or FUNCTION_REFERENCE is not allowed to be
mapped by a DataMapping.c()
Please note that for unions there is [constr_1441] and [constr_1607] that are restricting
such a modeling.

190 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

5.2.1.1 Mapping of Variable Data Prototypes with primitive datatypes on System

Signals (Sender-Receiver Communication)

This section describes the relation between the VariableDataPrototype with prim-
itive datatypes and the SystemSignal (see Figure 5.15).
[TPS_SYST_02082] SenderReceiverInterface.dataElement is typed by an
ApplicationPrimitiveDataType of category VALUE or BOOLEAN and a
DataTypeMap exists dIf a SenderReceiverInterface.dataElement is typed by
an ApplicationPrimitiveDataType of category VALUE or BOOLEAN and a
DataTypeMap exists that points to the ApplicationPrimitiveDataType and an
ImplementationDataType of category VALUE or TYPE_REFERENCE that eventu-
ally references (via the SwDataDefProps.implementationDataType) an Imple-
mentationDataType of category VALUE, then this SenderReceiverInterface.
dataElement is a candidate for a primitive Data Mapping.c()
[TPS_SYST_02083] SenderReceiverInterface.dataElement is typed by an
ApplicationPrimitiveDataType of category STRING and a DataTypeMap
exists dIf a SenderReceiverInterface.dataElement is typed by an Appli-
cationPrimitiveDataType of category STRING and a DataTypeMap exists
that points to the ApplicationPrimitiveDataType and an Implementation-
DataType of category ARRAY or TYPE_REFERENCE that eventually references
(via the SwDataDefProps.implementationDataType) an Implementation-
DataType of category ARRAY with a subElement that either
• represents the platform type uint8 or
• references a SwBaseType with a SwBaseType.baseTypeDefinition.base-
TypeSize set to the value 8 and the SwBaseType.baseTypeDefinition.
baseTypeEncoding set to NONE,
then this SenderReceiverInterface.dataElement is a candidate for a primitive
Data Mapping.c()
[TPS_SYST_02084] SenderReceiverInterface.dataElement is typed by an
ApplicationArrayDataType and a DataTypeMap exists dIf a Sender-
ReceiverInterface.dataElement is typed by an ApplicationArrayDataType
and a DataTypeMap exists that points to the ApplicationArrayDataType and an
ImplementationDataType of category ARRAY or TYPE_REFERENCE that eventu-
ally references (via the SwDataDefProps.implementationDataType) an Imple-
mentationDataType of category ARRAY with a subElement that either
• represents the platform type uint8 or
• references a SwBaseType with a SwBaseType.baseTypeDefinition.base-
TypeSize set to the value 8 and the SwBaseType.baseTypeDefinition.
baseTypeEncoding set to NONE,
then this SenderReceiverInterface.dataElement is a candidate for a primitive
Data Mapping.c()

191 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_02085] SenderReceiverInterface.dataElement is typed by an

ImplementationDataType of category ARRAY dIf a SenderReceiverInter-
face.dataElement is typed by an ImplementationDataType of category ARRAY
with a subElement that either
• represents the platform type uint8 or
• references a SwBaseType with a SwBaseType.baseTypeDefinition.base-
TypeSize set to the value 8 and the SwBaseType.baseTypeDefinition.
baseTypeEncoding set to NONE,
then this SenderReceiverInterface.dataElement is a candidate for a primitive
Data Mapping.c()
[TPS_SYST_02086] SenderReceiverInterface.dataElement is typed by an
ImplementationDataType of category VALUE or TYPE_REFERENCE dIf a
SenderReceiverInterface.dataElement is typed by an Implementation-
DataType of category VALUE or TYPE_REFERENCE that eventually references
(via the SwDataDefProps.implementationDataType) an Implementation-
DataType of category VALUE then this SenderReceiverInterface.dataEle-
ment is a candidate for a primitive Data Mapping.c()
[TPS_SYST_02087] SenderReceiverInterface.dataElement is typed by an
ApplicationPrimitiveDataType of category BOOLEAN and no DataTypeMap
exists dThe SenderReceiverInterface.dataElement is a candidate for a primi-
tive Data Mapping.c()
[TPS_SYST_02088] SenderReceiverInterface.dataElement is typed by an
ApplicationArrayDataType and no DataTypeMap exists dIf a Sender-
ReceiverInterface.dataElement is typed by an ApplicationArrayDataType
and no DataTypeMap exists and the ApplicationArrayDataType fulfills the fol-
lowing conditions:
• ApplicationPrimitiveDataType.swDataDefProps.dataConstr exists
and refers to a PhysConstrs.
• ApplicationPrimitiveDataType.swDataDefProps.compuMethod exists
and refers to a CompuMethod of category TEXTTABLE and CompuMethod.com-
puPhysToInternal exists.
• Application of ApplicationPrimitiveDataType.swDataDefProps.com-
puMethod to ApplicationPrimitiveDataType.swDataDefProps.data-
Constr yields a numerical range in [0 .. 255]
then the SenderReceiverInterface.dataElement is a candidate for a primitive
Data Mapping.c()
[TPS_SYST_02089] SenderReceiverInterface.dataElement is typed by an
ApplicationPrimitiveDataType of category STRING and no DataTypeMap

192 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

exists dIf a SenderReceiverInterface.dataElement is typed by an Applica-

tionPrimitiveDataType of category STRING and no DataTypeMap exists and
the ApplicationPrimitiveDataType fulfills the following conditions:
• ApplicationPrimitiveDataType.swDataDefProps.swRecordLay-
out exists and values of SwRecordLayout.swRecordLayoutGroup.
swRecordLayoutGroupFrom and SwRecordLayout.swRecordLayout-
Group.swRecordLayoutGroupTo are both set to 1.
• AApplicationPrimitiveDataType.swDataDefProps.swTextProps
exists and refers to an SwBaseType where the SwBaseType.baseTypeDef-
inition.baseTypeEncoding is set to NONE and the value of SwBaseType.
baseTypeDefinition.baseTypeSize is set to 8.
then the SenderReceiverInterface.dataElement is a candidate for a primitive
Data Mapping.c()
[TPS_SYST_02090] SenderReceiverInterface.dataElement is typed by an
ApplicationPrimitiveDataType of category VALUE and no DataTypeMap ex-
ists dThere is no clear indication that the SenderReceiverInterface.dataEle-
ment is a candidate for a primitive Data Mapping.c()
[TPS_SYST_01037] primitive Data Mapping of UINT8-Arrays dThe primitive Data
Mapping may also be used for the Data Mapping of UINT8-Arrays. This supports an
optimized definition of the Data Mapping.c()
In other words it is allowed to map an array VariableDataPrototype consisting
of UINT8 elements to exactly one SystemSignal in the context of one Sender-
ReceiverToSignalMapping. A UINT8 element may be a String or an array that
contains array elements of Integer type with range 0..255.
Background: In the ECU Configuration of the AUTOSAR COM module such a Sys-
temSignal will be mapped to a COM Signal with the ComSignalType UINT8_N.
[TPS_SYST_02279] SenderReceiverInterface.dataElement is typed by a
“new-world” variable-size ApplicationArrayDataType and a DataTypeMap ex-
ists dA SenderReceiverInterface.dataElement is a candidate for a primitive
SenderReceiverToSignalMapping to a single SystemSignal if all following con-
ditions are fulfilled:
• a SenderReceiverInterface.dataElement is typed by an Application-
ArrayDataType that fulfills the conditions of a “new-world” dynamic-size array
data type according to [TPS_SWCT_01644] (see definition in Software Compo-
nent Template [5])
• the ApplicationArrayDataType has the dynamicArraySizeProfile =
VSA_LINEAR
• a DataTypeMap exists that points to both the ApplicationArrayDataType
and an ImplementationDataType that fulfills the conditions of a “new-world”

193 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

dynamic size array data type according to [TPS_SWCT_01645] (see definition in

Software Component Template [5]) and is of category STRUCTURE
• the referenced ImplementationDataType has the dynamicArraySizePro-
file = VSA_LINEAR
• the referenced ImplementationDataType has two subElements where
– one is a numerical value that represents the size indicator and
– the other is an ImplementationDataTypeElement of category ARRAY
that in turn contains a subElement that represents the platform type uint8.
c()
[constr_5112] ImplementationDataType needs to be defined if a “new-world”
variable-size ApplicationArrayDataType is mapped to a single SystemSig-
nal dA SenderReceiverInterface.dataElement that is typed by a “new-world”
variable-size ApplicationArrayDataType according to [TPS_SWCT_01644] (see
definition in Software Component Template [5]) is only allowed to be mapped to a sin-
gle SystemSignal by the SenderReceiverToSignalMapping if a DataTypeMap
exists that points to both the ApplicationArrayDataType and an Implementa-
tionDataType that fulfills the conditions of a “new-world” dynamic size array data
type according to [TPS_SWCT_01645] (see definition in Software Component Tem-
plate [5]).c()
[TPS_SYST_02280] SenderReceiverInterface.dataElement is typed by a
“new-world” variable-size ImplementationDataType dA SenderReceiverIn-
terface.dataElement is a candidate for a primitive SenderReceiverToSig-
nalMapping to a single SystemSignal if all following conditions are fulfilled:
• the SenderReceiverInterface.dataElement is typed by an Implementa-
tionDataType that fulfills the conditions of a “new-world” dynamic-size array
data type according to [TPS_SWCT_01645] (see definition in Software Compo-
nent Template [5]).
• the referenced ImplementationDataType has the dynamicArraySizePro-
file = VSA_LINEAR
• the ImplementationDataType is of category STRUCTURE with two subEle-
ments where
– one is a numerical value that represents the size indicator and
– the other is an ImplementationDataTypeElement of category ARRAY
that in turn contains a subElement that represents the platform type uint8.
c()
With [TPS_SYST_02279] and [TPS_SYST_02280] it is possible to map a dataEle-
ment that represents a “new-world” variable-size array to a single SystemSignal
without the usage of a data transformer.

194 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Please note that the mapping of an “old-world” variable-size array (see definition in
Software Component Template [5]) to a single SystemSignal is not supported by
AUTOSAR since the Rte_Send call does not include the IN parameter [length] and the
Rte_Receive API does not include the OUT parameter [length] any longer that was
used in former releases to pass the number of elements in the data element.
[constr_5113] Mapping of “old-world” variable size arrays to a single System-
Signal is not supported. dThe SenderReceiverToSignalMapping is not al-
lowed to map a dataElement that is typed by an “old-world” variable size array
defined by [TPS_SWCT_01641] and [TPS_SWCT_01642] (see definition in Software
Component Template [5]) to a single SystemSignal.c()
ARElement
AtpStructureElement
System

+ containerIPduHeaderByteOrder: ByteOrderEnum [0..1]

+ ecuExtractVersion: RevisionLabelString [0..1]
+ pncVectorLength: PositiveInteger [0..1]
+ pncVectorOffset: PositiveInteger [0..1]
+ systemVersion: RevisionLabelString

«atpVariation,atpSplitable»

+mapping 0..*

Identifiable
SystemMapping

«atpVariation»

+dataMapping *

DataMapping

ARElement
SenderReceiverToSignalMapping +systemSignal
SystemSignal
1
+ dynamicLength: Boolean

+dataElement AutosarDataPrototype
«instanceRef» 1 VariableDataPrototype
+signalToReceiverTextTableMapping

+senderToSignalTextTableMapping

0..1 0..1

TextTableMapping

+ identicalMapping: Boolean [0..1]

+ mappingDirection: MappingDirectionEnum [0..1]
«atpVariation»
+ bitfieldTextTableMaskFirst: PositiveInteger [0..1]
+ bitfieldTextTableMaskSecond: PositiveInteger [0..1]

Figure 5.15: Mapping of data elements with primitive datatypes (SenderRecPrimi-

tiveTypeMapping)

195 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class SenderReceiverToSignalMapping
Package M2::AUTOSARTemplates::SystemTemplate::DataMapping
Note Mapping of a sender receiver communication data element to a signal.
Base ARObject, DataMapping
Attribute Type Mult. Kind Note
dataElement VariableDataPrototype 1 iref Reference to the data element.
InstanceRef implemented by:VariableDataPrototypeIn
SystemInstanceRef
senderToSignal TextTableMapping 0..1 aggr This mapping allows for the text-table translation between
TextTable the sending DataPrototype that is defined in the Port
Mapping Prototype and the physicalProps defined for the System
Signal.
signalTo TextTableMapping 0..1 aggr This mapping allows for the text-table translation between
ReceiverText the physicalProps defined for the SystemSignal and a
TableMapping receiving DataPrototype that is defined in the Port
Prototype.
systemSignal SystemSignal 1 ref Reference to the system signal used to carry the data
element.
Table 5.24: SenderReceiverToSignalMapping

[TPS_SYST_02304] Conversion of discrete parts of a CompuMethod on signal

level in SenderReceiverToSignalMapping dIf a SystemSignal defines a Com-
puMethod of category TEXTTABLE, SCALE_LINEAR_AND_TEXTTABLE, and BIT-
FIELD_TEXTTABLE, a conversion of the texttable part of the CompuMethod of the
AutosarDataType of the sending DataPrototype to the SystemSignal as well
as from the SystemSignal to the CompuMethod associated with the Autosar-
DataType of the receiving DataPrototype may be necessary.
For this purpose, meta-class SenderReceiverToSignalMapping aggregates the
meta-class TextTableMapping in the roles senderToSignalTextTableMapping
and signalToReceiverTextTableMapping.c()
As explained in specification of the the AUTOSAR Software Component Template [5],
the TextTableMapping allows enumerated types to be connected when they have
the same or similar semantics but different numerical and/or symbolic representations
of those semantics.
[TPS_SYST_02305] Relevance of attribute TextTableMapping.mappingDirec-
tion in an aggregation by SenderReceiverToSignalMapping dThe value of at-
tributes
• SenderReceiverToSignalMapping.senderToSignalTextTableMap-
ping.mappingDirection
• SenderReceiverToSignalMapping.signalToReceiverTextTableMap-
ping.mappingDirection
has no meaning and shall be ignored.c()

196 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class TextTableMapping
Package M2::AUTOSARTemplates::SWComponentTemplate::PortInterface
Note Defines the mapping of two DataPrototypes typed by AutosarDataTypes that refer to CompuMethods of
category TEXTTABLE, SCALE_LINEAR_AND_TEXTTABLE or BITFIELD_TEXTTABLE.
Base ARObject
Attribute Type Mult. Kind Note
bitfieldTextTable PositiveInteger 0..1 attr This attribute can be used to support the mapping of bit
MaskFirst field to bit field, boolean values to bit fields, and vice
versa. The attribute defines the bit mask for the first
element of the TextTableMapping.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=preCompileTime
bitfieldTextTable PositiveInteger 0..1 attr This attribute can be used to support the mapping of bit
MaskSecond field to bit field, boolean values to bit fields, and vice
versa. The attribute defines the bit mask for the second
element of the TextTableMapping.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=preCompileTime
identical Boolean 0..1 attr If identicalMapping is set == true the values of the two
Mapping referenced DataPrototypes do not need any conversion of
the values.
mapping MappingDirectionEnum 0..1 attr Specifies the conversion direction for which the TextTable
Direction Mapping is applicable.
valuePair TextTableValuePair * aggr Defines a pair of values which are translated into each
other.
Table 5.25: TextTableMapping

5.2.1.2 Mapping of Variable Data Prototypes with composite datatypes (Sender-

Receiver Communication)

This section describes the mapping of VariableDataPrototypes typed by compos-

ite data types to SystemSignals.
It is not possible to map a VariableDataPrototype typed by composite data type
directly (without any additional mechanisms) to one SystemSignal because The RTE
is required to treat AUTOSAR signals transmitted using sender-receiver communica-
tion consistently. For this purpose, data transformation or SystemSignalGroups is
used.
There are two ways to map a VariableDataPrototype typed by composite data
type to SystemSignals/SystemSignalGroups:
1. Use data transformation and map it directly to a SystemSignal.
2. Map it to a SystemSignalGroup with SenderReceiverToSignal-
GroupMapping
[constr_3506] Mapping of composite data type to SystemSignals in System-
SignalGroup dEither all or a subset of elements of a composite data type shall be

197 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

mapped to SystemSignals which shall be members of one SystemSignalGroup if

no data transformation (except COM Based Transformer) is used.
There are two exceptions to this rule:
• it is allowed to map an array VariableDataPrototype consisting of UINT8 el-
ements to exactly one SystemSignal in the context of one SenderReceiver-
ToSignalMapping (see [TPS_SYST_01037]).
• in case the COM Based Transformer [18] is used it is the integral part of the
approach to have a fixed mapping of the individual elements of composite data
types to SystemSignals in a SystemSignalGroup ([TPS_SYST_02058]).
c()

5.2.1.2.1 Data Transformation

If data transformation is used, the consistency of the composite data is assured by the
transformation.
A VariableDataPrototype typed by composite data type can be mapped to one
SystemSignal without any SystemSignalGroup if data transformation is used.
In that case any required mapping between the ApplicationCompositeElement-
DataPrototypes of the VariableDataPrototype of the connected PortProto-
types needs to be expressed by means of a PortInterfaceMapping attached to
the SwConnector connecting the two PortPrototypes and not by means of two
separated DataMappings (one referencing the VariableDataPrototype at the
PPortPrototype and the other one referencing the VariableDataPrototype at
the RPortPrototype).
During creation of a System Extract of the System Configuration Description or the
creation of an ECU Extract of the System Configuration Description, this PortInter-
faceMapping needs to be preserved in order to support proper deserializing trans-
formation at the receiver side (see chapter 13.4 and 14.2).
See chapter 7 for details how to enable data transformation.
In case the COM Based Transformer [18] is used the mapping from section 7.3.3 is
required.

5.2.1.2.2 Mapping via SystemSignalGroups

The VariableDataPrototype that is referenced by dataElement can be typed

by an ApplicationDataType or by an ImplementationDataType. This type de-
cides which reference is used within the SenderRecRecordElementMapping and
SenderRecArrayElementMapping.

198 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Composite DataPrototypes may nest within composite VariableDataProto-

types. Each element typed by a primitive data type of such nested composite Vari-
ableDataPrototype can be mapped to one SystemSignal of a SystemSignal-
Group.
Please note that not every single element typed by a primitive data type needs to be
mapped to a SystemSignal since a partial mapping is also supported that maps
a subset of elements of the composite data type to separate SystemSignals of a
SystemSignalGroup.
The mapping between the SystemSignal and the VariableDataPrototype is
provided in the SenderReceiverToSignalGroupMapping (see Figure 5.16).

199 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

DataMapping

ARElement +signalGroup +dataElement AutosarDataPrototype

SenderReceiverToSignalGroupMapping VariableDataPrototype
SystemSignalGroup 1 «instanceRef» 1

+typeMapping 1
+complexTypeMapping +complexTypeMapping
SenderRecCompositeTypeMapping
0..1 0..1

SenderRecRecordTypeMapping SenderRecArrayTypeMapping

+senderToSignalTextTableMapping 0..1

TextTableMapping

+ identicalMapping: Boolean [0..1]

+ mappingDirection: MappingDirectionEnum [0..1] +signalToReceiverTextTableMapping
«atpVariation»
+ bitfieldTextTableMaskFirst: PositiveInteger [0..1] 0..1
+ bitfieldTextTableMaskSecond: PositiveInteger [0..1]
+senderToSignalTextTableMapping
+signalToReceiverTextTableMapping

0..1 0..1

AbstractImplementationDataTypeElement
ImplementationDataTypeElement
+implementationArrayElement
+implementationRecordElement

0..1
0..1
+recordElementMapping

*
IndexedArrayElement
SenderRecRecordElementMapping
+ index: Integer

+indexedArrayElement 1

+applicationRecordElement 0..1

ApplicationCompositeElementDataPrototype
ApplicationRecordElement

+ isOptional: Boolean [0..1]

+applicationArrayElement 0..1

ApplicationCompositeElementDataPrototype
ApplicationArrayElement

+ arraySizeHandling: ArraySizeHandlingEnum [0..1]

+ arraySizeSemantics: ArraySizeSemanticsEnum [0..1]
«atpVariation»
* +systemSignal 0..1 +systemSignal + maxNumberOfElements: PositiveInteger [0..1] +arrayElementMapping *
ARElement
0..1 SenderRecArrayElementMapping
SystemSignal
+systemSignal
+ dynamicLength: Boolean

Figure 5.16: Mapping of data elements with composite data types (SenderRecCompos-
iteTypeMapping)

[constr_3000] valid SenderRecCompositeTypeMappings dAll Sender-

RecRecordElementMappings or SenderRecArrayElementMappings ag-
gregated in the context of a given SenderReceiverToSignalGroupMapping shall
reference a SystemSignal that is also referenced in the role systemSignal by the

200 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

SystemSignalGroup that is referenced by the enclosing SenderReceiverToSig-

nalGroupMapping in the role signalGroup.c()
In other words: within the context of an SenderReceiverToSignalGroupMapping,
it shall only be possible to refer to a SystemSignal that is a member of the System-
SignalGroup referenced by the SenderReceiverToSignalGroupMapping.
Please note that [constr_3000] does not demand that all leaf elements of the composite
data type are actually mapped to a SystemSignal.
[TPS_SYST_02278] Existence of SystemSignals in a SystemSignalGroup that
are not referenced by a SenderRecCompositeTypeMapping dThere are use
cases where not all SystemSignals of a SystemSignalGroup are referenced by
a SenderRecRecordElementMapping or a SenderRecArrayElementMapping.
One example is the ComBased Transformer use case where the SystemSignal-
Group contains SystemSignals that are added by additional Transformers like the
E2E Transformer (e.g. CRC and Alive Counter), but only the application data element
signals are mapped by the SenderReceiverToSignalGroupMapping. One addi-
tional use case is the partial mapping of composite data types where only a subset of
elements of the composite data type are mapped to SystemSignals of the System-
SignalGroup.c()
Class SenderReceiverToSignalGroupMapping
Package M2::AUTOSARTemplates::SystemTemplate::DataMapping
Note Mapping of a sender receiver communication data element with a composite datatype to a signal group.
Base ARObject, DataMapping
Attribute Type Mult. Kind Note
dataElement VariableDataPrototype 1 iref Reference to a data element with a composite datatype
which is mapped to a signal group.
InstanceRef implemented by:VariableDataPrototypeIn
SystemInstanceRef
signalGroup SystemSignalGroup 1 ref Reference to the signal group, which contain all primitive
datatypes of the composite type
typeMapping SenderRecComposite 1 aggr The CompositeTypeMapping maps the ApplicationArray
TypeMapping Elements and ApplicationRecordElements to Signals of
the SignalGroup.

Table 5.26: SenderReceiverToSignalGroupMapping

Class SenderRecCompositeTypeMapping (abstract)

Package M2::AUTOSARTemplates::SystemTemplate::DataMapping
Note Two mappings exist for the composite data types: "ArrayTypeMapping" and "RecordTypeMapping". In
both, a primitive datatype will be mapped to a system signal.
But it is also possible to combine the arrays and the records, so that an "array" could be an element of a
"record" and in the same manner a "record" could be an element of an "array". Nesting these data types
is also possible.
If an element of a composite data type is again a composite one, the "CompositeTypeMapping" element
will be used one more time (aggregation between the ArrayElementMapping and CompositeType
Mapping or aggregation between the RecordElementMapping and CompositeTypeMapping).
5

201 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class SenderRecCompositeTypeMapping (abstract)
Base ARObject
Subclasses SenderRecArrayTypeMapping, SenderRecRecordTypeMapping
Attribute Type Mult. Kind Note
– – – – –
Table 5.27: SenderRecCompositeTypeMapping

202 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class SenderRecArrayTypeMapping
Package M2::AUTOSARTemplates::SystemTemplate::DataMapping
Note If the ApplicationCompositeDataType is an Array, the "ArrayTypeMapping" will be used.
Base ARObject, SenderRecCompositeTypeMapping
Attribute Type Mult. Kind Note
arrayElement SenderRecArray * aggr Each ApplicationArrayElement shall be mapped on a
Mapping ElementMapping SystemSignal.
senderToSignal TextTableMapping 0..1 aggr This mapping allows for the text-table translation between
TextTable the sending DataPrototype that is defined in the Port
Mapping Prototype and the physicalProps defined for the System
Signal.
signalTo TextTableMapping 0..1 aggr This mapping allows for the text-table translation between
ReceiverText the physicalProps defined for the SystemSignal and a
TableMapping receiving DataPrototype that is defined in the Port
Prototype.

Table 5.28: SenderRecArrayTypeMapping

Class SenderRecRecordTypeMapping
Package M2::AUTOSARTemplates::SystemTemplate::DataMapping
Note If the ApplicationCompositeDataType is a Record, the "RecordTypeMapping" will be used.
Base ARObject, SenderRecCompositeTypeMapping
Attribute Type Mult. Kind Note
recordElement SenderRecRecord * aggr Each ApplicationRecordElement shall be mapped on a
Mapping ElementMapping SystemSignal.

Table 5.29: SenderRecRecordTypeMapping

Class SenderRecRecordElementMapping
Package M2::AUTOSARTemplates::SystemTemplate::DataMapping
Note Mapping of a primitive record element to a SystemSignal. If the VariableDataPrototype that is referenced
by SenderReceiverToSignalGroupMapping is typed by an ApplicationDataType the reference application
RecordElement shall be used. If the VariableDataPrototype is typed by the ImplementationDataType the
reference implementationRecordElement shall be used. Either the implementationRecordElement or
applicationRecordElement reference shall be used.
If the element is composite, there will be no mapping to the SystemSignal (multiplicity 0). In this case the
RecordElementMapping element will aggregate the complexTypeMapping element. In that way also the
composite datatypes can be mapped to SystemSignals.
Base ARObject
Attribute Type Mult. Kind Note
application ApplicationRecord 0..1 ref Reference to an ApplicationRecordElement in the context
RecordElement Element of the dataElement or in the context of a composite
element.
complexType SenderRecComposite 0..1 aggr This aggregation will be used if the element is composite.
Mapping TypeMapping
implementation ImplementationData 0..1 ref Reference to an ImplementationRecordElement in the
RecordElement TypeElement context of the dataElement or in the context of a
composite element.
5

203 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class SenderRecRecordElementMapping
senderToSignal TextTableMapping 0..1 aggr This mapping allows for the text-table translation between
TextTable the sending DataPrototype that is defined in the Port
Mapping Prototype and the physicalProps defined for the System
Signal.
signalTo TextTableMapping 0..1 aggr This mapping allows for the text-table translation between
ReceiverText the physicalProps defined for the SystemSignal and a
TableMapping receiving DataPrototype that is defined in the Port
Prototype.
systemSignal SystemSignal 0..1 ref Reference to the system signal used to carry the primitive
ApplicationRecordElement.

Table 5.30: SenderRecRecordElementMapping

[constr_3230] Usage of SenderRecRecordElementMapping.applica-

tionRecordElement dSenderRecRecordElementMapping.application-
RecordElement shall only be used if the referenced context element (Variable-
DataPrototype that is referenced by the SenderReceiverToSignalGroupMap-
ping.dataElement) is typed by an ApplicationDataType.c()
[constr_3244] Usage of SenderRecRecordElementMapping.implementa-
tionRecordElement dSenderRecRecordElementMapping.implementa-
tionRecordElement shall only be used if the referenced context element (
VariableDataPrototype that is referenced by the SenderReceiverToSig-
nalGroupMapping.dataElement) is typed by an ImplementationDataType.c
()
Class SenderRecArrayElementMapping
Package M2::AUTOSARTemplates::SystemTemplate::DataMapping
Note The SenderRecArrayElement may be a primitive one or a composite one. If the element is primitive, it will
be mapped to the SystemSignal (multiplicity 1). If the VariableDataPrototype that is referenced by Sender
ReceiverToSignalGroupMapping is typed by an ApplicationDataType the reference to the Application
ArrayElement shall be used. If the VariableDataPrototype is typed by the ImplementationDataType the
reference to the ImplementationArrayElement shall be used.
If the element is composite, there will be no mapping to the SystemSignal (multiplicity 0). In this case the
ArrayElementMapping element will aggregate the TypeMapping element. In that way also the composite
datatypes can be mapped to SystemSignals.
Regardless whether composite or primitive array element is mapped the indexed element always needs
to be specified.
Base ARObject
Attribute Type Mult. Kind Note
complexType SenderRecComposite 0..1 aggr This aggregation will be used if the element is composite.
Mapping TypeMapping
indexedArray IndexedArrayElement 1 aggr Reference to an indexed array element in the context of
Element the dataElement or in the context of a composite element.
systemSignal SystemSignal 0..1 ref Reference to the system signal used to carry the primitive
ApplicationArrayElement.

Table 5.31: SenderRecArrayElementMapping

204 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class IndexedArrayElement
Package M2::AUTOSARTemplates::SystemTemplate::DataMapping
Note This element represents exactly one indexed element in the array. Either the applicationArrayElement or
implementationArrayElement reference shall be used.
Base ARObject
Attribute Type Mult. Kind Note
applicationArray ApplicationArray 0..1 ref Reference to an ApplicationArrayElement in an array.
Element Element
implementation ImplementationData 0..1 ref Reference to an ImplementationDataTypeElement in an
ArrayElement TypeElement array.
index Integer 1 attr Position of an element in an array. Starting position is 0.

Table 5.32: IndexedArrayElement

[constr_3231] Usage of IndexedArrayElement.applicationArrayElement d

IndexedArrayElement.applicationArrayElement shall only be used if the ref-
erenced context element (VariableDataPrototype that is referenced by the
SenderReceiverToSignalGroupMapping.dataElement) is typed by an Appli-
cationDataType.c()
[constr_3245] Usage of IndexedArrayElement.implementationArrayEle-
ment dIndexedArrayElement.implementationArrayElement shall only be
used if the referenced context element (VariableDataPrototype that is referenced
by the SenderReceiverToSignalGroupMapping.dataElement) is typed by an
ImplementationDataType.c()
Figure 5.17 shows a mapping example for nested composite data types.

Record a

SystemSignalGroup a
Record b
Integer c SystemSignal c
Integer d
SystemSignal d
Record c SystemSignal f
Integer f SystemSignal g
Integer g
Figure 5.17: Mapping example for nested composite data types

Record a is mapped with SenderReceiverToSignalGroupMapping to a System-

SignalGroup. The content of Record a is mapped with the SenderRecRecord-
TypeMapping. Since the first element of Record a is Record b the Sender-
RecRecordElementMapping does not contain a reference to a SystemSignal

- AUTOSAR Confidential -
205 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate
1 20.03.2007 AUTOSAR_SystemTemplate
System Template
AUTOSAR CP R21-11

because signals apply only to atomic data items. Instead it contains a complex-
TypeMapping with two SenderRecRecordElementMappings for Integer c and In-
teger d. These two elements are mapped to SystemSignals.
Please note that a partial mapping of a data element typed by composite data type
in a PPortPrototype is also supported. If a VariableDataPrototype with a
composite data type in a PPortPrototype is mapped to a SystemSignalGroup
then it is allowed to map only a subset of elements of the composite data type that
are primitives to separate SystemSignals of the SystemSignalGroup. This means
that it is possible to transmit a subset of a composite data element in a ISignalGroup
over the network. Figure 5.18 shows a partial mapping example for nested composite
data types.

Figure 5.18: Partial mapping example for nested composite data types

[TPS_SYST_02306] Conversion of discrete parts of a CompuMethod on signal

level in SenderRecRecordElementMapping and SenderRecArrayTypeMap-
ping dIf a SystemSignal defines a CompuMethod of category TEXTTABLE,
SCALE_LINEAR_AND_TEXTTABLE, and BITFIELD_TEXTTABLE, a conversion of the
texttable part of the CompuMethod of the AutosarDataType of the sending Dat-
aPrototype to the SystemSignal as well as from the SystemSignal to the Com-
puMethod associated with the AutosarDataType of the receiving DataPrototype
may be necessary.
For this purpose,
• meta-class SenderRecRecordElementMapping aggregates the meta-
class TextTableMapping in the roles SenderRecRecordElementMap-
ping.senderToSignalTextTableMapping and SenderRecRecordEle-
mentMapping.signalToReceiverTextTableMapping.

206 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• meta-class SenderRecArrayTypeMapping aggregates the meta-class

TextTableMapping in the roles SenderRecArrayTypeMapping.sender-
ToSignalTextTableMapping and SenderRecArrayTypeMapping.
signalToReceiverTextTableMapping.
c()
As explained in specification of the the AUTOSAR Software Component Template [5],
the TextTableMapping allows enumerated types to be connected when they have
the same or similar semantics but different numerical and/or symbolic representations
of those semantics.
[TPS_SYST_02307] Relevance of attribute TextTableMapping.mappingDirec-
tion in an aggregation by SenderRecRecordElementMapping or Sender-
RecArrayTypeMapping dThe value of attributes
• SenderRecRecordElementMapping.senderToSignalTextTableMap-
ping.mappingDirection
• SenderRecRecordElementMapping.signalToReceiverTextTableMap-
ping.mappingDirection
• SenderRecArrayTypeMapping.senderToSignalTextTableMapping.
mappingDirection
• SenderRecArrayTypeMapping.signalToReceiverTextTableMapping.
mappingDirection
has no meaning and shall be ignored.c()
[constr_5162] Valid TextTableMapping in the context of Sender-
RecRecordElementMapping dThe aggregation of a TextTableMapping at
SenderRecRecordElementMapping is only valid if the SenderRecRecordEle-
mentMapping also references a SystemSignal in the role systemSignal.c
()
Rationale: SenderRecRecordElementMapping could also be used on record el-
ements that itself need to be broken down further. In other words if the Sender-
RecRecordElementMapping aggregates a complexTypeMapping it shall not ag-
gregate a TextTableMapping.
[TPS_SYST_02308] TextTableMapping defined in the context of SenderRecAr-
rayTypeMapping dThe aggregation of a TextTableMapping at SenderRecAr-
rayTypeMapping allows for the text-table translation between all array elements of
an array data type that is used in a PortPrototype of the application software and
the physicalProps defined for the mapped SystemSignals.c()
Please note that the TextTableMapping is aggregated by the SenderRecArray-
TypeMapping because the same mapping rule is valid for all array elements.

207 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

The following example shows a case where an ApplicationRecordDataType is

defined that contains two ApplicationRecordElements. Each Application-
RecordElement defines a TEXTTABLE CompuMethod. One of the SystemSignals
to which one of the ApplicationRecordElements is mapped has a different Com-
puMethod defined and therefore a TextTableMapping is created that defines the
conversion of the texttable part of the CompuMethod of the AutosarDataType of the
sending DataPrototype and the CompuMethod of the SystemSignal.
Listing 5.1: Example for the definition of a TextTableMapping aggregated by the
SenderRecRecordElementMapping
<SENDER-REC-RECORD-TYPE-MAPPING>
<RECORD-ELEMENT-MAPPINGS>
<SENDER-REC-RECORD-ELEMENT-MAPPING>
<APPLICATION-RECORD-ELEMENT-REF DEST="APPLICATION-RECORD-ELEMENT">/
types/R1/enum1</APPLICATION-RECORD-ELEMENT-REF>
<SENDER-TO-SIGNAL-TEXT-TABLE-MAPPING>
<VALUE-PAIRS>
<TEXT-TABLE-VALUE-PAIR>
<FIRST-VALUE>0</FIRST-VALUE>
<SECOND-VALUE>0</SECOND-VALUE>
</TEXT-TABLE-VALUE-PAIR>
<TEXT-TABLE-VALUE-PAIR>
<FIRST-VALUE>1</FIRST-VALUE>
<SECOND-VALUE>1</SECOND-VALUE>
</TEXT-TABLE-VALUE-PAIR>
<TEXT-TABLE-VALUE-PAIR>
<FIRST-VALUE>2</FIRST-VALUE>
<SECOND-VALUE>1</SECOND-VALUE>
</TEXT-TABLE-VALUE-PAIR>
</VALUE-PAIRS>
</SENDER-TO-SIGNAL-TEXT-TABLE-MAPPING>
<SYSTEM-SIGNAL-REF DEST="SYSTEM-SIGNAL">/sig_a</SYSTEM-SIGNAL-REF>
</SENDER-REC-RECORD-ELEMENT-MAPPING>
<SENDER-REC-RECORD-ELEMENT-MAPPING>
<APPLICATION-RECORD-ELEMENT-REF DEST="APPLICATION-RECORD-ELEMENT">/
types/R1/enum2</APPLICATION-RECORD-ELEMENT-REF>
<SENDER-TO-SIGNAL-TEXT-TABLE-MAPPING>
<IDENTICAL-MAPPING>true</IDENTICAL-MAPPING>
</SENDER-TO-SIGNAL-TEXT-TABLE-MAPPING>
<SYSTEM-SIGNAL-REF DEST="SYSTEM-SIGNAL">/sig_b</SYSTEM-SIGNAL-REF>
</SENDER-REC-RECORD-ELEMENT-MAPPING>
</RECORD-ELEMENT-MAPPINGS>
</SENDER-REC-RECORD-TYPE-MAPPING>

5.2.1.3 Mapping of Client Server Operations to System Signals

This section describes the mapping of ClientServerOperations to SystemSig-

nals (see Figure 5.19).
[TPS_SYST_01148] Mapping of IN and INOUT ArgumentDataPrototypes to
callSignals dThe ArgumentDataPrototypes that are passed to the operation

208 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

(i.e. the direction is “in”) and the ArgumentDataPrototypes that are passed to
and returned from the operation (i.e. the direction is “inout”) are expected to be
mapped to the callSignal by the serializer.c()
[TPS_SYST_01149] Mapping of OUT and INOUT ArgumentDataPrototypes to
returnSignals dThe ArgumentDataPrototypes that are returned from the op-
eration (i.e. the direction is “out”) and the ArgumentDataPrototypes that are
passed to and returned from the operation (i.e. the direction is “inout”) are expected
to be mapped to the returnSignal by the serializer.c()
Please note that due to DataMapping restrictions the client-server communication
is only supported in AUTOSAR if the SOME/IP Transformer is used as serializer. In
SOME/IP the ApplicationErrors are part of the SOME/IP Header as Return Code
as described by [PRS_SOMEIP_00030] in [19]. This is the reason why the Applica-
tionErrors are not considered in the ClientServerToSignalMapping.
[TPS_SYST_01150] Mapping of returnSignal and callSignal to COM Signal
dIn the ECU Configuration of the AUTOSAR COM module the returnSignal and the
callSignal are expected to be mapped to COM Signals with the ComSignalType
UINT8_N or UINT8_DYN.c()
The ClientServerToSignalMapping can only map transformed data to System-
Signals because it contains no information how data shall be serialized, it only ref-
erences the primitive SystemSignal which shall contain the serialized data. How to
define the necessary information which serialization algorithm shall be applied can be
found in chapter 7. The implementation of this algorithm is provided via a BSW module.
DataMapping

ClientServerToSignalMapping

«instanceRef»
+clientServerOperation 1 +returnSignal 0..1 +callSignal 1

AtpStructureElement ARElement
Identifiable SystemSignal
ClientServerOperation
+ dynamicLength: Boolean
+ diagArgIntegrity: Boolean [0..1]

Figure 5.19: Mapping of a ClientServerOperation to a callSignal and a returnSignal

Class ClientServerToSignalMapping
Package M2::AUTOSARTemplates::SystemTemplate::DataMapping
Note This element maps the ClientServerOperation to call- and return-SystemSignals.
5

209 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class ClientServerToSignalMapping
Base ARObject, DataMapping
Attribute Type Mult. Kind Note
callSignal SystemSignal 1 ref Reference to the callSignal to which the IN and INOUT
ArgumentDataPrototypes are mapped.
clientServer ClientServerOperation 1 iref Reference to a ClientServerOperation, which is mapped
Operation to a call SystemSignal and a return SystemSignal.
InstanceRef implemented by:OperationInSystem
InstanceRef
returnSignal SystemSignal 0..1 ref Reference to the returnSignal to which the OUT and
INOUT ArgumentDataPrototypes are mapped.

Table 5.33: ClientServerToSignalMapping

[constr_3111] returnSignal in ClientServerToSignalMapping is mandatory

dA ClientServerToSignalMapping shall always have a returnSignal defined.c
()
[constr_3215] TransformationTechnology.version and Transformation-
Technology.protocol settings for request and response of a client/server com-
munication dTransformationTechnology.version and Transformation-
Technology.protocol shall be identical for ISignals that are derived from
the same ClientServerOperation. This means that all ISignals that refer
to ClientServerToSignalMapping.callSignal or to ClientServerToSig-
nalMapping.returnSignal of the same ClientServerToSignalMapping shall
have the same TransformationTechnology.protocol and Transformation-
Technology.version defined.c()
The ClientServerToSignalMapping (as any other DataMapping) defines the
mapping on the level of SystemSignals (see also section 5.2). For the communi-
cation on actual PhysicalChannels (could be actual VLAN or dedicated Ether-
netCluster) an ISignal and a corresponding ISignalTriggering needs to be
defined (see section 6.1).

210 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

ClientServerToSignalMapping

returnSignal callSignal

System Signal Return System Signal Call

ReturnISignal_VLAN1 ReturnISignal_VLAN2 CallISignal_VLAN1 CallISignal_VLAN2

ISignalTriggering ISignalTriggering ISignalTriggering ISignalTriggering

IST_ReturnVLAN1 IST_ReturnVLAN2 IST_CallVLAN1 IST_CallVLAN2

VLAN 1 VLAN 2
(PhysicalChannel) (PhysicalChannel)

Figure 5.20: Scenario in which a SOME/IP Service with a ClientServerOperation is of-

fered on several VLANs

In the example in figure 5.20 a server offers his service on two VLANs (could be ac-
tual VLAN or dedicated EthernetCluster). When a call arrives at the server from
VLAN1 it will be propagated in the “CallISignal_VLAN1” to the RTE. The RTE takes
the call message and de-serializes the payload and calls the Server. The result of the
server is serialized and needs to be put into a return ISignal. But from just look-
ing at the available ISignals for the return it is not possible to determine whether
the result message has to be put into the result ISignal “ReturnISignal_VLAN1” or
“ReturnISignal_VLAN2”.
Thus the RTE needs to determine to which PhysicalChannel the call ISignal be-
longs and choose the return ISignal which is defined on the same PhysicalChan-
nel. The ISignalTriggering defines on which PhysicalChannel an ISig-
nal is transported, thus by determining which ISignalTriggering refers to the
ISignal (in the call example ISignal: “CallISignal_VLAN1”, ISignalTriggering:
“IST_CallVLAN1” ) it is clear that the PhysicalChannel “VLAN 1” is the source of
the call and thus the return message needs to go to an ISignal which is transported
on that PhysicalChannel.
If a Server offers a service on several PhysicalChannels then there are some con-
straints to be respected in order for the RTE, Com, and LdCom to work together prop-
erly:
• Define an own ISignal-Pair (call and return) for each PhysicalChannel the
service shall be offered on. These ISignals refer to the respective call and
return SystemSignals.
• Only one ISignalTriggering per ISignal: each ISignal shall only be ref-
erenced by up to one ISignalTriggering.

211 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• Whether an ISignalTriggering is relevant for a specific RTE, Com, or LdCom

is determined by the ISignalTriggering referring to an ISignalPort, and
that ISignalPort is member of a CommunicationConnector which belongs
to the respective EcuInstance.
[constr_5273] One ISignalTriggering pair allowed per EthernetPhysi-
calChannel for a ClientServerOperation dIn the context of a System of cate-
gory ECU_SYSTEM_DESCRIPTION or ECU_EXTRACT, for each EthernetPhys-
icalChannel at most one pair of
• ISignalTriggering that refers to an ISignal that in turn refers to a Sys-
temSignal that is referenced by a specific ClientServerToSignalMapping
in the role callSignal
• ISignalTriggering that refers to an ISignal that in turn refers to a Sys-
temSignal that is referenced by the same ClientServerToSignalMapping
in the role returnSignal
shall exist.c()
Also it is required that a Client/Server interaction is fully provided on each Phys-
icalChannel, i.e. both callSignal and returnSignal shall be put onto the
PhysicalChannel.
[constr_5274] ISignalTriggerings that represent the callSignal and re-
turnSignal of the same ClientServerOperation on a PhysicalChannel
shall be referenced by the same ClientServerToSignalMapping dIf on an Eth-
ernetPhysicalChannel an ISignalTriggering that refers to an ISignal that
in turn refers to a SystemSignal that is referenced by a specific ClientServer-
ToSignalMapping in the role callSignal is defined, then another ISignalTrig-
gering shall be aggregated by the same EthernetPhysicalChannel and that
ISignalTriggering shall refer to an ISignal that in turn refers to a SystemSig-
nal that is referenced by the same ClientServerToSignalMapping in the role
returnSignal, and vice versa.c()

5.2.1.4 Mapping of a ApplicationCompositeElementDataPrototype within a

composite application data type on a System Signal (Sender-Receiver
Communication)

SenderReceiverCompositeElementToSignalMapping is used to map a Ap-

plicationCompositeElementDataPrototype that is aggregated within a com-
posite data type (record element or an array element) to a SystemSignal.

212 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

DataMapping

+dataElement AutosarDataPrototype
SenderReceiverCompositeElementToSignalMapping
«instanceRef» 0..1 VariableDataPrototype

+typeMapping 1
+complexTypeMapping +complexTypeMapping
SenderRecCompositeTypeMapping
0..1 0..1

SenderRecRecordTypeMapping SenderRecArrayTypeMapping

+senderToSignalTextTableMapping 0..1

TextTableMapping

+ identicalMapping: Boolean [0..1] +signalToReceiverTextTableMapping

+ mappingDirection: MappingDirectionEnum [0..1]
«atpVariation» 0..1
+ bitfieldTextTableMaskFirst: PositiveInteger [0..1]
+ bitfieldTextTableMaskSecond: PositiveInteger [0..1]
+senderToSignalTextTableMapping
+signalToReceiverTextTableMapping

0..1 0..1
AbstractImplementationDataTypeElement
ImplementationDataTypeElement
+implementationArrayElement
+implementationRecordElement

0..1
0..1
+recordElementMapping

SenderRecRecordElementMapping IndexedArrayElement

+ index: Integer
+indexedArrayElement

+applicationRecordElement 0..1 1

ApplicationCompositeElementDataPrototype
ApplicationRecordElement

+ isOptional: Boolean [0..1]

+applicationArrayElement 0..1

ApplicationCompositeElementDataPrototype
+arrayElementMapping

ApplicationArrayElement
+systemSignal

+ arraySizeHandling: ArraySizeHandlingEnum [0..1]

+ arraySizeSemantics: ArraySizeSemanticsEnum [0..1]
«atpVariation»
+ maxNumberOfElements: PositiveInteger [0..1]
1 0..1 +systemSignal
*
ARElement
SystemSignal 0..1 SenderRecArrayElementMapping
+systemSignal
+ dynamicLength: Boolean

Figure 5.21: Mapping of a Variable Data Prototype which is aggregated within a compos-
ite data type on a System Signal

[constr_3058] References from SenderRecArrayElementMapping and from

SenderRecRecordElementMapping to SystemSignals are not allowed within
a SenderReceiverCompositeElementToSignalMapping dThe reference
from SenderRecArrayElementMapping to SystemSignal and from Sender-
RecRecordElementMapping to SystemSignal shall not exist if the enclosing
SenderRecCompositeTypeMapping is owned by a SenderReceiverComposi-
teElementToSignalMapping.c()

213 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_01143] DataMapping on the sender side for elements of a com-

posite data type dOn the sender side, it is possible that only a subset of elements
of an ApplicationCompositeElementDataPrototype of a dataElement in a
PPortPrototype in its sender role is referenced by a DataMapping.c()
Class SenderReceiverCompositeElementToSignalMapping
Package M2::AUTOSARTemplates::SystemTemplate::DataMapping
Note Mapping of an Variable Data Prototype which is aggregated within a composite datatype to a System
Signal (only one element of the composite data type is mapped).
Base ARObject, DataMapping
Attribute Type Mult. Kind Note
dataElement VariableDataPrototype 0..1 iref Reference to a data element with a composite datatype
from which one element is mapped to a SystemSignal.
InstanceRef implemented by:VariableDataPrototypeIn
SystemInstanceRef
systemSignal SystemSignal 1 ref Reference to the SystemSignal to which one primitive of
the composite type is mapped.
typeMapping SenderRecComposite 1 aggr The CompositeTypeMapping maps one VariableData
TypeMapping Prototype of the composite data type to a SystemSignal.

Table 5.34: SenderReceiverCompositeElementToSignalMapping

SenderRecCompositeTypeMapping and all subclasses are described in section

5.2.1.2

5.2.1.5 Mapping of Trigger to SystemSignal

[TPS_SYST_05001] Send a Trigger across a network dIn order to be able to send

a Trigger across a network to trigger a RunnableEntity deployed to a different
EcuInstance it is possible to define a TriggerToSignalMapping that maps a
Trigger to a SystemSignal in the role systemSignal.c()
[constr_1198] TriggerToSignalMapping.systemSignals eligible for a Trig-
gerToSignalMapping in case no DataTransformation is used dThe ISignal
that is referenced by a SystemSignal that in turn is referenced by a TriggerToSig-
nalMapping in the role systemSignal shall have the length attribute set to 0 if the
ISignal does not reference a DataTransformation in the role dataTransfor-
mation.c()
[constr_1199] ISignals relating to systemSignals eligible for a Trigger-
ToSignalMapping shall use update bit in case no DataTransformation is used
dAn ISignal
• that is used to reference a systemSignal that in turn is referenced by a Trig-
gerToSignalMapping and
• does not reference a DataTransformation in the role dataTransformation
shall be referenced by an ISignalToIPduMapping where the attribute up-
dateIndicationBitPosition is defined.c()

214 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Please note that according to [TPS_SYST_02021] the updateIndicationBitPo-

sition shall not be defined if LdCOM is used.
[constr_5258] TriggerToSignalMapping.systemSignals eligible for a Trig-
gerToSignalMapping in case DataTransformation is used dThe ISignal that
is referenced by a SystemSignal that in turn is referenced by a TriggerToSig-
nalMapping in the role systemSignal shall have its length attribute set to the
value of BufferProperties.headerLength attribute of the respective Transfor-
mationTechnology if the ISignal references a DataTransformation in the role
dataTransformation that in turn references the TransformationTechnology.c
()
For example, in case of the SOME/IP Transformer the 64 bit length covers the SOME/IP
header defined by the SOME/IP Transformer (i.e. Request ID, Protocol Version, In-
terfaceVersion, Message Type, and Return Code) (as defined by [constr_5258] and
[constr_3128]). The actual payload of the ISignal representing a trigger is 0.
[constr_5262] SystemSignal used for Trigger communication shall not be part
of any SystemSignalGroup dA SystemSignal that is target of a TriggerToSig-
nalMapping in the role systemSignal shall not be referenced by a SystemSig-
nalGroup in the role systemSignal.c()
[TPS_SYST_02365] No support of Com Based Transformer for Trigger commu-
nication dDue to [constr_5262] it is not possible to define a SystemSignal which
is representing a Trigger to be part of a SystemSignalGroup, thus it is not pos-
sible to define a Trigger to be processed by a Com Based Transformer (as Com
Based Transformer is enabled with the ISignalGroup.comBasedSignalGroup-
Transformation).c()
[TPS_SYST_05002] The value of startPosition is irrelevant dThe value of
startPosition shall not be considered inside an ISignalToIPduMapping that
references an ISignal used to reference a TriggerToSignalMapping.system-
Signal that in turn is referenced by a TriggerToSignalMapping.c()
Please note that in case of a TriggerToSignalMapping for transmission of a Trig-
ger over the network that has the swImplPolicy set to queued the sender will not
get any indication that the receiver queue is full.

215 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

ARElement
AtpStructureElement
System

+ containerIPduHeaderByteOrder: ByteOrderEnum [0..1]

+ ecuExtractVersion: RevisionLabelString [0..1]
+ pncVectorLength: PositiveInteger [0..1]
+ pncVectorOffset: PositiveInteger [0..1]
+ systemVersion: RevisionLabelString

«atpVariation,atpSplitable»
+mapping 0..*
Identifiable
SystemMapping

«atpVariation»

+dataMapping *

DataMapping

TriggerToSignalMapping

«instanceRef»

+trigger 1 +systemSignal 1

AtpStructureElement ARElement
Identifiable SystemSignal
Trigger
+ dynamicLength: Boolean
+ swImplPolicy: SwImplPolicyEnum [0..1]

Figure 5.22: Structure of a TriggerToSignalMapping

Class TriggerToSignalMapping
Package M2::AUTOSARTemplates::SystemTemplate::DataMapping
Note This meta-class represents the ability to map a trigger to a SystemSignal of size 0. The Trigger does not
transport any other information than its existence, therefore the limitation in terms of signal length.
Base ARObject, DataMapping
Attribute Type Mult. Kind Note
systemSignal SystemSignal 1 ref This is the SystemSignal taken to transport the Trigger
over the network.
Tags:xml.sequenceOffset=20
trigger Trigger 1 iref This represents the Trigger that shall be used to trigger
RunnableEntities deployed to a remote ECU.
Tags:xml.sequenceOffset=10
InstanceRef implemented by:TriggerInSystemInstance
Ref
Table 5.35: TriggerToSignalMapping

216 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

5.2.2 Signal Path Constraint

One task of the System Generator is to define the needed communication infrastructure
(e.g. ISignals, Pdus, Frames) between ECUs. The System Generator often has the
choice between alternative paths through the topology. In the example shown in Figure
5.23 the System Generator would have the choice between two paths (Path1: CAN3 or
Path2: CAN1-GW-CAN2) for a signal that is send by ECU2 and is received by ECU4.
If no further information is given the decision will be made e.g. by means of boundary
conditions like busload, transmissions speed, etc.
Path 2

CAN1 ECU3 CAN2

(GW)

ECU1 ECU2 CAN3 ECU4

Path 1
Figure 5.23: Example for a Communication Path

Signal Mapping Constraints allow to further restrict or specify the path(s) a signal is
allowed to be transmitted over. A path is specified by an list of PhysicalChannels.
There exist four different constraints for signals regarding the signal path (see Figure
5.24):
[TPS_SYST_01041] CommonSignalPath definition dThe CommonSignalPath de-
scribes that two or more signals shall take the same path in the topology.c(RS_SYST_-
00017)
[TPS_SYST_01042] ForbiddenSignalPath definition dThe ForbiddenSignal-
Path describes the path that one or more signals shall not take in the topology, e.g. in
case of safety critical transmission.c(RS_SYST_00020)
[TPS_SYST_01043] PermissibleSignalPath definition dThe PermissibleSig-
nalPath describes the path one or more signals may take in the topology. If more than
one PermissibleSignalPath is defined for the same signal/operation attributes,
any of them may be chosen.c(RS_SYST_00019, RS_SYST_00016)
[TPS_SYST_01044] SeparateSignalPath definition dThe SeparateSignalPath
describes that two or more signals shall take separate paths in the topology e.g. in
case of redundant transmission.c(RS_SYST_00018)
It is also possible that the same signal is aggregated two times by the SeparateSig-
nalPath element to indicate that this signal should be transmitted redundantly over
two different paths.
The meta-model part, which describes the Communication Path constraints, will be
explained in the following sections.

217 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

ARElement
AtpStructureElement
System

+ containerIPduHeaderByteOrder: ByteOrderEnum [0..1]

+ ecuExtractVersion: RevisionLabelString [0..1]
+ pncVectorLength: PositiveInteger [0..1]
+ pncVectorOffset: PositiveInteger [0..1]
+ systemVersion: RevisionLabelString

«atpVariation,atpSplitable»

+mapping 0..*
Identifiable
SystemMapping

«atpVariation»
+signalPathConstraint *

SignalPathConstraint

CommonSignalPath ForbiddenSignalPath PermissibleSignalPath SeparateSignalPath

Figure 5.24: Communication Path Description (SignalPathConstraints)

5.2.2.1 CommonSignalPath

SignalPathConstraint
CommonSignalPath

+signal * +operation *

SwcToSwcSignal SwcToSwcOperationArguments

+ direction: SwcToSwcOperationArgumentsDirectionEnum

«instanceRef»
«instanceRef»
+dataElement 1 +operation 1

AutosarDataPrototype AtpStructureElement
VariableDataPrototype Identifiable
ClientServerOperation

+ diagArgIntegrity: Boolean [0..1]

«enumeration»
SwcToSwcOperationArgumentsDirectionEnum

in
out

Figure 5.25: Description of signals that shall take the same way in the topology (Com-
monSignalPath)

218 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class CommonSignalPath
Package M2::AUTOSARTemplates::SystemTemplate::SignalPaths
Note The CommonSignalPath describes that two or more SwcToSwcSignals and/or SwcToSwcOperation
Arguments shall take the same way (Signal Path) in the topology.
Base ARObject, SignalPathConstraint
Attribute Type Mult. Kind Note
operation SwcToSwcOperation * aggr The arguments sent in one direction (either from client to
Arguments server or server to client) of the operations that shall take
the same signal path.
signal SwcToSwcSignal * aggr The SwcToSwcSignals that shall take the same way
(Signal Path) in the topology.

Table 5.36: CommonSignalPath

Class SwcToSwcSignal
Package M2::AUTOSARTemplates::SystemTemplate::SignalPaths
Note The SwcToSwcSignal describes the information (data element) that is exchanged between two SW
Components. On the SWC Level it is possible that a SW Component sends one data element from one
P-Port to two different SW Components (1:n Communication). The SwcToSwcSignal describes exactly
the information which is exchanged between one P-Port of a SW Component and one R-Port of another
SW Component.
Base ARObject
Attribute Type Mult. Kind Note
dataElement VariableDataPrototype 2 iref Reference to a data element on the PPortPrototype and
to the same data element on the RPortPrototype.
InstanceRef implemented by:VariableDataPrototypeIn
SystemInstanceRef

Table 5.37: SwcToSwcSignal

219 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class SwcToSwcOperationArguments
Package M2::AUTOSARTemplates::SystemTemplate::SignalPaths
Note The SwcToSwcOperationArguments describes the information (client server operation arguments, plus
the operation identification, if required) that are exchanged between two SW Components from exactly
one client to one server, or from one server back to one client. The direction attribute defines which
direction is described. If direction == IN, all arguments sent from the client to the server are described by
the SwcToSwcOperationArguments, in direction == OUT, it’s the arguments sent back from server to
client.
Base ARObject
Attribute Type Mult. Kind Note
direction SwcToSwcOperation 1 attr Direction addressed by this SwcToSwcClientServer
ArgumentsDirection Operation element.
Enum
operation ClientServerOperation 2 iref Reference to the operation at the client and at the server
side whose arguments are described by SwcToSwc
OperationArguments. The two ports referenced shall be
connected by a connector in the software component
description.
InstanceRef implemented by:OperationInSystem
InstanceRef
Table 5.38: SwcToSwcOperationArguments

Enumeration SwcToSwcOperationArgumentsDirectionEnum
Package M2::AUTOSARTemplates::SystemTemplate::SignalPaths
Note Direction addressed by this element.
Literal Description
in IN (all IN and INOUT arguments)
Tags:atp.EnumerationLiteralIndex=0
out OUT (all OUT and INOUT arguments) .
Tags:atp.EnumerationLiteralIndex=1

Table 5.39: SwcToSwcOperationArgumentsDirectionEnum

220 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

5.2.2.2 ForbiddenSignalPath

SignalPathConstraint
ForbiddenSignalPath

+physicalChannel 1..* +signal * +operation *

Identifiable
SwcToSwcSignal SwcToSwcOperationArguments
PhysicalChannel
+ direction: SwcToSwcOperationArgumentsDirectionEnum

+managedPhysicalChannel 0..*

«instanceRef» «instanceRef»

+dataElement 1 +operation 1

AutosarDataPrototype AtpStructureElement
VariableDataPrototype Identifiable
ClientServerOperation

+ diagArgIntegrity: Boolean [0..1]

Figure 5.26: Description of the signal path that a signal shall not take in the topology
(ForbiddenSignalPath)

Class ForbiddenSignalPath
Package M2::AUTOSARTemplates::SystemTemplate::SignalPaths
Note The ForbiddenSignalPath describes the physical channels which an element shall not take in the
topology. Such a signal path can be a constraint for the communication matrix, because such a path has
an effect on the frame generation and the frame path.
Base ARObject, SignalPathConstraint
Attribute Type Mult. Kind Note
operation SwcToSwcOperation * aggr Reference to the operation arguments of one operation
Arguments which shall not take the predefined way in the topology.
physical PhysicalChannel 1..* ref The SwcToSwcSignal shall not be transmitted on one of
Channel these physical channels.
signal SwcToSwcSignal * aggr The data element which shall not take the predefined way
in the topology.

Table 5.40: ForbiddenSignalPath

221 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

5.2.2.3 PermissibleSignalPath

SignalPathConstraint
PermissibleSignalPath

1..*
+physicalChannel {ordered} +signal * +operation *
Identifiable
SwcToSwcSignal SwcToSwcOperationArguments
PhysicalChannel
+ direction: SwcToSwcOperationArgumentsDirectionEnum

+managedPhysicalChannel 0..*

«instanceRef» «instanceRef»

+dataElement 1 +operation 1

AutosarDataPrototype AtpStructureElement
VariableDataPrototype Identifiable
ClientServerOperation

+ diagArgIntegrity: Boolean [0..1]

Figure 5.27: Description of the signal path that a signal shall take in the topology (Per-
missibleSignalPath)

Class PermissibleSignalPath
Package M2::AUTOSARTemplates::SystemTemplate::SignalPaths
Note The PermissibleSignalPath describes the way a data element shall take in the topology. The path is
described by ordered references to PhysicalChannels.
If more than one PermissibleSignalPath is defined for the same signal/operation attributes, any of them
can be chosen. Such a signal path can be a constraint for the communication matrix . This path
describes that one data element should take path A (e.g. 1. CAN channel, 2. LIN channel) and not path
B (1. CAN channel, FlexRay channel A).
This has an effect on the frame generation and the frame path.
Base ARObject, SignalPathConstraint
Attribute Type Mult. Kind Note
operation SwcToSwcOperation * aggr The arguments of an operation that can take the
Arguments predefined way in the topology.
physical PhysicalChannel 1..* ref The SwcToSwcSignal can be transmitted on one of these
Channel physical channels.
(ordered)
signal SwcToSwcSignal * aggr The data element which can take the predefined way in
the topology.

Table 5.41: PermissibleSignalPath

222 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

5.2.2.4 SeparateSignalPath

SignalPathConstraint
SeparateSignalPath

+signal * +operation *

SwcToSwcSignal SwcToSwcOperationArguments

+ direction: SwcToSwcOperationArgumentsDirectionEnum

«instanceRef»
«instanceRef»
+dataElement 1 +operation 1

AutosarDataPrototype AtpStructureElement
Identifiable
VariableDataPrototype
ClientServerOperation

+ diagArgIntegrity: Boolean [0..1]

Figure 5.28: Description of signals that shall not take the same way in the topology
(SeparateSignalPath)

Class SeparateSignalPath
Package M2::AUTOSARTemplates::SystemTemplate::SignalPaths
Note The SeparateSignalPath describes that two SwcToSwcSignals and/or SwcToSwcOperationArguments
shall not take the same way (Signal Path) in the topology (e.g. Redundancy). This means that the signals
are not allowed to share even a single physical channel in their path.
Base ARObject, SignalPathConstraint
Attribute Type Mult. Kind Note
operation SwcToSwcOperation * aggr The SwcToSwcOperationArguments that shall not take
Arguments the same way (Signal Path) in the topology.
signal SwcToSwcSignal * aggr The SwcToSwcSignals that shall not take the same way
(Signal Path) in the topology.

Table 5.42: SeparateSignalPath

223 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

5.3 RTE and basic software resource estimations

Important constraints for system partitioning are the available resources on the ECUs
in the system. For SW components, the resource estimations can be stated in SW
component descriptions. It is however not only SW components that require resources.
AUTOSAR RTE and basic software running on the ECU have resource needs as well.
The realization of the RTE and the kind of basic software to be run on a certain ECU
depend on the implicit and explicit usage of all basic software by the software com-
ponents. The software components need to communicate internally and with software
components on other ECUs. Furthermore, they have different needs with respect to
scheduling. This results in implicit use of e.g. communication and operating system
software. In addition, the software components make explicit use of basic software
when they e.g. utilize system services (e.g. diagnostics) and access sensors/actua-
tors via the I/O abstraction layer or the Complex Driver abstraction layer. Thus, the
resource consumption of the RTE and the basic software depend on the SW Compo-
nents mapped to the ECU, since this determines the exact configuration of the RTE
and the basic software.
[TPS_SYST_01126] Resource Consumption for RTE and basic software dThe re-
source consumption for RTE and basic software may be specified using class EcuRe-
sourceEstimation. Each estimation is performed for a specific ECU and for a spe-
cific set of SW mapped to that ECU (reference from EcuResourceEstimation to
EcuInstance and SwcToEcuMapping).c(RS_SYST_00002)
Different resource estimations for a specific ECU, but with different mappings may exist,
e.g. for different variants of the system, or to show the difference of resource needs
for different mappings. The EcuResourceEstimation aggregates the meta-class
ResourceConsumption from the GenericStructure package each for RTE and basic
software, which specifies stack and heap usage and execution time.
ExecutionTime and StackUsage are used to provide information on the implemen-
tation specific resource usage of the ExecutableEntity defined in the Internal-
Behavior of SW-Component respectively in the BswInternalBehavior of BSW
Module. MemorySection documents the resources needed to load the object file
containing the implementation on the ECU. HeapUsage describes the dynamic mem-
ory usage of the software.
Figure 5.29 shows the meta-model for resource estimations for RTE and basic SW.

224 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

ARElement
AtpStructureElement
System

+ containerIPduHeaderByteOrder: ByteOrderEnum [0..1]

+ ecuExtractVersion: RevisionLabelString [0..1]
+ pncVectorLength: PositiveInteger [0..1]
+ pncVectorOffset: PositiveInteger [0..1]
+ systemVersion: RevisionLabelString

«atpVariation,atpSplitable»
+mapping 0..* Identifiable
Identifiable SwcToEcuMapping
+swMapping
SystemMapping
«atpVariation» 0..*

«atpVariation» +swCompToEcuMapping *
+resourceEstimation *

EcuResourceEstimation

+bswResourceEstimation 0..1 +rteResourceEstimation 0..1

Identifiable +ecuInstance 1 +ecuInstance 1
ResourceConsumption
FibexElement
EcuInstance

+ comConfigurationGwTimeBase: TimeValue [0..1]

«atpVariation,atpSplitable» «atpVariation,atpSplitable» + comConfigurationRxTimeBase: TimeValue [0..1]
+ comConfigurationTxTimeBase: TimeValue [0..1]
+stackUsage 0..* +heapUsage 0..* «atpVariation,atpSplitable» + comEnableMDTForCyclicTransmission: Boolean [0..1]
Identifiable Identifiable «atpVariation,atpSplitable» + ethSwitchPortGroupDerivation: Boolean [0..1]
+ pncPrepareSleepTimer: TimeValue [0..1]
StackUsage HeapUsage +executionTime 0..*
A
+ pncSynchronousWakeup: Boolean [0..1]
Identifiable + pnResetTime: TimeValue [0..1]
+ sleepModeSupported: Boolean
ExecutionTime
+memorySection 0..* + v2xSupported: V2xSupportEnum [0..1]
+ wakeUpOverBusSupported: Boolean
Identifiable
MemorySection

+ alignment: AlignmentType [0..1]

+ memClassSymbol: CIdentifier [0..1]
+ option: Identifier [0..*]
+ size: PositiveInteger [0..1]
+ symbol: Identifier [0..1]

+executableEntity 0..1 +executableEntity 0..* +executableEntity 0..1

Identifiable
ExecutableEntity

+ minimumStartInterval: TimeValue [0..1]

+ reentrancyLevel: ReentrancyLevelEnum [0..1]

Figure 5.29: ECU resource estimations (ResourceEstimation)

[constr_3005] valid EcuResourceEstimation dThe same EcuInstance shall be

referenced directly from the EcuResourceEstimation and from the SwcToEcuMap-
ping:
EcuResourceEstimation.swCompToEcuMapping.ecuInstance == EcuResourceEsti-
mation.ecuInstancec()
Class EcuResourceEstimation
Package M2::AUTOSARTemplates::SystemTemplate::SWmapping
Note Resource estimations for RTE and BSW of a single ECU instance.
5

225 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class EcuResourceEstimation
Base ARObject
Attribute Type Mult. Kind Note
bswResource ResourceConsumption 0..1 aggr Estimation for the resource consumption of the basic
Estimation software.
ecuInstance EcuInstance 1 ref Reference to the ECU this estimation is done for.
introduction DocumentationBlock 0..1 aggr This represents introductory documentation about the ecu
resource estimation
Tags:xml.sequenceOffset=-10
rteResource ResourceConsumption 0..1 aggr Estimation for the resource consumption of the run time
Estimation environment.
swCompToEcu SwcToEcuMapping * ref References to SwcToEcuMappings that have been taken
Mapping into account for the resource estimations. This way it is
possible to define dfferent EcuResourceEstimations with
diifferent mappings, e.g. before and after mapping an
additional SW component.

Table 5.43: EcuResourceEstimation

Class ResourceConsumption
Package M2::AUTOSARTemplates::CommonStructure::ResourceConsumption
Note Description of consumed resources by one implementation of a software.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
accessCount AccessCountSet * aggr Set of access count values
Set
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=accessCountSet, accessCountSet.variation
Point.shortLabel
vh.latestBindingTime=preCompileTime
executionTime ExecutionTime * aggr Collection of the execution time descriptions for this
implementation. The aggregation of executionTime is
subject to variability with the purpose to support the
conditional existence of runnable entities.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=executionTime.shortName, execution
Time.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
heapUsage HeapUsage * aggr Collection of the heap memory allocated by this
implementation.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=heapUsage.shortName, heap
Usage.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
memorySection MemorySection * aggr An abstract memory section required by this
Implementation.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=memorySection.shortName, memory
Section.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
5

226 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class ResourceConsumption
sectionName SectionNamePrefix * aggr A prefix to be used for the memory section symbol in the
Prefix code.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=preCompileTime
stackUsage StackUsage * aggr Collection of the stack memory usage for each runnable
entity of this implementation. The aggregation of Stack
Usage is subject to variability with the purpose to support
the conditional existence of runnable entities.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=stackUsage.shortName, stack
Usage.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime

Table 5.44: ResourceConsumption

The element ResourceConsumption and the sub-elements HeapUsage, Memory-

Section, StackUsage and ExecutionTime are described in more detail in the
BSW Module Description [20].

5.4 Communication Management Mapping

The Communication Management Mapping is used to define the link between the ap-
plication’s communication request and the actual network topology.
Some applications may have the need to control the communication infrastructure dur-
ing their run-time. So they can control at which point in time certain communication
shall be enabled (requested) and when the communication can be disabled (release
request). How the control interaction is to be setup is specified in the Software Com-
ponent Template[5].
Which parts of the communication relies on such control is expressed using Port-
Groups. The PortGroup collect the set of PortPrototypes which shall be available
when the application requests communication.
The handling of communication management comes in two flavors, defined by the
category of the PortGroup:
• PARTIAL_NETWORKING
• MODE_MANAGEMENT
PortGroups of category PARTIAL_NETWORKING determine to control the commu-
nication via Partial Network Clusters (see subsection 5.4.1).
PortGroups of category MODE_MANAGEMENT determine to control the communi-
cation directly via ComManager (see subsection 5.4.2). This is specifically required in
cases where no partial networking is used or on network which do not support partial
networking (like Lin).

227 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

5.4.1 Partial Networking

The AUTOSAR BSW stack supports power saving during vehicle operation time with
the partial networking mechanism. This mechanism allows to shut down and startup
the bus communication interfaces of groups of ECUs (Partial Network Cluster) during
normal bus communication.
On the VFB Level Partial Networks are represented by Virtual Function Clusters and
are described with PortGroups. The Virtual Function Cluster groups the communica-
tion necessary to realize one or more vehicle functions that can become activated/de-
activated during normal vehicle operation. Virtual Function Clusters are described in
more detail in [5]. The Virtual Function Clusters are mapped onto Partial Network
Clusters.
There are two variants of the partial networking mechanism:
• The static partial networking mechanism where the mapping of Partial Network
Clusters (PNCs) to Virtual Function Clusters (and thus ECUs) is defined statically
during vehicle development and does not change afterwards.
• The dynamic partial networking mechanism that enables changes of the mapping
between PNCs and ECUs during life time of a vehicle by introducing a learning
algorithm (for details, see chapter 5.4.1.3).
The use of partial networking in general is defined based on the element PncMap-
ping. If partial networking is used, the dynamic partial networking is then further
defined by the attribute dynamicPncToChannelMappingEnabled of the element
CommunicationConnector.
[TPS_SYST_01133] Partial Network Clusters dPartial Network Clusters are realized
with ISignalIPduGroups using PncMapping.c(RS_SYST_00042)
Each PncMapping has the ability to define relations to ISignalIPduGroups,
PdurIPduGroups, and PhysicalChannels. These relations are used to describe
the impact of a PNC on the respective networking artifacts. The realization of those re-
lationships is typically to be implemented in the Basic Software Mode Manager (BswM).
• PncMapping.pncGroup (referring to ISignalIPduGroup) is used to define
which Com ISignalIPduGroups shall be enabled when this PNC is active. The
use-case is to enable/disable Com ISignalIPdus, especially periodic behavior
like cyclic sending and time-out monitoring.
• PncMapping.pncPdurGroup (referring to PdurIPduGroup) is used to define
which PdurIPduGroups shall be enabled when this PNC is active. The use-
case is to enable/disable Pdus which typically are not passing the Com module
(e.g. Pdus going through LdCom, Diagnostic IPdus, Gatewayed IPdus).
• PncMapping.physicalChannel (referring to PhysicalChannel) is used to
define which PhysicalChannels shall be enabled when this PNC is active.
The use-case is to enable/disable the whole PhysicalChannel and allows to

228 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

also cover Pdus which neither pass the Com module nor the Pdu Router module
(e.g. NM).
+managedPhysicalChannel 0..*

Identifiable Identifiable
PhysicalChannel SystemMapping

+physicalChannel 0..*

«atpVariation,atpSplitable» «atpVariation»
+frameTriggering 0..* +pncMapping *
Identifiable Describable «atpVariation»
+wakeupFrame
FrameTriggering PncMapping 0..* +pncConsumedProvidedServiceInstanceGroup
0..*
+ pncIdentifier: PositiveInteger FibexElement
+ pncWakeupEnable: Boolean [0..1] ConsumedProvidedServiceInstanceGroup
AtpStructureElement + shortLabel: Identifier [0..1]
+vfc
Identifiable
«instanceRef»
PortGroup «instanceRef»
0..*

+associatedConsumedProvidedServiceInstanceGroup
+innerGroup 0..*
0..*

+pncPdurGroup 0..* +pncGroup 0..* 0..* +dynamicPncMappingPduGroup

FibexElement FibexElement

+relevantForDynamicPncMapping
PdurIPduGroup ISignalIPduGroup

+ communicationMode: String + communicationDirection: CommunicationDirectionType

+ communicationMode: String

+associatedPdurIPduGroup *
+containedISignalIPduGroup * +associatedComIPduGroup
0..*

«atpVariation»
0..*

FibexElement
EcuInstance

+ comConfigurationGwTimeBase: TimeValue [0..1]

+ comConfigurationRxTimeBase: TimeValue [0..1]
+ comConfigurationTxTimeBase: TimeValue [0..1]
+ comEnableMDTForCyclicTransmission: Boolean [0..1]
+ ethSwitchPortGroupDerivation: Boolean [0..1]
Identifiable + pncPrepareSleepTimer: TimeValue [0..1]
CommunicationConnector + pncSynchronousWakeup: Boolean [0..1]
+connector + pnResetTime: TimeValue [0..1]
+ createEcuWakeupSource: Boolean [0..1] + sleepModeSupported: Boolean
+ dynamicPncToChannelMappingEnabled: Boolean [0..1] * «atpVariation» + v2xSupported: V2xSupportEnum [0..1]
+ pncFilterArrayMask: PositiveInteger [0..*] {ordered} + wakeUpOverBusSupported: Boolean
+ pncGatewayType: PncGatewayTypeEnum [0..1]

Figure 5.30: Mapping of Virtual Function Clusters onto Partial Network Clusters

Class PncMapping
Package M2::AUTOSARTemplates::SystemTemplate::PncMapping
Note Describes a mapping between one or several Virtual Function Clusters onto Partial Network Clusters. A
Virtual Function Cluster is realized by a PortGroup. A Partial Network Cluster is realized by one or more
IPduGroups.
Base ARObject, Describable
Attribute Type Mult. Kind Note
dynamicPnc ISignalIPduGroup * ref Reference to an ISignalIPduGroup that allows mapping of
MappingPdu this PNC without statically mapping this PNC directly to a
Group channel. This is needed to describe dynamic PNCs that
can be learned only at run-time and which have also a
relation to an ISignalIPduGroup.
Tags:atp.Status=draft
ident PncMappingIdent 0..1 aggr This adds the ability to become referrable to PncMapping.
5

229 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class PncMapping
physical PhysicalChannel * ref This reference maps the partial network to a
Channel communication channel.
pncConsumed ConsumedProvided * ref ConsumedProvidedServiceInstanceGroup used in a
Provided ServiceInstanceGroup Partial Network Cluster. This reference is optional, since
ServiceInstance this could be used for starting and stopping Consumed
Group ProvidedServiceInstanceGroup according the requested
partial network, but is not necessarily needed.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
pncGroup ISignalIPduGroup * ref IPduGroup participating in a Partial Network Cluster. This
reference is optional in case an ecu extract has only
indirect pnc access, i.e. ecu is not directly connected to a
network which supports partial network.
pncIdentifier PositiveInteger 1 attr Identifer of the Partial Network Cluster. This number
represents the absolute bit position of this Partial Network
Cluster in the NM Pdu.
pncPdurGroup PdurIPduGroup * ref This reference maps the Partial Network Cluster to a set
of PdurIpduGroups.
pncWakeup Boolean 0..1 attr If this parameter is available and set to true then this PNC
Enable will be woken up as soon as a channel wakeup occurs on
a channel where this PNC is assigned to. This is ensured
by adding this PNC to the corresponding channel wakeup
sources during upstream mapping.
relevantFor EcuInstance * ref Reference to a PNC Gateway ECU for PNCs which do
DynamicPnc not have a static channel mapping. This is needed to
Mapping describe dynamic PNCs that can be learned only at
run-time and which have no relation to an ISignalIPdu
Group.
Tags:atp.Status=draft
shortLabel Identifier 0..1 attr This attribute specifies an identifying shortName for the
PncMapping. It shall be unique in the System scope.
vfc PortGroup * iref Virtual Function Cluster to be mapped onto a Partial
Network Cluster. This reference is optional in case that
the System Description doesn’t use a complete Software
Component Description (VFB View). This supports the
inclusion of legacy systems.
InstanceRef implemented by:PortGroupInSystem
InstanceRef
wakeupFrame FrameTriggering * ref Reference to collection of FrameTriggerings that are used
for the wakeup of this PNC (Application Frames or Nm
Frames can be used). This reference is only valid if this
EcuExtract represents an ECU which has direct PNC
access, i.e. ECU is directly connected to a network which
supports partial network.

Table 5.45: PncMapping

[constr_3039] pncIdentifier range dThe pncIdentifier value shall be in the

range of 8..63 for normal CAN and in the range of 8..511 for CAN FD, FlexRay and
Ethernet.c()
Note: Older ECUs with a smaller PNC range can be used together with new ECUs with
a larger PNC range (e.g. when NM PDU length and PNC Range increased in the next
model year and some ECUs are overtaken). But take care that in that case the older
ECUs cannot react on PNC identifiers that are beyond their smaller range as they will
be ignored by those older ECUs.

230 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_03067] Definition of pncVectorOffset dThe attribute System.

pncVectorOffset shall define the common start byte position of the PNC vector
for all NM messages in the System.c()
[TPS_SYST_03068] Definition of pncVectorLength dThe attribute System.
pncVectorLength shall define the maximum PNC vector length from all NM mes-
sages of the System.c()
Partial Networks are considered System wide. If a specific PhysicalChannel has
a limited payload size and thus is not able to transport the entire PNC Vector infor-
mation in the payload of the NM messages it is possible to define a shortened PNC
Vector on that specific NmCluster (where that NmCluster configures the NM behav-
ior on that CommunicationCluster or in case of Ethernet the PhysicalChannel
representing a VLAN).
[constr_3687] Limited value range for NmCluster.pncClusterVectorLength
dThe value of NmCluster.pncClusterVectorLength shall be equal or smaller than
System.pncVectorLength.c()
[constr_3198] Uniqueness of PncMapping.shortLabel dIf the optional shortLa-
bel attribute is used it shall be unique in the System scope.c()
The runtime information that is used to coordinate the request/release information of
all partial networks is called pncVector. The size and position of the pncVector
inside the NmPdu is globally defined in the System class in chapter 1.6. The size might
be reduced using the optional NmCluster.pncClusterVectorLength attribute.
In the system description the NmPdus are described based on the actual network inter-
action (i.e. an ECU sends one NmPdu per network and receives a set of NmPdus).
NmPdus that define the existence of NM user data via the existence of the at-
tribute iSignalToIPduMapping shall be referenced by corresponding PduTrig-
gerings where the attribute iPduPort exists accordingly. This is also reflected by
[TPS_SYST_01057].
NmPdus that define the existence of NM user data via the definition of NmPdu.nm-
DataInformation shall not be referenced by PduTriggerings because neither
Com nor PduR are involved in the transmission (which lets the Nm module talk to the
bus interface directly).
Please note that a pncVector is transmitted as byte array, where each bit of the byte
array represents one particular partial network cluster. The AUTOSAR stack handles
a PNC bit vector as byte array data type.
[constr_3040] Restriction of pncIdentifier values dThe pncIdentifier value
shall be within the range described by pncVectorOffset and pncVectorLength.c
()
[constr_3146] Partial Networking timing constraint dFor Partial Networking the fol-
lowing timing constraints shall be ensured:

231 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• CAN / Ethernet: (pnResetTime + pncPrepareSleepTimer) < nmNetwork-

Timeout
• FlexRay: (pnResetTime + pncPrepareSleepTimer) < nmReadySleepTime
c()
[TPS_SYST_02145] Default behavior for not defined nmPncParticipation
dWhen NmCluster.nmPncParticipation is set to true or is not defined this Nm-
Cluster shall contribute to the partial network mechanism.c()
[constr_3323] Relation between NmCluster.nmPncParticipation and
PncMapping.pncGroup dIf a PncMapping references an ISignalIPduGroup
in role pncGroup which in turn
• contains (either directly or via one of its subordinate ISignalIPduGroups ref-
erenced in role containedISignalIPduGroup) ISignalIPdus that are ref-
erenced by a PduTriggering in role iPdu which in turn
• is composed by a PhysicalChannel in role pduTriggering which in turn
• is composed by CommunicationCluster in role physicalChannel which in
turn
• is referenced by an NmCluster in role communicationCluster,
then this NmCluster shall have its nmPncParticipation attribute set to TRUE un-
less the PhysicalChannel is referenced in the role managedPhysicalChannel.c
()
[constr_3484] PncMapping that refers a managedPhysicalChannel shall also
refer the managing PhysicalChannel dIf a PncMapping refers to a Physi-
calChannel (either directly in the role physicalChannel or indirectly by referenc-
ing an ISignalIPduGroup in the role pncGroup) and this PhysicalChannel is
referenced in the role managedPhysicalChannel, then the according managing
PhysicalChannel (the source of the managedPhysicalChannel reference) shall
also be referenced by the PncMapping (either directly in the role physicalChannel
or indirectly by referencing an ISignalIPduGroup in the role pncGroup).c()
Note that [constr_3484] ensures that the managing PhysicalChannel is part of the
same PNC as the managedPhysicalChannels.

232 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Identifiable FibexElement
PduTriggering +iPdu Pdu

1 + hasDynamicLength: Boolean [0..1]

+ length: UnlimitedInteger [0..1]

+pduTriggering 0..*
«atpVariation,atpSplitable»
Describable
+physicalChannel
Identifiable PncMapping
0..*
PhysicalChannel + pncIdentifier: PositiveInteger
+managedPhysicalChannel
0..* + pncWakeupEnable: Boolean [0..1]
+ shortLabel: Identifier [0..1]

IPdu
+physicalChannel 1..*

«atpVariation,atpSplitable»

FibexElement +dynamicPncMappingPduGroup 0..* +pncGroup 0..*

«atpVariation»
FibexElement
CommunicationCluster
ISignalIPdu ISignalIPduGroup
+iSignalIPdu
+ baudrate: PositiveUnlimitedInteger [0..1]
+ unusedBitPattern: Integer + communicationDirection: CommunicationDirectionType
+ protocolName: String [0..1] 0..* «atpVariation»
+ protocolVersion: String [0..1] + communicationMode: String

+communicationCluster 0..1 +containedISignalIPduGroup

0..*

Identifiable
NmCluster

+ nmChannelSleepMaster: Boolean [0..1]

+ nmNodeDetectionEnabled: Boolean [0..1]
+ nmNodeIdEnabled: Boolean [0..1]
+ nmPncParticipation: Boolean [0..1]
+ nmRepeatMsgIndEnabled: Boolean [0..1]
+ nmSynchronizingNetwork: Boolean [0..1]
+ pncClusterVectorLength: PositiveInteger [0..1]

Figure 5.31: Relation between NmCluster.nmPncParticipation and PncMapping.

pncGroup

[TPS_SYST_02146] Explicit definition of pncVector at NmPdu dIf there is an

ISignalToIPduMapping aggregated by NmPdu that fully matches the interval de-
fined by pncVectorOffset and pncVectorLength then the corresponding ISig-
nal represents the pncVector.c()
Attributes used to configure the Partial Network Wakeup of one specific Ecu are de-
scribed in chapter 3.3.1.4.
[TPS_SYST_03073]{DRAFT} Derivation of NmPnFilterMaskByte dThe Commu-
nicationConnector.pncFilterArrayMask is configured per Communication-
Connector. This data mask is calculated over the whole payload of the NmPdu ig-
noring the leading bytes which do not contain pncVector information. The number of
leading bytes which shall be ignored is equivalent to the value of System.pncVecto-
rOffset.c(RS_SYST_00042)
Example: For pncFilterArrayMask = 263 and pncVectorOffset = 2, pncIden-
tifier with number 63 in a NmPdu will be masked (see Figure 5.32).

Figure 5.32: Example of masked pncIdentifiers in a NmPdu

233 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Note that only pncIdentifier =< 63 can be used for the Filter mask, even if NM
PDUs are configured to be larger than 8 Byte and the PncVector defined in NM user
data exceeds the first 8 Byte.

5.4.1.1 Partial Networking and managed Ethernet switch

On switched Ethernet networks it is possible to let the Ethernet switch be managed by

an AUTOSAR ECU. In this case the configuration and the behavior of the Couplin-
gElement with couplingType=switch are controlled by the host ECU.
For the usage of Partial Networking on switched Ethernet networks with managed
CouplingElements the following use-case applies:
Depending on the requested Partial Networks it is possible to switch off Ethernet switch
ports (CouplingPorts) which are not involved in any currently active communication
([TPS_SYST_03055]). The time delay to switch off the CouplingPorts shall be in line
with the used Network Management timing to avoid switching off the CouplingPorts
before the Network Management has decided to go to sleep ([constr_3616]).
[TPS_SYST_03055] Semantics of EthernetCluster.coupling-
PortSwitchoffDelay dEthernetCluster.couplingPortSwitchoffDelay, if
defined, is used to configure a host ECU to delay a switch off of a CouplingPort.c()
If using Partial Networks and the possibility to switch off Ethernet switch ports (
CouplingPorts), it is possible to switch on CouplingPorts for a certain amount
of time, as defined in EthernetCluster.couplingPortStartupActiveTime
([TPS_SYST_03054]). This is used to enable the host ECU (ECU that maintains
an Ethernet switch) to listen to the network and wait for couplingPortStartu-
pActiveTime to receive Partial Network information. If Partial Network information is
received within couplingPortStartupActiveTime, then the according PNCs and
the Ethernet switch will be requested. With this Partial Network related request the con-
trolling of the Ethernet switch ports will be done as described in [TPS_SYST_03055]).
The remaining Ethernet switch ports will be switched off after couplingPortStar-
tupActiveTime expires ([TPS_SYST_03054])).
[TPS_SYST_03054] Semantics of EthernetCluster.couplingPortStartu-
pActiveTime dEthernetCluster.couplingPortStartupActiveTime, if de-
fined, is used to configure a host ECU to detect a wake-up and wait to receive a Partial
Network information. This also applies if a host ECU detects a reset as wake-up reason
and listens to the network if Partial Network information is available on that network.c()
In order to describe the relationships between Partial Networks and Ethernet switch
ports an optional reference from CouplingPort to a PncMappingIdent in the role
pncMapping is defined.

234 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_3615] Existence of EthernetCluster.couplingPortSwitchoffDelay

dThe attribute EthernetCluster.couplingPortSwitchoffDelay shall be de-
fined if at least one EcuInstance connected to that EthernetCluster has the
attribute ethSwitchPortGroupDerivation set to TRUE.c()
[constr_3616] Value of EthernetCluster.couplingPortSwitchoffDelay dIf
defined, the value of EthernetCluster.couplingPortSwitchoffDelay shall be
greater than UdpNmCluster.nmNetworkTimeout + UdpNmCluster.nmWaitBus-
SleepTime of the respective EthernetCluster.c()
[constr_3617] Existence of EthernetCluster.couplingPortStartupActive-
Time dThe attribute EthernetCluster.couplingPortStartupActiveTime shall
be defined if at least one EcuInstance connected to that EthernetCluster has
the attribute ethSwitchPortGroupDerivation set to TRUE.c()
[constr_3618] Value of EthernetCluster.couplingPortStartupActiveTime
dIf defined, the value of EthernetCluster.couplingPortStartupActiveTime
shall be greater than UdpNmCluster.nmNetworkTimeout + UdpNmCluster.
nmWaitBusSleepTime of the respective EthernetCluster.c()
Identifiable Identifiable
CouplingPort SystemMapping

+ connectionNegotiationBehavior: EthernetConnectionNegotiationEnum [0..1]

+ couplingPortRole: CouplingPortRoleEnum [0..1]
+ macLayerType: EthernetMacLayerTypeEnum [0..1]
+ physicalLayerType: EthernetPhysicalLayerTypeEnum [0..1]
+ receiveActivity: EthernetSwitchVlanIngressTagEnum [0..1]

«atpVariation»

«enumeration»
CouplingPortRoleEnum +pncMapping *
+pncMapping 0..* +managedPhysicalChannel 0..*
hostPort Describable
upLinkPort Referrable +ident +physicalChannel Identifiable
PncMapping
standardPort PhysicalChannel
PncMappingIdent 0..*
0..1 + pncIdentifier: PositiveInteger
+ pncWakeupEnable: Boolean [0..1]
+ shortLabel: Identifier [0..1]

+pncGroup 0..* +dynamicPncMappingPduGroup 0..*

FibexElement +containedISignalIPduGroup
ISignalIPduGroup 0..*

+ communicationDirection: CommunicationDirectionType
+ communicationMode: String

+associatedComIPduGroup *

CommunicationCluster FibexElement
EthernetCluster EcuInstance

+ couplingPortStartupActiveTime: TimeValue [0..1] + comConfigurationGwTimeBase: TimeValue [0..1]

+ couplingPortSwitchoffDelay: TimeValue [0..1] + comConfigurationRxTimeBase: TimeValue [0..1]
+ comConfigurationTxTimeBase: TimeValue [0..1]
+ comEnableMDTForCyclicTransmission: Boolean [0..1] +relevantForDynamicPncMapping
+ ethSwitchPortGroupDerivation: Boolean [0..1]
+ pncPrepareSleepTimer: TimeValue [0..1] 0..*
+ pncSynchronousWakeup: Boolean [0..1]
+ pnResetTime: TimeValue [0..1]
+ sleepModeSupported: Boolean
+ v2xSupported: V2xSupportEnum [0..1]
+ wakeUpOverBusSupported: Boolean

Figure 5.33: Partial Networking and managed Ethernet switch

The example in figure 5.34 illustrates the setup of an host ECU which manages 2
Ethernet switches.

235 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

The port 1 of Switch 1 is a hostPort.

The port 5 of Switch 1 and port 1 of Switch 2 are upLinkPorts.

Ethernet Switch Management ECU

AUTOSAR Ethernet
stack
0

1 1

Switch 1 Switch 2
2 3 4 5 2 3 4 5

Figure 5.34: Example of managed Ethernet switches

[constr_3523] CouplingPort and PncMapping in the scope of an Ethernet-

PhysicalChannel dIf
• a CouplingPort referring to an EthernetPhysicalChannel – via a Vlan-
Membership – references at least one PncMapping
• and that PncMapping contains PDUs – via the assignment of PncMapping.
pncGroup – that are transported on this EthernetPhysicalChannel
then every CouplingPort referring to that EthernetPhysicalChannel shall ref-
erence at least one PncMapping as well.c()
If a CouplingPort referring to an EthernetPhysicalChannel – via a VlanMem-
bership – references no PncMapping then any other CouplingPort referring to
that EthernetPhysicalChannel is allowed to either reference PncMappings or
not.
[TPS_SYST_03018] Aggregation of PNCs at the hostPort dA CouplingPort with
couplingPortRole set to hostPort shall reference all PncMappings that are ref-
erenced by any CouplingPorts of the same CouplingElement and all Couplin-
gElements connected to this CouplingElement.c()
[constr_3524] Definition of couplingPortRole on CouplingPort for managed
CouplingElement dA managed CouplingElement shall have either
• at most one CouplingPort with couplingPortRole set to hostPort or
• at least one CouplingPort with couplingPortRole set to upLinkPort.
c()
[constr_3525] Connection of CouplingPort with couplingPortRole set to up-
LinkPort dA CouplingPort with couplingPortRole set to upLinkPort shall

236 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

be connected to exactly one other CouplingPort with couplingPortRole set to

upLinkPort.c()
[TPS_SYST_03020] Default value for CouplingPort.couplingPortRole if not
defined dIf no value for the attribute CouplingPort.couplingPortRole is defined
then standardPort shall be assumed.c()
[TPS_SYST_03019] Modeling of CouplingPorts for managed CouplingEle-
ment dOnly CouplingPorts that participate in the communication of a managed
CouplingElement shall be modeled in the System Description.c()
All other ports of an Ethernet switch are not modeled. The expected behavior of un-
modeled Ethernet switch ports on runtime:
1. the Ethernet switch driver switches off this Ethernet switch ports during its initial-
ization
2. unmodeled Ethernet switch ports shall never be switched on.

5.4.1.2 Partial Network Gateway

As Partial Networks are spread over multiple networks their state has to be synchro-
nized by gateway ECUs connected to a Partial Network on more than one network.
Therefore a gateway mechanism is available where per network it can be configured if
the network takes part in Partial network gateway algorithm or not. When more than
one gateway is connected to one network then only one gateway shall be configured
as main gateway.
[constr_5093] pncGatewayType and PhysicalChannel dWhen multiple Commu-
nicationConnectors with pncGatewayType set to a value other than none are
referenced by the same PhysicalChannel then only up to one Communication-
Connector shall have the pncGatewayType set to active.c()
An ECU having a Partial Network connected to more than one network may not neces-
sarily coordinate this Partial Network. There can be uses-cases where such an ECU
is connected to multiple networks where this Partial Network is relevant but all of these
networks are handled by the same gateway or by various gateways connected on an-
other network. In this case the ECU does not coordinate the Partial Network.
[constr_5094] pncGatewayType and ECU dWhen an ECU is connected to more than
one PhysicalChannel and has a relation to a Partial Network then all Communica-
tionConnectors of this ECU where this Partial Network is related to shall have the
pncGatewayType value either set to none or to a value different than none (i.e.
active or passive).c()
Hint: This constraint ensures that an ECU either coordinates a Partial Network on all
of its connected channels or on none.

237 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

5.4.1.3 Dynamic Partial Network Cluster Mapping

In order to reduce the coding/adaptions-variants because of the wakeup-sleep-

behavior (i.e. Function that transmits and receives PDUs mapped to PNCs can be
deactivated/activated, placed on different ECUs or even run on Adaptive-AUTOSAR
partitions) the PNC-to-channel-mapping table of the PNC Gateways can be dynami-
cally reconfigured.
For this functionality, two parts of the PNC-to-channel-mapping need to exist:
• statically configured via SystemDescription and stored in ROM. This is used to
define PNC routing for critical system communication (i.e. keep bus communica-
tion alive during hazard lights). This is also the default behavior when dynamic
PNC-to-channel-mapping is not used or before this dynamic handling was intro-
duced.
• configurable to be changed during runtime, stored in NVRAM. The Entries can
be read and set (never unset) by a learning algorithm and via APIs. The table
can also be reset by API, but it contains at least the entries out of the statically
configured table.

238 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

PN-Cluster N
PN-Cluster 1

PN-Cluster 2

PN-Cluster 3

PN-Cluster 4

PN-Cluster 5

…
Bus X S S

Bus Y S

Bus Z

Bus to other GwECU S S

PN-Cluster N
PN-Cluster 1

PN-Cluster 2

PN-Cluster 3

PN-Cluster 4

PN-Cluster 5

Bus X S S S …

Bus Y L S

Bus Z L

Bus to other GwECU L S S

Figure 5.35: Example for static and configurable PNC-to-channel-mapping

There are two different kinds of mapping table entries as shown in Figure 5.35.
• Static PNC Mapping (S): Entries in PNC-to-channel-mapping are defined in
ARXML and stored in nonvolatile memory of the ECU.
• Configurable PNC Mapping (L): Entries in PNC-to-channel-mapping can be
added dynamically via PNC learning mechanism but can also be reset.
Mappings can only be added to already existing PNCs. New PNCs cannot be intro-
duced dynamically, but it shall be possible to have PNCs available even without existing
mapping/actual usage. Note that even if a PNC has at least one static relation it is still
learnable to additional channel relations.
“Static” entries of the PNC-to-channel-mapping (black “S” in Figure 5.35) can be de-
fined via the PncMapping attributes pncGroup, wakeupFrame or physicalChan-
nel.

239 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

If a PNC has no “static” mapping and therefore no entries within the PNC-to-channel-
mapping, but entries shall be learnable (blue “L” in Figure 5.35), even if there is no
Tx-/Rx-Relation to the Gateway running the PNC Gateway, then the PNC could be
defined in System Description via the PncMapping attributes relevantForDynam-
icPncMapping or dynamicPncMappingPduGroup.
Note: Defining such dynamic PNC-to-channel-mapping entries makes only sense if
the PNC is assigned to a CommunicationConnector where dynamicPncToChan-
nelMappingEnabled is set to TRUE. Otherwise those dynamic mappings will not be
handled by the ECU on this channel. Learning of dynamic PNC-to-channel-mapping
is started by an explicit trigger. The node that starts this algorithm sends a Partial
Network Learning request, which is then responded by all nodes with their current
PNC Membership. PNC Gateways will forward this request to other channels. During
this learning phase the PNC Gateway observes all responses and updates the PNC-
to-channel-mapping accordingly, depending on which channels a PNC member was
observed/received.
Note: While the PNC-to-channel-mapping could be dynamically re-configured, all rout-
ing paths (including source and target I-PDUs) within a Gateway are still configured
statically. Therefore it is expected that the design of the SystemDescription ensure
that all routing paths of all potentially expected PNC-to-channel-mappings are provided
statically. For this dynamic PNC-to-channel-mapping some configurations restrictions
and design limitations are needed to ensure proper functionality. These are provided
in the following either as constraints or as text if a constraint is not feasible.
[constr_5167]{DRAFT} pncGatewayType and ECU over the whole system dOnly
one PNC Gateway ECU in the whole System shall exist that sets on all its Communi-
cationConnectors the pncGatewayType to active.c()
This constraint ensures that only one top level PNC coordinator exists. This is crucial
as otherwise PNC system is either completely split in several parts over the system or
connected in a way that would lead to cycles.
[constr_5168]{DRAFT} pncGatewayType passive and connected ECUs dFor all
CommunicationConnectors with pncGatewayType set to passive belonging to
one PNC Gateway ECU, all connected counterpart CommunicationConnectors
where pncGatewayType is set to active shall belong to one ECU.c()
This constraint ensures that one ECU cannot be passively connected to two different
coordinators. This avoids coordination problems in normal systems as there is no coor-
dination from passive to passive. For dynamic PNC-to-channel mapping it is essential
to avoid cycles in the forwarding of the learning request.
[constr_5169]{DRAFT} pncGatewayType and (routing) paths dNo path over all net-
works shall exist that connects a CommunicationConnector with pncGateway-
Type active to a CommunicationConnector with pncGatewayType passive where
both CommunicationConnectors belong to the same ECU.c()
This constraint ensures that PNC Gateways have no cyclic connections which would
lead to a blocking request keeping the whole system awake.

240 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_5170]{DRAFT} nmPassiveModeEnabled and dynamicPncToChan-

nelMappingEnabled dIf nmPassiveModeEnabled is set to TRUE on a NmNode
then dynamicPncToChannelMappingEnabled shall be set to FALSE on the
according CommunicationConnector referring to the same CommunicationCon-
troller.c()
Note: A passive NM node cannot transmit its cluster membership to the Gateway.
Therefore, it cannot take part at the dynamic PNC learning and all assigned PNCs
have to be statically configured, i.e. no dynamic mapping is allowed.
Additionally this constraint also leads to the fact that defining dynamic mappings for
such a NmNode makes no sense as they will be ignored. The EthernetCommuni-
cationConnector.pncFilterDataMask / FlexrayCommunicationConnector.
pncFilterDataMask / CanCommunicationConnector.pncWakeupDataMask of
the Gateways have to consider learnable PNCs.
In a system with multiple (cascaded) Gateways, the RepeatMessage time has to be
sufficient to fulfill its purpose and provide enough time for PNC Learning mechanism
to receive at least one NM PDU of all NmNodes.

5.4.2 Com Management Mapping

The AUTOSAR BSW stack supports the configuration of the ComM module which en-
capsulates the control of the underlying communication services. The ComM module
collects the bus communication access requests from communication requestors and
coordinates the bus communication access requests. In order to utilize the communi-
cation requests from application software the Software Component Template supports
the definition of PortGroups with the category MODE_MANAGEMENT. In this sec-
tion it is described how PortGroups with the category MODE_MANAGEMENT are
mapped to communication channels.
Identifiable
SystemMapping

«atpVariation»
0..*
+comManagementMapping +managedPhysicalChannel 0..*

Identifiable Identifiable
ComManagementMapping +physicalChannel PhysicalChannel

0..*

«instanceRef»
+comManagementPortGroup 0..* +comManagementGroup 0..*

AtpStructureElement FibexElement
Identifiable ISignalIPduGroup
PortGroup
+ communicationDirection: CommunicationDirectionType
+ communicationMode: String

+innerGroup 0..*

«instanceRef»

Figure 5.36: Mapping between PortGroups and communication channels

241 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class ComManagementMapping
Package M2::AUTOSARTemplates::SystemTemplate
Note Describes a mapping between one or several Mode Management PortGroups and communication
channels.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
com ISignalIPduGroup * ref IPduGroup participating in a Mode Management Port
Management Group.
Group
com PortGroup * iref Mode Management PortGroup to be mapped onto a
Management communication channel. This reference is optional in
PortGroup case that the System Description doesn’t use a complete
Software Component Description (VFB View). This
supports the inclusion of legacy systems.
InstanceRef implemented by:PortGroupInSystem
InstanceRef
physical PhysicalChannel * ref This reference maps the Mode Management PortGroup
Channel partial network to communication channels.

Table 5.46: ComManagementMapping

5.5 Software Cluster Mapping

[TPS_SYST_02348]{DRAFT} Mapping of CpSoftwareCluster to EcuInstance
dThe assignment of a concrete CpSoftwareCluster to an EcuInstance is done by
means of the meta-class CpSoftwareClusterToEcuInstanceMapping.c()

242 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

ARElement
AtpStructureElement
System

+ containerIPduHeaderByteOrder: ByteOrderEnum [0..1]

+ ecuExtractVersion: RevisionLabelString [0..1]
+ pncVectorLength: PositiveInteger [0..1]
+ pncVectorOffset: PositiveInteger [0..1]
+ systemVersion: RevisionLabelString

«atpVariation,atpSplitable»
+mapping 0..*
Identifiable
SystemMapping

«atpVariation,atpSplitable»
+swClusterMapping 0..*

Identifiable
CpSoftwareClusterToEcuInstanceMapping

+ecuInstance 0..1

FibexElement
EcuInstance

+ comConfigurationGwTimeBase: TimeValue [0..1]

+ comConfigurationRxTimeBase: TimeValue [0..1]
+ comConfigurationTxTimeBase: TimeValue [0..1]
+ comEnableMDTForCyclicTransmission: Boolean [0..1]
+ ethSwitchPortGroupDerivation: Boolean [0..1]
+ pncPrepareSleepTimer: TimeValue [0..1]
+ pncSynchronousWakeup: Boolean [0..1]
+ pnResetTime: TimeValue [0..1]
+ sleepModeSupported: Boolean
+ v2xSupported: V2xSupportEnum [0..1]
+ wakeUpOverBusSupported: Boolean

Figure 5.37: Modeling of the CpSoftwareClusterToEcuInstanceMapping

Class CpSoftwareClusterToEcuInstanceMapping
Package M2::AUTOSARTemplates::SystemTemplate::SoftwareCluster
Note This meta class maps a CpSoftwareCluster to a EcuInstance.
Tags:atp.Status=draft
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
ecuInstance EcuInstance 0..1 ref Reference to a specific ECU Instance description.
Tags:atp.Status=draft
swCluster CpSoftwareCluster * ref The mapped CP Software Cluster
Tags:atp.Status=draft

Table 5.47: CpSoftwareClusterToEcuInstanceMapping

[TPS_SYST_02347]{DRAFT} Mapping of CpSoftwareClusterResource to Ap-

plicationPartition dThe assignment of a concrete CpSoftwareClusterRe-
source to an ApplicationPartition is done by means of the meta-class Cp-
SoftwareClusterResourceToApplicationPartitionMapping.c()

243 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Identifiable ARElement
SystemMapping CpSoftwareClusterMappingSet

«atpVariation,atpSplitable» «atpVariation,atpSplitable»
+resourceToApplicationPartitionMapping 0..* +resourceToApplicationPartitionMapping 0..*

Identifiable
CpSoftwareClusterResourceToApplicationPartitionMapping

+resource 0..1 +applicationPartition 0..1

Identifiable ARElement
CpSoftwareClusterResource ApplicationPartition

+ globalResourceId: PositiveInteger [0..1]

+ isMandatory: Boolean [0..1]

Figure 5.38: Modeling of the CpSoftwareClusterResourceToApplicationParti-

tionMapping

Class CpSoftwareClusterResourceToApplicationPartitionMapping
Package M2::AUTOSARTemplates::SystemTemplate::SoftwareCluster
Note This meta class maps a Software Cluster resource to an Application Partition to restrict the usage.
Tags:atp.Status=draft
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
application ApplicationPartition 0..1 ref ApplicationPartition for which the mapping applies.
Partition
Tags:atp.Status=draft
resource CpSoftwareCluster 0..1 ref Software Cluster Resource for which the mapping applies.
Resource
Tags:atp.Status=draft

Table 5.48: CpSoftwareClusterResourceToApplicationPartitionMapping

Class CpSoftwareClusterMappingSet
Package M2::AUTOSARTemplates::SystemTemplate::SoftwareCluster
Note This meta-class represents the ability to aggregate a collection of CP Software Cluster relevant
mappings. This is applicable if a CP Software Cluster is described besides a concrete System, e.g. a
reusable CP Software Cluster.
Tags:
atp.Status=draft
atp.recommendedPackage=CpSoftwareClusterMappingSets
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
portElementTo PortElementTo * aggr maps a communication resource to CP Software Clusters
ComResource Communication
Stereotypes: atpSplitable; atpVariation
Mapping ResourceMapping
Tags:
atp.Splitkey=portElementToComResourceMapping.short
Name, portElementToComResourceMapping.variation
Point.shortLabel
atp.Status=draft
vh.latestBindingTime=postBuild
5

244 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class CpSoftwareClusterMappingSet
resourceTo CpSoftwareCluster * aggr Maps a Software Cluster resource to an Application
Application ResourceToApplication Partition to restrict the usage.
Partition PartitionMapping
Stereotypes: atpSplitable; atpVariation
Mapping
Tags:
atp.Splitkey=resourceToApplicationPartition
Mapping.shortName, resourceToApplicationPartition
Mapping.variationPoint.shortLabel
atp.Status=draft
vh.latestBindingTime=systemDesignTime
softwareCluster CpSoftwareClusterTo * aggr maps a service resource to CP Software Clusters
ToResource ResourceMapping
Stereotypes: atpSplitable; atpVariation
Mapping
Tags:
atp.Splitkey=softwareClusterToResourceMapping.short
Name, softwareClusterToResourceMapping.variation
Point.shortLabel
atp.Status=draft
vh.latestBindingTime=preCompileTime
swcTo SwcToApplication * aggr maps SwComponentPrototypes in a CP Software Cluster
Application PartitionMapping to ApplicationPartitions
Partition
Stereotypes: atpSplitable; atpVariation
Mapping
Tags:
atp.Splitkey=swcToApplicationPartitionMapping.short
Name, swcToApplicationPartitionMapping.variation
Point.shortLabel
vh.latestBindingTime=postBuild

Table 5.49: CpSoftwareClusterMappingSet

[constr_5219]{DRAFT} CpSoftwareCluster shall only be mapped to one

EcuInstance dWithin the context of one CpSoftwareCluster, for all CpSoft-
wareCluster.swComponentAssignment.swComponent (and nested instances of
SwComponentPrototypes) that are referenced by a SwcToEcuMapping in the role
component the following condition shall be be fulfilled: all referencing SwcToEcuMap-
pings shall refer to the same EcuInstance in the role ecuInstance and this
EcuInstance shall also be referenced in the role ecuInstance by all CpSoft-
wareClusterToEcuInstanceMappings that also refer to said CpSoftwareClus-
ter in the role swCluster.c()
The statement made by [constr_5219] is visualized by Figure 5.39.

245 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

ARElement
AtpStructureElement
System

+ containerIPduHeaderByteOrder: ByteOrderEnum [0..1]

+ ecuExtractVersion: RevisionLabelString [0..1]
+ pncVectorLength: PositiveInteger [0..1]
+ pncVectorOffset: PositiveInteger [0..1]
+ systemVersion: RevisionLabelString

«atpSplitable,atpVariation» «atpVariation,atpSplitable»
+swCluster 0..* +mapping 0..*
ARElement Identifiable
CpSoftwareCluster SystemMapping

+swCluster 0..*
«atpVariation,atpSplitable» «atpVariation»
+swClusterMapping 0..* +swMapping 0..*

Identifiable Identifiable
CpSoftwareClusterToEcuInstanceMapping SwcToEcuMapping

«atpVariation,atpSplitable» «instanceRef»

+ecuInstance 0..1 +ecuInstance 1 +component 1..*

FibexElement AtpPrototype
EcuInstance SwComponentPrototype

+ comConfigurationGwTimeBase: TimeValue [0..1]

+ comConfigurationRxTimeBase: TimeValue [0..1] +swComponent 0..1
+ comConfigurationTxTimeBase: TimeValue [0..1]
+ comEnableMDTForCyclicTransmission: Boolean [0..1]
+ ethSwitchPortGroupDerivation: Boolean [0..1]
+ pncPrepareSleepTimer: TimeValue [0..1]
+ pncSynchronousWakeup: Boolean [0..1]
+ pnResetTime: TimeValue [0..1]
+ sleepModeSupported: Boolean
+ v2xSupported: V2xSupportEnum [0..1] «instanceRef»
+ wakeUpOverBusSupported: Boolean

0..* +swComponentAssignment

SwComponentPrototypeAssignment

Figure 5.39: Visualization of constr_5219

246 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6 Communication
This chapter describes all topics that deal with constraints or configurations that de-
scribe the information exchange between the ECUs. The description of communica-
tion matrices in the System Template is based on the description in ASAM FIBEX [9].
Because of the requirements of AUTOSAR some extensions were made to the original
FIBEX model.
The main elements to describe communication in the System Template are System-
Signals, ISignals, Pdus and Frames, as it can be seen on Figure 6.1.
Frames can be defined independently of communication clusters. On the communica-
tion channel the Frame is represented by the referencing FrameTriggering.
A Frame has a payload section of a certain length in bytes, which contains an arbitrary
number of non-overlapping Pdus. In AUTOSAR only FlexRay supports the packing and
unpacking of multiple Pdus into/out of one FlexRay Frame. The AUTOSAR CanIf and
LinIf are not capable of packing multiple Pdus into one Frame.
[constr_3036] Pdus in CAN and LIN Frames dCAN Frames and LIN Frames shall
only contain one Pdu.c()
Note that via the ContainerIPdu it is possible to transport several IPdus in one
ContainerIPdu in order to support CAN FD.
A Pdu (Protocol Data Unit) is the information delivered through a network layer. For the
network to understand which layer is being discussed, a single-letter prefix is added to
the PDU.
• IPdu - Interaction Layer Protocol Data Unit (assembled and disassembled in
Com). In the case of external communication the Interaction Layer packs one or
more signals into assigned IPdus and passes them to the underlying layer for
transfer between nodes in a network.
• NPdu - Network Layer Protocol Data Unit (assembled and disassembled in a
Transport Protocol module). The TP module0 s main purpose is the segmentation
and reassembly of IPdus that do not fit in one of the assigned NPdus.
• LPdu - Data Link Layer Protocol Data Unit (assembled and disassembled in
AUTOSAR Hardware Abstraction layer). The element Frame in the System Tem-
plate represents the AUTOSAR Layered Architectures LSdu. Sdu is the abbre-
viation of "Service Data Unit". The Data Link Layers LPdu contains the LSdu
and PCI (Protocol Control Information). The LPdu is not described in the System
Template.

247 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Application Layer
ARElement ARElement
SystemSignal +systemSignal SystemSignalGroup
*

+systemSignal 1 +systemSignalGroup 1

0..1
+iSignalGroup 0..1

Identifiable NmPdu GeneralPurposePdu IPdu UserDefinedPdu

ISignalToIPduMapping

+iSignalToIPduMapping 0..* +iSignalToPduMapping 0..*

«atpVariation»

ISignalIPdu DcmIPdu MultiplexedIPdu

FibexElement +iSignalIPdu
ISignalIPduGroup
«atpVariation» 0..*

J1939DcmIPdu NPdu UserDefinedIPdu

+containedISignalIPduGroup
0..*

Describable +iPduTimingSpecification
IPduTiming GeneralPurposeIPdu
0..1 «atpVariation»

Data Link Layer

Identifiable
«atpPrototype»
PduToFrameMapping
+pduToFrameMapping 0..*
«atpVariation»

FibexElement
Frame

Identifiable +frame 1
ISignalTriggering

+iSignalTriggering Identifiable +pduTriggering Identifiable

PduTriggering FrameTriggering
0..* «atpVariation» 0..* «atpVariation»

+iSignalTriggering 0..* +pduTriggering 0..* +frameTriggering 0..*

«atpVariation,atpSplitable» «atpVariation,atpSplitable» «atpVariation,atpSplitable»

+managedPhysicalChannel
Identifiable
0..*
PhysicalChannel

Figure 6.1: Communication Overview (FibexCore: Communication)

In case no multiplexing is performed the IPdus of Com that fit into one frame can be
passed directly via the PDU Router to the communication interfaces.
[constr_3037] maximum Frame frameLength for CAN and LIN dFor CAN and LIN
the maximum frameLength is 8 bytes and 64 bytes in case of CAN FD.c()
[constr_3038] maximum Frame frameLength for FlexRay dFor FlexRay the maxi-
mum frameLength is 254 bytes.c()

248 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_01048] Handling of large IPdus dLarge IPdus that are too long to
fit into one Frame of the respective subclass of CommunicationCluster shall be
routed via a Transport Protocol to the communication interfaces.c()
For example an IPdu with the length of 10 bytes needs to be routed via a Transport
Protocol on CAN but on FlexRay this is not required.
The Transport Protocols are described in more detail in chapter 6.8.
If multiplexing is performed an IPdu is routed between the IPdu Multiplexer and the
Interface Layer or Transport Layer. To distinguish these two different cases two spe-
cializations ISignalIPdu and MultiplexedIPdu are introduced. A ISignalIPdu
represents an IPdu handled by AUTOSAR Com. The AUTOSAR IPduM is responsible
to combine Com ISignalIPdus to MultiplexedIPdus. On receiver-side the IPduM
is responsible to interpret the content of MultiplexedIPdus and provide Com sepa-
rated ISignalIPdus by taking into account the value of the selector field. The IPdu
Multiplexer is described in more detail in chapter 6.5.
AUTOSAR Com provides the possibility to define Transmission Modes for each Com
ISignalIPdu. For this reason the ISignalIPdu aggregates the IPduTiming. The
Transmission Modes are described in more detail in chapter 6.4.

6.1 Triggerings and Ports

The elements FrameTriggering, PduTriggering and ISignalTriggering are
describing the usage of Frames, IPdus and ISignals on a PhysicalChannel.
A FrameTriggering need to fulfill requirements for contained Pdus that are defined
by the corresponding PduTriggerings. And the PduTriggering need to fulfill re-
quirements for contained ISignals that are defined by the corresponding ISignal-
Triggerings. The references between the Triggering elements can be used to de-
scribe these relationships. More details can be found in class tables of FrameTrig-
gering, PduTriggering and ISignalTriggering.
In AUTOSAR the timing of bus messages can be controlled by send requests of the
Application layer in combination with the Com Transmission Modes and Transfer Prop-
erties (esp. CAN). On the other hand it can be controlled by the FlexRay or LIN Inter-
face. In this case the Bus Interface only requests IPdus that have to be provided by
Com.
In the System Template the Com controlled timing is described with the aggregation
between the ISignalIPdu and the IPduTiming. The LIN and FlexRay Scheduling
Tables are described in the FrameTriggering.
Timing requirements for FlexRay, TTCAN and LIN Pdus can be specified with the Tim-
ing Extension model. More details are described in chapter 1.7.3.

249 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

+managedPhysicalChannel 0..*

CommunicationConnector +commConnector PhysicalChannel

+ createEcuWakeupSource: Boolean [0..1]

0..*«atpVariation»
+ dynamicPncToChannelMappingEnabled: Boolean [0..1]
+ pncFilterArrayMask: PositiveInteger [0..*] {ordered}
+ pncGatewayType: PncGatewayTypeEnum [0..1]

«atpVariation»
+ecuCommPortInstance 0..*

CommConnectorPort

+ communicationDirection: CommunicationDirectionType
«atpVariation,atpSplitable»

+iSignalTriggering
«atpVariation,atpSplitable»

0..*

ISignalPort
ISignalTriggering «atpVariation,atpSplitable»
+iSignalPort
+ firstTimeout: TimeValue [0..1]
+ handleInvalid: HandleInvalidEnum [0..1] *
+ timeout: TimeValue [0..1]

+iSignalTriggering
0..*
+pduTriggering 0..*
IPduPort

+ iPduSignalProcessing: IPduSignalProcessingEnum [0..1] PduTriggering

+ rxSecurityVerification: Boolean [0..1]
+ timestampRxAcceptanceWindow: TimeValue [0..1] «atpVariation»
+iPduPort
+ useAuthDataFreshness: Boolean [0..1]
*
+pduTriggering 0..* +frameTriggering 0..*
+dataFilter 0..1
«atpVariation»
DataFilter FramePort FrameTriggering

+ dataFilterType: DataFilterTypeEnum [0..1] +framePort

+ mask: UnlimitedInteger [0..1]
+ max: UnlimitedInteger [0..1] *
+ min: UnlimitedInteger [0..1]
+ offset: PositiveInteger [0..1]
+ period: PositiveInteger [0..1]
+ x: UnlimitedInteger [0..1]

«enumeration» «enumeration»
IPduSignalProcessingEnum CommunicationDirectionType
deferred in
immediate out

Figure 6.2: Communication Matrix (FibexCore: CommunicationMatrix)

Figure 6.2 shows the relationship between the CommConnectorPort and the
FrameTriggering, PduTriggering and ISignalTriggering. This relationship
allows to specify explicitly which Frames, Pdus, ISignals are received/sent by the
connected ECU on the connected channel.
[constr_3243] FrameTriggering.pduTriggering condition dA FrameTrigger-
ing shall reference a PduTriggering if the PduTriggering references a Pdu that
is referenced by a PduToFrameMapping which in turn is aggregated by the Frame
that is referenced by that FrameTriggering.c()
[constr_3250] PduTriggering.iSignalTriggering condition dA PduTrigger-
ing shall reference an ISignalTriggering if the ISignalTriggering references
an ISignal or an ISignalGroup that is referenced by an ISignalToIPduMap-
ping which in turn is aggregated by the Pdu that is referenced by that PduTrigger-
ing.c()

250 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_02102] FrameTriggering.pduTriggering references that shall be

ignored dReferences from FrameTriggering to PduTriggering which are not
covered by [constr_3243] shall be ignored.c()
As a consequence of [constr_3243] the following implications can be derived:
• The PduTriggering of the ContainerIPdu is referenced from the
FrameTriggering but the PduTriggerings of the contained IPdus are not
referenced from the FrameTriggering.
• The PduTriggering of the MultiplexedIPdu is referenced from the
FrameTriggering but the PduTriggerings of the multiplexed Part Pdus are
not referenced from the FrameTriggering.
[TPS_SYST_02104] Triggerings on PhysicalChannel dThe following modeling
creates a "membership" of ISignals, ISignalGroups, Pdus, and Frames in a given
PhysicalChannel:
• PhysicalChannel aggregates
– ISignalTriggering that in turn references ISignal in the role iSignal
– ISignalTriggering that in turn references an ISignalGroup in the role
iSignalGroup ([constr_5106] applies).
• PhysicalChannel aggregates PduTriggering that in turn references a Pdu
in the role iPdu.
• PhysicalChannel aggregates FrameTriggering that in turn references a
Frame in the role frame.
c()
[constr_5106] ISignalGroup and ISignal referenced from ISignalTrigger-
ing dEither an ISignalGroup and all ISignals referenced from the ISignal-
Group are also referenced from ISignalTriggerings aggregated at the same
PhysicalChannel or neither the ISignalGroup nor any of the ISignals refer-
enced by the ISignalGroup shall be referenced from ISignalTriggerings.c()
[TPS_SYST_01142] Rules for the creation of references to Ports (ecuComm-
PortInstance) with communicationDirection out on sending Ecu d
• Application sends ISignal or ISignalGroup
– Reference from ISignalTriggering to ISignalPort shall be created
for an ISignal that is not part of an ISignalGroup
– Reference from ISignalTriggering to ISignalPort shall be created
for the ISignalGroup
– Reference from ISignalTriggering to ISignalPort shall be created
for the ISignalGroup members that are sent by the Application.
– PduTriggering reference to IPduPort shall be created

251 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

– FrameTriggering reference to FramePort shall be created

• COM Signal Gateway
– Reference from ISignalTriggering to ISignalPort shall be created
for an ISignal that is not part of an ISignalGroup
– Reference from ISignalTriggering to ISignalPort shall be created
for the ISignalGroup
– Reference from ISignalTriggering to ISignalPort for a subset of
ISignals inside the ISignalGroup shall be created (in case not all mem-
bers of the ISignalGroup participate in the target Signal Gateway rela-
tion).
– PduTriggering reference to IPduPort shall be created
– FrameTriggering reference to FramePort shall be created
• ISignal or ISignalGroup is mapped to ISignalIPdu but NOT sent by Ap-
plication or Signal Gateway
– No ISignalTriggering reference to ISignalPort shall be created for
an ISignal that is not part of an ISignalGroup
– No ISignalTriggering reference to ISignalPort shall be created for
an ISignalGroup
– No ISignalTriggering reference to ISignalPort shall be created for
any ISignal that is part of an ISignalGroup
– PduTriggering reference to IPduPort shall be created
– FrameTriggering reference to FramePort shall be created
• Neither ISignal, ISignalGroup, Pdu, nor Frame sent by the ECU
– No ISignalTriggering reference to ISignalPort shall be created for
an ISignal that is not part of an ISignalGroup
– No ISignalTriggering reference to ISignalPort shall be created for
an ISignalGroup
– No ISignalTriggering reference to ISignalPort shall be created for
any ISignal that is part of an ISignalGroup
– No PduTriggering reference to IPduPort shall be created
– No FrameTriggering reference to FramePort shall be created
c()
Please note that it is possible to configure a signal that is transmitted by an application
and also routed by a SignalGateway. At runtime it has to be ensured that only one path
is active at a particular point in time (to avoid race conditions in COM Stack).

252 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_02106] Rules for the creation of references to Ports (ecuComm-

PortInstance) with communicationDirection in on receiving Ecu d
• Application receives ISignal or ISignalGroup
– Reference from ISignalTriggering to ISignalPort shall be created
for an ISignal that is not part of an ISignalGroup
– Reference from ISignalTriggering to ISignalPort shall be created
for the ISignalGroup
– Reference from ISignalTriggering to ISignalPort shall be created
for the ISignalGroup members that are received by the Application.
– PduTriggering reference to IPduPort shall be created
– FrameTriggering reference to FramePort shall be created
• COM Signal Gateway
– Reference from ISignalTriggering to ISignalPort shall be created
for an ISignal that is not part of an ISignalGroup
– Reference from ISignalTriggering to ISignalPort shall be created
for the ISignalGroup
– Reference from ISignalTriggering to ISignalPort for a subset of
ISignals inside the ISignalGroup shall be created (in case not all mem-
bers of the ISignalGroup participate in the source Signal Gateway rela-
tion).
– PduTriggering reference to IPduPort shall be created
– FrameTriggering reference to FramePort shall be created
• ISignal or ISignalGroup is mapped to ISignalIPdu but NOT received by
Application or Signal Gateway
– No ISignalTriggering reference to ISignalPort shall be created for
an ISignal that is not part of an ISignalGroup
– No ISignalTriggering reference to ISignalPort shall be created for
an ISignalGroup
– No ISignalTriggering reference to ISignalPort shall be created for
any ISignal that is part of an ISignalGroup
– PduTriggering reference to IPduPort shall be created
– FrameTriggering reference to FramePort shall be created
• Neither ISignal, ISignalGroup, Pdu, nor Frame received by the ECU
– No ISignalTriggering reference to ISignalPort shall be created for
an ISignal that is not part of an ISignalGroup

253 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

– No ISignalTriggering reference to ISignalPort shall be created for

an ISignalGroup
– No ISignalTriggering reference to ISignalPort shall be created for
any ISignal that is part of an ISignalGroup
– No PduTriggering reference to IPduPort shall be created
– No FrameTriggering reference to FramePort shall be created
c()
[constr_3252] ISignalTriggering.iSignalPort reference condition dAn
ISignalTriggering shall only reference an ISignalPort if the Communica-
tionConnector aggregating that ISignalPort is referenced by the Physi-
calChannel which in turn aggregates that ISignalTriggering.c()
[constr_3253] PduTriggering.iPduPort reference condition dA PduTrigger-
ing shall only reference an IPduPort if the CommunicationConnector aggregat-
ing that IPduPort is referenced by the PhysicalChannel which in turn aggregates
that PduTriggering.c()
[constr_3254] FrameTriggering.framePort reference condition dA
FrameTriggering shall only reference a FramePort if the Communication-
Connector aggregating that FramePort is referenced by the PhysicalChannel
which in turn aggregates that FrameTriggering.c()
[constr_3255] FrameTriggering.pduTriggering reference condition with re-
gard to the PhysicalChannel dA FrameTriggering shall only reference a
PduTriggering in the role pduTriggering if both the FrameTriggering and
PduTriggering are aggregated by the same PhysicalChannel.c()
[constr_3256] PduTriggering.iSignalTriggering reference condition with
regard to the PhysicalChannel dA PduTriggering shall only reference an
ISignalTriggering in the role iSignalTriggering if both the PduTrigger-
ing and ISignalTriggering are aggregated by the same PhysicalChannel.c
()
The following rules apply for the creation of PduTriggerings and IPduPorts:
• [TPS_SYST_01052] Routing of UserDefinedPdus, NmPdus, NPdus d
UserDefinedPdus, NmPdus, NPdus which are not going through the Pdu
Router get their triggering information via the containing FrameTriggering and
FramePort (no PduTriggering is defined for these Pdus).c()
• [TPS_SYST_03021] Routing of GeneralPurposePdus with category
GLOBAL_TIME dGeneralPurposePdus with category GLOBAL_TIME shall
have PduTriggering and IPduPorts defined.c()

254 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• [TPS_SYST_02091] Routing of GeneralPurposePdus with category SD and

GeneralPurposePdus with category DoIP dGeneralPurposePdus with cat-
egory SD and GeneralPurposePdus with category DoIP shall have PduTrig-
gering and IPduPorts defined since no Frames and FrameTriggerings are
defined for Pdus that are handled by the SoAd.c()
• [TPS_SYST_01053] Low-level routing of NPdus dIn case of a low-level rout-
ing of NPdus the Pdus are handled like IPdus and the PduTriggering and
IPduPort shall be defined.c()
• [TPS_SYST_01138] Low-level routing of XcpPdus dLow-level routing of Gen-
eralPurposeIPdus with category XCP: In case of a low-level routing of Gen-
eralPurposeIPdus with category XCP the Pdus are handled like IPdus and
the PduTriggering and IPduPort shall be defined.c()
• [TPS_SYST_01054] Routing of DcmIPdus dDcmIPdus shall have PduTrig-
gering and IPduPorts since they are handled by the PduR (connection to the
Dcm and/or DcmIPdu-routing).c()
• [TPS_SYST_01055] Routing of ISignalIPdus that are part of a Multi-
plexedIPdu dISignalIPdus that are part of a MultiplexedIPdu (static or
dynamic) and are also handled by the Com module shall have a PduTrigger-
ing and IPduPorts since they are handled by the PduR (and Com). Especially
it is allowed to ignore certain received parts of a MultiplexedIPdu in a specific
ECU.c()
• [TPS_SYST_01056] Routing of ISignalIPdus, UserDefinedIPdus,
MultiplexedIPdus, GeneralPurposeIPdus, ContainerIPdus dISig-
nalIPdus (not part of MultiplexedIPdus), UserDefinedIPdus, Multi-
plexedIPdus, GeneralPurposeIPdus and ContainerIPdus shall have a
PduTriggering and IPduPort if they are handled by the PduR. Especially it
is allowed to ignore a certain IPdu out of a Flexray frame if it is not considered in
a specific ECU.c(RS_SYST_00055)
• [TPS_SYST_01057] Routing of NmPdus dIf an NmPdu contains user data de-
fined via the existence of NmPdu.iSignalToIPduMapping and is consequently
handled via the PduR and Com the NmPdu shall also be referenced by a corre-
sponding PduTriggering where attribute iPduPort exists accordingly.c()
• [TPS_SYST_02059] Routing of SecuredIPdus dSecuredIPdus shall have a
PduTriggering and IPduPort defined since they are handled by the PduR.
Pdus that are part of a SecuredIPdu and are also handled by the Com module
shall have a PduTriggering and IPduPorts since they are handled by the
PduR (and Com).c(RS_SYST_00054)
• [TPS_SYST_02061] Routing of IPdus that are part of a ContainerIPdu d
IPdus that are part of a ContainerIPdu shall have a PduTriggering and
IPduPorts since they are handled by the PduR.c(RS_SYST_00055)
The following rule applies to the creation of ISignalTriggering and ISignalPort:

255 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_01058] Pdu Gateway where an Ecu only routes a PduTriggering

without being interested in the content dIn case of a Pdu Gateway where an Ecu
only routes a PduTriggering without being interested in the content, the reference
between the ISignalTriggerings (that are referred to by the PduTriggering in
the role iSignalTriggering) and the respective ISignalPorts shall not be cre-
ated.c()

RTE

Signals

Diagnostic
AUTOSAR Communi-
IPDU multiplexer CDD
COM cation
Manager
MULTIPLEXED- CONTAINER-
I-SIGNAL-I-PDU I-SIGNAL-I-PDU DCM-I-PDU USER-DEFINED-I-PDU
I-PDU I-PDU
I-SIGNAL-I-PDU

SecOC
PDU Router SECURED-I-PDU
UserData NM-PDU
NM
NM
Module
NM
Module
NM
I-PDU Module
I-PDU I-PDU I-PDU I-PDU I-PDU I-PDU Module
CAN Tp
FlexRay Tp J1939Tp CDD

N-PDU N-PDU USER-DEFINED-PDU

N-PDU

NM-PDU NM-PDU NM-PDU Communication

HW
FlexRay Interface LIN Interface
CAN Interface Abstraction
(incl. LIN TP)
L-PDU L-PDU L-PDU

Communication Drivers

FlexRay Driver CAN Driver LIN Low Level Driver

Figure 6.3: AUTOSAR Layered Architecture

Class CommConnectorPort (abstract)

Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreTopology
Note The Ecu communication relationship defines which signals, Pdus and frames are actually received and
transmitted by this ECU.
For each signal, Pdu or Frame that is transmitted or received and used by the Ecu an association
between an ISignalPort, IPduPort or FramePort with the corresponding Triggering shall be created. An
ISignalPort shall be created only if the corresponding signal is handled by COM (RTE or Signal
Gateway). If a Pdu Gateway ECU only routes the Pdu without being interested in the content only a
FramePort and an IPduPort needs to be created.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Subclasses FramePort, IPduPort, ISignalPort
Attribute Type Mult. Kind Note
communication Communication 1 attr Communication Direction of the Connector Port (input or
Direction DirectionType output Port).

Table 6.1: CommConnectorPort

256 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class FramePort
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note Connectors reception or send port on the referenced channel referenced by a FrameTriggering.
Base ARObject, CommConnectorPort, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
– – – – –
Table 6.2: FramePort

Class IPduPort
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note Connectors reception or send port on the referenced channel referenced by a PduTriggering.
Base ARObject, CommConnectorPort, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
iPduSignal IPduSignalProcessing 0..1 attr Definition of the two signal processing modes Immediate
Processing Enum and Deferred for both Tx and Rx IPdus.
rxSecurity Boolean 0..1 attr This attribute defines the bypassing of signature
Verification authentication or MAC verification in the receiving ECU. If
not defined or set to true the signature authentication or
MAC verification shall be performed for the SecuredIPdu.
If set to false the signature authentication or MAC
verification shall not be performed for the SecuredIPdu.
timestampRx TimeValue 0..1 attr This attribute is used to define the maximum allowed
Acceptance deviation in seconds from the expected timestamp for
Window which a SecuredIPdu is still deemed authentic. Please
note that this attribute is for documentation only to allow
the configuration of required freshness value manager
and no upstream mapping is defined for it.
useAuthData Boolean 0..1 attr This attribute describes whether a part of AuthenticPdu
Freshness contained in a SecuredIPdu shall be passed on to the
SWC that verifies and generates the Freshness. The part
of the Authentic-PDU is defined by the authData
FreshnessStartPosition and authDataFreshnessLength.

Table 6.3: IPduPort

[constr_3137] IPduPort.rxSecurityVerification is configurable on the re-

ceiver side dThe IPduPort.rxSecurityVerification attribute shall only be used
in IPduPorts with the communicationDirection = in.c()
[constr_3138] IPduPort.rxSecurityVerification validness dThe IPduPort.
rxSecurityVerification information is only valid for SecuredIPdus.c()
[constr_3337] IPduPort.useAuthDataFreshness is configurable on the re-
ceiver side dThe IPduPort.useAuthDataFreshness attribute shall only be used
in IPduPorts with the communicationDirection = in.c()
[constr_3338] IPduPort.useAuthDataFreshness validness dThe IPduPort.
useAuthDataFreshness information is only valid for SecuredIPdus.c()

257 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Enumeration IPduSignalProcessingEnum
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note Definition of signal processing modes.
Literal Description
deferred The signal indications / confirmations are deferred.
Tags:atp.EnumerationLiteralIndex=0
immediate The signal indications / confirmations are performed.
Tags:atp.EnumerationLiteralIndex=1

Table 6.4: IPduSignalProcessingEnum

Class ISignalPort
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note Connectors reception or send port on the referenced channel referenced by an ISignalTriggering. If
different timeouts or DataFilters for ISignals need to be specified several ISignalPorts may be created.
Base ARObject, CommConnectorPort, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
dataFilter DataFilter 0..1 aggr Optional specification of a signal COM filter at the
receiver side in case that the System Description doesn’t
use a complete Software Component Description (VFB
View). This supports the inclusion of legacy system
signals. If a full DataMapping exist for the SystemSignal
this information may be available from a configured
ReceiverComSpec. In this case the ReceiverComSpec
overrides this optional specification.
firstTimeout TimeValue 0..1 attr • ISignalPort with communicationDirection = in:
Optional first timeout value in seconds for the reception of
the ISignal.
• ISignalPort with communicationDirection = out:
Optional first timeout value in seconds for transmission
deadline monitoring.
handleInvalid HandleInvalidEnum 0..1 attr This attribute defines how invalidation is applied to the
ISignals received in the context of this ISignalPort.
timeout TimeValue 0..1 attr • ISignalPort with communicationDirection = in:
Optional timeout value in seconds for the reception of the
ISignal. The attribute value is used to configure the Com
Timeout in the COM module. The RTE ignores this
attribute. The timeout can also be specified with the
NonqueuedReceiverComSpec.aliveTimeout attribute. If a
full DataMapping exists for the SystemSignal and the
value is available in the configured ReceiverComSpec,
then the timeout value in the ReceiverComSpec overrides
this optional timeout specification during the creation of
the Base Ecu Configuration of the COM module.
• ISignalPort with communicationDirection = out:
Optional timeout value in seconds for the transmission of
the ISignal. The attribute value is used to configure the
ComTimeout in the COM module. The RTE ignores this
attribute. The timeout can also be specified with the ender
ComSpec.transmissionAcknowledge.timeout attribute. If
a full DataMapping exists for the SystemSignal and the
value is available in the configured SenderComSpec, then
the timeout value in the SenderComSpec overrides this
5

258 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class ISignalPort
4
optional timeout specification during the creation of the
Base Ecu Configuration of the COM module.
This attribute can be used in the following cases:
• legacy signal where the System Description
doesn’t use a complete Software Component
Description (VFB View) and where the Data
Mapping is missing.
• bus monitoring use cases in which the Data
Mapping is ignored.

Table 6.5: ISignalPort

Enumeration HandleInvalidEnum
Package M2::AUTOSARTemplates::SWComponentTemplate::Communication
Note Strategies of handling the reception of invalidValue.
Literal Description
dontInvalidate Invalidation is switched off.
Tags:atp.EnumerationLiteralIndex=0
external Replace a received invalidValue. The replacement value is sourced from the externalReplacement.
Replacement
Tags:atp.EnumerationLiteralIndex=1
keep The application software is supposed to handle signal invalidation on RTE API level either by Data
ReceiveErrorEvent or check of error code on read access.
Tags:atp.EnumerationLiteralIndex=2
replace Replace a received invalidValue. The replacement value is specified by the initValue.
Tags:atp.EnumerationLiteralIndex=3

Table 6.6: HandleInvalidEnum

[TPS_SYST_01059] Relationship between FrameTriggering and CommConnec-

torPort dFor the reference between FrameTriggering and FramePort two ap-
proaches are supported:
• One to One relationship between FrameTriggering and FramePort per
EcuInstance
• One FramePort per communicationDirection per EcuInstance exists
and is referenced by all applicable FrameTriggerings (n to 1).
c()
[TPS_SYST_01060] Relationship between PduTriggering and CommConnec-
torPort dFor the reference between PduTriggering and IPduPort two ap-
proaches are supported:
• One to One relationship between PduTriggering and IPduPort per EcuIn-
stance
• One IPduPort per communicationDirection per EcuInstance exists and
is referenced by all applicable PduTriggerings (n to 1).

259 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

c()
[TPS_SYST_01061] Relationship between ISignalTriggering and CommCon-
nectorPort dFor the reference between ISignalTriggering and ISignalPort
two approaches are supported:
• One to One relationship between ISignalTriggering and ISignalPort per
EcuInstance
• One ISignalPort per communicationDirection per timeout per EcuIn-
stance exists and is referenced by all applicable PduTriggerings (n to 1).
c()
[TPS_SYST_02208] ISignalPort.handleInvalid defines the reception invali-
dation behavior dThe attribute ISignalPort.handleInvalid defines the behavior
during signal reception if the respective ISignal’s invalidValue is received. The
ISignal is assigned to this ISignalPort via the ISignalTriggering.c()
[TPS_SYST_02209] Not defined ISignalPort.handleInvalid behavior dIf the
attribute ISignalPort.handleInvalid is not defined then the value dontInval-
idate shall be assumed.c()
[constr_5053] Existence of ISignalPort.handleInvalid dIf the ISignalPort
has a networkRepresentationProps.invalidValue defined then the ISignal-
Port.communicationDirection shall equal in.c()
[constr_5054] externalReplacement not applicable for ISignalPort.han-
dleInvalid dIn the context of ISignalPort.handleInvalid the value exter-
nalReplacement shall not be used.c()
The action externalReplacement can only be implemented by the RTE. Thus it is
required to have a ComSpec definition.
[TPS_SYST_02210] Data invalidation in case the dataTypePolicy is set to
override or legacy dIf the dataTypePolicy of an ISignal is set to override or
legacy, the ISignalPort.handleInvalid attribute defines the data invalidation.c
()

260 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.2 ISignals
SystemSignals can be defined independently of CommunicationClusters and
are representing the VariableDataPrototypes, ArgumentDataPrototypes,
Triggers and ModeDeclarationGroupPrototypes in the communication de-
scription.
The RTE supports a "signal fan-out" where the same signal (System Signal) is sent
in different IPdus to multiple receivers. The Pdu Router supports the "PDU fan-out"
where the same IPdu is sent to multiple destinations.
To support the "signal fan-out" ISignals and ISignalGroups are introduced. An
ISignal(ISignalGroup) represents the SystemSignal(SystemSignalGroup) of
the Interaction Layer.
In case of "signal fan-out", several ISignals in different IPdus refer to the same
SystemSignal. The "Signal fan-out" will be executed by the RTE. ISignals describe
the Interface between the precompile configured RTE and the potentially postbuild
configured Com Stack.
The ISignalToIPduMapping element describes the mapping of ISignals to
ISignalIPdus and defines the position of an ISignal within an ISignalIPdu.
[constr_3009] Overlapping of ISignals is prohibited dISignals mapped to an
ISignalIPdu shall not overlap.c()
[constr_5253] Value range of ISignal.length dThe value of ISignal.length
shall be in the range of 0..34359738360 Bits.c()
[constr_3010] ISignalIPdu length shall not be exceeded dThe combined length
of all ISignals and updateIndicationBitPositions that are mapped into an
ISignalIPdu shall not exceed the defined Pdu length.c()
[constr_3011] Overlapping of updateIndicationBits of ISignals is prohib-
ited dThe updateIndicationBitPosition for an ISignal in an ISignalIPdu
shall not overlap with other updateIndicationBitPositions or ISignal loca-
tions.c()
[TPS_SYST_01062] Network representation of an ISignal dWith the aggregation
of SwDataDefProps in the role networkRepresentationProps the actual repre-
sentation of the ISignal on the network can be specified.c(RS_SYST_00047)
[TPS_SYST_01063] Context of network representation of an ISignal dThe
dataTypePolicy defines from which context the network representation specifica-
tion shall be taken.c(RS_SYST_00001, RS_SYST_00047)
For an alternative network representation it is important to define an alternative Sw-
DataDefProps especially SwBaseType defining alternative encoding (e.g. from float
in PortInterface to integer on bus).

261 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_3060] Usage of networkRepresentationProps and physicalProps

dUsage of networkRepresentationProps and physicalProps shall follow the
restrictions given in table 6.7.c()
Attributes of SwDataDefProps SystemSignal.physicalProps ISignal.networkProps
additionalNativeTypeQualifier NA NA
annotation NA NA
baseType NA D
baseType.category NA M
BaseTypeDirectDefinition.baseTypeEncoding NA D
BaseTypeDirectDefinition.byteOrder NA NA
BaseTypeDirectDefinition.baseTypeSize NA 0..1
BaseTypeDirectDefinition.memAlignment NA NA
BaseTypeDirectDefinition.nativeDeclaration NA NA
compuMethod D I
dataConstr D M
displayFormat D M
implementationDataType NA NA
invalidValue NA D
stepSize NA NA
swAddrMethod NA NA
swAlignment NA NA
swBitRepresentation NA NA
swCalibrationAccess NA NA
swCalprmAxisSet NA NA
swComparisonVariable NA NA
swDataDependency NA NA
swHostVariable NA NA
swImplPolicy NA NA
swIntendedResolution NA NA
swInterpolationMethod NA NA
swIsVirtual NA NA
swPointerTargetProps NA NA
swRecordLayout NA NA
swRefreshTiming NA NA
swTextProps NA NA
swValueBlockSize NA NA
unit D M
valueAxisDataType NA NA

Table 6.7: Allowed SwDataDefProps Attributes for the ISignal and SystemSignal

The following settings apply in table 6.7:

D Define the attribute independent from settings to the left.
I Inherit the definition from the left for usage in the scope of this element. This means
that the information is taken over in the respective context without further ARXML
configuration. The attribute of the SwDataDefProps shall not exist on the right
side.

262 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

NA Attribute is not applicable for usage in the scope of this element.

M Attribute is meaningless in the scope of this element. As it was allowed in previous
versions, declaring it as Not Applicable (NA) would break compatibility. Tools
shall ignore such an attribute without a warning.
In case that the System Description doesn’t use a complete Software Component De-
scription (VFB View) the physicalProps and networkRepresentationProps are
used to configure the Data Semantics.
The networkRepresentationProps contains a reference to the SwBaseType.
This reference can be used for the derivation of the ComSignalType in the AUTOSAR
Com Configuration.
Please note that a DataTransformation that is based on the network represen-
tation is explained in more detail in chapter 7.3.2.3.1. This chapter also contains an
explanation that describes a data conversion based on CompuMethods (see section
7.3.2.3.1.1 for more details).
[TPS_SYST_02001] networkRepresentationProps are mandatory in case the
dataTypePolicy is set to override or legacy dIf the dataTypePolicy of an
ISignal is set to override or legacy, the networkRepresentationProps for
the respective ISignal have to be specified.c()
[TPS_SYST_02006] Usage of networkRepresentationFromComSpec dIf the
networkRepresentationFromComSpec is used either the SwDataDefProps in
the role networkRepresentation aggregated by the SenderComSpec or Re-
ceiverComSpec shall exist or the ImplementationDataType shall exist.c()
Please note that some categorys of CompuMethod cannot be successfully converted
to A2L [21] because A2L does not provide an equivalent semantics that comes close
to the respective AUTOSAR semantics.
A prominent example for such a case is a CompuMethod of category
SCALE_LINEAR_AND_TEXTTABLE that actually has more than one linear interval and
a texttable part.
[TPS_SYST_02079] Identification of ImplementationDataType for a given
ISignal in an Ecu Extract d
1. From the ISignal go to the referenced SystemSignal
2. Find all DataMappings that refer to the SystemSignal
3. For all VariableDataPrototypes referenced by the applicable DataMap-
pings
(a) If the VariableDataPrototype is typed by an ApplicationDataType
and belongs to a CompositionSwComponentType then for all
DataTypeMappingSets referenced by the CompositionSwComponent-
Type find the DataTypeMap that refers to this ApplicationDataType.
The DataTypeMap also refers to the wanted ImplementationDataType.

263 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

(b) If the VariableDataPrototype is typed by an ApplicationDataType

and belongs to an AtomicSwComponentType then for all DataTypeMap-
pingSets referenced by the InternalBehavior of the AtomicSwCom-
ponentType find the DataTypeMap that refers to this Application-
DataType. The DataTypeMap also refers to the wanted Implementa-
tionDataType.
(c) If the VariableDataPrototype is typed by an Implementation-
DataType then the ImplementationDataType is the wanted one.
c()
[TPS_SYST_02076] networkRepresentationProps in case the dataTypePol-
icy is set to transformingISignal dIf the value of ISignal.dataTypePolicy
is set to transformingISignal then ISignal.networkRepresentationProps
shall be ignored.c()
[constr_3199] ISignal that has dataTypePolicy set to transformingISig-
nal shall reference a DataTransformation dIn a complete model every ISignal
that has dataTypePolicy set to transformingISignal shall reference a Data-
Transformation.c()
[TPS_SYST_01065] Mapping onto the ComSignalType enumeration dThe map-
ping of baseTypeSize, baseTypeEncoding, ISignal.iSignalType and Sys-
temSignal.dynamicLength onto the ComSignalType enumeration is described in
Table 6.8.c(RS_SYST_00029)
In other words Table 6.8 focuses only on the derivation of the ComSignalType. This
table shall not be taken as a source to derive requirements on the modeling of SwBase-
Types used on the level of the RTE.

264 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

SystemSig-
ISignal.
BaseTypeEncod- nal.
BaseTypeSize iSignal- ComSignalType
ing dynami-
Type
cLength
SINT8, ComBit-
2C 8 Bits primitive not applicable Size derived from
ISignal.length
SINT8 if ISig-
nal.length <=
2C not available primitive not applicable 8. ComBitSize de-
rived from ISig-
nal.length
SINT16, ComBit-
2C 16 Bits primitive not applicable Size derived from
ISignal.length
SINT16 if ISig-
nal.length > 8
and <= 16. Com-
2C not available primitive not applicable
BitSize derived
from ISignal.
length
SINT32, ComBit-
2C 32 Bits primitive not applicable Size derived from
ISignal.length
SINT32 if ISig-
nal.length > 16
and <= 32. Com-
2C not available primitive not applicable
BitSize derived
from ISignal.
length
SINT64, ComBit-
2C 64 Bits primitive not applicable Size derived from
ISignal.length
SINT64 if ISig-
nal.length > 32
and <= 64. Com-
2C not available primitive not applicable
BitSize derived
from ISignal.
length
UINT8, ComBit-
NONE 8 Bits primitive not applicable Size derived from
ISignal.length
5

265 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
SystemSig-
ISignal.
BaseTypeEncod- nal.
BaseTypeSize iSignal- ComSignalType
ing dynami-
Type
cLength
UINT8 if ISig-
nal.length <=
NONE not available primitive not applicable 8. ComBitSize de-
rived from ISig-
nal.length
UINT16, ComBit-
NONE 16 Bits primitive not applicable Size derived from
ISignal.length
UINT16 if ISig-
nal.length > 8
and <= 16. Com-
NONE not available primitive not applicable
BitSize derived
from ISignal.
length
UINT32, ComBit-
NONE 32 Bits primitive not applicable Size derived from
ISignal.length
UINT32 if ISig-
nal.length > 16
and <= 32. Com-
NONE not available primitive not applicable
BitSize derived
from ISignal.
length
UINT64, ComBit-
NONE 64 Bits primitive not applicable Size derived from
ISignal.length
UINT64 if ISig-
nal.length > 32
and <= 64. Com-
NONE not available primitive not applicable
BitSize derived
from ISignal.
length
FLOAT32, ComBit-
IEEE754 32 Bits primitive not applicable Size derived from
ISignal.length
FLOAT32, ISig-
nal.length = 32.
IEEE754 not available primitive not applicable ComBitSize de-
rived from ISig-
nal.length
5

266 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
SystemSig-
ISignal.
BaseTypeEncod- nal.
BaseTypeSize iSignal- ComSignalType
ing dynami-
Type
cLength
FLOAT64, ComBit-
IEEE754 64 Bits primitive not applicable Size derived from
ISignal.length
FLOAT64, ISig-
nal.length = 64.
IEEE754 not available primitive not applicable ComBitSize de-
rived from ISig-
nal.length
NONE,
ISO-8859-1, UINT8_N, Com-
ISO-8859-2, SignalLength de-
8 Bits array false
WINDOWS-1252, rived from ISig-
UTF-8, UTF-16, nal.length
UCS-2
NONE,
ISO-8859-1, UINT8_N, Com-
ISO-8859-2, SignalLength de-
not available array false
WINDOWS-1252, rived from ISig-
UTF-8, UTF-16, nal.length
UCS-2
NONE,
ISO-8859-1, UINT8_DYN,
ISO-8859-2, ComSignalLength
8 Bits array true
WINDOWS-1252, derived from
UTF-8, UTF-16, ISignal.length
UCS-2
NONE,
ISO-8859-1, UINT8_DYN,
ISO-8859-2, ComSignalLength
not available array true
WINDOWS-1252, derived from
UTF-8, UTF-16, ISignal.length
UCS-2
BOOLEAN ignored primitive not applicable BOOLEAN
Table 6.8: SwBaseType to ComSignalType Mapping

The setting "not applicable" for an Attribute in Table 6.8 means that no value shall be
set for this Attribute. The setting "ignored" for an Attribute in Table 6.8 means than any
value is accepted for this Attribute, but the value will be ignored in creation of the ECU
configuration value file.

267 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_3258] Restriction on ISignal.length in case iSignalType is set to

array dIf ISignal.iSignalType is set to array then ISignal.length shall be a
multiple of 8.c()
[TPS_SYST_02111] VariableDataPrototype in case ISignal.iSignalType is
set to array dIf ISignal.iSignalType is set to array the corresponding Vari-
ableDataPrototype shall boil down to an Array according to [TPS_SYST_02083],
[TPS_SYST_02084], [TPS_SYST_02085] and [TPS_SYST_02089].c()
The invalidValue is aggregated by the SwDataDefProps element. The Sw-
DataDefProps and the SwBaseType classes are described in more detail in the
Software Component Template [5].
«enumeration» Pdu
Identifiable +managedPhysicalChannel 0..*
DataTypePolicyEnum IPdu
PhysicalChannel
networkRepresentationFromComSpec
legacy
override
transformingISignal

«atpVariation,atpSplitable»

+iSignalTriggering 0..*

Identifiable ISignalIPdu
ISignalProps
ISignalTriggering
+ handleOutOfRange: HandleOutOfRangeEnum + unusedBitPattern: Integer

+iSignalProps 0..1

«atpSplitable» «atpVariation»
+iSignal
0..1
+iSignalToPduMapping 0..*
FibexElement +iSignal
Identifiable
ISignal 0..1 ISignalToIPduMapping
+iSignalGroup 0..1
+ dataTypePolicy: DataTypePolicyEnum
+iSignal + packingByteOrder: ByteOrderEnum [0..1]
+ iSignalType: ISignalTypeEnum [0..1] FibexElement
+iSignalGroup + startPosition: UnlimitedInteger [0..1]
+ length: UnlimitedInteger ISignalGroup
0..* + transferProperty: TransferPropertyEnum [0..1]
0..1 + updateIndicationBitPosition: UnlimitedInteger [0..1]

+networkRepresentationProps 0..1 «enumeration»

+initValue 0..1 0..1 +timeoutSubstitutionValue TransferPropertyEnum
«atpVariation»
SwDataDefProps +invalidValue ValueSpecification triggered
pending
+ shortLabel: Identifier [0..1] triggeredOnChange
0..1
triggeredWithoutRepetition
triggeredOnChangeWithoutRepetition
+physicalProps 0..1
«enumeration» «enumerati...
+systemSignalGroup 1 HandleOutOfRangeEnum ISignalTypeEnum
+systemSignal none
ARElement ARElement primitive
+systemSignal SystemSignal ignore array
* SystemSignalGroup
saturate
1 + dynamicLength: Boolean default
+transformingSystemSignal
invalid
0..1 externalReplacement

Figure 6.4: ISignals and the mapping into IPdus (FibexCore: SignalOverview)

The configuration of the COM Module for atomic signals can largely be derived from
the System Template.
[TPS_SYST_01066] Derivation of Tx COM Signals dA ComSignal shall be defined
in the COM module configuration for each ISignalToIPduMapping that is aggre-
gated by ISignalIPdu that in turn is referenced by a PduTriggering that in turn
references an IPduPort where the communicationDirection is set to out of the
regarded ECU.

268 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Exception: If the ISignal is part of a Signal Gateway relation (ISignalMapping.

targetSignal pointing to an ISignalTriggering referencing this ISignal) the
creation of a ComSignal is not mandated if
• the ISignal does not point to a SystemSignal that is referenced by a
DataMapping (application does not send the gatewayed signal content) or
• the ISignal points to a SystemSignal that is referenced by a DataMap-
ping in which the RPortPrototype is used as the context element and
the destination ISignalTriggering.iSignalPort.communicationDirec-
tion equals out (application sends the gatewayed signal content) or
• the ISignalToIPduMapping.iSignal.dataTypePolicy is set to legacy.
In these cases the configuration of ComGwMapping can be done by means of ComG-
wSourceDescription and ComGwDestinationDescription. However it is pos-
sible to create ComSignals for the ComGwSignal approach as well (i.e., even if the
application does not require access to the respective SystemSignal).c()
[TPS_SYST_01067] Derivation of Rx COM Signals dA ComSignal shall be defined
in the COM module configuration for each ISignalToIPduMapping that is aggre-
gated by ISignalIPdu that in turn is referenced by a PduTriggering that in turn
references an IPduPort where the communicationDirection is set to in in the
regarded ECU.
Exception: If the ISignal is part of a Signal Gateway relation (ISignalMapping.
sourceSignal pointing to an ISignalTriggering referencing this ISignal) the
creation of a ComSignal is not mandated if
• the ISignal does not point to a SystemSignal that is referenced by a
DataMapping (application is not interested in the gatewayed signal content) or
• the ISignal points to a SystemSignal that is referenced by a DataMapping
in which the PPortPrototype is used as the context element and source
ISignalTriggering.iSignalPort.communicationDirection equals in
(application is not interested in the gatewayed signal content) or
• the ISignalToIPduMapping.iSignal.dataTypePolicy is set to legacy.
In these cases the configuration of ComGwMapping can be done by means of ComG-
wSourceDescription and ComGwDestinationDescription. However it is pos-
sible to create ComSignals for the ComGwSignal approach as well (i.e., even if the
application does not require access to the respective SystemSignal).c()
To support the AUTOSAR concept of composite data types the AUTOSAR COM layer
provides signal groups. Every record or array element of a composite data type re-
quires a SystemSignal for the transmission. But the RTE has to guarantee the con-
sistent transmission of data.
[TPS_SYST_01153] Atomic transport of SystemSignalGroups dA SystemSig-
nalGroup shall be transmitted and received consistently; therefore it provides data
consistency for composite data types.c()

269 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

A SystemSignalGroup refers to a set of SystemSignals that shall always be kept

together in a common IPdu. An ISignalGroup represents a SystemSignalGroup
of the Interaction Layer. In the case of "signal fan-out", several ISignalGroups refer
to the same SystemSignalGroup.
Record A SystemSignalGroupA
Int X SystemSignal X
Record B SystemSignal Y
Int Y SystemSignal Z
Bool Z

RTE Fanout

ISignalGroupA_1 ISignalGroupA_2
ISignal X_1 ISignal X_2
ISignal Y_1 ISignal Y_2
ISignal Z_1 ISignal Z_3
Figure 6.5: ISignal example

The example in Figure 6.5 shows the usage of ISignalGroups and ISignals. In
this example a record is mapped to a SystemSignalGroup. All Application-
RecordElements with ApplicationPrimitiveDataType are mapped to individ-
ual SystemSignals. If the same SystemSignalGroup is sent to different receivers
(RTE Fanout) then two different ISignalGroups are created. For each SystemSig-
nal within the SystemSignalGroup an ISignal is created. The different ISignals
of the same SystemSignal can have different network representations.
[TPS_SYST_01156] Definition of ISignalTriggerings is allowed for ISig-
nalGroups and for GroupSignals dIf an ISignalGroup is referenced by an
ISignalTriggering then the ISignals that are contained in the ISignalGroup
(GroupSignals) may be referenced as well by ISignalTriggerings.c()
[constr_3094] Consistent ISignalPort.communicationDirection for
ISignalTriggerings of ISignalGroups and contained ISignals dIn case the
ISignals contained in an ISignalGroup are referenced by an ISignalTrig-
gering, the communicationDirection of the ISignalPort referenced by the
ISignal’s ISignalTriggering shall be identical to the communicationDi-
rection of the ISignalPort referenced by the containing ISignalGroup’s
ISignalTriggering.c()
Please note that not all ISignals that are part of the ISignalGroup need to
have a reference to an ISignalPort via an ISignalTriggering as described by
[TPS_SYST_02106].

270 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_01157] Allowed usage of attributes for ISignals, ISignalGroups

and GroupSignals dTable 6.9 shows attributes that may be used to configure ISig-
nals in different roles (ISignals that are not part of an ISignalGroup and ISig-
nals that are part of an ISignalGroup) and ISignalGroups.c()

Attributes ISignal ISignalGroup GroupSignal

startPosition 1 NA 1
updateIndicationBitPosition 0..1 0..1 NA
transferProperty 0..1 0..1 0..1
packingByteOrder 1 NA 1
dataFilter 0..1 NA 0..1

Table 6.9: Allowed usage of attributes for ISignals, ISignalGroups and GroupSig-
nals

[constr_3067] initValue defined in the context of ISignal dThe definition of an

initValue in the context of an ISignal shall only be a NumericalValueSpeci-
fication, TextValueSpecification or ArrayValueSpecification that ag-
gregates elements of type NumericalValueSpecification or TextValueSpec-
ification.c()
[constr_3437] invalidValue defined in the context of ISignal dThe definition
of SwDataDefProps.invalidValue aggregated by an ISignal in the role net-
workRepresentationProps shall only be a NumericalValueSpecification,
TextValueSpecification or ArrayValueSpecification that aggregates ele-
ments of type NumericalValueSpecification or TextValueSpecification.c
()
[constr_3438] timeoutSubstitutionValue defined in the context of ISignal
dThe definition of an timeoutSubstitutionValue in the context of an ISignal
shall only be a NumericalValueSpecification, TextValueSpecification or
ArrayValueSpecification that aggregates elements of type NumericalValue-
Specification or TextValueSpecification.c()
[TPS_SYST_02012] initValue and invalidValue represent internal values
dThe initValue and invalidValue aggregated by the networkRepresenta-
tionProps shall represent the internal values.c()
[TPS_SYST_02110] Default behavior for ISignal.iSignalType dIn case ISig-
nal.iSignalType is not defined the value "primitive" shall be assumed.c()
[TPS_SYST_02144] ComTimeoutSubstitution does not apply for signal gateway
operation dThe specification of ComTimeoutSubstitution by defining the ISig-
nal.timeoutSubstitutionValue does not apply for signal gateway operation.
Only when the ISignal is processed for an upper layer the ComTimeoutSubsti-
tution is actually performed.c()
Note: Since an ISignal may be candidate for both - local reception and gateway oper-
ation - a definition of ISignal.timeoutSubstitutionValue is valid on ISignals
which are defined for gateway operation.

271 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class ISignal
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note Signal of the Interaction Layer. The RTE supports a "signal fan-out" where the same System Signal is
sent in different SignalIPdus to multiple receivers.
To support the RTE "signal fan-out" each SignalIPdu contains ISignals. If the same System Signal is to
be mapped into several SignalIPdus there is one ISignal needed for each ISignalToIPduMapping.
ISignals describe the Interface between the Precompile configured RTE and the potentially Postbuild
configured Com Stack (see ECUC Parameter Mapping).
In case of the SystemSignalGroup an ISignal shall be created for each SystemSignal contained in the
SystemSignalGroup.
Tags:atp.recommendedPackage=ISignals
Base ARObject, CollectableElement, FibexElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
data DataTransformation 0..1 ref Optional reference to a DataTransformation which
Transformation represents the transformer chain that is used to transform
the data that shall be placed inside this ISignal.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=dataTransformation.dataTransformation,
dataTransformation.variationPoint.shortLabel
vh.latestBindingTime=codeGenerationTime
dataTypePolicy DataTypePolicyEnum 1 attr With the aggregation of SwDataDefProps an ISignal
specifies how it is represented on the network. This
representation follows a particular policy. Note that this
causes some redundancy which is intended and can be
used to support flexible development methodology as well
as subsequent integrity checks.
If the policy "networkRepresentationFromComSpec" is
chosen the network representation from the ComSpec
that is aggregated by the PortPrototype shall be used. If
the "override" policy is chosen the requirements specified
in the PortInterface and in the ComSpec are not fulfilled
by the networkRepresentationProps. In case the System
Description doesn’t use a complete Software Component
Description (VFB View) the "legacy" policy can be
chosen.
initValue ValueSpecification 0..1 aggr Optional definition of a ISignal’s initValue in case the
System Description doesn’t use a complete Software
Component Description (VFB View). This supports the
inclusion of legacy system signals.
This value can be used to configure the Signal’s "Init
Value".
If a full DataMapping exist for the SystemSignal this
information may be available from a configured Sender
ComSpec and ReceiverComSpec. In this case the
initvalues in SenderComSpec and/or ReceiverComSpec
override this optional value specification. Further
restrictions apply from the RTE specification.
iSignalProps ISignalProps 0..1 aggr Additional optional ISignal properties that may be stored
in different files.
Stereotypes: atpSplitable
Tags:atp.Splitkey=iSignalProps
iSignalType ISignalTypeEnum 0..1 attr This attribute defines whether this iSignal is an array that
results in a UINT8_N / UINT8_DYN ComSignalType in the
COM configuration or a primitive type.
5

272 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class ISignal
length UnlimitedInteger 1 attr Size of the signal in bits. The size needs to be derived
from the mapped VariableDataPrototype according to the
mapping of primitive DataTypes to BaseTypes as used in
the RTE. Indicates maximum size for dynamic length
signals.
The ISignal length of zero bits is allowed.
network SwDataDefProps 0..1 aggr Specification of the actual network representation. The
Representation usage of SwDataDefProps for this purpose is restricted to
Props the attributes compuMethod and baseType. The optional
baseType attributes "memAllignment" and "byteOrder"
shall not be used.
The attribute "dataTypePolicy" in the SystemTemplate
element defines whether this network representation shall
be ignored and the information shall be taken over from
the network representation of the ComSpec.
If "override" is chosen by the system integrator the
network representation can violate against the
requirements defined in the PortInterface and in the
network representation of the ComSpec.
In case that the System Description doesn’t use a
complete Software Component Description (VFB View)
this element is used to configure "ComSignalDataInvalid
Value" and the Data Semantics.
systemSignal SystemSignal 1 ref Reference to the System Signal that is supposed to be
transmitted in the ISignal.
timeout ValueSpecification 0..1 aggr Defines and enables the ComTimeoutSubstituition for this
Substitution ISignal.
Value
transformation TransformationISignal * aggr A transformer chain consists of an ordered list of
ISignalProps Props transformers. The ISignal specific configuration
properties for each transformer are defined in the
TransformationISignalProps class. The transformer
configuration properties that are common for all ISignals
are described in the TransformationTechnology class.

Table 6.10: ISignal

Enumeration DataTypePolicyEnum
Package M2::AUTOSARTemplates::SystemTemplate::DataMapping
Note This class lists the supported DataTypePolicies.
Literal Description
legacy In case the System Description doesn’t use a complete Software Component Description (VFB View)
this value can be chosen. This supports the inclusion of legacy signals.
The aggregation of SwDataDefProps shall be used to configure the "ComSignalDataInvalidValue"
and the Data Semantics.
Tags:atp.EnumerationLiteralIndex=0
network Ignore any networkRepresentationProps of this ISignal and use the networkRepresentation from the
Representation ComSpec.
FromComSpec
Please note that the usage does not imply the existence of the SwDataDefProps in the role network
Representation aggregated by the SenderComSpec or ReceiverComSpec if an ImplementationData
Type is defined.
Tags:atp.EnumerationLiteralIndex=1
5

273 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Enumeration DataTypePolicyEnum
override If this value is chosen the requirements specified in the ComSpec (networkRepresentationFromCom
Spec) are not fullfilled by the aggregated SwDataDefProps. In this case the networkRepresentation is
specified by the aggregated swDataDefProps.
Tags:atp.EnumerationLiteralIndex=2
transformingISignal This literal indicates that a transformer chain shall be used to communicate the ISignal as UINT8_N
over the bus.
Tags:atp.EnumerationLiteralIndex=4

Table 6.11: DataTypePolicyEnum

Enumeration ISignalTypeEnum
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note This enumeration defines ISignal types that are used for derivation of the ComSignalType in the COM
configuration.
Literal Description
array ISignal shall be interpreted as an array (UINT8_N, UINT8_DYN)
Tags:atp.EnumerationLiteralIndex=0
primitive ISignal shall be interpreted as a primitive type (e.g. UINT_8, SINT_32)
Tags:atp.EnumerationLiteralIndex=1

Table 6.12: ISignalTypeEnum

Class ISignalProps
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note Additional ISignal properties that may be stored in different files.
Base ARObject
Attribute Type Mult. Kind Note
handleOutOf HandleOutOfRange 1 attr This attribute defines the outOfRangeHandling for
Range Enum received and sent signals.

Table 6.13: ISignalProps

Enumeration HandleOutOfRangeEnum
Package M2::AUTOSARTemplates::SWComponentTemplate::Communication
Note A value of this type is taken for controlling the range checking behavior of the AUTOSAR RTE.
Literal Description
default The RTE will use the initValue if the actual value is out of the specified bounds.
Tags:atp.EnumerationLiteralIndex=0
external This indicates that the value replacement is sourced from the attribute replaceWith.
Replacement
Tags:atp.EnumerationLiteralIndex=1
ignore The RTE will ignore any attempt to send or receive the corresponding dataElement if the value is out
of the specified range.
Tags:atp.EnumerationLiteralIndex=2
invalid The RTE will use the invalidValue if the value is out of the specified bounds.
Tags:atp.EnumerationLiteralIndex=3
5

274 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Enumeration HandleOutOfRangeEnum
none A range check is not required.
Tags:atp.EnumerationLiteralIndex=4
saturate The RTE will saturate the value of the dataElement such that it is limited to the applicable upper
bound if it is greater than the upper bound. Consequently, it is limited to the applicable lower bound if
the value is less than the lower bound.
Tags:atp.EnumerationLiteralIndex=5

Table 6.14: HandleOutOfRangeEnum

Class ISignalGroup
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note SignalGroup of the Interaction Layer. The RTE supports a "signal fan-out" where the same System
Signal Group is sent in different SignalIPdus to multiple receivers.
An ISignalGroup refers to a set of ISignals that shall always be kept together. A ISignalGroup represents
a COM Signal Group.
Therefore it is recommended to put the ISignalGroup in the same Package as ISignals (see
atp.recommendedPackage)
Tags:atp.recommendedPackage=ISignalGroup
Base ARObject, CollectableElement, FibexElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
comBased DataTransformation 0..1 ref Optional reference to a DataTransformation which
SignalGroup represents the transformer chain that is used to transform
Transformation the data that shall be placed inside this ISignalGroup
based on the COMBasedTransformer approach.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=comBasedSignalGroupTransformation.data
Transformation, comBasedSignalGroup
Transformation.variationPoint.shortLabel
vh.latestBindingTime=codeGenerationTime
iSignal ISignal * ref Reference to a set of ISignals that shall always be kept
together.
systemSignal SystemSignalGroup 1 ref Reference to the SystemSignalGroup that is defined on
Group VFB level and that is supposed to be transmitted in the
ISignalGroup.
transformation TransformationISignal * aggr A transformer chain consists of an ordered list of
ISignalProps Props transformers. The ISignalGroup specific configuration
properties for each transformer are defined in the
TransformationISignalProps class. The transformer
configuration properties that are common for all ISignal
Groups are described in the TransformationTechnology
class.
Table 6.15: ISignalGroup

Class SystemSignalGroup
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
5

275 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class SystemSignalGroup
Note A signal group refers to a set of signals that shall always be kept together. A signal group is used to
guarantee the atomic transfer of AUTOSAR composite data types.
The SystemSignalGroup defines a signal grouping on VFB level. On cluster level the Signal grouping is
described by the ISignalGroup element.
Tags:atp.recommendedPackage=SystemSignalGroups
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
systemSignal SystemSignal * ref Reference to a set of SystemSignals that shall always be
kept together.
transforming SystemSignal 0..1 ref Optional reference to the SystemSignal which shall
SystemSignal contain the transformed (linear) data.

Table 6.16: SystemSignalGroup

Class ISignalToIPduMapping
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note An ISignalToIPduMapping describes the mapping of ISignals to ISignalIPdus and defines the position of
the ISignal within an ISignalIPdu.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
iSignal ISignal 0..1 ref Reference to a ISignal that is mapped into the ISignal
IPdu.
Each ISignal contained in the ISignalGroup shall be
mapped into an IPdu by an own ISignalToIPduMapping.
The references to the ISignal and to the ISignalGroup in
an ISignalToIPduMapping are mutually exclusive.
iSignalGroup ISignalGroup 0..1 ref Reference to an ISignalGroup that is mapped into the
SignalIPdu. If an ISignalToIPduMapping for an ISignal
Group is defined, only the UpdateIndicationBitPosition
and the transferProperty is relevant. The startPosition
and the packingByteOrder shall be ignored.
Each ISignal contained in the ISignalGroup shall be
mapped into an IPdu by an own ISignalToIPduMapping.
The references to the ISignal and to the ISignalGroup in
an ISignalToIPduMapping are mutually exclusive.
packingByte ByteOrderEnum 0..1 attr This parameter defines the order of the bytes of the signal
Order and the packing into the SignalIPdu. The byte ordering
"Little Endian" (MostSignificantByteLast), "Big Endian"
(MostSignificantByteFirst) and "Opaque" can be selected.
For opaque data endianness conversion shall be
configured to Opaque. The value of this attribute impacts
the absolute position of the signal into the SignalIPdu
(see the startPosition attribute description).
For an ISignalGroup the packingByteOrder is irrelevant
and shall be ignored.
5

276 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class ISignalToIPduMapping
startPosition UnlimitedInteger 0..1 attr This parameter is necessary to describe the bitposition of
a signal within an SignalIPdu. It denotes the least
significant bit for "Little Endian" and the most significant
bit for "Big Endian" packed signals within the IPdu (see
the description of the packingByteOrder attribute). In
AUTOSAR the bit counting is always set to "sawtooth"
and the bit order is set to "Decreasing". The bit counting
in byte 0 starts with bit 0 (least significant bit). The most
significant bit in byte 0 is bit 7.
Please note that the way the bytes will be actually sent on
the bus does not impact this representation: they will
always be seen by the software as a byte array.
If a mapping for the ISignalGroup is defined, this attribute
is irrelevant and shall be ignored.
transferProperty TransferPropertyEnum 0..1 attr Defines how the referenced ISignal contributes to the
send triggering of the ISignalIPdu.
update UnlimitedInteger 0..1 attr The UpdateIndicationBit indicates to the receivers that the
IndicationBit signal (or the signal group) was updated by the sender.
Position Length is always one bit. The UpdateIndicationBitPosition
attribute describes the position of the update bit within the
SignalIPdu. For Signals of a ISignalGroup this attribute is
irrelevant and shall be ignored.
Note that the exact bit position of the updateIndicationBit
Position is linked to the value of the attribute packingByte
Order because the method of finding the bit position is
different for the values mostSignificantByteFirst and most
SignificantByteLast. This means that if the value of
packingByteOrder is changed while the value of update
IndicationBitPosition remains unchanged the exact bit
position of updateIndicationBitPosition within the
enclosing ISignalIPdu still undergoes a change.
This attribute denotes the least significant bit for "Little
Endian" and the most significant bit for "Big Endian"
packed signals within the IPdu (see the description of the
packingByteOrder attribute). In AUTOSAR the bit
counting is always set to "sawtooth" and the bit order is
set to "Decreasing". The bit counting in byte 0 starts with
bit 0 (least significant bit). The most significant bit in byte
0 is bit 7.

Table 6.17: ISignalToIPduMapping

[constr_5322] Value range of ISignalToIPduMapping.startPosition dThe

value of ISignalToIPduMapping.startPosition shall be in the range of
0..4294967295 Bits.c()
Please note that the range of ISignalToIPduMapping.startPosition is resc-
tricted by [constr_5322] to the max value of 4294967295 Bits because of the de-
fined range of the ComBitPosition parameter that is defined in the COM Config-
uration [22].
[constr_5323] Value range of ISignalToIPduMapping.updateIndicationBit-
Position dThe value of ISignalToIPduMapping.updateIndicationBitPosi-
tion shall be in the range of 0..4294967295 Bits.c()

277 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Please note that the range of ISignalToIPduMapping.updateIndicationBit-

Position is resctricted by [constr_5323] to the max value of 4294967295 Bits be-
cause of the defined range of the ComUpdateBitPosition parameter that is defined
in the COM Configuration [22].
[constr_3514] No two ISignalToIPduMappings shall reference the identical
ISignal dNo two ISignalToIPduMappings shall reference the identical ISignal
in the role iSignal in the scope of one System.c()
Enumeration TransferPropertyEnum
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note Transfer Properties of a Signal.
Literal Description
pending If the signal has the TransferProperty pending, then the function Com_SendSignal shall not perform a
transmission of the IPdu associated with the signal.
Tags:atp.EnumerationLiteralIndex=0
triggered The signal in the assigned IPdu is updated and a request for the IPdu’s transmission is made.
Tags:atp.EnumerationLiteralIndex=1
triggeredOnChange The signal in the assigned IPdu is updated and a request for the IPdus transmission is made only if
the signal value is different from the already stored signal value.
Tags:atp.EnumerationLiteralIndex=2
triggeredOnChange The signal in the assigned IPdu is updated and a request for the IPdus transmission is made only if
WithoutRepetition the signal value is different from the already stored signal value. In the DIRECT/N-TIMES or MIXED
transmission mode (EventControlledTiming) the IPdu will be transmitted just once without a
repetition, independent of the defined NumberOfRepeats.
Tags:atp.EnumerationLiteralIndex=3
triggeredWithout The signal in the assigned IPdu is updated and a request for the IPdu’s transmission is made. In the
Repetition DIRECT/N-TIMES or MIXED transmission mode (EventControlledTiming) the IPdu will be transmitted
just once without a repetition, independent of the defined NumberOfRepeats.
Tags:atp.EnumerationLiteralIndex=4

Table 6.18: TransferPropertyEnum

[TPS_SYST_02198] Applicable transferProperty for ISignal dIf the

ISignalToIPduMapping refers to an ISignal in the role iSignal then
• the pending transferProperty does not cause transmission of the ISig-
nalIPdu if the ISignal is updated.
• if the ISignalIPdu has an EventControlledTiming aggregated at the
TransmissionModeTiming then the transferProperty values
– triggered and triggeredWithoutRepetition do cause immediate
transmission of the ISignalIPdu if the ISignal is updated.
– triggeredOnChange and triggeredOnChangeWithoutRepetition
do cause immediate transmission of the ISignalIPdu if the ISignal is
updated and has changed.
c()
[constr_3459] Applicable transferProperty for group signal dIf the ISignal-
ToIPduMapping refers to an ISignal in the role iSignal and

278 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

this ISignal is referenced by an ISignalGroup in the role iSignal then

the ISignalToIPduMapping of the ISignal shall either
• have transferProperty pending or triggeredOnChange defined, or
• have no transferProperty defined.
c()
[constr_3460] Full definition of transferProperty for group signal dIf at least
one of the ISignals belonging to an ISignalGroup has a transferProperty
defined (via their respective ISignalToIPduMapping) then
all other ISignals belonging to the same ISignalGroup shall have a transfer-
Property defined as well.c()
Note: [constr_3460] ensures that either
• no group signal has a transferProperty defined, then [TPS_SYST_02199]
applies, or
• every group signal has a transferProperty defined, then
[TPS_SYST_02200] applies.
[TPS_SYST_02199] Applicable transferProperty for ISignalGroup and no
group signal has transferProperty defined dIf the ISignalToIPduMapping
refers to an ISignalGroup in the role iSignalGroup and
the ISignalIPdu has an EventControlledTiming aggregated at the Transmis-
sionModeTiming and
none of the ISignals belonging to the ISignalGroup have a transferProperty
defined (via their respective ISignalToIPduMapping) then
if the ISignalToIPduMapping of the ISignalGroup has the transferProperty
• pending defined then an update of this ISignalGroup does not cause the
transmission of the ISignalIPdu.
• triggered or triggeredWithoutRepetition defined then an update of this
ISignalGroup does cause immediate transmission of the ISignalIPdu.
• triggeredOnChange or triggeredOnChangeWithoutRepetition defined
then an update of this ISignalGroup in combination with the change of any of
the contained group signals does cause immediate transmission of the ISig-
nalIPdu.
c()
[TPS_SYST_02200] Applicable transferProperty for ISignalGroup and
group signals have transferProperty defined dIf the ISignalToIPduMapping
refers to an ISignalGroup in the role iSignalGroup and
the ISignalIPdu has an EventControlledTiming aggregated at the Transmis-
sionModeTiming and
the ISignals belonging to the ISignalGroup have a transferProperty defined

279 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

(via their respective ISignalToIPduMapping) then

if the ISignalToIPduMapping of the ISignalGroup has the transferProperty
• pending defined then an update of this ISignalGroup does not cause the
transmission of the ISignalIPdu.
• triggered or triggeredWithoutRepetition defined then an update of this
ISignalGroup does cause immediate transmission of the ISignalIPdu.
• triggeredOnChange or triggeredOnChangeWithoutRepetition defined
then an update of this ISignalGroup in combination with the change of any of
the contained group signals which have transferProperty=triggeredOn-
Change defined does cause immediate transmission of the ISignalIPdu.
c()
[constr_3461] TransferProperty for group signals if ISignalGroup has trans-
ferProperty=pending dIf the ISignalToIPduMapping refers to an ISignal-
Group in the role iSignalGroup and
the transferProperty is set to pending then
the group signals of this ISignalGroup shall either
• have no transferProperty defined (via their respective ISignalToIP-
duMapping) or
• every ISignal belonging to the ISignalGroup shall have the transfer-
Property=pending defined.
c()
Class ISignalTriggering
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note A ISignalTriggering allows an assignment of ISignals to physical channels.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
iSignal ISignal 0..1 ref This reference shall be used if an ISignal is transported
on the PhysicalChannel. This reference forms an XOR
relationship with the ISignalTriggering-ISignalGroup
reference.
iSignalGroup ISignalGroup 0..1 ref This reference shall be used if an ISignalGroup is
transported on the PhysicalChannel. This reference
forms an XOR relationship with the ISignal
Triggering-ISignal reference.
iSignalPort ISignalPort * ref References to the ISignalPort on every ECU of the
system which sends and/or receives the ISignal.
References for both the sender and the receiver side
shall be included when the system is completely defined.

Table 6.19: ISignalTriggering

280 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.2.1 Efficient COM for large data

AUTOSAR defines an alternative communication path between the RTE and the Com-
munication Stack called Efficient COM for large data module (LdCom). The System
Template does not define specific attributes which would distinguish whether the tradi-
tional Com or the LdCom shall be used. The idea behind this feature is rather that
• IF the LdCom module is integrated in an Ecu
• AND the specific interaction fulfills certain properties
• THEN LdCom shall be used.
Thus the usage of LdCom inside an ECU is project specific and is not derived from
system description properties.
Note: even when all requirements for usage of LdCom are fulfilled it is not necessarily
required to actually have an LdCom module inside the respective Ecu. It is rather a
project specific decision whether LdCom module is integrated.
All of the following requirements need to be fulfilled in order to allow the usage of
LdCom for the specific ISignal / ISignalIPdu combination.
[TPS_SYST_02015] LdCom: only one ISignal mapped to the ISignalIPdu
dOnly if exactly one ISignal is mapped into an ISignalIPdu and the LdCom mod-
ule is present, this ISignal shall be handled by LdCom.c(RS_SYST_00049)
[TPS_SYST_02016] LdCom: only Transformer output and UINT8_N or
UINT8_DYN supported dOnly if
• the data type of the ISignal is either UINT8_N or UINT8_DYN
• or the ISignal has a reference to the DataTransformation in the role data-
Transformation
and the LdCom module is present, this ISignal shall be handled by LdCom.c(RS_-
SYST_00049)
[TPS_SYST_02017] LdCom: Opaque ISignalToIPduMapping.packingByte-
Order dOnly if packingByteOrder has the value "Opaque" and the LdCom module
is present, this ISignal shall be handled by LdCom.c(RS_SYST_00049)
[TPS_SYST_02018] LdCom: ISignalToIPduMapping.startPosition shall be
0 dOnly if ISignalToIPduMapping.startPosition equals 0 (zero) and the LdCom
module is present, this ISignal shall be handled by LdCom.c(RS_SYST_00049)
[TPS_SYST_02019] LdCom: ISignalToIPduMapping.transferProperty shall
be triggered or triggeredWithoutRepetition for sent ISignals dOnly if ISignal-
ToIPduMapping.transferProperty equals triggered or triggeredWithoutRepeti-
tion for a Signal that is sent by the EcuInstance and the LdCom module is present,
this ISignal shall be handled by LdCom.c(RS_SYST_00049)

281 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_02020] LdCom: No IPduTiming.minimumDelay defined dThe ISig-

nal is mapped into an ISignalIPdu. Only if this ISignalIPdu does not contain
an IPduTiming in iPduTimingSpecification which has IPduTiming.mini-
mumDelay defined, the ISignalIPdu is sent by the EcuInstance and the LdCom
module is present, this ISignal shall be handled by LdCom.c(RS_SYST_00049)
[TPS_SYST_02021] LdCom: ISignalToIPduMapping.updateIndicationBit-
Position shall not be defined dOnly if ISignalToIPduMapping.updateIndica-
tionBitPosition is not defined and the LdCom module is present, this ISignal
shall be handled by LdCom.c(RS_SYST_00049)
[TPS_SYST_02022] LdCom: Only the transmissionModeTrueTiming defined
dThe ISignal is mapped into an ISignalIPdu. Only if this ISignalIPdu has ex-
actly the TransmissionModeDeclaration.transmissionModeTrueTiming de-
fined (via ISignalIPdu.iPduTimingSpecification), the ISignalIPdu is sent
by the EcuInstance and the LdCom module is present, this ISignal shall be han-
dled by LdCom.c(RS_SYST_00049)
[TPS_SYST_02023] LdCom: DataFilter "always" if TransmissionModeCon-
dition defined dThe ISignal is mapped into an ISignalIPdu. If this ISig-
nalIPdu has either
• no TransmissionModeDeclaration.transmissionModeCondition de-
fined (via ISignalIPdu.iPduTimingSpecification) or
• DataFilter.dataFilterType is set to "always" for the TransmissionMod-
eCondition of this ISignalIPdu.
and this ISignalIPdu is sent by the EcuInstance and the LdCom module is
present, this ISignal shall be handled by LdCom.c(RS_SYST_00049)
[TPS_SYST_02024] LdCom: No ModeDrivenTransmissionModeCondition de-
fined dThe ISignal is mapped into an ISignalIPdu. Only if this ISignalIPdu
has no TransmissionModeDeclaration.modeDrivenTrueCondition and mod-
eDrivenFalseCondition, the ISignalIPdu is sent by the EcuInstance and the
LdCom module is present, this ISignal shall be handled by LdCom.c(RS_SYST_-
00049)
[TPS_SYST_02025] LdCom: Only EventControlledTiming defined dThe ISig-
nal is mapped into an ISignalIPdu. Only if this ISignalIPdu has an
EventControlledTiming (via TransmissionModeTiming.eventControlled-
Timing) and the LdCom module is present, this ISignal shall be handled by Ld-
Com.c(RS_SYST_00049)
[TPS_SYST_02026] LdCom: Only EventControlledTiming with no repetition
defined dThe ISignal is mapped into an ISignalIPdu. Only if this ISignalIPdu
has an EventControlledTiming (via TransmissionModeTiming.eventCon-
trolledTiming) with EventControlledTiming.numberOfRepetitions = 0 de-
fined and the LdCom module is present, this ISignal shall be handled by LdCom.c
(RS_SYST_00049)

282 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

TransmissionModeTiming TransmissionModeDeclaration
+transmissionModeTrueTiming

0..1

+transmissionModeDeclaration 0..1

+eventControlledTiming 0..1

Describable FibexElement
Describable
EventControlledTiming CoreCommunication::ISignal
CoreCommunication::IPduTiming
+ numberOfRepetitions: Integer + dataTypePolicy: DataTypePolicyEnum
+ minimumDelay: TimeValue [0..1]
+ iSignalType: ISignalTypeEnum [0..1]
0..1 +iPduTimingSpecification + length: UnlimitedInteger

+iSignal 0..1

«atpVariation»

IPdu Identifiable
CoreCommunication::ISignalIPdu CoreCommunication::ISignalToIPduMapping

+ unusedBitPattern: Integer +iSignalToPduMapping + packingByteOrder: ByteOrderEnum [0..1]

+ startPosition: UnlimitedInteger [0..1]
«atpVariation» 0..*
+ transferProperty: TransferPropertyEnum [0..1]
+ updateIndicationBitPosition: UnlimitedInteger [0..1]

Figure 6.6: Pdu Timing excerpt that may be used to configure LdCom

[TPS_SYST_02027] LdCom: No ISignalPort.timeout reception timeout de-

fined dOnly if the ISignalPort which the ISignalTriggering is referring to has
no ISignalPort.timeout defined and the LdCom module is present, this ISignal
shall be handled by LdCom.c(RS_SYST_00049)
[TPS_SYST_02164] LdCom: No ISignalPort.firstTimeout reception timeout
defined dOnly if the ISignalPort which the ISignalTriggering is referring to
has no ISignalPort.firstTimeout defined and the LdCom module is present,
this ISignal shall be handled by LdCom.c(RS_SYST_00049)
[TPS_SYST_02028] LdCom: No ISignalPort.dataFilter defined dOnly if the
ISignalPort which the ISignalTriggering is referring to has either
• no ISignalPort.dataFilter defined
• or the DataFilter.dataFilterType = always
and the LdCom module is present, this ISignal shall be handled by LdCom.c(RS_-
SYST_00049)
[TPS_SYST_03001] LdCom: ISignalIPdu not part of any ISignalIPduGroup
dOnly if the ISignalIPdu is not referenced by any ISignalIPduGroup in the role
iSignalIPdu and the LdCom module is present, this ISignalIPdu shall be handled
by LdCom.c(RS_SYST_00049)
The following table gives an overview about the specification item relevance for the
sender and for the receiver side.
Spec Item Number Spec Item Headline Motivation Applies to Model element
LdCom: only one ISignal LdCom only supports one ISig-
[TPS_SYST_02015] Rx + Tx ISignalToIPduMapping
mapped to the ISignalIPdu. nal per PDU.

LdCom: only Transformer output

LdCom only supports Byte Array
[TPS_SYST_02016] and UINT8_N or UINT8_DYN sup- Rx + Tx ISignal
Signals.
ported.

283 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Spec Item Number Spec Item Headline Motivation Applies to Model element
LdCom: Opaque ISignalToIP- LdCom only supports Byte Array
[TPS_SYST_02017] Rx + Tx ISignalToIPduMapping
duMapping.packingByteOrder. Signals.

LdCom: ISignalToIPduMap- LdCom only supports Signals start-

[TPS_SYST_02018] ping.startPosition shall be Rx + Tx ISignalToIPduMapping
ing in the first byte of the PDU.
0.
LdCom: ISignalToIPduMap-
ping.transferProperty shall LdCom only supports one ISignal
[TPS_SYST_02019] per PDU. That signal has to trigger Tx ISignalToIPduMapping
be triggered or triggeredWith-
outRepetition. the transmission.

LdCom: No IPduTiming.mini- LdCom does not support event trig-

[TPS_SYST_02020] Tx ISignalIPdu
mumDelay defined. gered transmission with repetitions.

LdCom: ISignalToIPduMap-
[TPS_SYST_02021] LdCom does not support update
ping.updateIndicationBit- Rx + Tx ISignalToIPduMapping
bits.
Position shall not be defined.
LdCom: Only the transmission- LdCom does not support transmis-
[TPS_SYST_02022] Tx ISignalIPdu
ModeTrueTiming defined. sion modes.
LdCom: DataFilter "always" if
[TPS_SYST_02023] LdCom does not support transmis-
TransmissionModeCondition Tx ISignalIPdu
sion modes.
defined.
LdCom: No ModeDrivenTrans-
[TPS_SYST_02024] LdCom does not support transmis-
missionModeCondition de- Tx ISignalIPdu
sion modes.
fined.
LdCom: Only EventCon- LdCom does not support cyclic
[TPS_SYST_02025] Tx ISignalIPdu
trolledTiming defined. transmission.
LdCom: Only EventCon- LdCom does not support cyclic
[TPS_SYST_02026] trolledTiming with no repetition transmission nor repeated trans- Tx ISignalIPdu
defined. mission.
LdCom: No ISignalPort.time- LdCom does not support timeout
[TPS_SYST_02027] Rx ISignalPort
out reception timeout defined. handling.

LdCom: No ISignalPort. LdCom does not support timeout

[TPS_SYST_02164] firstTimeout reception timeout Rx ISignalPort
handling.
defined.
LdCom: No ISignalPort. LdCom does not support timeout
[TPS_SYST_02028] Rx ISignalPort
dataFilter defined. handling.

LdCom: ISignalIPdu not part of LdCom does not support ISig-

[TPS_SYST_03001] Rx + Tx ISignalIPdu
any ISignalIPduGroup. nalIPduGroups.

Table 6.20: Relevance of LdCom spec items for TX and RX

6.2.2 Big Endian and Little Endian memory layout of Pdus and Frames

The AUTOSAR system description provide means to specify how the memory layout
looks like when signals are packed into Pdus and Pdus are packed into Frames. The
layout of Pdus and Frames on different communication systems is out of scope of
AUTOSAR. The specification of attributes Bit counting (monotone or sawtooth) and Bit
order (decreasing or increasing)1 is not supported by AUTOSAR. In AUTOSAR these
attributes are fixed.
[TPS_SYST_01068] Bit Counting in AUTOSAR dThe Bit counting shall always be
considered as "sawtooth".c()
[TPS_SYST_01069] Bit Order in AUTOSAR dThe bit order shall always be considered
as "Decreasing".c()
When a signal is mapped into a Pdu only the packingByteOrder affects the memory
layout of the signal inside the Pdu beginning with it’s start bit position.

1
More details about Bit counting and Bit order can be found in ASAM FIBEX [9].

284 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Little endian stores the least significant byte first and begins with the least significant
bit, i.e. loworder bit in the sequence (the least significant bit serves as start bit).
Big endian stores the most significant byte first and begins with the most significant bit,
i.e. the bit with the greatest numerical value (the most significant bit serves as start
bit).
In both cases the bit positions in the mapped signals increase with the bit positions in
the ISignalIPdu such that the bit 20 is mapped to position n in the ISignalIPdu
and bit 21 is mapped to position n+1 and so on.
Example 6.7 shows the memory layout for Little Endian and Big Endian if an ISig-
nal with a length of 10 bits is mappped into a Pdu. The start bit position is 5.

Figure 6.7: PackingByteOrder Example

The following examples are showing the mapping of Pdus into Frames.
The first example in Figure 6.8 for little endian shows a Frame with four bytes that
contains a single Pdu that is two bytes long. The PduToFrameMapping.startPo-
sition is defined with 8 and since the packingByteOrder is set to mostSignif-
icantByteLast the startPosition denotes the least significant bit of the Pdu in
the Frame. The bit position of the mapped Pdu increases with the bit positions in the
Frame such that the bit 20 is mapped to position n in the ISignalIPdu and bit 21 is
mapped to position n+1 and so on.
Please note that the Pdus are byte aligned in a Frame and only the values 0, 8, 16,
24,... (for little endian) and 7, 15, 23, ... (for big endian) for PduToFrameMapping.
startPosition are allowed.
Figure 6.8 also shows that the Pdu contains three ISignals. The first ISignal has
the ISignalToIPduMapping.startPosition defined as 0 and is 5 bits long. The
bitposition of the second signal is 5 and the length is 10 bits. And the third signal has
the bitposition 15 and is only 1 bit long. Since the ISignalToIPduMapping.pack-
ingByteOrder is defined with mostSignificantByteLast as well the startPo-
sition of the ISignals denotes the least significant bit of the ISignal in the Pdu.

285 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11
PduToFrameMapping

Little Endian byte order:

Signal layout in Pdu:

Byte 1 2
Bit 15 14 13 12 11 10 9 8 23 22 21 20 19 18 17 16
Signal 22 21 20 2-4 2-3 22 - 2-1 2-0 2-0 29 28 27 26 25 24 23
Pdu bit 7 6 5 4- 3- 2- 1- 0- 15
- 14 13 12 11 10 9 8

Pdu layout in Frame:

Byte 0 1 2 3
Bit 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 23 22 21 20 19 18 17 16 31 30 29 28 27 26 25 24

27 26 25 24 23 22 21 20 215 214 213 212 211 210 29 28

Pdu - - - - - - - - - - - - - - - -

Figure 6.8: PackingByteOrder Example

- AUTOSAR Confidential -
2 20.03.2007 AUTOSAR_SystemTemplate

The second example in Figure 6.9 for big endian shows again a Frame with four bytes
that contains a single Pdu that is two bytes long. The PduToFrameMapping.start-
Position is defined with 15 and since the packingByteOrder is set to mostSig-
nificantByteFirst the startPosition denotes the most significant bit of the
Pdu in the Frame.
Figure 6.9 also shows that the Pdu contains three ISignals. The first ISignal has
the ISignalToIPduMapping.startPosition defined as 7 and is 5 bits long. The
bitposition of the second signal is 2 and the length is 10 bits. And the third signal has
the bitposition 8 and is only 1 bit long. Since the ISignalToIPduMapping.pack-
ingByteOrder is defined with mostSignificantByteFirst as well the start-
Position of the ISignals denotes the most significant bit of the ISignal in the
PduToFrameMapping
Pdu.
Big Endian byte order:
Signal layout in Pdu:

Byte 1 2
Frame bit 15 14 13 12 11 10 9 8 23 22 21 20 19 18 17 16
Signal 24 23 22 2-1 2-0 2-9 2-8 2-7 2-6 25 24 23 22 21 20 20
Pdu bit 7 6 5 4- 3- 2- 1- 0- 15
- 14 13 12 11 10 9 8

Pdu layout in Frame:

Byte 0 1 2 3
Bit 7 6 5 4 3 2 1 0 15 14 13 12 11 10 9 8 23 22 21 20 19 18 17 16 31 30 29 28 27 26 25 24

Pdu - - - - - - - - 215 214 213 212 211 210 29 28 27 26 25 24 23 22 21 20 - - - - - - - -

Figure 6.9: PackingByteOrder Example

- AUTOSAR Confidential -
3 20.03.2007 AUTOSAR_SystemTemplate

Please note that the positioning of SegmentPositions in a MultiplexedIPdu

works in the exact same way. The examples in Figure 6.8 and Figure 6.9 can be
taken as well as an example for a MultiplexedIPdu where the 1 bit signal defines

286 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

the selectorField and the other two signals represent segments defined for the Dynam-
icPart.

287 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.3 PDUs
The chapter introduces the different Pdu types that are supported in the AUTOSAR
Architecture and by the AUTOSAR Meta-Model.
The PDU Router is responsible only for the routing of IPdus. Other Pdus that are
direct specializations of the Pdu meta-class are not routed by the PDU Router.
UserDefinedPdus and UserDefinedIPdus are used to describe PDU-based com-
munication over Complex Drivers. Chapter 6.14 provides a more detailed description
of CDDs.

288 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

FibexElement Identifiable FibexElement

Frame PhysicalChannel EcuInstance

+ frameLength: Integer [0..1] + comConfigurationGwTimeBase: TimeValue [0..1]

+ comConfigurationRxTimeBase: TimeValue [0..1]
+ comConfigurationTxTimeBase: TimeValue [0..1]
+managedPhysicalChannel 0..* + comEnableMDTForCyclicTransmission: Boolean [0..1]
«atpVariation»
+pduToFrameMapping 0..* + ethSwitchPortGroupDerivation: Boolean [0..1]
+ pncPrepareSleepTimer: TimeValue [0..1]
Identifiable + pncSynchronousWakeup: Boolean [0..1]
«atpPrototype» + pnResetTime: TimeValue [0..1]
PduToFrameMapping «atpVariation,atpSplitable» + sleepModeSupported: Boolean
+ v2xSupported: V2xSupportEnum [0..1]
+ packingByteOrder: ByteOrderEnum + wakeUpOverBusSupported: Boolean
+ startPosition: Integer
+ updateIndicationBitPosition: Integer [0..1]

+pdu 1 +pduTriggering 0..* +associatedPdurIPduGroup *

FibexElement Identifiable FibexElement
+iPdu
Pdu PduTriggering PdurIPduGroup
+iPdu
+ hasDynamicLength: Boolean [0..1] 0..* «atpVariation» + communicationMode: String
+ length: UnlimitedInteger [0..1] 1

NmPdu IPdu UserDefinedPdu GeneralPurposePdu

+ nmDataInformation: Boolean [0..1] + cddType: String [0..1]
+ nmVoteInformation: Boolean [0..1]
+ unusedBitPattern: Integer [0..1]

0..*
+nmPdu

DcmIPdu SecuredIPdu
NPdu GeneralPurposeIPdu
+ diagPduType: DiagPduType + useAsCryptographicIPdu: Boolean [0..1]
+ useSecuredPduHeader: SecuredPduHeaderEnum [0..1]

MultiplexedIPdu UserDefinedIPdu
+ selectorFieldByteOrder: ByteOrderEnum [0..1] ISignalIPdu
+ cddType: String [0..1]
+ selectorFieldLength: Integer [0..1] + unusedBitPattern: Integer
+ selectorFieldStartPosition: Integer [0..1]
+ triggerMode: TriggerMode [0..1]
+ unusedBitPattern: Integer [0..1] ContainerIPdu

+ containerTimeout: TimeValue [0..1]

J1939DcmIPdu + containerTrigger: ContainerIPduTriggerEnum [0..1]
+ headerType: ContainerIPduHeaderTypeEnum
+ diagnosticMessageType: PositiveInteger [0..1] + minimumRxContainerQueueSize: PositiveInteger [0..1]
+ minimumTxContainerQueueSize: PositiveInteger [0..1]
+ rxAcceptContainedIPdu: RxAcceptContainedIPduEnum
+ thresholdSize: PositiveInteger [0..1]
+ unusedBitPattern: PositiveInteger [0..1]

+iSignalIPdu 0..*
«atpVariation»
+associatedComIPduGroup *

FibexElement
ISignalIPduGroup
«atpVariation» + communicationDirection: CommunicationDirectionType
+ communicationMode: String

+containedISignalIPduGroup
0..*

Figure 6.10: Pdus and the mapping into Frames (FibexCore: PDUOverview)

The PduToFrameMapping element describes the mapping of Pdus to Frames and

defines the position of a Pdu within a Frame. By using different PduToFrameMap-
pings it is possible to use the same Pdu in different Frames.

289 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_3516] limitation of Frame.frameLength for CAN L-PDUs dThe Frame.

frameLength of CAN PDUs shall be restricted to 0..8 for classic CAN L-PDUs and
0..8, 12, 16, 20, 24, 32, 48, 64 for CAN FD L-PDUs.c()
Please note that only a single Pdu is allowed to be mapped into a CAN Frame. The
Pdu.length of the Pdu that is mapped into the CAN Frame is allowed to be smaller
then the Frame.frameLength if padding is configured.
A timing description IPduTiming can be aggregated directly by the ISignalIPdu.
This timing description can be used for the Configuration of COM Transmission Modes.
The PduTriggering describes on which channel the Pdu is transmitted. Timing re-
quirements may be specified with the Timing Extension model. More details are de-
scribed in chapter 1.7.3. Such Pdu timing requirements needs to be fulfilled by the
timing specification on the Frame.
Class Pdu (abstract)
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note Collection of all Pdus that can be routed through a bus interface.
Base ARObject, CollectableElement, FibexElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Subclasses GeneralPurposePdu, IPdu, NmPdu, UserDefinedPdu
Attribute Type Mult. Kind Note
hasDynamic Boolean 0..1 attr This attribute defines whether the Pdu has dynamic
Length length (true) or not (false). Please note that the usage of
this attribute is restricted by [constr_3448].
length UnlimitedInteger 0..1 attr Pdu length in bytes. In case of dynamic length IPdus
(containing a dynamical length signal), this value
indicates the maximum data length. It should be noted
that in former AUTOSAR releases (Rel 2.1, Rel 3.0, Rel
3.1, Rel 4.0 Rev. 1) this parameter was defined in bits.
The Pdu length of zero bytes is allowed.

Table 6.21: Pdu

[constr_5249] Existence of Pdu.length dFor each Pdu, attribute length shall exist
at the time when the Ecu configuration of the COM stack is created.c()
Reason: Bsw modules might buffer the payload of the Pdu and for this purpose the
Pdu.length needs to be provided. A second reason is that future extensions of the
Pdu can be prepared by setting the length to an appropriate value.
[constr_5321] Value range of Pdu.length dThe value of Pdu.length shall be in the
range of 0..4294967295 Bytes.c()
[constr_3448] Restriction for usage of Pdu.hasDynamicLength dThe Pdu.hasDy-
namicLength attribute is only relevant for UserDefinedPdus, UserDefinedIPdus,
J1939DcmIPdus.c()
For the remaining (I)Pdus, the fact whether they are dynamic or not should be derivable
from the configuration of the upper layer:
• ISignalIPdu: At least one dynamic signal mapped to the PDU.

290 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• SecuredIPdu and MultiplexedIPdu: At least one of the associated upper

layer PDUs has dynamic length.
• ContainerIPdu: Pdu is dynamic if:
– the headerType is shortHeader or longHeader.
– the headerType is noHeader and the last contained PDU has dynamic
length.
• NPdu: TP layer takes care of length handling, not visible to application.
• DcmIPdu: always dynamic
• NmPdu: always static
• GeneralPurposePdu and GeneralPurposeIPdu: Depending on upper layer,
which could be: SD, TSync, DoIP, XCP, SomeIpTp, Dlt.
Class IPdu (abstract)
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note The IPdu (Interaction Layer Protocol Data Unit) element is used to sum up all Pdus that are routed by the
PduR.
Base ARObject, CollectableElement, FibexElement, Identifiable, MultilanguageReferrable, Packageable
Element, Pdu, Referrable
Subclasses ContainerIPdu, DcmIPdu, GeneralPurposeIPdu, ISignalIPdu, J1939DcmIPdu, MultiplexedIPdu, NPdu,
SecuredIPdu, UserDefinedIPdu
Attribute Type Mult. Kind Note
containedIPdu ContainedIPduProps 0..1 aggr Defines whether this IPdu may be collected inside a
Props ContainerIPdu.

Table 6.22: IPdu

Class ISignalIPdu
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note Represents the IPdus handled by Com. The ISignalIPdu assembled and disassembled in AUTOSAR
COM consists of one or more signals. In case no multiplexing is performed this IPdu is routed to/from the
Interface Layer.
A maximum of one dynamic length signal per IPdu is allowed.
Tags:atp.recommendedPackage=Pdus
Base ARObject, CollectableElement, FibexElement, IPdu, Identifiable, MultilanguageReferrable, Packageable
Element, Pdu, Referrable
Attribute Type Mult. Kind Note
iPduTiming IPduTiming 0..1 aggr Timing specification for Com IPdus (Transmission
Specification Modes). This information is mandatory for the sender in a
System Extract. This information may be omitted on
receivers in a System Extract.
atpVariation: The timing of a Pdu can vary.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
5

291 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class ISignalIPdu
iSignalToPdu ISignalToIPduMapping * aggr Definition of SignalToIPduMappings included in the Signal
Mapping IPdu.
atpVariation: The content of a PDU can be variable.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
unusedBit Integer 1 attr AUTOSAR COM and AUTOSAR IPDUM are filling not
Pattern used areas of an IPDU with this bit-pattern. This attribute
is mandatory to avoid undefined behavior. This
byte-pattern will be repeated throughout the IPdu.

Table 6.23: ISignalIPdu

Class NmPdu
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note Network Management Pdu
Tags:atp.recommendedPackage=Pdus
Base ARObject, CollectableElement, FibexElement, Identifiable, MultilanguageReferrable, Packageable
Element, Pdu, Referrable
Attribute Type Mult. Kind Note
iSignalToIPdu ISignalToIPduMapping * aggr This optional aggregation is used to describe NmUser
Mapping Data that is transmitted in the NmPdu. The counting of
the startPosition starts at the beginning of the NmPdu
regardless whether Cbv or Nid are used.
nmData Boolean 0..1 attr Defines if the Pdu contains NM Data. If the NmPdu does
Information not aggregate any ISignalToIPduMappings it still may
contain UserData that is set via Nm_SetUserData(). If the
ISignalToIPduMapping exists then the nmDataInformation
attribute shall be ignored.
nmVote Boolean 0..1 attr Defines if the Pdu contains NM Vote information.
Information
unusedBit Integer 0..1 attr AUTOSAR COM is filling not used areas of an Pdu with
Pattern this bit-pattern. This attribute can only be used if the nm
DataInformation attribute is set to true.
Table 6.24: NmPdu

Please note that in AUTOSAR only FrNm is able to send out NmPdus with and without
voting information:
[constr_3073] nmVoteInformation only valid for FrNm dThe nmVoteInforma-
tion attribute is only valid for FrNm.c()
Class NPdu
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note This is a Pdu of the Transport Layer. The main purpose of the TP Layer is to segment and reassemble
IPdus.
Tags:atp.recommendedPackage=Pdus
Base ARObject, CollectableElement, FibexElement, IPdu, Identifiable, MultilanguageReferrable, Packageable
Element, Pdu, Referrable
Attribute Type Mult. Kind Note
5

292 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class NPdu
– – – – –
Table 6.25: NPdu

Class DcmIPdu
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note Represents the IPdus handled by Dcm.
Tags:atp.recommendedPackage=Pdus
Base ARObject, CollectableElement, FibexElement, IPdu, Identifiable, MultilanguageReferrable, Packageable
Element, Pdu, Referrable
Attribute Type Mult. Kind Note
diagPduType DiagPduType 1 attr Attribute is used to distinguish a request from a response.

Table 6.26: DcmIPdu

293 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Enumeration DiagPduType
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note Used to distinguish a diagnostic request from a response.
Literal Description
diagRequest Diagnostic Request
Tags:atp.EnumerationLiteralIndex=0
diagResponse Diagnostic Response
Tags:atp.EnumerationLiteralIndex=1

Table 6.27: DiagPduType

Class J1939DcmIPdu
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note Represents the IPdus handled by J1939Dcm.
Tags:atp.recommendedPackage=Pdus
Base ARObject, CollectableElement, FibexElement, IPdu, Identifiable, MultilanguageReferrable, Packageable
Element, Pdu, Referrable
Attribute Type Mult. Kind Note
diagnostic PositiveInteger 0..1 attr This attribute is used to identify the actual DMx message,
MessageType e.g 1 means DM01, etc.

Table 6.28: J1939DcmIPdu

[constr_3096] Allowed values for diagnosticMessageType dThe allowed values

of diagnosticMessageType range from 1..57.c()
Class GeneralPurposePdu
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note This element is used for AUTOSAR Pdus without additional attributes that are routed by a bus interface.
Please note that the category name of such Pdus is standardized in the AUTOSAR System Template.
Tags:atp.recommendedPackage=Pdus
Base ARObject, CollectableElement, FibexElement, Identifiable, MultilanguageReferrable, Packageable
Element, Pdu, Referrable
Attribute Type Mult. Kind Note
– – – – –
Table 6.29: GeneralPurposePdu

294 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_3081] Value of category in GeneralPurposePdu dThe attribute category

of GeneralPurposePdu can have the following values:
• SD (Service Discovery)
• GLOBAL_TIME
• DoIP
c()
Class GeneralPurposeIPdu
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note This element is used for AUTOSAR Pdus without attributes that are routed by the PduR. Please note that
the category name of such Pdus is standardized in the AUTOSAR System Template.
Tags:atp.recommendedPackage=Pdus
Base ARObject, CollectableElement, FibexElement, IPdu, Identifiable, MultilanguageReferrable, Packageable
Element, Pdu, Referrable
Attribute Type Mult. Kind Note
– – – – –
Table 6.30: GeneralPurposeIPdu

[constr_3082] Value of category in GeneralPurposeIPdu dThe attribute cate-

gory of GeneralPurposeIPdu can have the following values:
• XCP
• SOMEIP_SEGMENTED_IPDU
• DLT
c()
Class UserDefinedPdu
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note UserDefinedPdu allows to describe PDU-based communication over Complex Drivers. If a new BSW
module is added above the BusIf (e.g. a new Nm module) then this Pdu element shall be used to
describe the communication.
Tags:atp.recommendedPackage=Pdus
Base ARObject, CollectableElement, FibexElement, Identifiable, MultilanguageReferrable, Packageable
Element, Pdu, Referrable
Attribute Type Mult. Kind Note
cddType String 0..1 attr This attribute defines the CDD that transmits or receives
the UserDefinedIPdu. If several CDDs are defined this
attribute is used to distinguish between them.

Table 6.31: UserDefinedPdu

Class UserDefinedIPdu
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
5

295 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class UserDefinedIPdu
Note UserDefinedIPdu allows to describe PDU-based communication over Complex Drivers. If a new BSW
module is added above the PduR (e.g. a Diagnostic Service ) then this IPdu element shall be used to
describe the communication.
Tags:atp.recommendedPackage=Pdus
Base ARObject, CollectableElement, FibexElement, IPdu, Identifiable, MultilanguageReferrable, Packageable
Element, Pdu, Referrable
Attribute Type Mult. Kind Note
cddType String 0..1 attr This attribute defines the CDD that transmits or receives
the UserDefinedPdu. If several CDDs are defined this
attribute is used to distinguish between them.

Table 6.32: UserDefinedIPdu

Class <<atpPrototype>> PduToFrameMapping

Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note A PduToFrameMapping defines the composition of Pdus in each frame.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
packingByte ByteOrderEnum 1 attr This attribute defines the order of the bytes of the Pdu
Order and the packing into the Frame. Please consider that
[constr_3246] and [constr_3222] are restricting the usage
of this attribute.
pdu Pdu 1 ref Reference to a I-Pdu, N-Pdu or NmPdu that is transmitted
in the Frame.
startPosition Integer 1 attr This attribute describes the bitposition of a Pdu within a
Frame.
Please note that the absolute position of the Pdu in the
Frame is determined by the definition of the packingByte
Order attribute. If Big Endian is specified, the start
position indicates the bit position of the most significant bit
in the Frame. If Little Endian is specified, the start position
indicates the bit position of the least significant bit in the
Frame. The bit counting in byte 0 starts with bit 0 (least
significant bit). The most significant bit in byte 0 is bit 7.
The Pdus are byte aligned in a Frame and only the values
0, 8, 16, 24,... (for little endian) and 7, 15, 23, ... (for big
endian) are allowed.
update Integer 0..1 attr Indication to the receivers that the corresponding Pdu
IndicationBit was updated by the sender. This attribute describes the
Position position of the update bit in the frame that aggregates this
PDUToFrameMapping. Length is always one bit.
Note that the exact bit position of the updateIndicationBit
Position is linked to the value of the attribute packingByte
Order because the method of finding the bit position is
different for the values mostSignificantByteFirst and most
SignificantByteLast. This means that if the value of
packingByteOrder is changed while the value of update
IndicationBitPosition remains unchanged the exact bit
position of updateIndicationBitPosition within the
enclosing Frame still undergoes a change.
This attribute denotes the least significant bit for "Little
Endian" and the most significant bit for "Big Endian"
packed signals within the IPdu (see the description of the
5

296 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class <<atpPrototype>> PduToFrameMapping
4
packingByteOrder attribute). In AUTOSAR the bit
counting is always set to "sawtooth" and the bit order is
set to "Decreasing". The bit counting in byte 0 starts with
bit 0 (least significant bit). The most significant bit in byte
0 is bit 7.

Table 6.33: PduToFrameMapping

[constr_3246] Frame.packingByteOrder mix within a Frame is not allowed dAll

PduToFrameMappings within a Frame shall have the same packingByteOrder
value.c()
Please note that the absolute position (bit-position) of the Pdu in the Frame is de-
termined by the definition of the packingByteOrder attribute. The Pdus are byte
aligned in a Frame and the values 0, 8, 16, 24,... (for little endian) and 7, 15, 23, ... (for
big endian) are allowed. For reasons of simplicity a mix of the packingByteOrder is
not allowed.
[constr_3222] No ByteOrderEnum.opaque allowed for PduToFrameMapping.
packingByteOrder dThe values of PduToFrameMapping.packingByteOrder
are restricted to ByteOrderEnum.mostSignificantByteFirst and Byte-
OrderEnum.mostSignificantByteLast. I.e. the value ByteOrderEnum.opaque
is not allowed.c()

297 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class IPduTiming
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note AUTOSAR COM provides the possibility to define two different TRANSMISSION MODES for each IPdu.
The Transmission Mode of an IPdu that is valid at a specific point in time is selected using the values of
the signals that are mapped to this IPdu. For each IPdu a Transmission Mode Selector is defined. The
Transmission Mode Selector is calculated by evaluating the conditions for a subset of signals (class
TransmissionModeCondition in the System Template).
The Transmission Mode Selector is defined to be true, if at least one Condition evaluates to true and is
defined to be false, if all Conditions evaluate to false.
Base ARObject, Describable
Attribute Type Mult. Kind Note
minimumDelay TimeValue 0..1 attr Minimum Delay in seconds between successive
transmissions of this I-PDU, independent of the
Transmission Mode.
transmission TransmissionMode 0..1 aggr AUTOSAR COM allows configuring statically two different
Mode Declaration transmission modes for each I-PDU (True and False). The
Declaration Transmission Mode Selector evaluates the conditions for
a subset of signals and decides the transmission mode. It
is possible to switch between the transmission modes
during runtime.

Table 6.34: IPduTiming

Class PduTriggering
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note The PduTriggering describes on which channel the IPdu is transmitted. The Pdu routing by the PduR is
only allowed for subclasses of IPdu.
Depending on its relation to entities such channels and clusters it can be unambiguously deduced
whether a fan-out is handled by the Pdu router or the Bus Interface.
If the fan-out is specified between different clusters it shall be handled by the Pdu Router. If the fan-out is
specified between different channels of the same cluster it shall be handled by the Bus Interface.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
iPdu Pdu 1 ref Reference to the Pdu for which the PduTriggering is
defined. One I-Pdu can be triggered on different channels
(PduR fan-out). The Pdu routing by the PduR is only
allowed for subclasses of IPdu.
Nevertheless is the reference to the Pdu element
necessary since the PduTriggering element is also used
to specify the sending and receiving connections to Ecu
Ports.
iPduPort IPduPort * ref References to the IPduPort on every ECU of the system
which sends and/or receives the I-PDU.
References for both the sender and the receiver side
shall be included when the system is completely defined.
iSignal ISignalTriggering * ref This reference provides the relationship to the ISignal
Triggering Triggerings that are implemented by the PduTriggering.
The reference is optional since no ISignalTriggering can
be defined for DCM and Multiplexed Pdus.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
5

298 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class PduTriggering
secOcCrypto SecOcCryptoService 0..1 ref This reference identifies the crypto profile applicable to
Mapping Mapping the usage (send, receive) of the also referenced Secured
IPdu.
Obviously, this reference is only applicable if the
Pdutriggering also references a SecuredIPdu in the role i
Pdu.
triggerIPduSend TriggerIPduSend * aggr Defines the trigger for the Com_TriggerIPDUSend API
Condition Condition call. Only if all defined TriggerIPduSendConditions
evaluate to true (AND associated) the Com_Trigger
IPDUSend API shall be called.

Table 6.35: PduTriggering

AUTOSAR COM provides a mechanism of starting/stopping COM PDU groups (ISig-

nalIPduGroup). Please note that in a System Model an ISignalIPdu can belong
to several ISignalIPduGroups of different EcuInstances. So it is not possible
to deduce the assignment of an ISignalIPduGroup to an EcuInstance via the
iSignalIPdus that are included in the ISignalIPduGroup. The assignment of
an ISignalIPduGroup to an EcuInstance is therefore realized with the EcuIn-
stance.associatedComIPduGroup reference.
Please note that the EcuInstance.associatedComIPduGroup reference is only
used to assign the top-level ISignalIPduGroups to an EcuInstance. The assign-
ment of the containedISignalIPduGroups to an EcuInstance is done via the
aggregating ISignalIPduGroup that in turn is referenced by an EcuInstance.

ECU 1 ECU 2

ISignalIPduGroup ISignalIPduGroup ISignalIPduGroup

1A 1B 2C

ISignalIPduGroup ISignalIPduGroup
1A1 2C1

ISignalIPdu z ISignalIPdu x ISignalIPdu y

Figure 6.11: Example for ISignalIPduGroups and their assignment to EcuInstances

- AUTOSAR Confidential -
1 05.02.2008 ECU Extract - Specification Improvement

299 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class ISignalIPduGroup
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note The AUTOSAR COM Layer is able to start and to stop sending and receiving configurable groups of
I-Pdus during runtime. An ISignalIPduGroup contains either ISignalIPdus or ISignalIPduGroups.
Tags:atp.recommendedPackage=ISignaliPduGroup
Base ARObject, CollectableElement, FibexElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
communication Communication 1 attr This attribute determines in which direction IPdus that are
Direction DirectionType contained in this IPduGroup will be transmitted
(communication direction can be either In or Out).
communication String 1 attr This attribute defines the use-case for this ISignalIPdu
Mode Group (e.g. diagnostic, debugging etc.). For example, in a
diagnostic mode all IPdus - which are not involved in
diagnostic - are disabled. The use cases are not limited to
a fixed enumeration and can be specified as a string.
contained ISignalIPduGroup * ref An I-Pdu group can be included in other I-Pdu groups.
ISignalIPdu Contained I-Pdu groups shall not be referenced by the
Group EcuInstance.
iSignalIPdu ISignalIPdu * ref Reference to a set of Signal I-Pdus, which are contained
in the ISignal I-Pdu Group.
atpVariation: The content of a ISignal I-Pdu group can
vary (->vehicle modes).
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
nmPdu NmPdu * ref Reference to a set of NmPdus with NmUserData, which
are contained in the ISignalIPduGroup.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild

Table 6.36: ISignalIPduGroup

Enumeration CommunicationDirectionType
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note Describes the communication direction.
Literal Description
in Reception (Input)
Tags:atp.EnumerationLiteralIndex=0
out Transmission (Output)
Tags:atp.EnumerationLiteralIndex=1

Table 6.37: CommunicationDirectionType

[constr_3020] communicationDirection of containedISignalIPduGroups

dThe value of the attribute communicationDirection of containedISignalIP-
duGroup shall be identical to the value of the attribute communicationDirection
of the enclosing ISignalIPduGroup.c()
The AUTOSAR Pdu Router provides a mechanism of enabling/disabling of routing path
groups (PdurIPduGroup).

300 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Please note that in a System Model a PduTriggering can belong to several

PdurIPduGroups of different EcuInstances. So it is not possible to deduce the as-
signment of an PdurIPduGroup to an EcuInstance via the PduTriggerings that
are included in the ISignalIPduGroup. The assignment of an PdurIPduGroup to
an EcuInstance is therefore realized with the EcuInstance.associatedPdurIP-
duGroup reference.
Class PdurIPduGroup
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note The AUTOSAR PduR will enable and disable the sending of configurable groups of IPdus during runtime
according to the AUTOSAR PduR specification.
Tags:atp.recommendedPackage=PdurIPduGroups
Base ARObject, CollectableElement, FibexElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
communication String 1 attr This attribute defines the use-case for this PduRIPdu
Mode Group. For example, in a diagnostic mode all IPdus -
which are not involved in diagnostic - are disabled. The
use cases are not limited to a fixed enumeration and can
be specified as a string.
iPdu PduTriggering * ref Reference to a set of IPdus, which are contained in the
PduR I-Pdu Group. If an IPdu is routed by the PduR to
different destinations (PduR fan-out) than an Pdu
Triggering for each destination is created in the System
Template. To enable/disable a specific destination the
PdurIPduGroup refers to the PduTriggering.
atpVariation: The content of a PduR I-Pdu group can vary
(->vehicle modes).
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild

Table 6.38: PdurIPduGroup

6.3.1 ContainerIPdu

IPdu collection
Multiple PDU to is usedMapping
Frame to transport several (smaller) IPdus in one (large) Con-
tainerIPdu. A possible use case for example is the extended payload size for Eth-
ernet and CanFd in combination with the limited payload of Can and Lin, where Pdus
from Format
a Can ofnetwork shall be
a dynamically routedPDUs
mapped onto within
an Ethernet network and then back to a Can
a PDU container
again. Header size has to be configured per PDU container

Header1 I-PDU Header2 I-PDU … PDU-Container

PDU Header

ID DLC

Figure 6.12: Layout of a ContainerIPdu if HeaderMode is used

Short Header Full Header

ID 24 bit ID 32 bit
301 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate
DLC 8 bit DLC 32 bit
System Template
AUTOSAR CP R21-11

For each IPdu which is put inside a ContainerIPdu, a header may be pro-
vided which determines which IPdu is contained (ContainedIPduProps.head-
erIdLongHeader or headerIdShortHeader) and what the size of that IPdu is (
DLC during runtime). With this header mode the receivers are able to extract the in-
dividual contained IPdus again. As an alternative option to the usage of headers a
statically configured layout of IPdus in the ContainerIPdu is supported.
FibexElement
Pdu

+ hasDynamicLength: Boolean [0..1]

+ length: UnlimitedInteger [0..1]

+iPdu 1

Identifiable +containedPduTriggering
PduTriggering
0..1

+containedPduTriggering 0..*
ContainedIPduProps

+ collectionSemantics: ContainedIPduCollectionSemanticsEnum +containedIPduProps IPdu

+ headerIdLongHeader: PositiveInteger [0..1]
0..1
+ headerIdShortHeader: PositiveInteger [0..1]
+ offset: PositiveInteger [0..1]
+ priority: PositiveInteger [0..1]
+ timeout: TimeValue [0..1]
+ trigger: PduCollectionTriggerEnum [0..1]
+ updateIndicationBitPosition: PositiveInteger [0..1]

+containedIPduTriggeringProps 0..*

ContainerIPdu

+ containerTimeout: TimeValue [0..1]

+ containerTrigger: ContainerIPduTriggerEnum [0..1]
+ headerType: ContainerIPduHeaderTypeEnum
+ minimumRxContainerQueueSize: PositiveInteger [0..1]
+ minimumTxContainerQueueSize: PositiveInteger [0..1]
+ rxAcceptContainedIPdu: RxAcceptContainedIPduEnum
+ thresholdSize: PositiveInteger [0..1]
+ unusedBitPattern: PositiveInteger [0..1]

«enumeration»
«enumeration» ContainerIPduHeaderTypeEnum «enumeration» «enumeration»
RxAcceptContainedIPduEnum ContainerIPduTriggerEnum PduCollectionTriggerEnum
shortHeader
acceptAll longHeader firstContainedTrigger always
acceptConfigured noHeader defaultTrigger never

«enumeration»
ContainedIPduCollectionSemanticsEnum

lastIsBest
queued

Figure 6.13: ContainerIPdu with ContainedIPduProps

Class ContainerIPdu
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note Allows to collect several IPdus in one ContainerIPdu based on the headerType.
Tags:atp.recommendedPackage=Pdus
Base ARObject, CollectableElement, FibexElement, IPdu, Identifiable, MultilanguageReferrable, Packageable
Element, Pdu, Referrable
Attribute Type Mult. Kind Note
containedIPdu ContainedIPduProps * aggr Defines properties for an IPdu that is part of the
TriggeringProps ContainerIPdu.
containedPdu PduTriggering * ref This PduTriggering shall be collected inside the Container
Triggering IPdu.
5

302 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class ContainerIPdu
container TimeValue 0..1 attr When this timeout expires the ContainerIPdu is sent out.
Timeout The respective timer is started when the first Ipdu is put
into the ContainerIPdu. This attribute is ignored on
receiver side.
containerTrigger ContainerIPduTrigger 0..1 attr Defines if the transmission of the ContainerIPdu shall be
Enum requested right after the first ContainedIPdu was put into
it. This attribute shall be ignored on receiver side.
headerType ContainerIPduHeader 1 attr Defines whether and which header type is used (header
TypeEnum id and length).
minimumRx PositiveInteger 0..1 attr This attribute defines the minimum queue size for
Container received containers.
QueueSize
minimumTx PositiveInteger 0..1 attr This attribute defines the minimum queue size for
Container transmitted containers.
QueueSize
rxAccept RxAcceptContainedI 1 attr Defines whether this ContainerIPdu has a fixed set of
ContainedIPdu PduEnum containedIPdus assigned for reception.
thresholdSize PositiveInteger 0..1 attr Defines the size threshold which, when exceeded,
triggers the sending of the ContainerIPdu although the
maximum Pdu size has not been reached yet. Unit: byte.
unusedBit PositiveInteger 0..1 attr IPduM fills not updated areas of the ContainerPdu with
Pattern this byte-pattern.

Table 6.39: ContainerIPdu

[constr_3436] Value range of minimumTxContainerQueueSize and minimum-

RxContainerQueueSize dIf defined, the value of minimumTxContainerQueue-
Size and minimumRxContainerQueueSize shall be in the range of 0..255.c()
Enumeration ContainerIPduTriggerEnum
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note Defines when the transmission of the ContainerIPdu shall be requested.
Literal Description
defaultTrigger Defines that the transmission of the ContainerIPdu shall be requested when the default trigger
conditions apply (e.g. timeout of threshold).
Tags:atp.EnumerationLiteralIndex=0
firstContained Defines that the transmission of the ContainerIPdu shall be requested right after the first Contained
Trigger IPdu was put into the ContainerIPdu.
Tags:atp.EnumerationLiteralIndex=1

Table 6.40: ContainerIPduTriggerEnum

Enumeration ContainerIPduHeaderTypeEnum
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note Is used to define the header type and size of ContainerIPdus. The header size includes the header id
and the length information.
Literal Description
5

303 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Enumeration ContainerIPduHeaderTypeEnum
longHeader Header size is 64 bit:
• Header Id 32 bit
• Dlc 32 bit
Tags:atp.EnumerationLiteralIndex=0
noHeader No Header is used and the location of each containedPdu in the ContainerPdu is statically configured.
Tags:atp.EnumerationLiteralIndex=2
shortHeader Header size is 32 bit:
• Header Id 24 bit
• Dlc 8 bit.
Tags:atp.EnumerationLiteralIndex=1

Table 6.41: ContainerIPduHeaderTypeEnum

Enumeration RxAcceptContainedIPduEnum
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note Defines whether this ContainerIPdu has a fixed set of containedIPdus assigned for reception.
Literal Description
acceptAll No fixed set of containedIPdus is defined for reception, any known containedIPdu (based on header
Id) shall be expected within this ContainerIPdu.
Tags:atp.EnumerationLiteralIndex=0
acceptConfigured A fixed set of containedIPdus is defined for reception. Only these assigned containedIPdus (based on
headerId) are expected in this ContainerIPdu. If a not assigned containedIPdu is received within this
ContainerIPdu this containedIPdu is discarded.
Tags:atp.EnumerationLiteralIndex=1

Table 6.42: RxAcceptContainedIPduEnum

Class ContainedIPduProps
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note Defines the aspects of an IPdu which can be collected inside a ContainerIPdu.
Base ARObject
Attribute Type Mult. Kind Note
collection ContainedIPdu 1 attr Defines whether this ContainedIPdu shall be collected
Semantics CollectionSemantics using a last-is-best or queued semantics.
Enum
containedPdu PduTriggering 0..1 ref Reference to Pdu for which the ContainedIPduProps are
Triggering valid.
headerIdLong PositiveInteger 0..1 attr Defines the header id this IPdu shall have in case this
Header IPdu is put inside a ContainerIPdu with headerType =
longHeader.
headerIdShort PositiveInteger 0..1 attr Defines the header id this IPdu shall have in case this
Header IPdu is put inside a ContainerIPdu with headerType =
shortHeader.
offset PositiveInteger 0..1 attr Byte offset that describes the location of the Contained
Pdu in the ContainerPdu if no header is used.
priority PositiveInteger 0..1 attr Defines a priority of a ContainedTxPdu. 255 represents
the lowest priority and 0 represent the highest priority.
5

304 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class ContainedIPduProps
timeout TimeValue 0..1 attr Defines a IPdu specific sender timeout which can reduce
the ContainerIPdu timer when this containedIPdu is put
inside the ContainerIPdu. This attribute is ignored on
receiver side.
trigger PduCollectionTrigger 0..1 attr Defines whether this IPdu does trigger the sending of the
Enum ContainerIPdu. This attribute is ignored on receiver side.
update PositiveInteger 0..1 attr The updateIndicationBit specifies the bit location of
IndicationBit ContainedIPdu Update-Bit in the Container PDU. It
Position indicates to the receivers that the ContainedIPdu in the
ContainerIPdu was updated.

Table 6.43: ContainedIPduProps

[constr_5268] Existence of ContainedIPduProps.containedPduTriggering

reference dIf a ContainedIPduProps is aggregated at the ContainerIPdu in the
role ContainerIPdu.containedIPduTriggeringProps then the reference Con-
tainedIPduProps.containedPduTriggering shall exist.c()
[constr_5269] Exclusion of ContainedIPduProps.containedPduTriggering
reference dIf a ContainedIPduProps is aggregated at the IPdu in the role IPdu.
containedIPduProps then the reference ContainedIPduProps.containedP-
duTriggering shall NOT exist.c()
[constr_5270] Exclusive usage of ContainerIPdu.containedPduTrigger-
ing and ContainerIPdu.containedIPduTriggeringProps dA Container-
IPdu shall only have either ContainerIPdu.containedPduTriggering OR Con-
tainerIPdu.containedIPduTriggeringProps defined.c()
Note: [constr_5270] implies that a ContainerIPdu can define its contained
PduTriggerings either directly via ContainerIPdu.containedPduTriggering
or indirectly via ContainerIPdu.containedIPduTriggeringProps.
[TPS_SYST_02372] Precedence of ContainedIPduProps settings dIf a Con-
tainerIPdu aggregates ContainedIPduProps in the role containedIPduTrig-
geringProps then any IPdu.containedIPduProps defined at the IPdu which is
referenced by the PduTriggering in the role iPdu shall be ignored.c()
Note: [TPS_SYST_02372] applies to the ContainedIPduProps as a whole. This
means that it is NOT supported to just define a sub-set of attributes in the Con-
tainerIPdu.containedIPduTriggeringProps and take missing attributes from
the IPdu.containedIPduProps.
Enumeration ContainedIPduCollectionSemanticsEnum
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note Defines the collection semantics for ContainedIPdus.
Literal Description
lastIsBest The ContainedIPdu data will be fetched via TriggerTransmit just before the transmission executes.
Tags:atp.EnumerationLiteralIndex=0
5

305 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Enumeration ContainedIPduCollectionSemanticsEnum
queued The ContainedIPdu data will instantly be stored to the ContainerIPdu in the context of the Transmit
API.
Tags:atp.EnumerationLiteralIndex=1

Table 6.44: ContainedIPduCollectionSemanticsEnum

Enumeration PduCollectionTriggerEnum
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::ServiceInstances
Note Defines whether a Pdu contributes to the triggering of the data transmission if Pdu collection is
enabled.
Literal Description
always Pdu will trigger the transmission of the data.
Tags:atp.EnumerationLiteralIndex=0
never Pdu will be buffered and will not trigger the transmission of the data.
Tags:atp.EnumerationLiteralIndex=1

Table 6.45: PduCollectionTriggerEnum

[TPS_SYST_02062] Allowed ContainedIPduProps.headerIdLongHeader and

ContainedIPduProps.headerIdShortHeader values dContainedIPduProps.
headerIdLongHeader and ContainedIPduProps.headerIdShortHeader shall
be restricted to values different from 0 (all bits of the value set to 0).c(RS_SYST_00055)
Since the header information is larger than 8 bit the byte ordering of the header in-
side the ContainerIPdu needs to be defined. This is done at System level. Thus
all ContainerIPdus have the header information in the same byte order within one
System.
[TPS_SYST_02063] Byte order of ContainerIPdu header information dThe Sys-
tem.containerIPduHeaderByteOrder defines in which byte order the header in-
formation shall be put into the ContainerIPdu.c(RS_SYST_00055)
[constr_3140] No ByteOrderEnum.opaque allowed for System.container-
IPduHeaderByteOrder dThe values of System.containerIPduHeaderByte-
Order are restricted to ByteOrderEnum.mostSignificantByteFirst and Byte-
OrderEnum.mostSignificantByteLast. I.e. the value ByteOrderEnum.opaque
is not allowed.c()
The following assumptions lead to the modeling of the ContainerIPdu structure:
• [TPS_SYST_02097] Basic definition of contained IPdus dEvery IPdu for
which:
– IPdu.containedIPduProps are defined or
– the PduTriggering is referenced in the role containedIPduTrigger-
ingProps
can be collected inside a ContainerIPdu.c(RS_SYST_00055)

306 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• [TPS_SYST_02098] Header id and header type of a contained IPdu dA con-

tained IPdu shall always have the same headerId per header type (long or short
header), regardless in which ContainerIPdu it is collected. If noHeader is set
then the contained IPdu does not need to have a headerId.c(RS_SYST_00055)
• [TPS_SYST_02099] Relation between ContainerIPdu and contained
PduTriggerings on sender side dIn the scope of one EcuInstance a
PduTriggering that has a reference to an IPduPort with direction OUT shall
be referenced either
– by a ContainerIPdu in the role containedPduTriggering or
– ContainerIPdu.containedIPduTriggeringProps.containedP-
duTriggering
at most once.c(RS_SYST_00055)
• [TPS_SYST_02100] Relation between ContainerIPdu and contained
IPdus on receiver side dOn receiver side, it is not necessarily required to stat-
ically define which IPdus may be contained inside a ContainerIPdu if the
header mode is used. Thus it would be possible to update the senders of Con-
tainerIPdus and put different or additional IPdus inside.c(RS_SYST_00055)
The ContainerIPdu defines which IPdus may be collected inside that Con-
tainerIPdu (ContainerIPdu.containedPduTriggering or ContainerIPdu.
containedIPduTriggeringProps.containedPduTriggering). Dynamic as-
signment of a contained IPdu to different ContainerIPdus during run-time is not
supported by the IPdu multiplexer. Nevertheless it is allowed to collect an IPdu in
several ContainerIPdus since each of those ContainerIPdus can be transmitted
individually (on the same or on a different PhysicalChannel).
If a ContainerIPdu is transmitted on different PhysicalChannels this can be
described in a System Description by a single Pdu element that is referenced by
PduTriggerings of the different PhysicalChannels.
The content of the ContainerIPdu is described by PduTriggerings that are ref-
erenced in the role ContainerIPdu.containedPduTriggering or Container-
IPdu.containedIPduTriggeringProps.containedPduTriggering. Please
note that although the contained PduTriggerings will also be transmitted on the
same PhysicalChannels as the ContainerIPdu it is completely sufficient that
the contained PduTriggerings that are contained in the ContainerIPdu are ag-
gregated by one of the PhysicalChannels on which the ContainerIPdu will be
transmitted. It is irrelevant which PduTriggerings of which PhysicalChannels
are chosen to describe the content of the ContainerIPdu since the assignment of
the ContainerIPdu to PhysicalChannels is done only by the PduTriggerings
that are pointing to the ContainerIPdu.

307 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

The reason for this modeling is the configuration of the PduR. One use case in the
PduR is the enabling and disabling of Pdus by PdurIPduGroups. The PdurIP-
duGroup works on PduTriggerings and there is also the use case to enable/disable
the ContainedIPdus in the PduR.
[constr_3141] Only IPdus shall be part of a ContainerIPdu dThe PduTrig-
gering which is referenced in the role ContainerIPdu.containedPduTrig-
gering or ContainerIPdu.containedIPduTriggeringProps.containedP-
duTriggering shall refer to a subclass of an IPdu in the role PduTriggering.
iPdu.c()
Only subclasses of IPdus are handled by the PduR and therefore are available for the
ContainerIPdu.
For the sender side this assignment defines which IPdus may be collected inside
this ContainerIPdu. For the receiver side this assignment may be omitted if Con-
tainerIPdu.rxAcceptContainedIPdu is set to RxAcceptContainedIPduEnum.
acceptAll.
[TPS_SYST_02064] Reception acceptance of contained IPdus dContainer-
IPdu.rxAcceptContainedIPdu defines for the receiver side whether the list of
ContainerIPdu.containedPduTriggering or ContainerIPdu.containedIP-
duTriggeringProps.containedPduTriggering is a closed set.
If ContainerIPdu.rxAcceptContainedIPdu = RxAcceptContainedIPduEnum.
acceptConfigured, only those IPdus (based on headerId) which are refer-
enced by this ContainerIPdu in the role ContainerIPdu.containedPduTrig-
gering or ContainerIPdu.containedIPduTriggeringProps.containedP-
duTriggering are extracted from this ContainerIPdu.
If ContainerIPdu.rxAcceptContainedIPdu = RxAcceptContainedIP-
duEnum.acceptAll, the IPdus (based on headerId) which are referenced by this
ContainerIPdu in the role ContainerIPdu.containedPduTriggering or
ContainerIPdu.containedIPduTriggeringProps.containedPduTrigger-
ing are expected inside this ContainerIPdu but also any other IPdu is extracted
which is referenced by any other ContainerIPdu.rxAcceptContainedIPdu with
RxAcceptContainedIPduEnum.acceptAll set.c(RS_SYST_00055)
Thus all referenced IPdus which are referenced from ContainerIPdu.rxAccept-
ContainedIPdu with RxAcceptContainedIPduEnum.acceptAll form the set of
IPdus which are considered for the reception of ANY ContainerIPdu with Con-
tainerIPdu.rxAcceptContainedIPdu = RxAcceptContainedIPduEnum.ac-
ceptAll.
For the receiver side ContainerIPdu.containedPduTriggering or Container-
IPdu.containedIPduTriggeringProps.containedPduTriggering may be
omitted if ContainerIPdu.rxAcceptContainedIPdu is set to RxAcceptCon-
tainedIPduEnum.acceptAll. Such a ContainerIPdu will accept any of the

308 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

contained IPdus from the acceptAll IPdu set if they have the headerId (head-
erIdShortHeader or headerIdLongHeader) defined by the ContainerIPdu.
headerType configured.
There are use-cases where several IPdus with identical content are transported on the
vehicle networks. One motivation to design the communication structure like this is that
the communication timing attributes may be different and thus need to be represented
by different ISignalIPdus (i.e. different ISignalIPdu.iPduTimingSpecifica-
tion, e.g. to support the transmission on Can and Fr networks with different transmis-
sion modes). When the content of the IPdus is identical they can be transported using
the same header Id. Thus it is transparent for the receiver via which channel a specific
IPdu arrived in case of ContainerIPdu with acceptAll setting.
In such a setup it may occur that several PduTriggerings for IPdus with identical
header IDs are defined as candidates for the set of IPdus which are considered for
the reception of acceptAll ContainerIPdus. This is considered a valid setup and
shall be resolved during derivation to ECU Configuration.
The Ecu Configuration for ContainerIPdu.rxAcceptContainedIPdu = accep-
tAll uses a set of Contained Rx Pdus without a relation to Container Pdus. This set
is defined during derivation of the Ecu Configuration from the System Description. If
duplicates occur they are only included once in the set of Contained Rx Pdus.
In such a case there is additional information required to select which of these
PduTriggerings shall be taken for the configuration and which shall be omitted.
[TPS_SYST_02196] PduTriggering is referenced by several Container-
IPdus dIn case a PduTriggering is referenced in the role ContainerIPdu.
containedPduTriggering or ContainerIPdu.containedIPduTriggering-
Props.containedPduTriggering by several ContainerIPdus with Container-
IPdu.rxAcceptContainedIPdu = RxAcceptContainedIPduEnum.acceptAll
and has a reference to an IPduPort with direction IN then this PduTriggering shall
only be considered once for the set of IPdus which are considered for the reception of
acceptAll ContainerIPdus.c(RS_SYST_00055)
[constr_3403] Usage of ContainerIPdu.rxAcceptContainedIPdu if noHeader
is used dIf the ContainerIPdu.headerType is set to noHeader then the Con-
tainerIPdu.rxAcceptContainedIPdu attribute value shall be set to acceptCon-
figured.c()
[TPS_SYST_03014] Transmission triggering by the first contained IPdu put into
a ContainerIPdu dThe attribute ContainerIPdu.containerTrigger determines
whether the transmission of a ContainerIPdu shall be requested when the first con-
tained IPdu was put into the ContainerIPdu.
In case containerTrigger equals firstContainedTrigger the transmission of
the ContainerIPdu shall be requested when the first contained IPdu is put into the
ContainerIPdu.

309 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

In case containerTrigger equals defaultTrigger the transmission of the Con-

tainerIPdu shall be requested when the other trigger conditions defined by the
ContainerIPdu are fulfilled (e.g. containerTimeout, thresholdSize).c(RS_-
SYST_00055)
Note: This trigger condition is independent from PduCollectionTriggerEnum.al-
ways which is defined for specific IPdus. With the attribute ContainerIPdu.con-
tainerTrigger = firstContainedTrigger on the other hand, any contained
IPdu will trigger the ContainerIPdu transmission.
Rationale for this trigger condition is the efficient usage (allow the ContainerIPdus
to reach a certain fill level) of triggered transmission on time- (containerTrigger
typically set to firstContainedTrigger) and event-driven (containerTrigger
typically set to defaultTrigger) buses.
The ContainedIPduProps defines a header Id per ContainerIPdu.headerType
which shall be used in the Pdu header of the ContainerIPdu in case that the head-
erType is set to shortHeader or longHeader. In case that the headerType is set
to noHeader the layout of IPdus in the ContainerIPdu is statically configured and
no header Id is required.
[constr_3454] Unique headerIdLongHeader for acceptConfigured dFor a
ContainerIPdu with ContainerIPdu.rxAcceptContainedIPdu = RxAccept-
ContainedIPduEnum.acceptConfigured and ContainerIPdu.headerType =
longHeader the following shall apply: All referenced IPdus (via ContainerIPdu.
containedPduTriggering or ContainerIPdu.containedIPduTriggering-
Props.containedPduTriggering) shall have a unique ContainedIPduProps.
headerIdLongHeader within the scope of this ContainerIPdu.c()
[constr_3455] Unique headerIdShortHeader for acceptConfigured dFor a
ContainerIPdu with ContainerIPdu.rxAcceptContainedIPdu = RxAccept-
ContainedIPduEnum.acceptConfigured and ContainerIPdu.headerType =
shortHeader the following shall apply: All referenced IPdus (via ContainerIPdu.
containedPduTriggering or ContainerIPdu.containedIPduTriggering-
Props.containedPduTriggering) shall have a unique ContainedIPduProps.
headerIdShortHeader within the scope of this ContainerIPdu.c()
Note: With [constr_3454] and [constr_3455] it is possible to have the same header Id
value received in different ContainerIPdus. It just has to be guaranteed that in the
scope of one ContainerIPdu the reception of header Id is unambiguous.
[constr_3142] Mandatory headerIdLongHeader for longHeader dFor each
IPdu which is assigned to a ContainerIPdu in the role ContainerIPdu.con-
tainedPduTriggering or ContainerIPdu.containedIPduTriggeringProps.
containedPduTriggering with ContainerIPdu.headerType = longHeader
the ContainedIPduProps.headerIdLongHeader shall be defined.c()
[constr_3143] Mandatory headerIdShortHeader for shortHeader dFor each
IPdu which is assigned to a ContainerIPdu in the role ContainerIPdu.con-
tainedPduTriggering or ContainerIPdu.containedIPduTriggeringProps.

310 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

containedPduTriggering with ContainerIPdu.headerType = shortHeader

the ContainedIPduProps.headerIdShortHeader shall be defined.c()
[constr_3402] Mandatory offset if noHeader is used dFor each IPdu which
is assigned to a ContainerIPdu in the role ContainerIPdu.contained-
PduTriggering or ContainerIPdu.containedIPduTriggeringProps.con-
tainedPduTriggering with ContainerIPdu.headerType = noHeader the Con-
tainedIPduProps.offset shall be defined.c()
[constr_3404] Usage of ContainedIPduProps.updateIndicationBitPosi-
tion dContainedIPduProps.updateIndicationBitPosition is only allowed
to be set to a value if the headerType of the ContainerIPdu that contains the
IPdu with ContainerIPdu.containedPduTriggering or ContainerIPdu.con-
tainedIPduTriggeringProps.containedPduTriggering is set to noHeader.c
()
[constr_3405] Dynamic Length IPdu inside of a static configured Container-
IPdu dOnly the last contained IPdu (according to the ContainedIPduProps.off-
set) of a ContainerIPdu with static container layout (i.e., a ContainerIPdu with
headerType set to noHeader) is allowed to be a dynamic length IPdu (i.e, a con-
tained IPdu that at runtime may exhibit a length different from the one statically con-
figured via Pdu.length of the respective Pdu). All other contained IPdus of a Con-
tainerIPdu with static container layout have to be static length IPdus.c()
[TPS_SYST_02065] Contained IPdu specific transmission timeout dThe IPdu
specific transmission timeout can be specified at ContainedIPduProps.timeout.
If no ContainedIPduProps.timeout is provided the timeout from the Container-
IPdu shall be used (ContainerIPdu.containerTimeout).c(RS_SYST_00055)
The case where neither the ContainerIPdu.containerTimeout nor the Con-
tainedIPduProps.timeout is provided, will result in no time-based triggering of
ContainerIPdus which might lead to long delays or no transmission at all if no other
sending condition for this ContainerIPdu does occur (e.g. no further IPdu is col-
lected inside this ContainerIPdu).
[TPS_SYST_02066] ContainerIPdu.thresholdSize dThe attribute Container-
IPdu.thresholdSize defines the threshold when a ContainerIPdu shall be trig-
gered for transmission. If the payload size of the ContainerIPdu exceeds the value
of thresholdSize this ContainerIPdu shall be transmitted.c(RS_SYST_00055)
Note: The ContainerIPdu.thresholdSize supports the definition of a transmis-
sion threshold which takes the data transmission model of the communication into ac-
count. Especially when operating with variable length IPdus, only the maximum length
of these IPdus is defined in the System Description. Only having the maximumLength
information it is not possible to derive a sensible threshold for the ContainerIPdu
this variable length IPdu is collected in. Thus a ContainerIPdu would wait for fur-
ther contained IPdus. Using a transmission model it can be calculated that the average

311 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

size contained IPdu will not fit into that ContainerIPdu anymore and provide this as
a requirement in ContainerIPdu.thresholdSize.
Another use case for the ContainedIPduProps is to support the usage of optimized
trigger transmit collection of IPdus in ContainerIPdus. Therefore it is necessary
to distinguish between contained IPdus with lastIsBest (will be fetched via trigger
transmit just before the transmission executes) and those with queued semantics (will
instantly be stored in the context of the transmit API). This distinction is possible on the
level of single contained IPdus with the attribute collectionSemantics.
For all intents and purposes, the different handling of contained IPdus depending on
the semantics is supported by the attribute ContainedIPduProps.collectionSe-
mantics that allows the individual setting of the intended semantics per contained
IPdu.
[constr_3517] Consistent setting of ContainedIPduProps.collectionSeman-
tics in the context of one ContainerIPdu dThe value of the attribute Con-
tainedIPduProps.collectionSemantics shall be identical for all contained
IPdus within the context of a given ContainerIPdu.c()
[constr_3144] Mandatory IPdu.containedIPduProps for contained IPdus dFor
each IPdu which is assigned to a ContainerIPdu in the role ContainerIPdu.con-
tainedPduTriggering the IPdu.containedIPduProps shall be defined.c()
ContainedIPduProps is optional and may be ignored in case the IPdu is not
mapped into a ContainerIPdu. A use-case is that an IPdu is fan-out in the PduR
and one PduTriggering is part of a ContainerIPdu while the other PduTrigger-
ing is directly transported via a bus interface.
Another case where ContainedIPduProps aggregated at the IPdu are ignored is
described in [TPS_SYST_02372].
[constr_3488] Value range of ContainedIPduProps.priority dIf defined, the
value of ContainedIPduProps.priority shall be in the range of 0..255.c()
[constr_3489] ContainedIPduProps.priority is only applicable if a Con-
tainerIPdu header is used dContainedIPduProps.priority is only applicable
if the headerType of the ContainerIPdu is set to shortHeader or longHeader.c
()
[constr_3490] ContainedIPduProps.priority is only applicable if collec-
tionSemantics is set to lastIsBest dContainedIPduProps.priority is only
applicable if ContainedIPduProps.collectionSemantics is set to lastIs-
Best.c()

6.3.2 SecuredIPdu

AUTOSAR supports an authentication mechanism for critical data on the level of Pdus.

312 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_02060] SecuredIPdus dSecuredIPdu shall be used to describe an

IPdu that is protected against unauthorized manipulation and replay attacks.c(RS_-
SYST_00054)
Please note that several SecuredIPdus may exist with the same dataId value since
the same data may be transported on different channels.
[TPS_SYST_02148] Meaning of useAsCryptographicIPdu that is not set or set
to false dIf useAsCryptographicIPdu is not set or set to false the SecuredIPdu
contains the payload of an Authentic IPdu supplemented by additional Authentication
Information (Freshness Counter and an Authenticator).c(RS_SYST_00054)
[TPS_SYST_02149] Meaning of useAsCryptographicIPdu that is set to true dIf
useAsCryptographicIPdu is set to true the SecuredIPdu contains the Authenti-
cator for a payload that is transported in a separate message. The separate Authentic
IPdu is described by the PduTriggering that is referenced with the payload refer-
ence.c(RS_SYST_00054)
The attribute useAsCryptographicIPdu decides whether one single Pdu or two
Pdus are transferred on the communication bus. In either case always two IPdus shall
be modeled:
• SecuredIPdu with a PduTriggering
• payload IPdu with a PduTriggering
[TPS_SYST_02172] Modeling of SecuredIPdu in case useAsCrypto-
graphicIPdu is set to false dIf the useAsCryptographicIPdu is set to false only
the SecuredIPdu shall be either
• mapped into a Frame by the PduToFrameMapping or
• mapped into a StaticSocketConnection or
• assigned to an AbstractServiceInstance via PduActivationRouting-
Group that references the SoConIPduIdentifier that represents the Se-
curedIPdu or
• assigned to a ContainerIPdu.
c(RS_SYST_00054)

313 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

cryptographicPduTriggering: Can:
PduTriggering CanPhysicalChannel
Frame_Id26:
+pduTriggering
FrameTriggering

+iPdu +frame

CryptographicPdu: SecuredIPdu +pdu cryptographicPduMapping: +pduToFrameMapping CryptoAndAuthenticFrame:

PduToFrameMapping CanFrame
useAsCryptographicIPdu = false

+payload

authenticPduTriggering:
PduTriggering

+iPdu

authenticPdu: ISignalIPdu

Figure 6.14: Example for the modeling of SecuredIPdu with useAsCryptographicIPdu

set to false

If a SecuredIPdu is transmitted on different PhysicalChannels this can be de-

scribed in a System Description by a single SecuredIPdu element that is referenced
by PduTriggerings of the different PhysicalChannels.
The payload of the SecuredIPdu is described by exactly one PduTriggering that is
referenced in the role payload. Please note that although the payload PduTrigger-
ing will also be transmitted on the same PhysicalChannels as the SecuredIPdu
it is completely sufficient that the payload PduTriggering that is referenced by the
SecuredIPdu is aggregated by one of the PhysicalChannels on which the Se-
curedIPdu is transmitted. It is irrelevant which PduTriggering of which Physi-
calChannel is chosen to describe the payload of the SecuredIPdu since the as-
signment of the SecuredIPdu to PhysicalChannels is done only by the PduTrig-
gerings that are pointing to the SecuredIPdu.
The reason for this modeling is the configuration of the PduR. One use case in the
PduR is the enabling and disabling of Pdus by PdurIPduGroups. The PdurIP-
duGroup works on PduTriggerings and there is also the use case to enable/disable
the SecuredIPdus in the PduR.
[TPS_SYST_02173] Modeling of SecuredIPdu in case useAsCrypto-
graphicIPdu is set to true dIf the useAsCryptographicIPdu is set to true
then the SecuredIPdu and the payload IPdu shall be either
• mapped into Frames by the PduToFrameMapping or
• assigned to StaticSocketConnection or
• assigned to AbstractServiceInstances via PduActivationRouting-
Group that references the SoConIPduIdentifiers that represent the Se-
curedIPdu and the payload IPdu or

314 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• assigned to ContainerIPdus.
c(RS_SYST_00054)
[constr_5259] PduTriggerings and FrameTriggerings of SecuredIPdu with
useAsCryptographicIPdu = true dIn case that a SecuredIPdu is defined with
useAsCryptographicIPdu = true as described by [TPS_SYST_02173] then:
• the PduTriggering of the AuthenticPdu
• the PduTriggering of the CryptographicPdu
• the FrameTriggering that references the Frame to which the AuthenticPdu
is mapped
• the FrameTriggering that references the Frame to which the Cryptograph-
icPdu is mapped
shall be aggregated by the same PhysicalChannel.c()
[TPS_SYST_02361] PduR Fan-out of SecuredIPdu with useAsCrypto-
graphicIPdu = true dIf a PduR fan-out of a SecuredIPdu with useAsCrypto-
graphicIPdu = true is defined then [constr_5259] shall be considered on all Physi-
calChannels on which the SecuredIPdu is transmitted.c()
In other words the PduTriggerings of the AuthenticPdu and the Cryptograph-
icPdu and the FrameTriggerings that reference the Frames to which the Authen-
ticPdu and CryptographicPdu are mapped need to be defined on all Physi-
calChannels on which the SecuredIPdu is transmitted.
cryptographicPduTriggering: Can:
PduTriggering CanPhysicalChannel

+pduTriggering CryptoFrame_Id25:
FrameTriggering

+iPdu +frame

CryptographicPdu: SecuredIPdu +pdu cryptographicPduMapping: +pduToFrameMapping CryptoFrame:

PduToFrameMapping CanFrame
useAsCryptographicIPdu = true

+payload

authenticPduTriggering:
PduTriggering
+pduTriggering AuthenticFrame_Id29:
FrameTriggering

+iPdu +frame

authenticPdu: ISignalIPdu +pdu authenticPduMapping: +pduToFrameMapping AuthenticFrame:

PduToFrameMapping CanFrame

Figure 6.15: Example for the modeling of SecuredIPdu with useAsCryptographicIPdu

set to true

315 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Please note that [TPS_SYST_02059] defines that the PduTriggerings of the Se-
curedIPdu and PduTriggerings of the payload IPdu shall both reference IPdu-
Ports.
A SecuredIPdu defines freshness properties by referencing the reusable Se-
cureCommunicationFreshnessProps in the role freshnessProps. The authen-
tication properties are defined by reusable SecureCommunicationAuthentica-
tionProps that are referenced in the role authenticationProps. Configuration
settings that are specific to the SecuredIPdu are defined in SecureCommunica-
tionProps.
Please note that if the SecuredIPdu does not reference the SecureCommunica-
tionFreshnessProps in the role freshnessProps the freshness value will not be
included in the SecuredIPdu.
FibexElement
SecureCommunicationPropsSet

+freshnessProps 0..* +authenticationProps 0..*

Identifiable Identifiable
SecureCommunicationFreshnessProps SecureCommunicationAuthenticationProps

+ freshnessCounterSyncAttempts: PositiveInteger [0..1] + authInfoTxLength: PositiveInteger [0..1]

+ freshnessTimestampTimePeriodFactor: PositiveInteger [0..1]
+ freshnessValueLength: PositiveInteger [0..1]
+ freshnessValueTxLength: PositiveInteger [0..1]
+ useFreshnessTimestamp: Boolean [0..1]

+freshnessProps 0..1 +authenticationProps 0..1

IPdu
SecuredIPdu «enumeration»
SecuredPduHeaderEnum
+ useAsCryptographicIPdu: Boolean [0..1]
+ useSecuredPduHeader: SecuredPduHeaderEnum [0..1] noHeader
securedPduHeader08Bit
securedPduHeader16Bit
securedPduHeader32Bit
+secureCommunicationProps 1
+payload 1
SecureCommunicationProps Identifiable
PduTriggering
+ authDataFreshnessLength: PositiveInteger [0..1]
+ authDataFreshnessStartPosition: PositiveInteger [0..1]
+ authenticationBuildAttempts: PositiveInteger [0..1]
+ authenticationRetries: PositiveInteger
+ dataId: PositiveInteger
+ freshnessValueId: PositiveInteger [0..1] +iPduPort *
+ messageLinkLength: PositiveInteger [0..1] CommConnectorPort
+ messageLinkPosition: PositiveInteger [0..1]
IPduPort
+ secondaryFreshnessValueId: PositiveInteger [0..1]
+ securedAreaLength: PositiveInteger [0..1] + iPduSignalProcessing: IPduSignalProcessingEnum [0..1]
+ securedAreaOffset: PositiveInteger [0..1] + rxSecurityVerification: Boolean [0..1]
+ timestampRxAcceptanceWindow: TimeValue [0..1]
+ useAuthDataFreshness: Boolean [0..1]

Figure 6.16: SecuredIPdu with SecureCommunicationProps

Class SecuredIPdu
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
5

316 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class SecuredIPdu
Note If useAsCryptographicPdu is not set or set to false this IPdu contains the payload of an Authentic IPdu
supplemented by additional Authentication Information (Freshness Counter and an Authenticator).
If useAsCryptographicPdu is set to true this IPdu contains the Authenticator for a payload that is
transported in a separate message. The separate Authentic IPdu is described by the Pdu that is
referenced with the payload reference from this SecuredIPdu.
Tags:atp.recommendedPackage=Pdus
Base ARObject, CollectableElement, FibexElement, IPdu, Identifiable, MultilanguageReferrable, Packageable
Element, Pdu, Referrable
Attribute Type Mult. Kind Note
authentication SecureCommunication 0..1 ref Reference to authentication properties that are valid for
Props AuthenticationProps this SecuredIPdu.
freshnessProps SecureCommunication 0..1 ref Reference to freshness properties that are valid for this
FreshnessProps SecuredIPdu.
payload PduTriggering 1 ref Reference to a Pdu that will be protected against
unauthorized manipulation and replay attacks.
secure SecureCommunication 1 aggr Specific configuration properties for this SecuredIPdu.
Communication Props
Props
useAs Boolean 0..1 attr If this attribute is set to true the SecuredIPdu contains the
Cryptographic Authentication Information for an AuthenticIPdu that is
IPdu transmitted in a separate message. The AuthenticIPdu
contains the original payload, i.e. the secured data.
If this attribute is set to false this SecuredIPdu contains
the payload of an Authentic IPdu supplemented by
additional Authentication Information.
useSecuredPdu SecuredPduHeader 0..1 attr This attribute defines the size of the header which is
Header Enum inserted into the SecuredIPdu. If this attribute is set to
anything but noHeader, the SecuredIPdu contains the
Secured I-PDU Header to indicate the length of the
AuthenticIPdu. The AuthenticIPdu contains the original
payload, i.e. the secured data.

Table 6.46: SecuredIPdu

Enumeration SecuredPduHeaderEnum
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note Defines the header which will be inserted into the SecuredIPdu.
Literal Description
noHeader No header included in the SecuredPdu.
Tags:atp.EnumerationLiteralIndex=0
securedPdu 8 Bit Secured I-PDU Header included in the Secured I-PDU.
Header08Bit
Tags:atp.EnumerationLiteralIndex=1
securedPdu 16 Bit Secured I-PDU Header included in the Secured I-PDU.
Header16Bit
Tags:atp.EnumerationLiteralIndex=2
securedPdu 32 Bit Secured I-PDU Header included in the Secured I-PDU.
Header32Bit
Tags:atp.EnumerationLiteralIndex=3

Table 6.47: SecuredPduHeaderEnum

317 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class SecureCommunicationProps
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note This meta-class contains configuration settings that are specific for an individual SecuredIPdu.
Base ARObject
Attribute Type Mult. Kind Note
authData PositiveInteger 0..1 attr This attribute defines the length in bits of the authentic
Freshness PDU data that is passed to the SWC that verifies and
Length generates the Freshness.
authData PositiveInteger 0..1 attr This value determines the start position in bits of the
FreshnessStart Authentic PDU that shall be passed on to the SWC that
Position verifies and generates the Freshness. The bit counting is
done according to TPS_SYST_01068.
authentication PositiveInteger 0..1 attr This attribute specifies the number of authentication build
BuildAttempts attempts.
authentication PositiveInteger 1 attr This attribute defines the additional number of
Retries authentication attempts that are to be carried out when
the generation of the authentication information failed for
a given SecuredIPdu. If zero is set than only one
authentication attempt is done.
dataId PositiveInteger 1 attr This attribute defines a numerical identifier for the
Secured I-PDU.
freshnessValue PositiveInteger 0..1 attr This attribute defines the Id of the Freshness Value. The
Id Freshness Value might be a normal counter or a time
value.
messageLink PositiveInteger 0..1 attr SecOC links an AuthenticIPdu and CryptographicIPdu
Length together by repeating a specific part (Message Linker) of
the AuthenticIPdu in the CryptographicIPdu. This attribute
defines the length in bits of the messageLinker.
messageLink PositiveInteger 0..1 attr SecOC links an AuthenticIPdu and CryptographicIPdu
Position together by repeating a specific part (Message Linker) of
the AuthenticIPdu in the CryptographicIPdu. This attribute
defines the startPosition in bits of the messageLinker.
secondary PositiveInteger 0..1 attr This attribute defines the Id of the Secondary Freshness
FreshnessValue Value. The Secondary Freshness Value might be a
Id normal counter or a time value. Please note that this
attribute is for documentation only to allow the
configuration of required freshness value manager and no
upstream mapping is defined for it.
securedArea PositiveInteger 0..1 attr This attribute defines the length in bytes of the area within
Length the payload Pdu which will be secured.
securedArea PositiveInteger 0..1 attr This attribute defines the start position (offset in byte) of
Offset the area within the payload Pdu which will be secured.

Table 6.48: SecureCommunicationProps

SecureCommunicationProps.freshnessValueId does not need to be defined in

case of a time-based Freshness Value. In case of a counter-based Freshness Value
the freshnessValueId may be defined locally in the Ecuc or may be provided by
the OEM in a System Description (this may be useful if several ECUs need to sync the
freshness for a certain freshnessValueId).

318 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class SecureCommunicationPropsSet
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note Collection of properties used to configure SecuredIPdus.
Tags:atp.recommendedPackage=SecureCommunicationPropsSet
Base ARObject, CollectableElement, FibexElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
authentication SecureCommunication * aggr Authentication properties used to configure Secured
Props AuthenticationProps IPdus.
freshnessProps SecureCommunication * aggr Freshness properties used to configure SecuredIPdus.
FreshnessProps

Table 6.49: SecureCommunicationPropsSet

Class SecureCommunicationFreshnessProps
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note Freshness properties used to configure SecuredIPdus.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
freshness PositiveInteger 0..1 attr This attribute defines the number of Freshness Counter
CounterSync re-synchronization attempts when a verification failed for
Attempts a Secured I-PDU. If the value is zero, there will be no
additional verification attempt to synchronize with a
potentially better fitting Freshness Counter value. This
attribute is only applicable if useFreshnessTimestamp is
FALSE.
freshness PositiveInteger 0..1 attr This attribute defines a factor that specifies the time
TimestampTime period for the Freshness Timestamp. It holds a
PeriodFactor multiplication factor that specifies the concrete meaning
of a Freshness Timestamp increment by one on basis of
microseconds.
freshnessValue PositiveInteger 0..1 attr This attribute defines the complete length in bits of the
Length Freshness Value. As long as the key doesn’t change the
counter shall not overflow. The length of the counter shall
be determined based on the expected life time of the
corresponding key and frequency of usage of the counter.
freshnessValue PositiveInteger 0..1 attr This attribute defines the length in bits of the Freshness
TxLength Value to be included in the payload of the Secured I-PDU.
This length is specific to the least significant bits of the
complete Freshness Counter. If the attribute is 0 no
Freshness Value is included in the Secured I-PDU.
useFreshness Boolean 0..1 attr This attribute specifies whether the Freshness Value is
Timestamp generated through individual Freshness Counters or by a
Timestamps. The value is set to TRUE when Timestamps
are used.
Table 6.50: SecureCommunicationFreshnessProps

Class SecureCommunicationAuthenticationProps
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note Authentication properties used to configure SecuredIPdus.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
5

319 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class SecureCommunicationAuthenticationProps
authInfoTx PositiveInteger 0..1 attr This attribute defines the length in bits of the
Length authentication code to be included in the payload of the
authenticated Pdu.
Table 6.51: SecureCommunicationAuthenticationProps

[TPS_SYST_02281] Definition of SecuredIPdu.authDataFreshnessStartPo-

sition dSecuredIPdu.authDataFreshnessStartPosition defines the position
of the most significant bit of the Freshness Value in the Pdu.c()
[TPS_SYST_02282] Definition of SecuredIPdu.messageLinkPosition dSe-
curedIPdu.messageLinkPosition defines the position of the most significant bit
of the Message Link in the Pdu.c()
Please note that the bit counting and bit order is defined by [TPS_SYST_01068]
and [TPS_SYST_01069] and is also valid to determine the position of the auth-
DataFreshness and messageLink.
[constr_3136] Allowed payload of SecuredIPdus dSecuredIPdus are al-
lowed to reference PduTriggerings of ISignalIPdus, ContainerIPdus,
DcmIPdus, MultiplexedIPdus, GeneralPurposeIPdus with category
SOMEIP_SEGMENTED_IPDU and UserDefinedIPdus.c()
Please note that it is currently not possible to refer to a SecuredIPdu in the roles Mul-
tiplexedIPdu.staticPart and MultiplexedIPdu.dynamicPart and therefore
it is not possible to include SecuredIPdus in either the static part or dynamic part of
a MultiplexedIPdu. In other words, a MultiplexedIPdu can be the payload of
a SecuredIPdu, but conversely a SecuredIPdu cannot become a part of a Multi-
plexedIPdu.
[TPS_SYST_02171] Secured Area in payload Pdu dThe area within the payload Pdu
that is secured is specified by the securedAreaOffset and securedAreaLength.
In case that these two attributes are not configured the complete payload Pdu is se-
cured.c(RS_SYST_00054)
[constr_3399] Existence of securedAreaOffset and securedAreaLength dIf
the securedAreaOffset is defined then the securedAreaLength shall be defined
as well and vice versa.c()
[TPS_SYST_02152] Security profile dThe Security profile is defined by Se-
cureCommunicationFreshnessProps.category and by SecureCommunica-
tionAuthenticationProps.category.c(RS_SYST_00054)
[constr_3324] Category of SecureCommunicationFreshnessProps and Se-
cureCommunicationAuthenticationProps dSecureCommunicationFresh-
nessProps that is referenced by a SecuredIPdu in the role freshnessProps shall
have the same category value as the SecureCommunicationAuthentication-
Props that is referenced by the same SecuredIPdu in the role authentication-
Props.c()

320 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_02153] Standardized values for the attribute category of meta-class

SecureCommunicationFreshnessProps dThe following values of the attribute
category of meta-class SecureCommunicationFreshnessProps are reserved
by the AUTOSAR standard: PROFILE_01, PROFILE_02, PROFILE_03.c(RS_SYST_-
00054)
[TPS_SYST_02154] Standardized values for the attribute category of meta-class
SecureCommunicationAuthenticationProps dThe following values of the at-
tribute category of meta-class SecureCommunicationAuthenticationProps
are reserved by the AUTOSAR standard: PROFILE_01, PROFILE_02, PROFILE_03.c
(RS_SYST_00054)
[constr_3325] SecureCommunicationFreshnessProps, SecureCommunica-
tionAuthenticationProps and CryptoServicePrimitive attribute values
for predefined categories dTable Table 6.52 defines applicable attribute values for
security profiles that are standardized by AUTOSAR.c()
In other words if you want to define a SecuredIPdu in a particular Profile you have
to reference the SecureCommunicationFreshnessProps and SecureCommuni-
cationAuthenticationProps and the PduTriggering of this SecuredIPdu
that shall reference a SecOcCryptoServiceMapping that points to CryptoSer-
vicePrimitive that contributes the authentication Algorithm and the CryptoSer-
viceKey that contributes the length.
Attributes PROFILE_01 PROFILE_02 PROFILE_03
algorithmFamily CRYPTO_ALGOFAM_AES CRYPTO_ALGOFAM_AES CRYPTO_ALGOFAM_AES
algorithmMode CRYPTO_ALGOMODE_CMAC CRYPTO_ALGOMODE_CMAC CRYPTO_ALGOMODE_CMAC
length 128 bits 128 bits 128 bits
authInfoTxLength 24 bits 24 bits 28 bits
freshnessValueLength Not specified 0 bits 64 bits
freshnessVal-
8 bits 0 bits 4 bits
ueTxLength

Table 6.52: Security Profiles that are standardized by AUTOSAR

[constr_3339] Relation between authDataFreshnessStartPosition, au-

thDataFreshnessLength and useAuthDataFreshness dIf authDataFresh-
nessStartPosition and authDataFreshnessLength are set to a value for a
SecuredIPdu then the useAuthDataFreshness shall be set as well to a value
on all IPduPorts with communicationDirection = in that are referenced by a
PduTriggering of the SecuredIPdu.c()
[TPS_SYST_02189] Setting of useSecuredPduHeader attribute dThe useSe-
curedPduHeader shall be set to a value other than noHeader if the length of the
payload Pdu is dynamic and is transmitted directly over a network which may insert
padding bytes depending on the length (e.g. CANFD, Flexray).c(RS_SYST_00054)
In case the SecuredIPdu is contained in a ContainerIPdu or is a TP-N-SDU, its
length is correctly passed by the lower layer. In these cases the SecuredIPduHeader
is not needed.

321 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Please note that the dynamic-length Pdu can be an ISignalIPdu that contains a
SystemSignal with dynamicLength set to true. In general it is not possible to run
diagnostics on fixed-length Pdus. Therefore, there is a probability that at least a subset
of DcmIPdus and UserDefinedIPdus can have dynamic length.
[constr_3406] All signals before authDataFreshnessStartPosition shall
have a static length dIn case that
• an ISignalIPdu is referenced by the SecuredIPdu with the payload refer-
ence via the PduTriggering and
• the authDataFreshnessStartPosition and authDataFresh-
nessLength define the area in the ISignalIPdu that is taken to verify
and generate the Freshness then
all ISignals that are mapped into the ISignalIPdu in front of the configured au-
thDataFreshnessStartPosition shall have a static length.c()
Please note that parts of the Authentic IPdu can be used as freshness when auth-
DataFreshnessStartPosition and authDataFreshnessLength are defined.
But therefore the part of the Authentic IPdu to be used as the freshness has to be
always available at same position in the Authentic IPdu.
[constr_3407] Freshness Value in Authentic IPdu is not allowed to be used in
case of ContainerIPdu with a dynamic layout dIf a ContainerIPdu that is ref-
erenced by the SecuredIPdu with the payload reference via the PduTriggering
contains a dynamic layout (i.e. ContainerIPdu.headerType is set to longHeader
or shortHeader) and multiple contained IPdus then each IPduPort that is refer-
enced by the PduTriggering of the SecuredIPdu shall have the attribute useAu-
thDataFreshness set to false.c()
Please note that for ContainerIPdus with a dynamic layout it cannot be ensured
which contained IPdu will be put in which position (depends on various timing and
trigger conditions). Therefore [constr_3407] applies.
[constr_5060] Mapping of a SecuredIPdu into a LinFrame is not allowed dThe
mapping of a SecuredIPdu into a LinFrame with a PduToFrameMapping is not
allowed.c()
In other words the usage of Pdus that are secured by SecOC is not allowed on a LIN
Network.

6.3.2.1 Crypto Infrastructure for SecuredIPdu

From the cryptographic point of view, the usage of SecuredIPdu is connected to

the application of two cryptographic operations, MacGenerate (for sending the Se-
curedIPdu) and MacVerify (for receiving the SecuredIPdu).

322 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

There are use cases for OEMs to already provide a pre-configuration of the crypto
stack specifically for the handling of SecuredIPdu.
In order to support these use cases model elements in the meta-model are defined
that allow for modeling a “crypto infrastructure” that facilitates the derivation of the
configuration of operations MacGenerate and MacVerify in the crypto stack.
The formalization of a Pdu that is sent or received is based on the PduTriggering
and its reference to an IPduPort, specifically by interpreting the attribute IPduPort.
communicationDirection. The details of the approach are summarized in Figure
6.17.
[TPS_SYST_05020] Semantics of CryptoServiceMapping dMeta-class Cryp-
toServiceMapping represents an abstract base class for the creation of mappings in
the context of cryptographic operations. Concrete sub-classes define the mapping with
respect to specific cryptographic use cases, e.g. SecOC, TLS.c(RS_SYST_00054)
Class CryptoServiceMapping (abstract)
Package M2::AUTOSARTemplates::SystemTemplate::SecureCommunication
Note This meta-class represents an abstract base class for specializations of crypto service mappings.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Subclasses SecOcCryptoServiceMapping, TlsCryptoServiceMapping
Attribute Type Mult. Kind Note
– – – – –
Table 6.53: CryptoServiceMapping

[TPS_SYST_05021] Semantics of SecOcCryptoServiceMapping dMeta-class

SecOcCryptoServiceMapping represents the mapping functionality required for
the configuration of PDU-based secure communication by means of the SecOc.
In particular, the SecOcCryptoServiceMapping associates a CryptoServi-
cePrimitive with the applicable CryptoServiceKey.c(RS_SYST_00054)
Class SecOcCryptoServiceMapping
Package M2::AUTOSARTemplates::SystemTemplate::SecureCommunication
Note This meta-class has the ability to represent a crypto service mapping for the Pdu-based communication
via SecOC.
Base ARObject, CryptoServiceMapping, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
authentication CryptoServicePrimitive 0..1 ref This reference identifies the applicable crypto primitive for
the authentication.
cryptoService CryptoServiceKey 0..1 ref This reference identifies the applicable crypto key.
Key
cryptoService CryptoServiceQueue 0..1 ref This reference identifies the CryptoServiceQueue the
Queue processing of this SecOcCryptoServiceMapping shall be
performed in.

Table 6.54: SecOcCryptoServiceMapping

323 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_05022] Semantics of PduTriggering.secOcCryptoMapping dThe

reference PduTriggering.secOcCryptoMapping allows for modeling the relation
of the usages (send, receive) of a SecuredIPdu to a given CryptoServiceMap-
ping and thereby distinguish between the configuration of cryptographic operations
MacGenerate and MacVerify.c(RS_SYST_00054)
In other words, the cryptographic use case is connected to the value of attribute com-
municationDirection of the IPduPort that is referenced by an PduTriggering
that also references a SecOcCryptoServiceMapping:
• If the value of communicationDirection is set to in then the cryptographic
use case MacVerify applies.
• If the value of communicationDirection is set to out then the cryptographic
use case MacGenerate applies.
[constr_1669] Existence of PduTriggering.secOcCryptoMapping dThe refer-
ence PduTriggering.secOcCryptoMapping shall only exist if the PduTrigger-
ing also references a SecuredIPdu in the role iPdu.c()
As the SecOcCryptoServiceMapping is referenced by a PduTriggering the
SecOcCryptoServiceMapping needs to work for both the sender and the re-
ceivers of the corresponding Pdu in the context of a System of category SYS-
TEM_DESCRIPTION/SYSTEM_EXTRACT as well as in the context of a System of cat-
egory ECU_EXTRACT.
[TPS_SYST_05023] Semantics of CryptoServicePrimitive dMeta-class Cryp-
toServicePrimitive allows for the description of the applicable cryptographic al-
gorithm.c(RS_SYST_00054)
Class CryptoServicePrimitive
Package M2::AUTOSARTemplates::SystemTemplate::SecureCommunication
Note This meta-class has the ability to represent a crypto primitive.
Tags:atp.recommendedPackage=CryptoPrimitives
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
algorithmFamily String 0..1 attr This attribute represents a description of the family (e.g.
AES) of crypto algorithm implemented by the crypto
primitive.
algorithmMode String 0..1 attr This attribute represents a description of the mode of the
crypto algorithm implemented by the crypto primitive.
algorithm String 0..1 attr This attribute represents a further description of the
Secondary secondary family of crypto algorithm implemented by the
Family crypto primitive.
The secondary family is needed for the specification of
the hash algorithm for a signature check, e.g. using RSA.

Table 6.55: CryptoServicePrimitive

[TPS_SYST_05024] Semantics of CryptoServiceKey dMeta-class CryptoSer-

viceKey allows for the description of the applicable cryptographic key. The ability to

324 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

aggregate a ValueSpecification in the role developmentValue shall be used

to distribute development keys to suppliers such that crypto functionality can be ade-
quately verified during development.c(RS_SYST_00054)
Identifiable ARElement
ValueSpecification
CryptoServiceMapping CryptoServicePrimitive
+ shortLabel: Identifier [0..1]
+ algorithmFamily: String [0..1]
+ algorithmMode: String [0..1] +developmentValue 0..1
+ algorithmSecondaryFamily: String [0..1]

+authentication 0..1

+cryptoServiceKey ARElement
SecOcCryptoServiceMapping
CryptoServiceKey
0..1
+ algorithmFamily: String
+secOcCryptoMapping 0..1 + keyGeneration: CryptoServiceKeyGenerationEnum [0..1]
+cryptoServiceQueue 0..1 + keyStorageType: String [0..1]
+ length: PositiveInteger
ARElement
CryptoServiceQueue
Identifiable FibexElement
PduTriggering + queueSize: PositiveInteger [0..1] Pdu

+iPdu + hasDynamicLength: Boolean [0..1]

+ length: UnlimitedInteger [0..1]
1
«enumeration»
CryptoServiceKeyGenerationEnum

keyDerivation
keyStorage IPdu
SecuredIPdu
+payload + useAsCryptographicIPdu: Boolean [0..1]
+ useSecuredPduHeader: SecuredPduHeaderEnum [0..1]
1

+iPduPort * +authenticationProps 0..1

CommConnectorPort Identifiable
IPduPort SecureCommunicationAuthenticationProps

+ iPduSignalProcessing: IPduSignalProcessingEnum [0..1] + authInfoTxLength: PositiveInteger [0..1]

+ rxSecurityVerification: Boolean [0..1]
+ timestampRxAcceptanceWindow: TimeValue [0..1]
+ useAuthDataFreshness: Boolean [0..1]

Figure 6.17: Modeling of crypto infrastructure for SecuredIPdu

Please note that the developmentValue most likely will be used in the form of
a TextValueSpecification. However, the aggregation has still be modeled by
means of using the abstract base class ValueSpecification to gain some head-
room for future extension.
Class CryptoServiceKey
Package M2::AUTOSARTemplates::SystemTemplate::SecureCommunication
Note This meta-class has the ability to represent a crypto key
Tags:atp.recommendedPackage=CryptoDevelopmentKeys
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
algorithmFamily String 1 attr This attribute represent the description of the family of the
applicable crypto algorithm.
development ValueSpecification 0..1 aggr This aggregation represents the ability to assign a
Value specific value to the crypto key as part of the system
description. This value can then be taken for the
development of the respective ECU.
keyGeneration CryptoServiceKey 0..1 attr This attribute describes how a the specific cryptographic
GenerationEnum key is created.
5

325 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class CryptoServiceKey
keyStorageType String 0..1 attr This attribute describes where the enclosing
cryptographic key shall be stored. AUTOSAR reserves
specific values for this attributes but it is possible to insert
custom values as well.
length PositiveInteger 1 attr This attribute describes the length of the cryptographic
key.

Table 6.56: CryptoServiceKey

Enumeration CryptoServiceKeyGenerationEnum
Package M2::AUTOSARTemplates::SystemTemplate::SecureCommunication
Note This enumeration shall be taken to express the handling of a crypto key in terms of whether it is
obtained from e.g. a diagnostic tester or whether it is created by derivation from a master key.
Literal Description
keyDerivation This means that the crypto key is created by derivation from a master key.
Tags:atp.EnumerationLiteralIndex=0
keyStorage This means that the crypto key is obtained from an external entity, e.g. a diagnostic tester.
Tags:atp.EnumerationLiteralIndex=1

Table 6.57: CryptoServiceKeyGenerationEnum

[TPS_SYST_05025] Standardized values of CryptoServicePrimitive.algo-

rithmFamily and CryptoServiceKey.algorithmFamily dThe following val-
ues of attributes CryptoServicePrimitive.algorithmFamily and CryptoSer-
viceKey.algorithmFamily are standardized by AUTOSAR:
• CRYPTO_ALGOFAM_SHA1: SHA1 hash
• CRYPTO_ALGOFAM_SHA2_224: SHA2-224 hash
• CRYPTO_ALGOFAM_SHA2_256: SHA2-256 hash
• CRYPTO_ALGOFAM_SHA2_384: SHA2-384 hash
• CRYPTO_ALGOFAM_SHA2_512: SHA2-512 hash
• CRYPTO_ALGOFAM_SHA2_512_224: SHA2-512/224 hash
• CRYPTO_ALGOFAM_SHA2_512_256: SHA2-512/256 hash
• CRYPTO_ALGOFAM_SHA3_224: SHA3-224 hash
• CRYPTO_ALGOFAM_SHA3_256: SHA3-256 hash
• CRYPTO_ALGOFAM_SHA3_384: SHA3-384 hash
• CRYPTO_ALGOFAM_SHA3_512: SHA3-512 hash
• CRYPTO_ALGOFAM_SHAKE128: SHAKE128 hash
• CRYPTO_ALGOFAM_SHAKE256: SHAKE256 hash
• CRYPTO_ALGOFAM_RIPEMD160: RIPEMD hash

326 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• CRYPTO_ALGOFAM_BLAKE_1_256: BLAKE-1-256 hash

• CRYPTO_ALGOFAM_BLAKE_1_512: BLAKE-1-512 hash
• CRYPTO_ALGOFAM_BLAKE_2s_256: BLAKE-2s-256 hash
• CRYPTO_ALGOFAM_BLAKE_2s_512: BLAKE-2s-512 hash
• CRYPTO_ALGOFAM_3DES: 3DES cipher
• CRYPTO_ALGOFAM_AES: AES cipher
• CRYPTO_ALGOFAM_CHACHA: ChaCha cipher
• CRYPTO_ALGOFAM_RSA: RSA cipher
• CRYPTO_ALGOFAM_ED25519: ED22518 elliptic curve
• CRYPTO_ALGOFAM_BRAINPOOL: Brainpool elliptic curve
• CRYPTO_ALGOFAM_ECCNIST: NIST ECC elliptic curves
• CRYPTO_ALGOFAM_RNG: Random Number Generator
• CRYPTO_ALGOFAM_SIPHASH: SipHash
• CRYPTO_ALGOFAM_ECIES: ECIES Cipher
• CRYPTO_ALGOFAM_SM2: SM2 elliptic curve algorithm
• CRYPTO_ALGOFAM_EEA3: Stream cipher based on ZUC
• CRYPTO_ALGOFAM_SM3: Hash algorithm based on ISO/IEC 10118-3:2018 Part
3: Dedicated hash-functions (SM3)
• CRYPTO_ALGOFAM_EIA3: Authentication based on ZUC
c(RS_SYST_00054)
[TPS_SYST_05026] Relation of CryptoServicePrimitive.algorithmFamily
to CryptoServiceKey.algorithmFamily dThe attribute CryptoServiceKey.
algorithmFamily shall be taken to check with the value of CryptoServicePrimi-
tive.algorithmFamily in order to make sure that the crypto key fits to the intended
usage.c(RS_SYST_00054)
[TPS_SYST_05027] Standardized values of CryptoServicePrimitive.algo-
rithmMode dThe following values of attributes CryptoServicePrimitive.algo-
rithmMode are standardized by AUTOSAR:
• CRYPTO_ALGOMODE_ECB: Blockmode - Electronic Code Book
• CRYPTO_ALGOMODE_CBC: Blockmode - Cipher Block Chaining
• CRYPTO_ALGOMODE_CFB: Blockmode - Cipher Feedback Mode
• CRYPTO_ALGOMODE_OFB: Blockmode - Output Feedback Mode

327 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• CRYPTO_ALGOMODE_CTR: Blockmode - Counter Modex

• CRYPTO_ALGOMODE_GCM: Blockmode - Galois/Counter Mode
• CRYPTO_ALGOMODE_XTS: XOR-encryption-based tweaked-codebook mode with
ciphertext stealing
• CRYPTO_ALGOMODE_RSAES_OAEP: RSA Optimal Asymmetric Encryption
Padding
• CRYPTO_ALGOMODE_RSAES_PKCS1_v1_5: RSA encryption/decryption with
PKCS#1 v1.5 padding
• CRYPTO_ALGOMODE_RSASSA_PSS: RSA Probabilistic Signature
• CRYPTO_ALGOMODE_RSASSA_PKCS1_v1_5: RSA signature with PKCS#1 v1.5
• CRYPTO_ALGOMODE_8ROUNDS: 8 rounds (e.g. ChaCha8)
• CRYPTO_ALGOMODE_12ROUNDS: 12 rounds (e.g. ChaCha12)
• CRYPTO_ALGOMODE_20ROUNDS: 20 rounds (e.g. ChaCha20)
• CRYPTO_ALGOMODE_HMAC: Hashed-based MAC
• CRYPTO_ALGOMODE_CMAC: Cipher-based MAC
• CRYPTO_ALGOMODE_GMAC: Galois MAC
• CRYPTO_ALGOMODE_CTRDRBG: Counter-based Deterministic Random Bit Gen-
erator
• CRYPTO_ALGOMODE_SIPHASH_2_4: Siphash-2-4
• CRYPTO_ALGOMODE_SIPHASH_4_8: Siphash-4-8
c(RS_SYST_00054)
Please note that it is positively supported to define custom values for attributes Cryp-
toServicePrimitive.algorithmFamily and CryptoServicePrimitive.al-
gorithmMode provided that the custom values are guaranteed to not clash with future
extension of the AUTOSAR standard. For example, this could be achieved by using a
prefix or suffix that is specific to the organization that defines the custom value.
[TPS_SYST_05028] Semantics of CryptoServiceKey.keyStorageType
dAttribute CryptoServiceKey.keyStorageType describes where the actual
key shall be stored on the ECU. This attribute has been deliberately modeled as a
String to allow future (and custom) extensions of the range of possible values.
AUTOSAR reserves the following values for this attribute:
• SHE
• RAM
• HSM

328 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• NVM
c(RS_SYST_00054)
Please note that custom values for attribute CryptoServiceKey.keyStorageType
are supported as long as the actual values are defined in a way such that a possible
clash with a later standardization by AUTOSAR becomes impossible.
The best way to achieve this is to use the company name (e.g. as a prefix) within the
custom value of CryptoServiceKey.keyStorageType.
Class CryptoServiceQueue
Package M2::AUTOSARTemplates::SystemTemplate::SecureCommunication
Note This meta-class has the ability to represent a crypto queue.
Tags:atp.recommendedPackage=CryptoServiceQueues
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
queueSize PositiveInteger 0..1 attr Defines the queue size of the CryptoServiceQueue.

Table 6.58: CryptoServiceQueue

[constr_5058] Value range for CryptoServiceQueue.queueSize dIf the Cryp-

toServiceQueue.queueSize is defined it shall have a value which is equal or
greater than 1.c()

6.3.3 EndToEndProtection for ISignalGroups

Caveat: The E2E wrapper approach involves technologies that are not subjected to
the AUTOSAR standard and is superseded by the superior E2E transformer approach
(which is fully standardized by AUTOSAR). Hence, new projects (without legacy con-
straints due to carry-over parts) shall use the fully standardized E2E transformer ap-
proach.
[TPS_SYST_01070] E2E Protection of ISignalGroups dIt is possible to protect the
inter-ECU data exchange of safety-related ISignalGroups which are mapped into
ISignalIPdus using protection mechanisms provided by E2E Library.c(RS_SYST_-
00028)
[TPS_SYST_01071] E2E Protection of several ISignalGroups in one ISig-
nalIPdu dIt is possible to protect several ISignalGroups in one ISignalIPdu us-
ing several EndToEndProtectionISignalIPdu elements.c(RS_SYST_00028)
The EndToEndProtectionISignalIPdu element refers to the ISignalGroup that
is to be protected and to the ISignalIPdu that transmits the protected ISignal-
Group. The dataOffset in the EndToEndProtectionISignalIPdu element de-
fines the starting position of the Array representation of the ISignalGroup.

329 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

The information how the referenced ISignalGroup shall be protected (through which
E2E Profile and with which E2E settings) is defined in the EndToEndDescription
element.
[TPS_SYST_01072] Offset attributes of EndToEndDescription dAll offset at-
tributes of EndToEndDescription are relative to the dataOffset with respect to
the ISignalIPdu (absolute position of the CRC = dataOffset + crcOffset).c(RS_-
SYST_00028)
For more details, see End to End Library [23].
[TPS_SYST_01073] E2E Protection via COM Callouts dIf the E2E Protection is done
via COM Callouts then the EndToEndProtectionISignalIPdu shall be defined.c
(RS_SYST_00028)
[TPS_SYST_01074] E2E Protection in the E2E Wrapper dIf the E2E Protection is
done in the E2E Wrapper then both EndToEndProtectionISignalIPdu and End-
ToEndProtectionVariablePrototype shall be defined.
Caveat: The E2E transformer approach is the standardized AUTOSAR way.c(RS_-
SYST_00028)
For more details, see Software Component Template specification [5].
[constr_1002] End-to-end protection does not support n:1 communication dAs
the n:1 communication scenario implies that probably not all senders use the same
dataId this scenario is explicitly not supported.c()

330 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

ARElement
EndToEndProtectionSet

«atpVariation,atpSplitable»

+endToEndProtection 0..*

Identifiable
EndToEndDescription
EndToEndProtection
+ category: NameToken [0..1]
+endToEndProfile + counterOffset: PositiveInteger [0..1]
+ crcOffset: PositiveInteger [0..1]
«atpSplitable» 0..1 + dataId: PositiveInteger [0..*] {ordered}
+ dataIdMode: PositiveInteger [0..1]
+ dataIdNibbleOffset: PositiveInteger [0..1]
+ dataLength: PositiveInteger [0..1]
«atpVariation,atpSplitable» + maxDeltaCounterInit: PositiveInteger [0..1]
+endToEndProtectionISignalIPdu 0..* + maxNoNewOrRepeatedData: PositiveInteger [0..1]
+ syncCounterInit: PositiveInteger [0..1]
EndToEndProtectionISignalIPdu

+ dataOffset: Integer

+iSignalIPdu 1 +iSignalGroup 1

IPdu FibexElement
ISignalIPdu ISignalGroup

+ unusedBitPattern: Integer

+iSignalGroup 0..1

«atpVariation»
+iSignalToPduMapping 0..*

Identifiable
ISignalToIPduMapping

+ packingByteOrder: ByteOrderEnum [0..1]

+ startPosition: UnlimitedInteger [0..1]
+ transferProperty: TransferPropertyEnum [0..1]
+ updateIndicationBitPosition: UnlimitedInteger [0..1]

Figure 6.18: EndToEndProtection for COM IPdus

Class EndToEndProtectionSet
Package M2::AUTOSARTemplates::SWComponentTemplate::EndToEndProtection
Note This represents a container for collection EndToEndProtectionInformation.
Tags:atp.recommendedPackage=EndToEndProtectionSets
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
endToEnd EndToEndProtection * aggr This is one particular EndToEndProtection.
Protection
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=endToEndProtection.shortName, endToEnd
Protection.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime

Table 6.59: EndToEndProtectionSet

Class EndToEndProtection
Package M2::AUTOSARTemplates::SWComponentTemplate::EndToEndProtection
Note This meta-class represents the ability to describe a particular end to end protection.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
5

331 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class EndToEndProtection
Attribute Type Mult. Kind Note
endToEnd EndToEndDescription 0..1 aggr This represents the particular EndToEndDescription.
Profile
Stereotypes: atpSplitable
Tags:atp.Splitkey=endToEndProfile
endToEnd EndToEndProtectionI * aggr Defines to which ISignalIPdu - ISignalGroup pair this End
Protection SignalIPdu ToEndProtection shall apply.
ISignalIPdu
In case several ISignalGroups are used to transport the
data (e.g. fan-out in the RTE) there may exist several End
ToEndProtectionISignalIPdu definitions.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=endToEndProtectionISignalIPdu, endToEnd
ProtectionISignalIPdu.variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
endToEnd EndToEndProtection * aggr Defines to which VariableDataPrototypes in the roles of
Protection VariablePrototype one sender and one or more receivers this EndTo
Variable Endprotection applies.
Prototype
It shall be possible to aggregate several EndToEnd
ProtectionVariablePrototype in case additional
hierarchical decompositions are introduced subsequently.
In this case one particular PortPrototype is split into
multiple PortPrototypes and connectors, all representing
the same data entity.
Caveat: The E2E wrapper approach involves
technologies that are not subjected to the AUTOSAR
standard and is superseded by the superior E2E
transformer approach (which is fully standardized by
AUTOSAR). Hence, new projects (without legacy
constraints due to carry-over parts) shall use the fully
standardized E2E transformer approach.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=endToEndProtectionVariablePrototype.short
Label, endToEndProtectionVariablePrototype.variation
Point.shortLabel
vh.latestBindingTime=preCompileTime

Table 6.60: EndToEndProtection

Class EndToEndProtectionISignalIPdu
Package M2::AUTOSARTemplates::SystemTemplate::EndToEndProtection
Note It is possible to protect the inter-ECU data exchange of safety-related ISignalGroups at the level of COM
IPdus using protection mechanisms provided by E2E Library. For each ISignalGroup to be protected, a
separate EndToEndProtectionISignalIPdu element shall be created within the EndToEndProtectionSet.
The EndToEndProtectionISignalIPdu element refers to the ISignalGroup that is to be protected and to the
ISignalIPdu that transmits the protected ISignalGroup. The information how the referenced ISignalGroup
shall be protected (through which E2E Profile and with which E2E settings) is defined in the EndToEnd
Description element.
Base ARObject
Attribute Type Mult. Kind Note
dataOffset Integer 1 attr This attribute defines the beginning offset (in bits) of the
Array representation of the Signal Group (including CRC,
counter and application signal group) in the IPdu. This
attribute is mandatory and the dataOffset shall always be
defined.
5

332 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class EndToEndProtectionISignalIPdu
iSignalGroup ISignalGroup 1 ref Reference to the ISignalGroup that is to be protected.
iSignalIPdu ISignalIPdu 1 ref Reference to the ISignalIPdu that transmits the protected
ISignalGroup.

Table 6.61: EndToEndProtectionISignalIPdu

Class EndToEndDescription
Package M2::AUTOSARTemplates::SWComponentTemplate::EndToEndProtection
Note This meta-class contains information about end-to-end protection. The set of applicable attributes
depends on the actual value of the category attribute of EndToEndProtection.
Base ARObject
Attribute Type Mult. Kind Note
category NameToken 0..1 attr The category represents the identification of the concrete
E2E profile. The applicable values are specified in a
semantic constraint and determine the applicable
attributes of EndToEndDescription.
Tags:xml.sequenceOffset=-100
counterOffset PositiveInteger 0..1 attr Bit offset of Counter from the beginning of the Array
representation of the Signal Group/VariableDataPrototype
(MSB order, bit numbering: bit 0 is the least important).
The offset shall be a multiplicity of 4 and it should be 8
whenever possible. For example, offset 8 means that the
counter will take the low nibble of the byte 1, i.e. bits 8 ..
11. If counterOffset is not present the value is defined by
the selected profile.
Tags:xml.sequenceOffset=-50
crcOffset PositiveInteger 0..1 attr Bit offset of CRC from the beginning of the Array
representation of the Signal Group/VariableDataPrototype
(MSB order, bit numbering: bit 0 is the least important).
The offset shall be a multiplicity of 8 and it should be 0
whenever possible. For example, offset 8 means that the
CRC will take the byte 1, i.e. bits 8..15. If crcOffset is not
present the value is defined by the selected profile.
Tags:xml.sequenceOffset=-60
dataId (ordered) PositiveInteger * attr This represents a unique numerical identifier.
Note: ID is used for protection against masquerading.
The details concerning the maximum number of values
(this information is specific for each E2E profile)
applicable for this attribute are controlled by a semantic
constraint that depends on the category of the EndToEnd
Protection.
Tags:xml.sequenceOffset=-90
dataIdMode PositiveInteger 0..1 attr There are three inclusion modes how the implicit two-byte
Data ID is included in the one-byte CRC:
• dataIDMode = 0: Two bytes are included in the
CRC (double ID configuration) This is used in
variant 1A.
• dataIDMode = 1: One of the two bytes byte is
included, alternating high and low byte,
depending on parity of the counter (alternating ID
configuration). For even counter low byte is
included; For odd counters the high byte is
included. This is used in variant 1B.
5

333 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class EndToEndDescription
4
• dataIDMode = 2: Only low byte is included, high
byte is never used. This is applicable if the IDs in
a particular system are 8 bits.
• dataIdMode = 3: The low byte is included in the
implicit CRC calculation, the low nibble of the
high byte is transmitted along with the data (i.e. it
is explicitly included), the high nibble of the high
byte is not used. This is applicable for the IDs up
to 12 bits.
Tags:xml.sequenceOffset=-85
dataIdNibble PositiveInteger 0..1 attr Bit offset of the low nibble of the high byte of Data ID. The
Offset applicability of this attribute is controlled by [constr_1261].
Tags:xml.sequenceOffset=-25
dataLength PositiveInteger 0..1 attr This attribute represents the length of the Array
representation of the Signal Group/VariableDataPrototype
including CRC and Counter in bits.
Tags:xml.sequenceOffset=-80
maxDelta PositiveInteger 0..1 attr Initial maximum allowed gap between two counter values
CounterInit of two consecutively received valid Data, i.e. how many
subsequent lost data is accepted. For example, if the
receiver gets Data with counter 1 and MaxDeltaCounter
Init is 1, then at the next reception the receiver can accept
Counters with values 2 and 3, but not 4.
Note that if the receiver does not receive new Data at a
consecutive read, then the receiver increments the
tolerance by 1.
Tags:xml.sequenceOffset=-70
maxNoNewOr PositiveInteger 0..1 attr The maximum amount of missing or repeated Data which
RepeatedData the receiver does not expect to exceed under normal
communication conditions.
Tags:xml.sequenceOffset=-40
syncCounterInit PositiveInteger 0..1 attr Number of Data required for validating the consistency of
the counter that shall be received with a valid counter (i.e.
counter within the allowed lock-in range) after the
detection of an unexpected behavior of a received
counter.
Tags:xml.sequenceOffset=-30

Table 6.62: EndToEndDescription

[constr_1001] Value of dataId shall be unique dThe value of the dataId shall be
unique within the scope of the System.c()
The maxDeltaCounterInit, maxNoNewOrRepeatedData and syncCoun-
terInit values can also be specified in the ReceiverComSpec. This allows
the definition of receiver specific values. Values for maxDeltaCounterInit,
maxNoNewOrRepeatedData and syncCounterInit that are defined in the
ReceiverComSpec override the possible values in the EndToEndDescription
class.
Caveat: Since the definition of those values is intended for the E2E wrapper approach,
those definitions will eventually be discontinued by AUTOSAR.

334 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

More details about those values can be found in the Software Component Template
specification [5].
The supported E2E profiles (possible values of category in EndToEndDescription) are
described in the Software Component Template [5] and the End to End Library [23].

335 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.3.4 GeneralPurposeConnection

In some cases it is important to describe a relation between different PduTrigger-

ings that are defined on the same PhysicalChannel, e.g. to create a link between
a Rx-Pdu and a Tx-Pdu. The GeneralPurposeConnection meta-class is able to
reference a number of PduTriggerings and thereby to set the referenced PduTrig-
gerings into a relationship that is defined by the GeneralPurposeConnection.
[TPS_SYST_02170] category of the GeneralPurposeConnection dThe cat-
egory of the GeneralPurposeConnection is used to define the purpose of the
relationship between the referenced PduTriggerings.c()
ARElement
GeneralPurposeConnection

+pduTriggering 0..*

Identifiable
PduTriggering

Figure 6.19: GeneralPurposeConnection

Class GeneralPurposeConnection
Package M2::AUTOSARTemplates::SystemTemplate::GeneralPurposeConnection
Note This meta-class allows to describe the relationship between several PduTriggerings that are defined on
the same PhysicalChannel, e.g. to create a link between Rx and Tx Pdu that are used for request/
response.
Tags:atp.recommendedPackage=GeneralPurposeConnections
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
pduTriggering PduTriggering * ref Reference to PduTriggerings that are connected to each
other by a GeneralPurposeConnection.

Table 6.63: GeneralPurposeConnection

[constr_3384] PduTriggerings referenced by GeneralPurposeConnection

shall be defined on the same PhysicalChannel dThe PduTriggerings that are
referenced by the GeneralPurposeConnection in the role pduTriggering shall
be defined on the same PhysicalChannel.c()
[constr_3383] Standardized values for the attribute category of meta-class Gen-
eralPurposeConnection dThe following values of the attribute category of meta-
class GeneralPurposeConnection are reserved by the AUTOSAR standard:
• XcpChannel
c()

336 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

The XcpChannel creates a link between one Tx-Pdu and one Rx-Pdu that are used for
request/response from one master.
[constr_3385] XcpChannel is allowed to reference exactly two PduTriggerings
dIn case that the category of meta-class GeneralPurposeConnection is set to the
value XcpChannel the GeneralPurposeConnection is allowed to reference exactly
two PduTriggerings in the role pduTriggering.c()
[constr_3386] XcpChannel is only allowed to reference PduTriggerings of Gen-
eralPurposeIPdus with category XCP dIn case that the category of meta-class
GeneralPurposeConnection is set to the value XcpChannel the GeneralPur-
poseConnection is allowed to reference PduTriggerings of GeneralPurpo-
seIPdus with category XCP.c()

6.4 IPdu Timing

AUTOSAR COM allows configuring statically two different transmission modes for each
IPdu (True and False). TransmissionModeDeclaration uses a transmission mode
selector, calculated from a number of individual TransmissionModeConditions or
ModeDrivenTransmissionModeConditions to decide which of the two modes is
selected. It is possible to switch between the transmission modes during runtime.

337 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

+initialMode
AtpStructureElement ARElement
Identifiable AtpBlueprint
0..1
ModeDeclaration AtpBlueprintable
+modeDeclaration AtpType
+ value: PositiveInteger [0..1] ModeDeclarationGroup
0..* «atpVariation»
+ onTransitionValue: PositiveInteger [0..1]

+modeDeclaration 1..*

ModeDrivenTransmissionModeCondition

+modeDrivenTrueCondition 0..* +modeDrivenFalseCondition 0..*

+transmissionModeFalseTiming
TransmissionModeTiming TransmissionModeDeclaration +transmissionModeCondition TransmissionModeCondition
0..1

+transmissionModeTrueTiming 0..*

0..1
+transmissionModeDeclaration 0..1

+cyclicTiming 0..1 +dataFilter 1

Describable
DataFilter
CyclicTiming Describable
IPduTiming + dataFilterType: DataFilterTypeEnum [0..1]
+ mask: UnlimitedInteger [0..1]
+ minimumDelay: TimeValue [0..1] + max: UnlimitedInteger [0..1]
+ min: UnlimitedInteger [0..1]
+eventControlledTiming 0..1 0..1 +iPduTimingSpecification + offset: PositiveInteger [0..1]
Describable + period: PositiveInteger [0..1]
+ x: UnlimitedInteger [0..1]
EventControlledTiming

+ numberOfRepetitions: Integer
FibexElement
ISignal
«atpVariation»
+ dataTypePolicy: DataTypePolicyEnum
+ iSignalType: ISignalTypeEnum [0..1]
+ length: UnlimitedInteger

+iSignal 0..1
+iSignalInIPdu 1
IPdu Identifiable
ISignalIPdu ISignalToIPduMapping
+ unusedBitPattern: Integer +iSignalToPduMapping + packingByteOrder: ByteOrderEnum [0..1]
«atpVariation» 0..* + startPosition: UnlimitedInteger [0..1]
+ transferProperty: TransferPropertyEnum [0..1]
+ updateIndicationBitPosition: UnlimitedInteger [0..1]

Figure 6.20: IPdu Timing

[TPS_SYST_01075] Signal content evaluation via TransmissionModeCondi-

tion dThe signal content can be evaluated as the transmission mode selector via
the TransmissionModeConditions.c(RS_SYST_00037)
[TPS_SYST_01076] Mode evaluation via modeDrivenTrueCondition or mod-
eDrivenFalseCondition dMode conditions can be evaluated as the transmission
mode selector via the modeDrivenTrueConditions or modeDrivenFalseCondi-
tions.c(RS_SYST_00037)
[constr_3045] Signal content evaluation vs. Mode evaluation dThe mode evalua-
tion and the signal content evaluation shall not be used in the same IPdu. A mix of
these two types is not allowed.c()
To use the signal content evaluation a TransmissionModeCondition can be at-
tached to each signal within an IPdu. Each TransmissionModeCondition con-
tains a reference to a signal and to an assigned filter. The filter condition is used for

338 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

the selection of the transmission mode. If at least one condition in the signal content
evaluation is true, Transmission Mode "TRUE" shall be used for this IPdu. In all other
cases, the Transmission Mode "FALSE" shall be used. More details can be found in
the COM Specification [22].
[constr_3046] Consistency of TransmissionModeCondition.iSignalInIPdu
dThe ISignalToIPduMapping referenced by the TransmissionModeCondition
in the role iSignalInIPdu shall belong to the same ISignalIPdu as the Trans-
missionModeCondition.c()
In the mode driven evaluation ModeDeclarations are evaluated. The transmis-
sionModeFalseTiming is activated if all defined modeDrivenFalseConditions
evaluate to true and the transmissionModeTrueTiming is activated if all defined
modeDrivenTrueConditions evaluate to true. Each condition that is defined by
ModeDrivenTransmissionModeCondition evaluates to true if one of the refer-
enced ModeDeclarations is active.
The TransmissionModeDeclaration element aggregates the Transmission-
ModeTiming in two different roles: transmissionModeTrueTiming and trans-
missionModeFalseTiming. The available COM Transmission Mode Timings can
be described by the CyclicTiming and EventControlledTiming elements (see
Table 6.64) that are aggregated by the TransmissionModeTiming class.
[TPS_SYST_01077] Mapping of Com Transmission Modes to System Template
elements dThe mapping of COM Transmission Modes to System Template elements
is described in Table 6.64.c(RS_SYST_00037)

COM Transmission Description realization in System Template

Modes
Periodic Transmissions occur indefinitely CyclicTiming
with a fixed period between them
Direct/n-times Event driven transmission with n-1 EventControlledTiming
repetitions
Mixed Periodic transmission with EventControlledTiming and
direct/n-times transmissions CyclicTiming
in between
None No transmission no timing assigned

Table 6.64: COM Transmission Modes

Class TransmissionModeDeclaration
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication::Timing
5

339 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class TransmissionModeDeclaration
Note AUTOSAR COM provides the possibility to define two different TRANSMISSION MODES (True and
False) for each I-PDU.
As TransmissionMode selector the signal content can be evaluated via transmissionModeCondition
(implemented directly in the COM module) or mode conditions can be defined with the modeDrivenTrue
Condition or modeDrivenFalseCondition (evaluated by BswM and invoking Com_SwitchIpduTxMode
COM API). If modeDrivenTrueCondition and modeDrivenFalseCondition are defined they shall never
evaluate to true both at the same time.
The mixing of Transmission Mode Switch via API and signal value is not allowed.
Base ARObject
Attribute Type Mult. Kind Note
modeDriven ModeDriven * aggr Defines the trigger for the Com_SwitchIpduTxMode
FalseCondition TransmissionMode Transmission Mode switch. Only if all defined modeDriven
Condition FalseConditions evaluate to true (AND associated) the
transmissionModeFalseTiming shall be activated. mode
DrivenTrueCondition and modeDrivenFalseCondition
shall never evaluate to true both at the same time.
modeDriven ModeDriven * aggr Defines the trigger for the Com_SwitchIpduTxMode
TrueCondition TransmissionMode Transmission Mode switch. Only if all defined modeDriven
Condition TrueConditions evaluate to true (AND associated) the
transmissionModeTrueTiming shall be activated. mode
DrivenTrueCondition and modeDrivenFalseCondition
shall never evaluate to true both at the same time.
transmission TransmissionMode * aggr The Transmission Mode Selector evaluates the conditions
ModeCondition Condition for a subset of signals and decides which transmission
mode should be used. In case only one transmission
mode is used there is no need for the "TransmissionMode
Condition" and its sub-structure. In case the transmission
mode shall be switched using the COM-API "Com_Switch
IpduTxMode" there is no need for the "TransmissionMode
Condition" and its sub-structure.
transmission TransmissionMode 0..1 aggr Timing Specification if the COM Transmission Mode is
ModeFalse Timing false. The Transmission Mode Selector is defined to be
Timing false, if all Conditions evaluate to false.
transmission TransmissionMode 0..1 aggr Timing Specification if the COM Transmission Mode is
ModeTrue Timing true. The Transmission Mode Selector is defined to be
Timing true, if at least one Condition evaluates to true.

Table 6.65: TransmissionModeDeclaration

Class TransmissionModeCondition
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication::Timing
Note Possibility to attach a condition to each signal within an I-PDU.
If at least one condition evaluates to true, TRANSMISSION MODE True shall be used for this I-Pdu. In all
other cases, the TRANSMISSION MODE FALSE shall be used.
Base ARObject
Attribute Type Mult. Kind Note
dataFilter DataFilter 1 aggr Possibilities to define conditions
iSignalInIPdu ISignalToIPduMapping 1 ref Reference to a signal to which a condition is attached.

Table 6.66: TransmissionModeCondition

340 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class ModeDrivenTransmissionModeCondition
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication::Timing
Note The condition defined by this class evaluates to true if one of the referenced modeDeclarations (OR
associated) is active. All referenced modeDeclarations shall be from the same ModeDeclarationGroup.
The condition is used to define which TransmissionMode shall be activated using Com_SwitchIpduTx
Mode.
Base ARObject
Attribute Type Mult. Kind Note
mode ModeDeclaration 1..* ref Reference to one modeDeclaration which is OR
Declaration associated in the context of the ModeDrivenTransmission
ModeCondition.

Table 6.67: ModeDrivenTransmissionModeCondition

The ModeDeclaration and the ModeDeclarationGroup is described in more de-

tail in the Software Component Template Specification [5].
Class TransmissionModeTiming
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication::Timing
Note If the COM Transmission Mode is false the timing is aggregated by the TransmissionModeTiming element
in the role of transmissionModeFalseTiming. If the COM Transmission Mode is true the timing is
aggregated by the TransmissionModeTiming element in the role of transmissionModeTrueTiming.
COM supports the following Transmission Modes:
• Periodic (Cyclic Timing)
• Direct /n-times (EventControlledTiming)
• Mixed (Cyclic and EventControlledTiming are assigned)
• None (no timing is assigned)
Base ARObject
Attribute Type Mult. Kind Note
cyclicTiming CyclicTiming 0..1 aggr Periodic Transmission Mode.
eventControlled EventControlledTiming 0..1 aggr Direct Transmission Mode.
Timing

Table 6.68: TransmissionModeTiming

341 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.4.1 Data Filter configuration

Data Filters are used on sender side to configure Transmission Mode Conditions
(TMC). On receiver side Data Filters can be used as filtering mechanisms for signals
(see ISignalPort element). More details about the usage of DataFilters can be
found in the Software Component Template Specification [5].
[TPS_SYST_02013] Usage of dataFilters on GroupSignals on receiver side
dIf the dataFilter of one GroupSignal evaluates to false the whole ISignal-
Group in which the GroupSignal is contained shall be discarded.c()
DataFilter «enumeration»
DataFilterTypeEnum
+ dataFilterType: DataFilterTypeEnum [0..1]
+ mask: UnlimitedInteger [0..1] always
+ max: UnlimitedInteger [0..1] maskedNewEqualsX
+ min: UnlimitedInteger [0..1] maskedNewDiffersMaskedOld
+ offset: PositiveInteger [0..1] maskedNewDiffersX
+ period: PositiveInteger [0..1] never
+ x: UnlimitedInteger [0..1] newIsWithin
newIsOutside
oneEveryN

Figure 6.21: Data Filter

Class DataFilter
Package M2::AUTOSARTemplates::CommonStructure::Filter
Note Base class for data filters. The type of the filter is specified in attribute dataFilterType. Some of the filter
types require additional arguments which are specified as attributes of this class.
Base ARObject
Attribute Type Mult. Kind Note
dataFilterType DataFilterTypeEnum 0..1 attr This attribute specifies the type of the filter.
mask UnlimitedInteger 0..1 attr Mask for old and new value.
max UnlimitedInteger 0..1 attr Value to specify the upper boundary
min UnlimitedInteger 0..1 attr Value to specify the lower boundary
offset PositiveInteger 0..1 attr Specifies the initial number of messages to occur before
the first message is passed
period PositiveInteger 0..1 attr Specifies number of messages to occur before the
message is passed again
x UnlimitedInteger 0..1 attr Value to compare with

Table 6.69: DataFilter

Enumeration DataFilterTypeEnum
Package M2::AUTOSARTemplates::CommonStructure::Filter
Note This enum specifies the supported DataFilterTypes.
Literal Description
always No filtering is performed so that the message always passes.
Tags:atp.EnumerationLiteralIndex=0
5

342 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Enumeration DataFilterTypeEnum
maskedNewDiffers Pass messages where the masked value has changed.
MaskedOld
(new_value&mask) !=(old_value&mask)
new_value: current value of the message
old_value: last value of the message (initialized with the initial value of the message, updated with
new_value if the new message value is not filtered out)
Tags:atp.EnumerationLiteralIndex=1
maskedNewDiffers Pass messages whose masked value is not equal to a specific value x
X
(new_value&mask) != x
new_value: current value of the message
Tags:atp.EnumerationLiteralIndex=2
maskedNewEquals Pass messages whose masked value is equal to a specific value x
X
(new_value&mask) == x
new_value: current value of the message
Tags:atp.EnumerationLiteralIndex=3
never The filter removes all messages.
Tags:atp.EnumerationLiteralIndex=4
newIsOutside Pass a message if its value is outside a predefined boundary.
(min > new_value) OR (new_value > max)
Tags:atp.EnumerationLiteralIndex=5
newIsWithin Pass a message if its value is within a predefined boundary.
min <= new_value <= max
Tags:atp.EnumerationLiteralIndex=6
oneEveryN Pass a message once every N message occurrences.
Algorithm: occurrence % period == offset
Start: occurrence = 0.
Each time the message is received or transmitted, occurrence is incremented by 1 after filtering.
Length of occurrence is 8 bit (minimum).
Tags:atp.EnumerationLiteralIndex=7

Table 6.70: DataFilterTypeEnum

343 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.4.2 Cyclic Timing

Describable
CyclicTiming

+timePeriod 1 +timeOffset 0..1

TimeRangeType

+ value: TimeValue

+tolerance 0..1

TimeRangeTypeTolerance

RelativeTolerance AbsoluteTolerance

+ relative: Integer + absolute: TimeValue

Figure 6.22: Cyclic Timing

Class CyclicTiming
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication::Timing
Note Specification of a cyclic sending behavior.
Base ARObject, Describable
Attribute Type Mult. Kind Note
timeOffset TimeRangeType 0..1 aggr This attribute specifies the time until first transmission of
this I-PDU. This attribute defines the time between Com_
IpduGroupStart and the first transmission of the cyclic
part of this transmission request for this I-PDU.
timePeriod TimeRangeType 1 aggr Period of the repetition of cyclic transmissions.

Table 6.71: CyclicTiming

344 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.4.3 EventControlled Timing

Describable
EventControlledTiming

+ numberOfRepetitions: Integer

+repetitionPeriod 0..1

TimeRangeType

+ value: TimeValue

+tolerance 0..1

TimeRangeTypeTolerance

RelativeTolerance AbsoluteTolerance

+ relative: Integer + absolute: TimeValue

Figure 6.23: EventControlled Timing

Class EventControlledTiming
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication::Timing
Note Specification of a event driven sending behavior. The PDU is sent n (numberOfRepeat + 1) times
separated by the repetitionPeriod. If numberOfRepeats = 0, then the Pdu is sent just once.
Base ARObject, Describable
Attribute Type Mult. Kind Note
numberOf Integer 1 attr Defines the number of repetitions for the Direct/N-Times
Repetitions transmission mode and the event driven part of Mixed
transmission mode.
repetitionPeriod TimeRangeType 0..1 aggr The repetitionPeriod specifies the time in seconds that
elapses before the pdu can be sent the next time
(Minimum repeat gap between two pdus). The repetition
Period is optional in case that no repetitions are
configured.

Table 6.72: EventControlledTiming

Class TimeRangeType
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication::Timing
Note The timeRange can be specified with the value attribute. Optionally a tolerance can be defined.
Base ARObject
Attribute Type Mult. Kind Note
tolerance TimeRangeType 0..1 aggr Optional specification of a tolerance.
Tolerance
value TimeValue 1 attr Average value of a date (in seconds)

Table 6.73: TimeRangeType

345 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class RelativeTolerance
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication::Timing
Note Maximum allowable deviation
Base ARObject, TimeRangeTypeTolerance
Attribute Type Mult. Kind Note
relative Integer 1 attr Maximum allowable deviation in percent (percent of the
corresponding TimeValue).

Table 6.74: RelativeTolerance

Class AbsoluteTolerance
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication::Timing
Note Maximum allowable deviation
Base ARObject, TimeRangeTypeTolerance
Attribute Type Mult. Kind Note
absolute TimeValue 1 attr Maximum allowable deviation in duration (in seconds)

Table 6.75: AbsoluteTolerance

346 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.4.4 Configuration of a trigger for COM_TriggerIPduSend API call

In the AUTOSAR BswM module a BswMAction with BswMTriggerIPduSend may

be defined. The COM API Com_TriggerIPDUSend is called when this action is con-
figured. By the call of Com_TriggerIPDUSend an IPdu with a given ID is triggered for
transmission.
With such a configuration a single transmission of an IPdu can be configured that is
independent of the configured COM transmission modes, e.g. in case of a vehicle
mode change.
In a System Description the usage of the Com_TriggerIPDUSend API is defined
with the TriggerIPduSendCondition that is aggregated by the PduTriggering
in the role triggerIPduSendCondition. The TriggerIPduSendCondition de-
fines the trigger for the Com_TriggerIPDUSend API call.
+initialMode
ModeDeclaration ModeDeclarationGroup
0..1
+ value: PositiveInteger [0..1] + onTransitionValue: PositiveInteger [0..1]
+modeDeclaration

0..* «atpVariation»

+modeDeclaration 1..*

TriggerIPduSendCondition

+triggerIPduSendCondition 0..*

PduTriggering

Figure 6.24: TriggerIPduSendCondition

Class TriggerIPduSendCondition
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication::Timing
Note The condition defined by this class evaluates to true if one of the referenced modeDeclarations (OR
associated) is active. The condition is used to define when the Pdu is triggered with the Com_Trigger
IPDUSend API call.
Base ARObject
Attribute Type Mult. Kind Note
mode ModeDeclaration 1..* ref Reference to one modeDeclaration which is OR
Declaration associated in the context of the TriggerIPduSend
Condition.

Table 6.76: TriggerIPduSendCondition

Only if all defined TriggerIPduSendConditions evaluate to true (AND associated)

the Com_TriggerIPDUSend API shall be called.

347 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_3211] PduTriggerings with triggerIPduSendCondition dOnly

PduTriggerings with references to ISignalIPdus are allowed to contain a trig-
gerIPduSendCondition.c()
Please note that OR Conditions defined by the TriggerIPduSendCondition.mod-
eDeclaration are evaluated first. The AND Conditions defined by PduTriggering.
triggerIPduSendConditions are evaluated after the OR Conditions.

348 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.5 I-Pdu Multiplexer

Multiplexing is used to transport varying Com IPdus at the same position in a single
multiplexed IPdu. A multiplexed IPdu consists of a dynamic part, a selector field and
an optional static part. According to the value of the selector field the dynamic part can
have a different layout.
[TPS_SYST_01078] Dynamic Part of a MultiplexedIPdu dFor each alternative of
a MultiplexedIPdu there is exactly one Com IPdu that is transmitted in the dynamic
part.c()
[TPS_SYST_01079] Static Part of a MultiplexedIPdu dThe static part of a Mul-
tiplexedIPdu is the same regardless of the selector field and consists of exactly one
Com IPdu.c()
The MultiplexedIPdu element contains attributes that describe the position and the
length of a selector within an IPdu. A selector is a bitfield of certain length, by the
value of which the corresponding data region of the dynamic part shall be interpreted
dynamically, i.e. at run-time.
[constr_3007] selectorFieldCodes for dynamic part alternatives dThe selec-
torFieldCodes for the dynamic part alternatives within one MultiplexedIPdu
shall differ from each other.c()
[constr_3097] Overlapping of segments of one MultiplexedIPdu is not allowed
dThe segments defined by the SegmentPosition elements of one and the same
MultiplexedIPdu - aggregated via StaticPart and DynamicPart - shall not
overlap.c()
[constr_3098] Defined segments of one MultiplexedIPdu shall not exceed the
length of the MultiplexedIPdu dThe segments defined by the SegmentPosition
elements of one and the same MultiplexedIPdu - aggregated via StaticPart and
DynamicPart - shall not exceed the length of the MultiplexedIPdu.c()
[constr_3099] Defined segments in a DynamicPart shall not exceed the length
of any DynamicPartAlternative.iPdu dThe segments defined by the Segment-
Position elements aggregated in the DynamicPart of a MultiplexedIPdu shall
not exceed the length of any DynamicPartAlternative.iPdu.c()
[constr_3100] Defined segments in a StaticPart shall not exceed the length of
the StaticPart.iPdu dThe segments defined by the SegmentPosition elements
aggregated in the StaticPart of a MultiplexedIPdu shall not exceed the length
of the StaticPart.iPduc()
[constr_3101] Signal representation of selector field for DynamicPartAlterna-
tive dEvery ISignalIPdu that is referenced by the DynamicPartAlternative
shall contain an ISignal that represents the selector field. The selector field signal
shall be located at the position that is described by the selectorFieldLength and
selectorFieldStartPosition.c()

349 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_5254] Value range of MultiplexedIPdu.selectorFieldLength dThe

value of MultiplexedIPdu.selectorFieldLength shall be in the range of 1..16
Bits.c()
It is assumed by the IPduM that the value of the ISignal representing the selec-
tor field value matches the value defined in DynamicPartAlternative.selector-
FieldCode. The IPduM does not set or modify the selector field value. Therefore it
is essential that the System Description is defined in a consistent way in order to get
valid selector field value configurations.
There are two approaches how the selector field value is configured:
• static initialization of the ISignal representing the selector field value.
• giving applications the possibility to write the selector field value.
If the selector field value is initialized using the ISignal representing the selector
field value then the consistency is defined in [TPS_SYST_02351]. In this case there
is no change to the value of the ISignal representing the selector field value during
runtime. Each DynamicPartAlternative has a corresponding IPdu with a cor-
rectly defined selector field value. Regardless which DynamicPartAlternative is
triggered by COM, it always has the correct selector field value.
[TPS_SYST_02351] Selector field signal initial values in case no application writ-
ing the selector field signal dIf
• the ISignal representing the selector field is referenced by an ISignalTrig-
gering and that ISignalTriggering refers to an ISignalPort where the
communicationDirection is set to out and
• the ISignal representing the selector field is referring to a SystemSignal and
that SystemSignal is neither
– referenced by a SenderReceiverToSignalMapping in the role system-
Signal nor
– part of a SystemSignalGroup that in turn is referenced by a Sender-
ReceiverToSignalGroupMapping,
then this ISignal representing the selector field shall have an initValue defined
which corresponds to the DynamicPartAlternative.selectorFieldCode of the
respective dynamic part alternative ISignalIPdu.c()
If the application shall be able to write the selector field value then the following
specification items apply: [TPS_SYST_02352], [constr_5232], [TPS_SYST_02353],
[TPS_SYST_02355], [TPS_SYST_02356], [constr_5233].
One possible use-case for the application to be able to write the selector field value
is to use the applications write access as the trigger to send out one specific Dynam-
icPartAlternative, exactly that DynamicPartAlternative which matches the
written selector field value. In order to achieve this functionality the COM module needs
to be configured according to the rules defined below.

350 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

The IPduM on sender side gets transmission requests from COM (for the case of ap-
plication writing the selector field value: the case of trigger transmit is excluded in
[TPS_SYST_02353]).
[TPS_SYST_02355] defines that only the valid DynamicPartAlternative is actu-
ally triggered for transmission by the COM module, and thus is made available to the
IPduM.
From the perspective of the IPduM there is not difference whether the selector field
value has been defined by initializing the COM-Signal or whether the application has
written the selector field value and the COM module has filtered the proper Dynamic-
PartAlternative to be sent to the IPduM.
[TPS_SYST_02352] Triggering in case of application writing the selector field
signal dIf
• the ISignal representing the selector field is referenced by an ISignalTrig-
gering and that ISignalTriggering refers to an ISignalPort where the
communicationDirection is set to out and
• the ISignal representing the selector field is referring to a SystemSignal and
that SystemSignal is either
– referenced by a SenderReceiverToSignalMapping in the role system-
Signal or
– part of a SystemSignalGroup that in turn is referenced by a Sender-
ReceiverToSignalGroupMapping,
then this ISignal representing the selector field shall be the only ISignal that is
mapped into the dynamic part alternative ISignalIPdu with a transferProperty
set to an arbitrary value.c()
[constr_5232] Triggering in case of application writing the selector field signal dIf
• the ISignal representing the selector field is referenced by an ISignalTrig-
gering and that ISignalTriggering refers to an ISignalPort where the
communicationDirection is set to out and
• the ISignal representing the selector field is referring to a SystemSignal and
that SystemSignal is either
– referenced by a SenderReceiverToSignalMapping in the role system-
Signal or
– part of a SystemSignalGroup that in turn is referenced by a Sender-
ReceiverToSignalGroupMapping
then any ISignal other than the ISignal representing the selector field shall be
mapped into that dynamic part alternative ISignalIPdu using the transferProp-
erty set to pending.c()

351 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

In other words, if the selector field signal is written by the application software, then
the selector field ISignal may be the only ISignal which triggers the dynamic part
alternative ISignalIPdu. No triggering of a dynamic part alternative ISignalIPdu
may be a use case as well, in such cases a cyclic transmission would still be possible.
[TPS_SYST_02353] No support for trigger transmit in case of application writing
the selector field signal dIf
• the ISignal representing the selector field is referenced by an ISignalTrig-
gering and that ISignalTriggering refers to an ISignalPort where the
communicationDirection is set to out and
• the ISignal representing the selector field is referring to a SystemSignal and
that SystemSignal is either
– referenced by a SenderReceiverToSignalMapping in the role system-
Signal or
– part of a SystemSignalGroup that in turn is referenced by a Sender-
ReceiverToSignalGroupMapping
then the dynamic part alternative ISignalIPdu, where the ISignal representing
the selector field is mapped to, shall not be used in a trigger transmit COM stack
configuration.c()
[TPS_SYST_02354] No support for Just-In-Time update of dynamic parts in case
of application writing the selector field signal dIf
• the ISignal representing the selector field is referenced by an ISignalTrig-
gering and that ISignalTriggering refers to an ISignalPort where the
communicationDirection is set to out and
• the ISignal representing the selector field is referring to a SystemSignal and
that SystemSignal is either
– referenced by a SenderReceiverToSignalMapping in the role system-
Signal or
– part of a SystemSignalGroup that in turn is referenced by a Sender-
ReceiverToSignalGroupMapping
then the IpduMJitUpdate configuration parameter of the IpduMTxDynamicPart
corresponding to the ISignalIPdu shall be configured to false during ECU Configu-
ration.c()
In other words, if the selector field signal is written by the application software, then the
dynamic part alternative ISignalIPdu shall only be triggered by the application layer,
no trigger transmit support allowed.
[TPS_SYST_02355] TransmissionModeDeclaration in case of application
writing the selector field signal dIf

352 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• the ISignal representing the selector field is referenced by an ISignalTrig-

gering and that ISignalTriggering refers to an ISignalPort where the
communicationDirection is set to out and
• the ISignal representing the selector field is referring to a SystemSignal and
that SystemSignal is either
– referenced by a SenderReceiverToSignalMapping in the role system-
Signal or
– part of a SystemSignalGroup that in turn is referenced by a Sender-
ReceiverToSignalGroupMapping
then the dynamic part alternative ISignalIPdu, where the ISignal representing
the selector field is mapped to, shall have an ISignalIPdu.iPduTimingSpecifi-
cation with a TransmissionModeDeclaration where the TransmissionMod-
eDeclaration.transmissionModeCondition defines a TransmissionMode-
Condition with
• TransmissionModeCondition.iSignalInIPdu refers to the ISignal-
ToIPduMapping which maps the ISignal representing the selector field
• DataFilter.dataFilterType = maskedNewEqualsX,
• DataFilter.mask is set to (2<selectorf ield_bitsize> ) - 1, where <selector-
field_bitsize> is the size of the selector field signal in bits, i.e. ISignal.length
of the ISignal representing the selector field,
• DataFilter.x corresponds to the DynamicPartAlternative.selector-
FieldCode of the respective dynamic part alternative ISignalIPdu,
• TransmissionModeDeclaration.transmissionModeFalseTiming shall
not be defined.
c()
[TPS_SYST_02356] Only one TransmissionModeCondition in case of applica-
tion writing the selector field signal dIf
• the ISignal representing the selector field is referenced by an ISignalTrig-
gering and that ISignalTriggering refers to an ISignalPort where the
communicationDirection is set to out and
• the ISignal representing the selector field is referring to a SystemSignal and
that SystemSignal is either
– referenced by a SenderReceiverToSignalMapping in the role system-
Signal or
– part of a SystemSignalGroup that in turn is referenced by a Sender-
ReceiverToSignalGroupMapping

353 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

then the dynamic part alternative ISignalIPdu, where the ISignal representing
the selector field is mapped to, shall have an ISignalIPdu.iPduTimingSpecifi-
cation with a TransmissionModeDeclaration where there is only one Trans-
missionModeCondition defined, as specified in [TPS_SYST_02355].c()
In other words, when the application software writes the selector field signal only that
dynamic part alternative ISignalIPdu with the matching selectorFieldCode is
actually available for sending.
[constr_5233] Usage of invalidValue in case of application writing the selector
field signal dIf
• the ISignal representing the selector field is referenced by an ISignalTrig-
gering and that ISignalTriggering refers to an ISignalPort where the
communicationDirection is set to out and
• the ISignal representing the selector field is referring to a SystemSignal and
that SystemSignal is either
– referenced by a SenderReceiverToSignalMapping in the role system-
Signal or
– part of a SystemSignalGroup that in turn is referenced by a Sender-
ReceiverToSignalGroupMapping
then
• the ISignal representing the selector field shall either
– define no invalid value (ISignal.networkRepresentationProps.in-
validValue) or
– the invalidValue defined shall be different than any of the defined selec-
tor field values for that MultiplexedIPdu.
c()

354 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Pdu Describable
IPdu IPduTiming

+ minimumDelay: TimeValue [0..1]

«enumeration» +iPduTimingSpecification 0..1

TriggerMode

none
staticPartTrigger «atpVariation»
dynamicPartTrigger
staticOrDynamicPartTrigger

MultiplexedIPdu SegmentPosition ISignalIPdu

+ selectorFieldByteOrder: ByteOrderEnum [0..1] + segmentByteOrder: ByteOrderEnum + unusedBitPattern: Integer

+ selectorFieldLength: Integer [0..1] + segmentLength: Integer
+ selectorFieldStartPosition: Integer [0..1] + segmentPosition: Integer
+ triggerMode: TriggerMode [0..1] +iPdu 1 +iPdu 1
+segmentPosition 1..*
+ unusedBitPattern: Integer [0..1]

«atpVariation» «atpVariation»
+staticPart 0..1 +dynamicPart 0..1 MultiplexedPart

StaticPart DynamicPart

DynamicPartAlternative
+dynamicPartAlternative
+ initialDynamicPart: Boolean
1..* + selectorFieldCode: Integer

Figure 6.25: I-Pdu Multiplexer (FibexCore: IPDUMultiplexerOverview)

355 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Enumeration TriggerMode
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note IPduM can be configured to send a transmission request for the new multiplexed I-PDU to the
PDU-Router because of conditions/ modes.
Literal Description
dynamicPartTrigger IPduM sends a transmission request to the PduR if a dynamic part is received.
Tags:atp.EnumerationLiteralIndex=0
none IPduM does not trigger transmission because of receiving anything of this IPdu in case of Trigger
Transmit.
Tags:atp.EnumerationLiteralIndex=1
staticOrDynamic IPduM sends a transmission request to the PduR if a static or dynamic part is received.
PartTrigger
Tags:atp.EnumerationLiteralIndex=2
staticPartTrigger IPduM sends a transmission request to the PduR if a static part is received.
Tags:atp.EnumerationLiteralIndex=3

Table 6.77: TriggerMode

Class MultiplexedIPdu
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note A MultiplexedPdu (i.e. NOT a COM I-PDU) contains a DynamicPart, an optional StaticPart and a selector
Field. In case of multiplexing this IPdu is routed between the Pdu Multiplexer and the Interface Layer.
A multiplexer is used to define variable parts within an IPdu that may carry different signals. The
receivers of such a IPdu can determine which signalPdus are transmitted by evaluating the selector field,
which carries a unique selector code for each sub-part.
Tags:atp.recommendedPackage=Pdus
Base ARObject, CollectableElement, FibexElement, IPdu, Identifiable, MultilanguageReferrable, Packageable
Element, Pdu, Referrable
Attribute Type Mult. Kind Note
dynamicPart DynamicPart 0..1 aggr According to the value of the selector field some parts of
the IPdu have a different layout. In a complete System
Description a MultiplexedIPdu shall contain a Dynamic
Part. The following use cases support the multiplicity to
be 0..1:
• If a MultiplexedIPdu is received by a Pdu
Gateway and is not delivered to the IPduM but
routed directly to a bus interface then the content
of the MulitplexedIPdu doesn’t need to be
described in the System Extract/Ecu Extract.
• If a MultiplexedIPdu is received by an ECU which
is only interested in the static part of the
MultiplexedIPdu then the dynamicPart does not
need to be described in the System Extract/Ecu
Extract.
atpVariation: Content of a multiplexed PDU can vary.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
5

356 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class MultiplexedIPdu
selectorField ByteOrderEnum 0..1 attr This attribute defines the order of the bytes of the selector
ByteOrder Field and the packing into the MultiplexedIPdu. Please
consider that [constr_3247] and [constr_3223] are
restricting the usage of this attribute.
In a complete System Description this attribute is
mandatory. If a MultiplexedPdu is received by a Pdu
Gateway and is not delivered to the IPduM but routed
directly to a bus interface then the content of the
MulitplexedPdu doesn’t need to be described in the
System Extract/Ecu Extract. To support this use case the
multiplicity is set to 0..1.
selectorField Integer 0..1 attr The size in bits of the selector field shall be configurable
Length in a range of 1-16 bits. In a complete System Description
this attribute is mandatory. If a MultiplexedPdu is received
by a Pdu Gateway and is not delivered to the IPduM but
routed directly to a bus interface then the content of the
MulitplexedPdu doesn’t need to be described in the
System Extract/Ecu Extract. To support this use case the
multiplicity is set to 0..1.
selectorField Integer 0..1 attr This parameter is necessary to describe the position of
StartPosition the selector field within the IPdu.
Note that the absolute position of the selectorField in the
MultiplexedIPdu is determined by the definition of the
selectorFieldByteOrder attribute of the Multiplexed Pdu. If
Big Endian is specified, the start position indicates the bit
position of the most significant bit in the IPdu. If Little
Endian is specified, the start position indicates the bit
position of the least significant bit in the IPdu. In
AUTOSAR the bit counting is always set to "sawtooth"
and the bit order is set to "Decreasing". The bit counting
in byte 0 starts with bit 0 (least significant bit). The most
significant bit in byte 0 is bit 7.
In a complete System Description this attribute is
mandatory. If a MultiplexedPdu is received by a Pdu
Gateway and is not delivered to the IPduM but routed
directly to a bus interface then the content of the
MulitplexedPdu doesn’t need to be described in the
System Extract/Ecu Extract. To support this use case the
multiplicity is set to 0..1.
staticPart StaticPart 0..1 aggr The static part of the multiplexed IPdu is the same
regardless of the selector field. The static part is optional.
atpVariation: Content of a multiplexed PDU can vary.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
triggerMode TriggerMode 0..1 attr IPduM can be configured to send a transmission request
for the new multiplexed IPdu to the PDU-Router because
of the trigger conditions/ modes that are described in the
TriggerMode enumeration.
In a complete System Description this attribute is
mandatory. If a MultiplexedPdu is received by a Pdu
Gateway and is not delivered to the IPduM but routed
directly to a bus interface then the content of the
MulitplexedPdu doesn’t need to be described in the
System Extract/Ecu Extract. To support this use case the
multiplicity is set to 0..1.
5

357 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class MultiplexedIPdu
unusedBit Integer 0..1 attr AUTOSAR COM and AUTOSAR IPDUM are filling not
Pattern used areas of an IPdu with this bit-pattern. This attribute
is mandatory to avoid undefined behavior. This
byte-pattern will be repeated throughout the IPdu.
In a complete System Description this attribute is
mandatory. If a MultiplexedPdu is received by a Pdu
Gateway and is not delivered to the IPduM but routed
directly to a bus interface then the content of the
MulitplexedPdu doesn’t need to be described in the
System Extract/Ecu Extract. To support this use case the
multiplicity is set to 0..1.

Table 6.78: MultiplexedIPdu

Class StaticPart
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note Some parts/signals of the I-PDU may be the same regardless of the selector field. Such a part is called
static part. The static part is optional.
Base ARObject, MultiplexedPart
Attribute Type Mult. Kind Note
iPdu ISignalIPdu 1 ref Reference to a Com IPdu which is routed to the IPduM
module and is combined to a multiplexedPdu.

Table 6.79: StaticPart

Class DynamicPart
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note Dynamic part of a multiplexed I-Pdu. Reserved space which is used to transport varying SignalIPdus at
the same position, controlled by the corresponding selectorFieldCode.
Base ARObject, MultiplexedPart
Attribute Type Mult. Kind Note
dynamicPart DynamicPartAlternative 1..* aggr Com IPdu alternatives that are transmitted in the Dynamic
Alternative Part of the MultiplexedIPdu.

Table 6.80: DynamicPart

Class DynamicPartAlternative
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note One of the Com IPdu alternatives that are transmitted in the Dynamic Part of the MultiplexedIPdu. The
selectorFieldCode specifies which Com IPdu is contained in the DynamicPart within a certain
transmission of a multiplexed PDU.
Base ARObject
Attribute Type Mult. Kind Note
initialDynamic Boolean 1 attr Dynamic part that shall be used to initialize this
Part multiplexed IPdu.
Constraint: Only one "DynamicPartAlternative" in a
"DynamicPart" shall be the initialDynamicPart.
iPdu ISignalIPdu 1 ref Reference to a Com IPdu which is routed to the IPduM
module and is combined to a multiplexedPdu.
5

358 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class DynamicPartAlternative
selectorField Integer 1 attr The selector field is part of a multiplexed IPdu. It consists
Code of contiguous bits. The value of the selector field selects
the layout of the multiplexed part of the IPdu.

Table 6.81: DynamicPartAlternative

Class MultiplexedPart (abstract)

Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note The StaticPart and the DynamicPart have common properties. Both can be separated in multiple
segments within the multiplexed PDU.
Base ARObject
Subclasses DynamicPart, StaticPart
Attribute Type Mult. Kind Note
segment SegmentPosition 1..* aggr The StaticPart and the DynamicPart can be separated in
Position multiple segments within the multiplexed PDU. Therefore
the StaticPart and the DynamicPart can contain multiple
SegmentPositions.

Table 6.82: MultiplexedPart

Class SegmentPosition
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note The StaticPart and the DynamicPart can be separated in multiple segments within the multiplexed PDU.
The ISignalIPdus are copied bit by bit into the MultiplexedIPdu. If the space of the first segment is 5 bits
large than the first 5 bits of the ISignalIPdu are copied into this first segment and so on.
Base ARObject
Attribute Type Mult. Kind Note
segmentByte ByteOrderEnum 1 attr This attribute defines the order of the bytes of the
Order segment and the packing into the MultiplexedIPdu.
Please consider that [constr_3247] and [constr_3224] are
restricting the usage of this attribute.
segmentLength Integer 1 attr Data Length of the segment in bits.
segment Integer 1 attr Segments bit position relatively to the beginning of a
Position multiplexed IPdu.
Note that the absolute position of the segment in the
MultiplexedIPdu is determined by the definition of the
segmentByteOrder attribute of the SegmentPosition. If
Big Endian is specified, the start position indicates the bit
position of the most significant bit in the IPdu. If Little
Endian is specified, the start position indicates the bit
position of the least significant bit in the IPdu. In
AUTOSAR the bit counting is always set to "sawtooth"
and the bit order is set to "Decreasing". The bit counting
in byte 0 starts with bit 0 (least significant bit). The most
significant bit in byte 0 is bit 7.

Table 6.83: SegmentPosition

[constr_3247] Byte order mix within a MultiplexedIPdu is not allowed dThe

segmentByteOrder of all SegmentPositions and the selectorFieldByte-
Order shall have the same value in the MultiplexedIPdu.c()

359 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_3223] No ByteOrderEnum.opaque allowed for MultiplexedIPdu.se-

lectorFieldByteOrder dThe values of MultiplexedIPdu.selectorFieldBy-
teOrder are restricted to ByteOrderEnum.mostSignificantByteFirst and
ByteOrderEnum.mostSignificantByteLast. I.e. the value ByteOrderEnum.
opaque is not allowed.c()
[constr_3224] No ByteOrderEnum.opaque allowed for SegmentPosition.seg-
mentByteOrder. dThe values of SegmentPosition.segmentByteOrder are re-
stricted to ByteOrderEnum.mostSignificantByteFirst and ByteOrderEnum.
mostSignificantByteLast. I.e. the value ByteOrderEnum.opaque is not al-
lowed.c()
Figure 6.26 shows an example of an IPdu Multiplexer. The static part of the multiplexed
IPdu contains ComIPduA. The value of the selector field in the dynamic part decides
which content is transmitted. ComIPduB is transmitted if the selector field value is "0".
ComIPduC is transmitted if the selector field value is "1".
The static and the dynamic part can consist of more than one element. These sub
parts of the static or dynamic parts are called segments. In Figure 6.26 the dynamic
Part is segmented into two parts. More details can be found in [24].
MuxPdu: MultiplexedIPdu

selectorFieldLength = 1
length = 64
selectorFieldStartPosition = 0

staticSegment: SegmentPosition
:StaticPart
segmentLength = 16
segmentPosition = 32 dynamicSegment1: SegmentPosition
:DynamicPart
segmentLength = 31
segmentPosition = 1

PduA: ISignalIPdu

dynamicSegment2: SegmentPosition

segmentLength = 16
segmentPosition = 48

PduC: ISignalIPdu alternative1: DynamicPartAlternative

selectorFieldCode = 1

PduB: ISignalIPdu alternative2: DynamicPartAlternative

selectorFieldCode = 0

Figure 6.26: I-Pdu Multiplexer Example

Each of the following figures shows an example with an allowed IPduM configuration.
Please note that the AUTOSAR IPduM module does not shift any part (static or dy-
namic) IPdu and just merges the payload. ISignalIPdus that are referenced by
the different DynamicPartAlternatives in one MultiplexedIPdu shall always
have the same length. A configuration may be optimized with respect to unused data
at end of a StaticPart ISignalIPdu. This is shown in figure 6.27 where the
ISignalIPdu that is referenced by the StaticPart is shorter than the Multi-
plexedIPdu. An optimization with respect to unused data at end of DynamicPar-
tAlternative ISignalIPdus is shown in figure 6.28.

360 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

0 48 64
MultiplexedPdu: Switch DynamicPart StaticPart DynamicPart

Alldynamic part
Referenced ISignalIPdus: alternativeshave the
samesize,even if
0 8 alternativescontain
unused areas.
DynamicPartAlternative: 1 Signal1 Signal2

0 8
DynamicPartAlternative: 2 Signal3 Signal4 Signal5

0 8
DynamicPartAlternative: 3 Signal3 Signal4 Signal6

0 Thestatic
part may
StaticPart: Signal6 be shorter

Figure 6.27: Multiplexer configuration example optimized with respect to unused data at
end of static part Pdu

0 48 64
MultiplexedPdu: Switch DynamicPart StaticPart

Referenced ISignalIPdus:
0 8
Alldynamic part
DynamicPartAlternative: 1 Signal1 Signal2 alternativeshave the
Thedynamic
parts may be
samesize,even if
shorter than the
0 8 alternativescontain
static part
unused areas.
DynamicPartAlternative: 2 Signal3 Signal4

0 8
DynamicPartAlternative: 3 Signal3 Signal4 Signal5

0 48
StaticPart: Signal6

Figure 6.28: Multiplexer configuration example optimized with respect to unused data at
end of dynamic part Pdus

361 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.5.1 I-Pdu Multiplexer in System Extract/ECU Extract

The processing in the ECU determines the description of MultiplexedIPdus in the

System Extract/Ecu Extract. In case that a Gateway ECU only routes a Multi-
plexedIPdu without being interested in the content leads to a reduced description
in the System Extract/ECU Extract. The following items describe the different scenar-
ios and the consequences for the System Extract/ECU Extract description. A complete
System Description contains all information.
[TPS_SYST_01080] Sending or receiving of a MultiplexedIPdu in System Ex-
tract/ECU Extract d
• all attributes of the MultiplexedIPdu are mandatory
• aggregated DynamicPart with associated ISignalIPdus is mandatory in case
– of sending
– of receiving if at least one DynamicPartAlternative is received by one
Ecu of the Extract.
• a PduTriggering shall be defined for the MultiplexedIPdu
• a PduTriggering shall be defined for all included ISignalIPdus in the Dy-
namicPart and StaticPart
c()
The initial ECU Configuration Generator configures COM, PduR, IpduM and lower lay-
ers with the information from the System Extract/ECU Extract.
[TPS_SYST_01081] Gatewaying of a MultiplexedIPdu in System Extract/ECU
Extract d
• StaticPart and DynamicPart definitions shall be omitted, thus no ISig-
nalIPdu description shall be included
• all attributes of the MultiplexedIPdu shall be omitted.
• a PduTriggering shall be defined only for the gatewayed MultiplexedIPdu
• an IPduMapping between the source and the target PduTriggerings shall be
defined
c()
The initial ECU Configuration Generator configures PduR and lower layers with the
information from the System Extract/ECU Extract.
[TPS_SYST_01082] Receiving and gatewaying of a MultiplexedIPdu in System
Extract/ECU Extract d
• all attributes of the MultiplexedIPdu are mandatory

362 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• aggregated DynamicPart with associated ISignalIPdus is mandatory in case

at least one DynamicPartAlternative is received by one Ecu of the Extract.
• a PduTriggering shall be defined for the MultiplexedIPdu
• an IPduMapping between the source and the target PduTriggerings shall be
defined
• a PduTriggering shall be defined for all included ISignalIPdus in the Dy-
namicPart and StaticPart
c()
The initial ECU Configuration Generator configures Com, PduR, IpduM and lower lay-
ers with the information from the System Extract/ECU Extract.

363 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.6 Frames
Identifiable
PhysicalChannel +managedPhysicalChannel 0..*

«atpVariation,atpSplitable»

+frameTriggering 0..*
Identifiable
FrameTriggering

+frame 1

FibexElement
Frame

+ frameLength: Integer [0..1]

«atpVariation»
+pduToFrameMapping 0..*

Identifiable
«atpPrototype» FibexElement
PduToFrameMapping Pdu
+pdu
+ packingByteOrder: ByteOrderEnum + hasDynamicLength: Boolean [0..1]
+ startPosition: Integer 1 + length: UnlimitedInteger [0..1]
+ updateIndicationBitPosition: Integer [0..1]

Figure 6.29: Frame Overview (FibexCore: FrameOverview)

[TPS_SYST_01083] Frame dA Frame represents a general design object that is used

to describe the layout of the included Pdus as a reusable asset.c()
[TPS_SYST_01084] FrameTriggering dThe FrameTriggering implements the
reusable definition of a Frame within a concrete context and thus defines a Frame’s
send behavior and identification on a certain PhysicalChannel.c()
[TPS_SYST_02255] Frame.frameLength usage for FlexrayFrames and Can-
Frames dThe frameLength for a FlexrayFrame shall be equal or larger than the
combined length of all Pdus that are mapped to the frame.
The frameLength for a CanFrame is used to describe the minimum length of a re-
ceived L-PDU to be accepted by a data length check. Therefore, it is possible to
configure a frameLength which is smaller than the mapped Pdu to this frame. If
data length check is not needed the frameLength of a CanFrame may be left unde-
fined. The reason for that is that if the CanFrame.frameLength is larger than the
Pdu.length of the mapped Pdu and data length check is used, a received Pdu will
always be discarded due to a failing minimum length check.c()

364 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class Frame (abstract)

Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note Data frame which is sent over a communication medium. This element describes the pure Layout of a
frame sent on a channel.
Base ARObject, CollectableElement, FibexElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Subclasses AbstractEthernetFrame, CanFrame, FlexrayFrame, LinFrame
Attribute Type Mult. Kind Note
frameLength Integer 0..1 attr The used length (in bytes) of the referencing frame.
Should not be confused with a static byte length reserved
for each frame by some platforms (e.g. FlexRay).
The frameLength of zero bytes is allowed.
Please consider also TPS_SYST_02255.
pduToFrame PduToFrameMapping * aggr A frames layout as a sequence of Pdus.
Mapping
atpVariation: The content of a frame can be variable.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild

Table 6.84: Frame

Class FrameTriggering (abstract)

Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreCommunication
Note The FrameTriggering describes the instance of a frame sent on a channel and defines the manner of
triggering (timing information) and identification of a frame on the channel, on which it is sent.
For the same frame, if FrameTriggerings exist on more than one channel of the same cluster the fan-out/
in is handled by the Bus interface.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Subclasses CanFrameTriggering, EthernetFrameTriggering, FlexrayFrameTriggering, LinFrameTriggering
Attribute Type Mult. Kind Note
frame Frame 1 ref One frame can be triggered several times, e.g. on
different channels. If a frame has no frame triggering, it
won’t be sent at all. A frame triggering has assigned
exactly one frame, which it triggers.
framePort FramePort * ref References to the FramePort on every ECU of the system
which sends and/or receives the frame.
References for both the sender and the receiver side
shall be included when the system is completely defined.
pduTriggering PduTriggering * ref This reference provides the relationship to the Pdu
Triggerings that are implemented by the FrameTriggering.
The reference is optional since no PduTriggering can be
defined for NmPdus and XCP Pdus.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild

Table 6.85: FrameTriggering

365 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.7 Specialized Attributes of the Communication Entities

In the Basic Software the timing of bus frames can be controlled by send requests of
the RTE in combination with the Transmission Mode and Transfer Property parameters
in COM. On the other hand the timing can be controlled by the FlexRay Interface and
LIN Interface.
This chapter describes the protocol specific extensions to the communication elements.
Identifiable
PhysicalChannel
+managedPhysicalChannel 0..*

«atpVariation,atpSplitable»

+frameTriggering 0..*
Identifiable
FrameTriggering FibexElement
+frame Frame

1 + frameLength: Integer [0..1]

FlexrayFrameTriggering
EthernetFrameTriggering
+ allowDynamicLSduLength: Boolean
+ messageId: PositiveInteger [0..1]
+ payloadPreambleIndicator: Boolean

+absolutelyScheduledTiming 0..*

FlexrayAbsolutelyScheduledTiming LinFrameTriggering CanFrameTriggering

+ slotID: PositiveInteger + identifier: Integer [0..1] + canAddressingMode: CanAddressingModeType

+ linChecksum: LinChecksumType [0..1] + canFrameRxBehavior: CanFrameRxBehaviorEnum [0..1]
+ canFrameTxBehavior: CanFrameTxBehaviorEnum [0..1]
+ identifier: Integer [0..1]
+ j1939requestable: Boolean [0..1]
+ rxMask: PositiveInteger [0..1]
+ txMask: PositiveInteger [0..1]

Figure 6.30: Frame Triggering

6.7.1 FlexRay specific description

[TPS_SYST_01128] Communication over FlexRay dThe System Template supports

the description of communication over FlexRay.c(RS_SYST_00024)
In the following, the elements necessary to describe the FlexRay communication are
specified.
FlexRay static segment parameters: Each FlexrayFrameTriggering is identified
by its slotID and communicationCycle. In the static segment all communication

366 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

slots are of identical, statically configured duration and all FrameTriggerings are of
identical, statically configured length.
The sending behavior where the exact time for the FlexrayFrameTriggerings
transmission is guaranteed is provided in the System Template by the usage of
FlexrayAbsolutelyScheduledTiming.
In the cycle counter field of every frame, the current value of the cycle counter is trans-
mitted (see FlexRay frame format). This value is incremented at the beginning of each
new cycle, ranging from 0 to 63, and is reset to 0 after a sequence of 64 cycles.
[TPS_SYST_01085] Transmission of a FrameTriggering multiple times within
one communication cycle dIn the static segment FlexrayFrameTriggerings can
be sent multiple times within one communication cycle. For describing this case multi-
ple FlexrayAbsolutelyScheduledTimings shall be used.c(RS_SYST_00024)
FlexRay dynamic segment parameters: In the dynamic segment the duration of com-
munication slots may vary in order to accommodate frames of varying length. Fur-
thermore, in the dynamic part, the slotID is equivalent to a priority. The higher the
number the lower is the priority.
The frames in the static and in the dynamic segment are described in the same way.
Each FlexrayFrameTriggering is identified by its slotID and communication-
Cycle. A description is provided by the usage of FlexrayAbsolutelyScheduled-
Timing.

367 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

FibexElement
Identifiable
+frame Frame
FrameTriggering
+ frameLength: Integer [0..1]
1

FlexrayFrameTriggering FlexrayFrame

+ allowDynamicLSduLength: Boolean
+ messageId: PositiveInteger [0..1]
+ payloadPreambleIndicator: Boolean

+absolutelyScheduledTiming 0..*

«enumeration» FlexrayAbsolutelyScheduledTiming
CycleRepetitionType
+ slotID: PositiveInteger
cycleRepetition1
cycleRepetition2
cycleRepetition4
cycleRepetition8
cycleRepetition16
cycleRepetition32
cycleRepetition64
cycleRepetition5 +communicationCycle 1
cycleRepetition10
cycleRepetition20 CommunicationCycle
cycleRepetition40
cycleRepetition50

CycleCounter CycleRepetition

+ CycleCounter: Integer + BaseCycle: Integer

+ CycleRepetition: CycleRepetitionType

Figure 6.31: FlexRay Absolutely Scheduled Timing

(Fibex4FlexRay:FlexrayAbsolutelyScheduledTiming)

Class FlexrayFrame
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Flexray::FlexrayCommunication
Note FlexRay specific Frame element.
Tags:atp.recommendedPackage=Frames
Base ARObject, CollectableElement, FibexElement, Frame, Identifiable, MultilanguageReferrable,
PackageableElement, Referrable
Attribute Type Mult. Kind Note
– – – – –
Table 6.86: FlexrayFrame

Class FlexrayFrameTriggering
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Flexray::FlexrayCommunication
Note FlexRay specific attributes to the FrameTriggering
Base ARObject, FrameTriggering, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
absolutely FlexrayAbsolutely * aggr Specification of a sending behaviour where the exact time
Scheduled ScheduledTiming for the frames transmission is guaranteed.
Timing
5

368 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class FlexrayFrameTriggering
allowDynamic Boolean 1 attr Allows L-PDU length reduction and indicates that the
LSduLength related CC buffer has to be reconfigured for the actual
length and Header-CRC before transmission of the
L-PDU.
If this attribute is set to true than the referenced Frame
length attribute defines the max. length.
messageId PositiveInteger 0..1 attr The first two bytes of the payload segment of the FlexRay
frame format for frames transmitted in the dynamic
segment can be used as receiver filterable data called the
message ID.
payload Boolean 1 attr Switching the Payload Preamble bit.
Preamble
Indicator
Table 6.87: FlexrayFrameTriggering

Class FlexrayAbsolutelyScheduledTiming
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Flexray::FlexrayCommunication
Note Each frame in FlexRay is identified by its slot id and communication cycle. A description is provided by
the usage of AbsolutelyScheduledTiming.
In the static segment a frame can be sent multiple times within one communication cycle. For describing
this case multiple AbsolutelyScheduledTimings have to be used. The main use case would be that a
frame is sent twice within one communication cycle.
Base ARObject
Attribute Type Mult. Kind Note
communication CommunicationCycle 1 aggr The communication cycle where the frame is sent.
Cycle
slotID PositiveInteger 1 attr In the static part the SlotID defines the slot in which the
frame is transmitted. The SlotID also determines, in
combination with FlexrayCluster::numberOfStaticSlots,
whether the frame is sent in static or dynamic segment. In
the dynamic part, the slot id is equivalent to a priority.
Lower dynamic slot ids are all sent until the end of the
dynamic segment. Higher numbers, which were ignored
that time, have to wait one cycle and then shall try again.
minValue: 1
maxValue: 2047

Table 6.88: FlexrayAbsolutelyScheduledTiming

369 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class CommunicationCycle (abstract)

Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreTopology
Note The communication cycle where the frame is sent.
Base ARObject
Subclasses CycleCounter, CycleRepetition
Attribute Type Mult. Kind Note
– – – – –
Table 6.89: CommunicationCycle

The communication cycle can be described by the CycleCounter or by the Cy-

cleRepetition:
Class CycleCounter
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreTopology
Note The communication cycle where the frame is send is described by the attribute "cycleCounter".
Base ARObject, CommunicationCycle
Attribute Type Mult. Kind Note
CycleCounter Integer 1 attr The communication cycle where the frame described by
this timing is sent. If a timing is given in this way the
referencing FlexrayCluster shall specify the cycleCount
Max as upper bound and point of total repetition. This
value is incremented at the beginning of each new cycle,
ranging from 0 to cycleCountMax, and is reset to 0 after a
sequence of cycleCountMax+1 cycles.

Table 6.90: CycleCounter

Class CycleRepetition
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreTopology
Note The communication cycle where the frame is send is described by the attributes baseCycle and cycle
Repetition.
Base ARObject, CommunicationCycle
Attribute Type Mult. Kind Note
BaseCycle Integer 1 attr The first communication cycle where the frame is sent.
This value is incremented at the beginning of each new
cycle, ranging from 0 to 63, and is reset to 0 after a
sequence of 64 cycles.
CycleRepetition CycleRepetitionType 1 attr The number of communication cycles (after the first cycle)
whenever the frame described by this timing is sent again.

Table 6.91: CycleRepetition

370 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Enumeration CycleRepetitionType
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::FibexCore::CoreTopology
Note The number of communication cycles (after the first cycle) whenever the frame is sent again. The
FlexRay communication controller allows only determined values.
Literal Description
cycleRepetition1 Attribute cycleRepetition value="1"
valid only for FlexRay Protocol 2.1 Rev A
Tags:atp.EnumerationLiteralIndex=0
cycleRepetition10 Attribute cycleRepetition value="10"
to support FlexRay 3.0
Tags:atp.EnumerationLiteralIndex=1
cycleRepetition16 Attribute cycleRepetition value="16"
valid only for FlexRay Protocol 2.1 Rev A
Tags:atp.EnumerationLiteralIndex=2
cycleRepetition2 Attribute cycleRepetition value="2"
valid only for FlexRay Protocol 2.1 Rev A
Tags:atp.EnumerationLiteralIndex=3
cycleRepetition20 Attribute cycleRepetition value="20"
to support FlexRay 3.0
Tags:atp.EnumerationLiteralIndex=4
cycleRepetition32 Attribute cycleRepetition value="32"
valid only for FlexRay Protocol 2.1 Rev A
Tags:atp.EnumerationLiteralIndex=5
cycleRepetition4 Attribute cycleRepetition value="4"
valid only for FlexRay Protocol 2.1 Rev A
Tags:atp.EnumerationLiteralIndex=6
cycleRepetition40 Attribute cycleRepetition value="40"
to support FlexRay 3.0
Tags:atp.EnumerationLiteralIndex=7
cycleRepetition5 Attribute cycleRepetition value="5"
to support FlexRay 3.0
Tags:atp.EnumerationLiteralIndex=8
cycleRepetition50 Attribute cycleRepetition value="50"
to support FlexRay 3.0
Tags:atp.EnumerationLiteralIndex=9
cycleRepetition64 Attribute cycleRepetition value="64"
valid only for FlexRay Protocol 2.1 Rev A
Tags:atp.EnumerationLiteralIndex=10
cycleRepetition8 Attribute cycleRepetition value="8"
valid only for FlexRay Protocol 2.1 Rev A
Tags:atp.EnumerationLiteralIndex=11

Table 6.92: CycleRepetitionType

371 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_3012] Overlapping of Pdus is prohibited dPdus mapped to a

FlexrayFrame shall NOT overlap.c()
[constr_3013] FlexrayFrame length shall not be exceeded dThe combined length
of all Pdus that are mapped into a FlexrayFrame shall not exceed the defined
FlexrayFrame length.c()
[constr_3014] Overlapping of updateIndicationBits for Pdus is prohibited dThe
updateIndicationBitPosition for a Pdu in a FlexrayFrame shall NOT overlap
with other updateIndicationBitPositions and Pdu locations.c()
[constr_5104] Assignment of a FlexrayFrame where allowDynamicLS-
duLength is set to true dFlexrayFrames which are referenced by a
FlexrayFrameTriggering where allowDynamicLSduLength is set to true shall
always be assigned to the dynamic segment.c()
[constr_5105] Mapping of Pdu with dynamic length in a FlexrayFrame dOnly the
last Pdu in a FlexrayFrame is allowed to be a Pdu with hasDynamicLength = true.c
()
Note: Please be aware that the dynamic Pdu at the end of the FlexRay Frame may
need to provide some mechanism to determine its actual length (e.g. length field,
termination). Otherwise the receiver is not able to determine the actual sent length.

6.7.2 LIN specific description

LIN is a protocol that is based on a single master - multiple slave principle. In the
following, the parameters will be specified, which are necessary to describe the LIN
Schedule Tables and the LIN Frames.
[TPS_SYST_01129] Communication over LIN dThe System Template supports the
description of communication over LIN.c(RS_SYST_00022)

372 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

+managedPhysicalChannel 0..*

Identifiable
LinPhysicalChannel
PhysicalChannel
+ busIdleTimeoutPeriod: TimeValue [0..1]
«atpVariation,atpSplitable»

+frameTriggering 0..*
FibexElement
Identifiable
Frame
FrameTriggering +frame
+ frameLength: Integer [0..1]
1
«enumeration»
«enumerati... ResumePosition
LinChecksumType
startFromBeginning
classic continueAtItPosition
enhanced
LinFrame
«enumeration»
LinFrameTriggering RunMode

+ identifier: Integer [0..1] RunContinuous

+ linChecksum: LinChecksumType [0..1] runOnce
«atpVariation»
+frameTriggering 1

LinUnconditionalFrame LinSporadicFrame LinEventTriggeredFrame

+linUnconditionalFrame 1..* +substitutedFrame 1..*

{ordered}

+collisionResolvingSchedule 0..1 +scheduleTable *

Identifiable
ScheduleTableEntry
+tableEntry LinScheduleTable
+ delay: TimeValue
+ positionInTable: Integer 1..* + resumePosition: ResumePosition [0..1]
+ runMode: RunMode [0..1]

LinCommunicationController
LinSlave

ApplicationEntry FreeFormatEntry LinConfigurationEntry +assignedController + assignNad: Boolean [0..1]

+ configuredNad: Integer
0..1 + functionId: PositiveInteger
+ initialNad: Integer [0..1]
+ nasTimeout: TimeValue [0..1]
+ supplierId: PositiveInteger
+ variantId: PositiveInteger

+assignedLinSlaveConfig 0..1 LinSlaveConfig

Referrable + configuredNad: Integer

LinSlaveConfigIdent +ident + functionId: PositiveInteger
+ initialNad: Integer [0..1] +linErrorResponse 1
0..1 + protocolVersion: String [0..1] +linErrorResponse
+ supplierId: PositiveInteger LinErrorResponse
+ variantId: PositiveInteger 0..1

Figure 6.32: LIN Schedule Table (Fibex4Lin:LinScheduleTable)

6.7.2.1 LIN Frames

One LIN Frame consists of two parts: header and response. The header is always
sent by a LinMaster, while the response is sent by only one dedicated LinSlave.
There are three different ways of transmitting frames on the bus: unconditional, event
triggered, and sporadic frames.

373 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class LinFrame (abstract)

Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Lin::LinCommunication
Note Lin specific Frame element.
Base ARObject, CollectableElement, FibexElement, Frame, Identifiable, MultilanguageReferrable,
PackageableElement, Referrable
Subclasses LinEventTriggeredFrame, LinSporadicFrame, LinUnconditionalFrame
Attribute Type Mult. Kind Note
– – – – –
Table 6.93: LinFrame

Class LinFrameTriggering
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Lin::LinCommunication
Note LIN specific attributes to the FrameTriggering
Base ARObject, FrameTriggering, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
identifier Integer 0..1 attr To describe a frames identifier on the communication
system, usually with a fixed identifierValue. For Lin
SporadicFrames the attribute shall be ignored.
linChecksum LinChecksumType 0..1 attr Type of checksum that the frame is using. This attribute is
optional because in case of sporadic frames it should not
be set.
Table 6.94: LinFrameTriggering

Enumeration LinChecksumType
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Lin::LinCommunication
Note Use of classic or enhanced checksum is managed by the master node and it is determined per frame
identifier;
Literal Description
classic Classic in communication with LIN 1.3 slave nodes
Tags:atp.EnumerationLiteralIndex=0
enhanced Enhanced in communication with LIN 2.0 slave nodes.
Tags:atp.EnumerationLiteralIndex=1

Table 6.95: LinChecksumType

[TPS_SYST_02095] LinFrameTriggering.linChecksum for LinUncondition-

alFrames dThe linChecksum attribute of a LinFrameTriggering that references
a LinUnconditionalFrame shall be set.c()
Class LinUnconditionalFrame
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Lin::LinCommunication
Note Unconditional frames carry signals. The master sends a frame header in a scheduled frame slot and the
designated slave node fills the frame with data.
Tags:atp.recommendedPackage=Frames
Base ARObject, CollectableElement, FibexElement, Frame, Identifiable, LinFrame, MultilanguageReferrable,
PackageableElement, Referrable
5

374 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class LinUnconditionalFrame
Attribute Type Mult. Kind Note
– – – – –
Table 6.96: LinUnconditionalFrame

[constr_3225] LinFrameTriggering.linChecksum not allowed for LinSpo-

radicFrames dThe linChecksum attribute of a LinFrameTriggering that refer-
ences a LinSporadicFrame shall not be set.c()
[constr_3226] LinFrameTriggering.linChecksum for LinEventTriggered-
Frames dWithin a PhysicalChannel the linChecksum attribute of a Lin-
FrameTriggering that references a LinEventTriggeredFrame shall have the
same value as the linChecksum attribute of each LinFrameTriggering that ref-
erences a LinUnconditionalFrame that in turn is referenced by that LinEvent-
TriggeredFrame.c()
[constr_3203] LinFrameTriggering to LinSporadicFrame reference restric-
tion in LinSporadicFrame context dWithin a PhysicalChannel a LinUncon-
ditionalFrame shall be referenced by only one LinFrameTriggering to allow a
derivation of the identifier of a substituted Frame if the LinUnconditionalFrame is
referenced by a LinSporadicFrame in the role substitutedFrame.c()
Class LinSporadicFrame
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Lin::LinCommunication
Note A sporadic frame is a group of unconditional frames that share the same frame slot. The sporadic frame
shall not contain any Pdus.
Tags:atp.recommendedPackage=Frames
Base ARObject, CollectableElement, FibexElement, Frame, Identifiable, LinFrame, MultilanguageReferrable,
PackageableElement, Referrable
Attribute Type Mult. Kind Note
substituted LinUnconditionalFrame 1..* ref Reference to a group of unconditional frames that share
Frame (ordered) the same frame slot. In case that more than one of the
declared frames needs to be transferred, the one first
listed shall be chosen.
Within a channel a LIN Frame shall be referenced by only
one FrameTriggering. This allows a derivation of the
identifier of a substituted Frame. The identifier is specified
in FrameTriggering element.
A LinUnconditionalFrame associated with a LinSporadic
Frame may not be allocated in the same LinSchedule
Table as the sporadic frame.

Table 6.97: LinSporadicFrame

[constr_3204] LinUnconditionalFrames associated with a LinSpo-

radicFrame dA LinUnconditionalFrame associated with a LinSporadicFrame
shall not be allocated in the same LinScheduleTable as the LinSporadicFrame.c
()

375 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_3205] Existence of FramePort for a FrameTriggering that references a

LinSporadicFrame dA FrameTriggering that references a LinSporadicFrame
shall not have a reference to a FramePort.c()
Instead of the LinSporadicFrame a LinUnconditionalFrame is sent in the times-
lot on the bus and therefore the FrameTriggering that references a LinSpo-
radicFrame does not need to have a reference to a FramePort.
Class LinEventTriggeredFrame
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Lin::LinCommunication
Note An event triggered frame is used as a placeholder to allow multiple slave nodes to provide its response.
The header of an event triggered frame is transmitted when a frame slot allocated to the event triggered
frame is processed. The publisher of an associated unconditional frame shall only transmit the response
if at least one of the signals carried in its unconditional frame is updated. The LIN Master discovers and
purges collisions with the collisionResolvingScheduleTable.
The event controlled frame shall not contain any Pdus.
Tags:atp.recommendedPackage=Frames
Base ARObject, CollectableElement, FibexElement, Frame, Identifiable, LinFrame, MultilanguageReferrable,
PackageableElement, Referrable
Attribute Type Mult. Kind Note
collision LinScheduleTable 0..1 ref Reference to the schedule table, which resolves a
Resolving collision.
Schedule
linUnconditional LinUnconditionalFrame 1..* ref A list of slaves can respond to the master request if at
Frame least one of the signals carried in its unconditional frame
is updated. For each response a LinFrameTriggering and
a LinUnconditionalFrame shall be defined. Within a
channel a LIN Frame shall be referenced by only one
FrameTriggering. This allows a derivation of the identifier
of a substituted Frame. The identifier is specified in
FrameTriggering element. The Unconditional frames
associated with an event triggered frame shall:
• have equal length.
• use the same checksum model (i.e. mixing LIN
1.x and LIN 2.x frames is not allowed).
• reserve the first data field to its protected
identifier (even if the associated unconditional
frame is scheduled as a unconditional frame in
the same or another schedule table).
• be published by different slave nodes.
• shall not be included directly in the same
schedule table as the event triggered frame is
scheduled.
Table 6.98: LinEventTriggeredFrame

[TPS_SYST_02077] Subscribers of a LinEventTriggeredFrame dFor each sub-

scriber of a LinEventTriggeredFrame a LinUnconditionalFrame and a Lin-
FrameTriggering that points to this LinUnconditionalFrame shall be defined.c
()
[constr_3202] LinFrameTriggering to LinUnconditionalFrame reference re-
striction in LinEventTriggeredFrame context dWithin a PhysicalChannel a
LinUnconditionalFrame shall be referenced by only one LinFrameTriggering

376 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

to allow a derivation of the identifier of a substituted Frame if the LinUncondition-

alFrame is referenced by a LinEventTriggeredFrame in the role linUncondi-
tionalFrame.c()
[constr_3206] Existence of FramePort for a FrameTriggering that references
a LinEventTriggeredFrame dA FrameTriggering that references a LinEvent-
TriggeredFrame shall not have a reference to a FramePort.c()
A LinUnconditionalFrame is sent as the response of a LinEventTriggered-
Frame on the bus instead and therefore the FrameTriggering that references a
LinEventTriggeredFrame does not need to have a reference to a FramePort.
[TPS_SYST_02078] LinUnconditionalFrames associated with a LinEvent-
TriggeredFrame dThe LinUnconditionalFrames associated with a LinEvent-
TriggeredFrame shall:
• have equal length
• use the same checksum model (i.e. mixing LIN 1.x and LIN 2.x frames is not
allowed)
• reserve the first data field to its protected identifier (even if the associated Li-
nUnconditionalFrame is scheduled as a LinUnconditionalFrame in the
same or another schedule table)
• be published by different slave nodes
• not be included directly in the same LinScheduleTable as the associated
LinEventTriggeredFrame.
c()

6.7.2.2 LIN Schedule Table

The LinMaster uses one or more predefined scheduling tables to start the sending
and receiving to the LIN bus. These scheduling tables contain at least the relative
timing that defines the message sending.
[constr_1657] Existence of LinPhysicalChannel.scheduleTable dIn any given
Ecu Extract that contains a LinSlave, the LinPhysicalChannel that relates to the
respective LinSlave via commConnector.commController shall not aggregate a
LinScheduleTable.c()
Class LinScheduleTable
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Lin::LinCommunication
Note The master task (in the master node) transmits frame headers based on a schedule table. The schedule
table specifies the identifiers for each header and the interval between the start of a frame and the start
of the following frame.
5

377 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class LinScheduleTable
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
resumePosition ResumePosition 0..1 attr Defines, where a schedule table shall be proceeded in
case if it has been interrupted by a run-once table or
MRF/SRF.
runMode RunMode 0..1 attr The schedule table can be executed in two different
modes.
tableEntry ScheduleTableEntry 1..* aggr The scheduling table consists of table entries, which
contain Frame slots.
Table 6.99: LinScheduleTable

Enumeration RunMode
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Lin::LinCommunication
Note The schedule table can be executed in two different modes.
Literal Description
RunContinuous RUN_CONTINUOUS run mode
Tags:atp.EnumerationLiteralIndex=0
runOnce RUN_ONCE run mode
Tags:atp.EnumerationLiteralIndex=1

Table 6.100: RunMode

Enumeration ResumePosition
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Lin::LinCommunication
Note Defines, where a schedule table shall be proceeded in case if it has been interrupted by a run-once
table or MRF/SRF.
Literal Description
continueAtItPosition Continue at IT Point.
Tags:atp.EnumerationLiteralIndex=0
startFromBeginning Start from the beginning
Tags:atp.EnumerationLiteralIndex=1

Table 6.101: ResumePosition

Class ScheduleTableEntry (abstract)

Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Lin::LinCommunication
Note Table entry in a LinScheduleTable. Specifies what will be done in the frame slot.
Base ARObject
Subclasses ApplicationEntry, FreeFormatEntry , LinConfigurationEntry
Attribute Type Mult. Kind Note
delay TimeValue 1 attr Relative delay between this tableEntry and the start of the
successor in the schedule table in seconds.
introduction DocumentationBlock 0..1 aggr This represents introductory documentation about the
schedule table entry.
Tags:xml.sequenceOffset=-10
5

378 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class ScheduleTableEntry (abstract)
positionInTable Integer 1 attr Relative position in the schedule table. The first entry
index in the schedule table is 0.

Table 6.102: ScheduleTableEntry

Class ApplicationEntry
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Lin::LinCommunication
Note Schedule table entry for application messages.
Base ARObject, ScheduleTableEntry
Attribute Type Mult. Kind Note
frameTriggering LinFrameTriggering 1 ref Specifies the LinFrame that will be transmitted in this
frame slot.
Table 6.103: ApplicationEntry

Class FreeFormatEntry (abstract)

Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Lin::LinCommunication
Note FreeFormat transmits a fixed master request frame with the eight data bytes provided. This may for
instance be used to issue user specific fixed frames.
Base ARObject, ScheduleTableEntry
Subclasses FreeFormat
Attribute Type Mult. Kind Note
– – – – –
Table 6.104: FreeFormatEntry

Class LinConfigurationEntry (abstract)

Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Lin::LinCommunication
Note A ScheduleTableEntry which contains LIN specific assignments.
Base ARObject, ScheduleTableEntry
Subclasses AssignFrameId, AssignFrameIdRange, AssignNad, ConditionalChangeNad, DataDumpEntry, Save
ConfigurationEntry, UnassignFrameId
Attribute Type Mult. Kind Note
assigned LinSlave 0..1 ref The LIN slaves controller who is target of this assignment.
Controller Optional in case LinConfigurationEntry.assignedLinSlave
Config exists.
assignedLin LinSlaveConfigIdent 0..1 ref The LIN slave that is target of this assignment.
SlaveConfig
Please note that this reference is redundant to the
assignedController reference.
In an Ecu Extract of the LinMaster the LinSlave Ecus shall
not be available.
The information that is described here is necessary in the
ECU Extract for the configuration of the LinMaster.

Table 6.105: LinConfigurationEntry

379 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.7.2.3 Configuration Services

Identifiable Referrable
ScheduleTableEntry
LinScheduleTable LinSlaveConfigIdent
+tableEntry + delay: TimeValue
+ resumePosition: ResumePosition [0..1]
+ runMode: RunMode [0..1] 1..* + positionInTable: Integer

+assignedLinSlaveConfig 0..1

LinCommunicationController
FreeFormat FreeFormatEntry LinSlave

+ byteValue: Integer [8] {ordered} + assignNad: Boolean [0..1]

+ configuredNad: Integer
+ functionId: PositiveInteger
+ initialNad: Integer [0..1]
+ nasTimeout: TimeValue [0..1] LinConfigurationEntry
+ supplierId: PositiveInteger +assignedController
+ variantId: PositiveInteger
0..1

AssignNad AssignFrameId UnassignFrameId AssignFrameIdRange ConditionalChangeNad

+ newNad: Integer + startIndex: Integer + byte: Integer

+ id: PositiveInteger
+ invert: Integer
+ mask: Integer
+ newNad: Integer
SaveConfigurationEntry +framePid 0..4

FramePid DataDumpEntry

+ index: Integer + byteValue: Integer [5] {ordered}

+ pid: PositiveInteger
+assignedFrameTriggering 1 +unassignedFrameTriggering 1

LinFrameTriggering Identifiable
FrameTriggering
+ identifier: Integer [0..1]
+ linChecksum: LinChecksumType [0..1]

Figure 6.33: LIN Configuration Entries (Fibex4Lin:LinConfigurationEntries)

LIN only supports 64 identifiers. That creates the need for extending the address
space. Hence the frames are identified by message ids from a much larger address
space that is additionally separated by supplier ids. During runtime the master as-
signs a LinId to the frame. In case of identical parts within a cluster the initial node ID
(oldNad) is used to differentiate such nodes.
To support that in System Template the AssignFrameId is introduced as a LIN spe-
cific extension. For the assignment a relation to the LinSlave is used. The LinSlave
element is referenced by a LinCommunicationConnector element that contains a
list of frames processed by the slave node. More details can be found in chapter
6.7.2.3.
Class AssignFrameId
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Lin::LinCommunication
Note Schedule entry for an Assign Frame Id master request.
Base ARObject, LinConfigurationEntry , ScheduleTableEntry
Attribute Type Mult. Kind Note
5

380 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class AssignFrameId
assignedFrame LinFrameTriggering 1 ref The frame whose identifier is set by this assignment.
Triggering

Table 6.106: AssignFrameId

Class UnassignFrameId
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Lin::LinCommunication
Note Schedule entry for an Unassign Frame Id master request where the protected identifier is assigned the
value 0x40. This will disable reception/transmission of a previously dynamically assigned frame identifier.
Base ARObject, LinConfigurationEntry , ScheduleTableEntry
Attribute Type Mult. Kind Note
unassigned LinFrameTriggering 1 ref The frame whose identifier is reset by this assignment.
FrameTriggering

Table 6.107: UnassignFrameId

[TPS_SYST_02363] messageId of AssignFrameId and UnassignFrameId dIn

case that the AssignFrameId or UnassignFrameId refers to a LinSlave in the
role assignedController the messageId of the AssignFrameId/Unassign-
FrameId can be derived from the messageId of the LinConfigurableFrame that
references the same LinFrame as the LinFrameTriggering that is referenced by
the AssignFrameId/UnassignFrameId and that is aggregated by the LinCommu-
nicationConnector in role linConfigurableFrame that points to this LinSlave
in the role commController.
In case that the AssignFrameId/UnassignFrameId refers to a LinSlaveCon-
figIdent in the role assignedLinSlaveConfig the messageId of the Assign-
FrameId/UnassignFrameId can also be derived from the messageId of the Lin-
ConfigurableFrame that references the same LinFrame as the LinFrameTrig-
gering that is referenced by the AssignFrameId/UnassignFrameId and that is
aggregated by the referenced LinSlaveConfig.c()
The Assign frame ID configuration service is replaced in LIN 2.1 by the Assign frame
ID range configuration service. AssignFrameIdRange is used to set or disable Pro-
tected Identifiers up to four frames. For the assignment a relation to the LinSlave
is used. The LinSlave element is referenced by a LinCommunicationConnector
element that contains a list of frames processed by the slave node. More details can
be found in chapter 6.7.2.3.
Class AssignFrameIdRange
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Lin::LinCommunication
Note AssignFrameIdRange generates an assign frame PID range request.
Base ARObject, LinConfigurationEntry , ScheduleTableEntry
Attribute Type Mult. Kind Note
5

381 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class AssignFrameIdRange
framePid FramePid 0..4 aggr Optional assignment of frame_PID values that are
included in the request. The frame_PIDs are ordered.
startIndex Integer 1 attr The startIndex sets the index to the first frame to assign a
PID.
Table 6.108: AssignFrameIdRange

Class FramePid
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Lin::LinCommunication
Note Frame_PIDs that are included in the request. The "pid" attribute describes the value and the "index"
attribute the position of the frame_PID in the request.
Base ARObject
Attribute Type Mult. Kind Note
index Integer 1 attr This attribute is used to order the frame_PIDs. The values
of index shall be unique within one AssignFrameIdRange.
pid PositiveInteger 1 attr Frame_PID value.

Table 6.109: FramePid

[constr_5031] Uniqueness of FramePid.index dFramePid.index shall always be

set and be unique in the context of the aggregating AssignFrameIdRange.c()
Assign NAD is used to resolve conflicting NADs in LIN clusters built using off-the-
shelves slave nodes or reused slave nodes. This request uses the initial NAD. The
NAD used for the response shall be the same as in the request, i.e. the initial NAD.
Class AssignNad
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Lin::LinCommunication
Note Schedule entry for an Assign NAD master request.
Base ARObject, LinConfigurationEntry , ScheduleTableEntry
Attribute Type Mult. Kind Note
newNad Integer 1 attr The newly assigned NAD value.

Table 6.110: AssignNad

The conditional change NAD is used to detect unknown slave nodes in a cluster and
to separate their NADs.
Class ConditionalChangeNad
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Lin::LinCommunication
Note Generates an conditional change NAD request. See ISO 17987 protocol specification for more
information.
Base ARObject, LinConfigurationEntry , ScheduleTableEntry
Attribute Type Mult. Kind Note
byte Integer 1 attr Byte Position of Data Byte that should be used for the
bitwise XOR with Invert and the bitwise AND with Mask.
id PositiveInteger 1 attr Byte Position of Id.
5

382 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class ConditionalChangeNad
invert Integer 1 attr Byte Position of Invert.
mask Integer 1 attr Byte Position of Mask.
newNad Integer 1 attr The newly assigned NAD value (Byte Position).

Table 6.111: ConditionalChangeNad

The Save Configuration service tells the slave node that the slave application shall save
the current configuration.
Class SaveConfigurationEntry
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Lin::LinCommunication
Note This service is used to notify a slave node to store its configuration.
Base ARObject, LinConfigurationEntry , ScheduleTableEntry
Attribute Type Mult. Kind Note
– – – – –
Table 6.112: SaveConfigurationEntry

The Data Dump service is reserved for initial configuration of a slave node by the slave
node supplier and the format of this message is supplier specific.
Class DataDumpEntry
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Lin::LinCommunication
Note This service is reserved for initial configuration of a slave node by the slave node supplier and the format
of this message is supplier specific.
Base ARObject, LinConfigurationEntry , ScheduleTableEntry
Attribute Type Mult. Kind Note
byteValue Integer 5 attr Supplier specific format.
(ordered)

Table 6.113: DataDumpEntry

With the FreeFormat a scheduling of fixed data content within a diagnostic frame is
defined. For that specification FreeFormat is introduced.
Class FreeFormat
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Lin::LinCommunication
Note Representing freely defined data.
Base ARObject, FreeFormatEntry , ScheduleTableEntry
Attribute Type Mult. Kind Note
byteValue Integer 8 attr The integer Value of a freely defined data byte.
(ordered)

Table 6.114: FreeFormat

In order to be consistent with the rest of the communication configuration, it is required

that the diagnostic LIN Frames (Master Request Frame, Slave Response Frame) are

383 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

explicitly modeled as Frame elements. LinFrameTriggerings dealing with diag-

nostic Frames thus reference this diagnostic frames.
[TPS_SYST_02276] Modeling of LIN master request frames dA LIN master request
frame shall be modeled per LinPhysicalChannel in terms of a LinFrameTrig-
gering referencing a LinUnconditionalFrame while the following rules apply:
• The LinFrameTriggering has identifier set to 60 (0x3C) and linChecksum
set to classic.
• The LinFrameTriggering has a reference to an “out” FramePort of the Lin-
Master and “in” FramePorts of the respective LinSlaves in the scope of the
same LinPhysicalChannel.
• The LinFrameTriggering references a LinUnconditionalFrame with
frameLength set to 8.
• The LinFrameTriggering references a PduTriggering that in turn refer-
ences a NPdu that is mapped to the LinUnconditionalFrame and that has
its length set to 8. The NPdu is referenced by a LinTpConnection in the role
dataPdu.
• The PduTriggering has a reference to an “out” IPduPort of the LinMaster
and “in” IPduPorts of the respective LinSlaves in the scope of the same
LinPhysicalChannel.
c()
[TPS_SYST_02277] Modeling of LIN slave response frames dA LIN slave response
frame shall be modeled per LinPhysicalChannel in terms of a LinFrameTrig-
gering referencing a LinUnconditionalFrame while the following rules apply:
• The LinFrameTriggering has identifier set to 61 (0x3D) and linChecksum
set to classic.
• The LinFrameTriggering has a reference to an “in” FramePort of the Lin-
Master and “out” FramePorts of the respective LinSlaves in the scope of the
same LinPhysicalChannel.
• The LinFrameTriggering references a LinUnconditionalFrame with
frameLength set to 8.
• The LinFrameTriggering references a PduTriggering that in turn refer-
ences a NPdu that is mapped to the LinUnconditionalFrame and that has
its length set to 8. The NPdu is referenced by a LinTpConnection in the role
dataPdu.
• The PduTriggering has a reference to an “in” IPduPort of the LinMaster
and “out” IPduPorts of the respective LinSlaves in the scope of the same
LinPhysicalChannel.
c()

384 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.7.3 CAN specific description

This chapter describes additions to the CAN definition of FrameTriggerings.

[TPS_SYST_01130] Communication over CAN dThe System Template supports the
description of communication over CAN.c(RS_SYST_00021)
Identifiable FibexElement
+frame
FrameTriggering Frame
1 + frameLength: Integer [0..1]

CanFrameTriggering CanFrame
+ canAddressingMode: CanAddressingModeType
+ canFrameRxBehavior: CanFrameRxBehaviorEnum [0..1]
+ canFrameTxBehavior: CanFrameTxBehaviorEnum [0..1]
+ identifier: Integer [0..1]
+ j1939requestable: Boolean [0..1]
+ rxMask: PositiveInteger [0..1]
«enumeration»
+ txMask: PositiveInteger [0..1]
CanAddressingModeType

standard
extended
+rxIdentifierRange 0..1

RxIdentifierRange

+ lowerCanId: PositiveInteger
+ upperCanId: PositiveInteger

«enumeration» «enumeration»
CanFrameRxBehaviorEnum CanFrameTxBehaviorEnum

any can20
canFd canFd
can20

Figure 6.34: CanFrameTriggering (Fibex4Can:CanCommunication)

Class CanFrame
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Can::CanCommunication
Note CAN specific Frame element. This element shall also be used for TTCan.
Tags:atp.recommendedPackage=Frames
Base ARObject, CollectableElement, FibexElement, Frame, Identifiable, MultilanguageReferrable,
PackageableElement, Referrable
Attribute Type Mult. Kind Note
– – – – –
Table 6.115: CanFrame

385 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class CanFrameTriggering
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Can::CanCommunication
Note CAN specific attributes to the FrameTriggering
Base ARObject, FrameTriggering, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
absolutely TtcanAbsolutely * aggr Each frame in TTCAN is identified by its slot id and
Scheduled ScheduledTiming communication cycle. A description is provided by the
Timing usage of AbsolutelyScheduledTiming.
canAddressing CanAddressingMode 1 attr The CAN protocol supports two types of frame formats.
Mode Type The standard frame format uses 11-bit identifiers and is
defined in the CAN specification 2.0 A. Additionally the
extended frame format allows 29-bit identifiers and is
defined in the CAN specification 2.0 B.
canFrameRx CanFrameRxBehavior 0..1 attr Defines which CAN protocol shall be expected for frame
Behavior Enum reception.
canFrameTx CanFrameTxBehavior 0..1 attr Defines which CAN protocol shall be used for frame
Behavior Enum transmission.
identifier Integer 0..1 attr This attribute is used to define the identifier this frame
shall use on the CAN network.
j1939requestable Boolean 0..1 attr Frame can be triggered by the J1939 request message.
rxIdentifier RxIdentifierRange 0..1 aggr Optional definition of a CanId range.
Range
rxMask PositiveInteger 0..1 attr Identifier mask which denotes the relevant bits in the CAN
Identifier. Together with the identifier, this parameter
defines a CAN identifier range.
txMask PositiveInteger 0..1 attr Identifier mask which denotes static bits in the CAN
identifier. The other bits can be set dynamically.

Table 6.116: CanFrameTriggering

Enumeration CanAddressingModeType
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Can::CanCommunication
Note Indicates whether standard or extended CAN identifiers are used
Literal Description
extended Extended 29-bit-identifiers are used (CAN 2.0B)
Tags:atp.EnumerationLiteralIndex=0
standard Standard 11-bit-identifiers are used (CAN 2.0A)
Tags:atp.EnumerationLiteralIndex=1

Table 6.117: CanAddressingModeType

Class RxIdentifierRange
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Can::CanCommunication
Note Optional definition of a CanId range to reduce the effort of specifying every possible FrameTriggering
within the defined Id range during reception. All frames received within a range are mapped to the same
Pdu that is passed to a upper layer module (e.g. Nm, CDD, PduR).
Base ARObject
Attribute Type Mult. Kind Note
lowerCanId PositiveInteger 1 attr This attribute can be used together with the upperCanId
attribute to define a range of CanIds.
5

386 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class RxIdentifierRange
upperCanId PositiveInteger 1 attr This attribute can be used together with the lowerCanId
attribute to define a range of CanIds.

Table 6.118: RxIdentifierRange

Enumeration CanFrameRxBehaviorEnum
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Can::CanCommunication
Note Defines different CAN protocols for frame reception behavior.
Literal Description
any This CAN frame may be received as both, CAN 2.0 and CAN FD.
Tags:atp.EnumerationLiteralIndex=0
can20 This CAN frame shall be received as CAN 2.0 only. In case the CAN frame is received as CAN FD it
is discarded during reception.
Tags:atp.EnumerationLiteralIndex=1
canFd This CAN frame shall be received as CAN FD only. In case the CAN frame is received as CAN 2.0 it
is discarded during reception.
Tags:atp.EnumerationLiteralIndex=2

Table 6.119: CanFrameRxBehaviorEnum

There exist use-cases where the CanFrameTriggering is used as a placeholder for

a variant number of actual Can frames and therefore no dedicated CAN identifier can
be defined (e.g. MetaData handling, Bus Mirroring).
[TPS_SYST_02201] Existence of CanFrameTriggering.identifier dIn a Sys-
tem with category SYSTEM_DESCRIPTION the identifier may be omitted if the
value is computed during runtime. In a System with category ECU_EXTRACT,
ECU_SYSTEM_DESCRIPTION or SYSTEM_EXTRACT for the transmitter the identi-
fier may be omitted if the value is computed during runtime. In an System with cat-
egory ECU_EXTRACT, ECU_SYSTEM_DESCRIPTION or SYSTEM_EXTRACT for the re-
ceiver the identifier may be omitted if rxIdentifierRange is defined.c()
[TPS_SYST_02256] Allowed CanFrame.frameLength settings dFor a CanFrame it
is allowed to configure a smaller frameLength than the length of the Pdu which is
mapped to this CanFrame. This is used to model the minimum length of the received
L-PDU of a CanFrame to be accepted, if the data length check is enabled.c()
The CanFrameTriggering.canFrameRxBehavior allows to define a tolerant CAN
FD reception strategy. With the setting any the respective CAN frame is accepted for
reception, regardless whether it is received with CAN FD or CAN 2.0 protocol.
Enumeration CanFrameTxBehaviorEnum
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Can::CanCommunication
Note Defines different CAN protocols for frame transmission behavior.
Literal Description
5

387 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Enumeration CanFrameTxBehaviorEnum
can20 This CAN frame shall be sent as CAN 2.0 only.
Tags:atp.EnumerationLiteralIndex=0
canFd This CAN frame shall be sent as CAN FD.
Tags:atp.EnumerationLiteralIndex=1

Table 6.120: CanFrameTxBehaviorEnum

Note that the transmission behavior of CanFrameTriggering.canFrameTxBehav-

ior may still be redefined in the communication stack on driver level.
[TPS_SYST_02168] MetaData support required if CanFrameTriggering.txMask
is used dThe usage of CanFrameTriggering.txMask requires the support of COM
Stack MetaData.c()
Please note that the MetaData support in [TPS_SYST_02168] is required to calculate
CAN-Ids at run-time.
[TPS_SYST_02169] MetaData support may be required if CanFrameTriggering.
rxMask is used dThe usage of CanFrameTriggering.rxMask may require the sup-
port of COM Stack MetaData.c()
Please note that the MetaData support in [TPS_SYST_02169] is required if the upper
layer is interested in the masked part of CAN-Id, e.g. J1939. In some cases the upper
layer is not interested in the masked part of CAN-Id, e.g. for CanNm the MetaData is
not required.

388 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.7.3.1 SAE J1939 Protocol specific description

J1939 is a protocol and application layer standard of the SAE (Society of Automotive
Engineers) based on the CAN technology. It defines parameters uniquely identified by
the SPN (Suspect Parameter Number). These are mapped to parameter groups that
are uniquely identified by a PGN (Parameter Group Number). Parameters are simply
handled as SystemSignals which have a name derived from the name of the SPNs.
A Parameter Group (PG) corresponds to an IPdu.
J1939 uses extended 29 bit CAN identifiers to encode a priority, the source address of
the frame, and a frame ID which is based on the PGN (Parameter Group Number) and
may contain the destination address.
J1939 supports IPdus with more than 8 bytes, and IPdus with variable length that
may exceed 8 bytes. As soon as an IPdu has more than 8 bytes, it does not fit in
a single CAN frame and a transport protocol shall be used. Variable length IPdus
will always be handled by the J1939 TP, regardless of the actual length. The J1939
Transport Protocol is described in chapter 6.8.8.
[TPS_SYST_01132] Communication over SAE J1939 dThe System Template sup-
ports the description of communication over SAE J1939.c(RS_SYST_00038)
[constr_3209] CanFrameTriggerings with identical PGN dFor all Can-
FrameTriggerings where the attribute identifier contains the identical PGN (as
defined in section 5.2 Protocol Data Unit in [25]) the attribute j1939requestable
shall also have an identical value.c()

389 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.7.4 TTCAN specific description

This chapter describes additions to the TTCAN definition of FrameTriggerings.

FibexElement
Identifiable
+frame Frame
FrameTriggering
+ frameLength: Integer [0..1]
1

CanFrameTriggering
CanFrame
+ canAddressingMode: CanAddressingModeType
+ canFrameRxBehavior: CanFrameRxBehaviorEnum [0..1]
+ canFrameTxBehavior: CanFrameTxBehaviorEnum [0..1]
+ identifier: Integer [0..1]
+ j1939requestable: Boolean [0..1]
+ rxMask: PositiveInteger [0..1]
+ txMask: PositiveInteger [0..1]

+absolutelyScheduledTiming 0..*

«enumeration» TtcanAbsolutelyScheduledTiming
CycleRepetitionType
+ timeMark: Integer
cycleRepetition1 + trigger: TtcanTriggerType
cycleRepetition2 «enumeration»
cycleRepetition4 TtcanTriggerType
cycleRepetition8
cycleRepetition16 Attributes
cycleRepetition32 +communicationCycle 1 + rxTrigger
cycleRepetition64 + txRefTrigger
cycleRepetition5 CommunicationCycle + txRefTriggerGap
cycleRepetition10 + txTriggerMerged
cycleRepetition20 + txTriggerSingle
cycleRepetition40 + watchTrigger
cycleRepetition50 + watchTriggerGap

CycleCounter CycleRepetition

+ CycleCounter: Integer + BaseCycle: Integer

+ CycleRepetition: CycleRepetitionType

Figure 6.35: TtcanAbsolutelyScheduledTiming (Fibex4Ttcan:TtcanCommunication)

390 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class TtcanAbsolutelyScheduledTiming
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ttcan::TtcanCommunication
Note Each frame in TTCAN is identified by its slot id and communication cycle. A description is provided by the
usage of AbsolutelyScheduledTiming.
A frame can be sent multiple times within one communication cycle. For describing this case multiple
AbsolutelyScheduledTimings have to be used. The main use case would be that a frame is sent twice
within one communication cycle.
Base ARObject
Attribute Type Mult. Kind Note
communication CommunicationCycle 1 aggr The communication cycle where the frame is sent.
Cycle
timeMark Integer 1 attr Where FlexRay counts the slots in the static segment,
TTCAN requires explicit Tx and Rx time marks.
trigger TtcanTriggerType 1 attr Trigger type for this time window.

Table 6.121: TtcanAbsolutelyScheduledTiming

Enumeration TtcanTriggerType
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ttcan::TtcanCommunication
Note This type lists all trigger types for a time window.
Literal Description
rxTrigger Check for message reception
Tags:atp.EnumerationLiteralIndex=0
txRefTrigger Send reference message in periodic case
Tags:atp.EnumerationLiteralIndex=1
txRefTriggerGap Send reference message in event-synchronised case
Tags:atp.EnumerationLiteralIndex=2
txTriggerMerged Send message in a merged arbitration window
Tags:atp.EnumerationLiteralIndex=3
txTriggerSingle Send message in an exclusive time window
Tags:atp.EnumerationLiteralIndex=4
watchTrigger Check for missing reference message in periodic case
Tags:atp.EnumerationLiteralIndex=5
watchTriggerGap Check for missing reference message in event-synchronised case
Tags:atp.EnumerationLiteralIndex=6

Table 6.122: TtcanTriggerType

391 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.7.5 Ethernet specific description

Important note: Please note that the model of Release 4.4.0 to describe the Ether-
net communication can still be used in the current release. Elements like Sock-
etConnectionBundle and SocketConnection are set to obsolete and will be re-
moved in a future release. The documentation of the old model is available in
the Rel. 4.4.0 System Template specification. For the usage of the Rel. 4.4.0
model only the attributes that are described in Release 4.4.0 are valid. A mixture
of the current release and Rel. 4.4.0 models is not allowed.
This chapter specifies how the data communication between nodes in an IP network
over TCP and UDP protocols is described with an AUTOSAR model.
[TPS_SYST_01091] Definition of SoAdConfig dThe SoAdConfig in the System
Template is defined per EthernetPhysicalChannel which represents a VLAN.c
(RS_SYST_00039)
The SoAdConfig element is the entry point for the description of the IP communi-
cation on a VLAN since it contains a collection of SocketAddresses of nodes that
are able to receive and transmit information over the VLAN. Each node is represented
by an EcuInstance. The SocketAddress defines a communication endpoint (IP
Unicast or IP Multicast) and assigns it to one EthernetCommunicationConnec-
tor of an EcuInstance in case of IP Unicast communication and to one or several
EthernetCommunicationConnectors in case of IP Multicast.
Class SoAdConfig
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::ServiceInstances
Note SoAd Configuration for one specific Physical Channel.
Base ARObject
Attribute Type Mult. Kind Note
connection SocketConnection * aggr This aggregation is obsolete and will be removed in the
future. The connectionGroup aggregation with bundled
Connections shall be used instead.
Old description: Collection of socket connections.
Stereotypes: atpVariation
Tags:
atp.Status=obsolete
vh.latestBindingTime=postBuild
connection SocketConnection * aggr Collection of SocketConnectionBundles.
Bundle Bundle
Stereotypes: atpVariation
Tags:
atp.Status=obsolete
vh.latestBindingTime=postBuild
socketAddress SocketAddress 1..* aggr Collection of SoAdAddresses.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild

Table 6.123: SoAdConfig

The SocketAddress is the element that is used to establish the link between the
EcuInstance and the NetworkEndpoint. The SocketAddress has a connec-
tor reference to the EthernetCommunicationConnector. The SocketAddress

392 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

also aggregates the ApplicationEndpoint that in turn references the Network-

Endpoint.
Class SocketAddress
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::ServiceInstances
Note This meta-class represents a socket address towards the rest of the meta-model. The actual semantics
of the represented socket address, however, is contributed by aggregation of an ApplicationEndpoint.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
allowedIPv6Ext IPv6ExtHeaderFilterList 0..1 ref Reference to a list of IPv6 Extension Headers allowed for
Headers this SocketConnection. If no list is referenced all IPv6
Extension Headers are allowed and processed.
allowedTcp TcpOptionFilterList 0..1 ref Reference to a list of TCP options allowed for this Socket
Options Connection.
application ApplicationEndpoint 0..1 aggr Application addressing
Endpoint
connector EthernetCommunication 0..1 ref Association to a CommunicationConnector in the
Connector topology description. This reference shall be used if the
SocketAddress describes an IP unicast address for an
ECU that is part of the model.
differentiated PositiveInteger 0..1 attr The 6-bit Differentiated Service Field in the IP headers
ServiceField may be used for classifying network traffic. If not set a
value of zero is used to indicate packets that have not
been classified.
flowLabel PositiveInteger 0..1 attr The 20-bit Flow Label field in the IPv6 header may be
used by a source to label sequences of packets for which
it requests special handling by the IPv6 routers, such as
non-default quality of service. If not set a Flow Label of
zero is used to indicate packets that have not been
labeled.
multicast EthernetCommunication * ref Association to a CommunicationConnector in the topology
Connector Connector description. This reference shall be used if the Socket
Address describes an IP multicast address. This multicast
SocketAddress contains references to those ECUs in the
model that want to receive the multicast messages.
pathMtu Boolean 0..1 attr Defines whether the Path MTU Discovery shall be
Discovery performed for the related socket.
Enabled
pduCollection PositiveInteger 0..1 attr Defines the maximum buffer size in Byte which shall be
MaxBufferSize filled before a socket with Pdu collection enabled shall be
transmitted to the lower layer.
pduCollection TimeValue 0..1 attr Defines the time in seconds which shall pass before a
Timeout socket with Pdu collection enabled shall be transmitted to
the lower layer after the first Pdu has been put into the
socket buffer.
staticSocket StaticSocketConnection * aggr Definition of a static SocketConnection.
Connection
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
udpChecksum UdpChecksum 0..1 attr Specifies if UDP checksum handling shall be enabled
Handling CalculationEnum (udpChecksumEnabled) or skipped (udpChecksum
Disabled) on the related socket connection.

Table 6.124: SocketAddress

The communication endpoint itself is defined by the ApplicationEndpoint that is

aggregated by the SocketAddress and by the NetworkEndpoint that in turn is
referenced by the ApplicationEndpoint and is defined on the VLAN. The Appli-
cationEndpoint is the endpoint in terms of application addressing and defines the

393 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

transport layer configuration. The IP-address that is connected to the transport layer is
defined by the referenced NetworkEndpoint.
[constr_5061] EthernetCommunicationConnectors and referencing Socke-
tAddresses shall be in the same VLAN dEach EthernetCommunicationCon-
nector that is referenced by a SocketAddress in the role connector or multi-
castConnector shall be referenced by the same EthernetPhysicalChannel that
aggregates the SoAdConfig that in turn aggregates the SocketAddress.c()
[constr_3299] SocketAddress.pathMtuDiscoveryEnabled setting depen-
dency dSocketAddress.pathMtuDiscoveryEnabled shall only be set to TRUE if
EthernetCommunicationConnector.pathMtuEnabled == TRUE.c()
[constr_3311] Usage of SocketAddress.flowLabel dSocketAddress.flowLa-
bel shall only be used if the aggregated ApplicationEndpoint refers to a Net-
workEndpoint with an Ipv6Configuration.c()
[TPS_SYST_02140] SocketAddress.udpChecksumHandling default value dIf
SocketAddress.udpChecksumHandling is not used the value udpCheck-
sumEnabled shall be assumed.c()
Enumeration UdpChecksumCalculationEnum
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::ServiceInstances
Note This enumeration defines the UDP checksum calculation.
Literal Description
udpChecksum Udp checksum handling shall be disabled
Disabled
Tags:atp.EnumerationLiteralIndex=1
udpChecksum Udp checksum handling shall be enabled
Enabled
Tags:atp.EnumerationLiteralIndex=0

Table 6.125: UdpChecksumCalculationEnum

[TPS_SYST_02141] Semantics of udpChecksumHandling dThe semantics of ud-

pChecksumHandling is different for the sending and the receiving side:
TX - calculation of UDP checksum:
• udpChecksumEnabled means that the UDP checksum is calculated on the
transmission side.
• udpChecksumDisabled means that the UDP checksum is not calculated but
set to zero on the transmission side.
RX - handling of UDP checksum of zero:
• udpChecksumEnabled means that the UDP checksum of zero is treated as
invalid checksum on receiver side (causing the UDP datagram to be dropped by
the receiver). A valid non-zero checksum is accepted and the UDP datagram is
forwarded to the upper layer.
• udpChecksumDisabled means the the UDP checksum of zero is treated as
valid checksum on the receiver side (causing the UDP datagram to be forwarded

394 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

to the upper layer). A valid non-zero checksum is accepted and the UDP data-
gram is forwarded to the upper layer as well.
c()
[TPS_SYST_02142] Reception of invalid checksum dOn Rx side an invalid check-
sum should always cause the related UDP datagram to be discarded independent of
the udpChecksumHandling value.c()
To enable the IPv6 packet filtering the attribute allowedIPv6ExtHeaders al-
lows to define a white list of IPv6 Extension Headers that are allowed
for a SocketAddress. Lists of IPv6 Extension Headers can be defined
with the IPv6ExtHeaderFilterList element and can be collected in
IPv6ExtHeaderFilterSets.
ARElement
IPv6ExtHeaderFilterSet

+extHeaderFilterList 0..*

Identifiable
IPv6ExtHeaderFilterList

+ allowedIPv6ExtHeader: PositiveInteger [1..*]

+allowedIPv6ExtHeaders 0..1

Identifiable
SocketAddress

+ differentiatedServiceField: PositiveInteger [0..1]

+ flowLabel: PositiveInteger [0..1]
+ pathMtuDiscoveryEnabled: Boolean [0..1]
+ pduCollectionMaxBufferSize: PositiveInteger [0..1]
+ pduCollectionTimeout: TimeValue [0..1]
+ udpChecksumHandling: UdpChecksumCalculationEnum [0..1]

Figure 6.36: IPv6 Extension Header Filter Set

Class IPv6ExtHeaderFilterSet
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::IPv6HeaderFilterList
Note Set of IPv6 Extension Header Filters.
Tags:atp.recommendedPackage=IPv6ExtHeaderFilterSets
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
extHeaderFilter IPv6ExtHeaderFilterList * aggr In order to permit or deny certain types of IPv6 extension
List headers a white list of IPv6 extension headers can be
configured.

Table 6.126: IPv6ExtHeaderFilterSet

395 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class IPv6ExtHeaderFilterList
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::IPv6HeaderFilterList
Note White list for the filtering of IPv6 extension headers.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
allowedIPv6Ext PositiveInteger 1..* attr IPv6 Extension Header type allowed by this filter.
Header
Table 6.127: IPv6ExtHeaderFilterList

[constr_3276] Prohibition of usage of allowedIPv6ExtHeaders in IPv4 Sock-

etAddress dIPv4 SocketAddress shall not define allowedIPv6ExtHeaders.
An IPv4 SocketAddress aggregates an ApplicationEndpoint that refers to a
NetworkEndpoint that has an Ipv4Configuration as networkEndpointAd-
dress.c()
[constr_3277] Restriction of usage of IPv6ExtHeaderFilterLists in IPv6
SocketAddress dAll SocketAddresses related to the same IPv6 NetworkEnd-
point shall all reference either no or exactly the same IPv6ExtHeaderFilterList
with the allowedIPv6ExtHeaders attribute.c()
To enable the filtering of Tcp options the attribute allowedTcpOptions defines a
white list of Tcp options that are allowed for a SocketAddress. Lists of Tcp Option
filters can be defined with the TcpOptionFilterList element and can be collected
in TcpOptionFilterSets.
ARElement
TcpOptionFilterSet

+tcpOptionFilterList 0..*

Identifiable
TcpOptionFilterList

+ allowedTcpOption: PositiveInteger [1..*]

+allowedTcpOptions 0..1

Identifiable
SocketAddress

+ differentiatedServiceField: PositiveInteger [0..1]

Figure 6.37: Tcp Option Filter Set

396 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class TcpOptionFilterSet
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::TcpOptionFilterSet
Note Set of TcpOptionFilterLists.
Tags:atp.recommendedPackage=TcpOptionFilterSets
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
tcpOptionFilter TcpOptionFilterList * aggr Collection of white lists for the filtering of TCP options.
List
Table 6.128: TcpOptionFilterSet

Class TcpOptionFilterList
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::TcpOptionFilterSet
Note White list for the filtering of TCP options.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
allowedTcp PositiveInteger 1..* attr TCP option kind allowed by this filter.
Option

Table 6.129: TcpOptionFilterList

[constr_3297] Prohibition of usage of allowedTcpOptions in Udp SocketAd-

dress dUdp SocketAddress shall not define allowedTcpOptions. A Udp Sock-
etAddress aggregates an ApplicationEndpoint that has a UdpTp defined as
tpConfiguration.c()

6.7.5.1 ApplicationEndpoint

Class ApplicationEndpoint
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note An application endpoint is the endpoint on an Ecu in terms of application addressing (e.g. socket). The
application endpoint represents e.g. the listen socket in client-server-based communication.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
consumed ConsumedService * aggr Consumed service instances.
ServiceInstance Instance
Tags:atp.Status=obsolete
maxNumberOf PositiveInteger 0..1 attr This attribute defines the maximal number of clients the
Connections Server is able to deal with in case of Service Discovery.
network NetworkEndpoint 1 ref Reference to the network address.
Endpoint
priority PositiveInteger 0..1 attr Defines the frame priority where values from 0 (best
effort) to 7 (highest) are allowed.
providedService ProvidedService * aggr Provided service instances.
Instance Instance
Tags:atp.Status=obsolete
5

397 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class ApplicationEndpoint
tlsCrypto TlsCryptoService 0..1 ref This reference identifies the applicable TlsCryptoService
Mapping Mapping Mapping that adds the ability for TLS-based encryption
on the enclosing ApplicationEndpoint.
tpConfiguration TransportProtocol 0..1 aggr Configuration of the used transport protocol.
Configuration

Table 6.130: ApplicationEndpoint

Identifiable
ApplicationEndpoint

+ maxNumberOfConnections: PositiveInteger [0..1]

+ priority: PositiveInteger [0..1]

+tpConfiguration 0..1

TransportProtocolConfiguration

GenericTp TcpUdpConfig RtpTp Ieee1722Tp

+tcpUdpConfig
+ tpAddress: String [0..1] + ssrc: PositiveInteger + relativeRepresentationTime: TimeValue [0..1]
+ tpTechnology: String 1 + streamIdentifier: PositiveInteger
+ subType: PositiveInteger [0..1]
+ version: PositiveInteger [0..1]

TcpTp
UdpTp
+ keepAliveInterval: TimeValue [0..1] HttpTp
+ keepAliveProbesMax: PositiveInteger [0..1] +tcpTpConfig + contentType: String [0..1]
+ keepAlives: Boolean [0..1] + protocolVersion: String
+ keepAliveTime: TimeValue [0..1] 1
+ requestMethod: RequestMethodEnum [0..1]
+ naglesAlgorithm: Boolean [0..1] + uri: UriString [0..1]
+ receiveWindowMin: PositiveInteger [0..1]
+ tcpRetransmissionTimeout: TimeValue [0..1]
«enumeration»
+udpTpPort 1 +tcpTpPort 1 RequestMethodEnum

get
TpPort post
+ dynamicallyAssigned: Boolean [0..1] head
+ portNumber: PositiveInteger [0..1] put
delete
trace
options
connect

Figure 6.38: Application Endpoint

Class TransportProtocolConfiguration (abstract)

Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Transport Protocol configuration.
5

398 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class TransportProtocolConfiguration (abstract)
Base ARObject
Subclasses GenericTp, HttpTp, Ieee1722Tp, RtpTp, TcpUdpConfig
Attribute Type Mult. Kind Note
– – – – –
Table 6.131: TransportProtocolConfiguration

The following Transport Protocols are supported by the System Template:

Class GenericTp
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Content Model for a generic transport protocol.
Base ARObject, TransportProtocolConfiguration
Attribute Type Mult. Kind Note
tpAddress String 0..1 attr Transport Protocol dependent Address.
tpTechnology String 1 attr Name of the used Transport Protocol.

Table 6.132: GenericTp

Class TcpUdpConfig (abstract)

Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Tcp or Udp Transport Protocol Configuration.
Base ARObject, TransportProtocolConfiguration
Subclasses TcpTp, UdpTp
Attribute Type Mult. Kind Note
– – – – –
Table 6.133: TcpUdpConfig

Class UdpTp
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Content Model for UDP configuration.
Base ARObject, TcpUdpConfig, TransportProtocolConfiguration
Attribute Type Mult. Kind Note
udpTpPort TpPort 1 aggr Udp Port configuration.

Table 6.134: UdpTp

Class TcpTp
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Content Model for TCP configuration.
Base ARObject, TcpUdpConfig, TransportProtocolConfiguration
Attribute Type Mult. Kind Note
keepAlive TimeValue 0..1 attr Specifies the interval in seconds between subsequent
Interval keepalive probes.
5

399 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class TcpTp
keepAlive PositiveInteger 0..1 attr Maximum number of times that TCP retransmits an
ProbesMax individual data segment before aborting the connection.
keepAlives Boolean 0..1 attr Indicates if Keep-Alive messages are sent.
keepAliveTime TimeValue 0..1 attr Specifies the time in seconds between the last data
packet sent and the first keepalive probe.
naglesAlgorithm Boolean 0..1 attr Indicates if Nagle’s Algorithm is used.
receiveWindow PositiveInteger 0..1 attr Minimum size of the TCP receive window in bytes.
Min
tcp TimeValue 0..1 attr Defines the timeout in seconds before an
Retransmission unacknowledged TCP segment is sent again. If the tcp
Timeout RetransmissionTimeout is not defined or set to "INF", no
TCP segments shall be re-transmitted.
tcpTpPort TpPort 1 aggr TCP Port configuration.

Table 6.135: TcpTp

Class RtpTp
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note RTP over UDP or over TCP as transport protocol.
Base ARObject, TransportProtocolConfiguration
Attribute Type Mult. Kind Note
ssrc PositiveInteger 1 attr Synchronization source identifier uniquely identifies the
source of a stream. The synchronization sources within
the same RTP session will be unique.
tcpUdpConfig TcpUdpConfig 1 aggr Tcp or Udp Configuration.

Table 6.136: RtpTp

Class Ieee1722Tp
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Content Model for IEEE 1722 configuration.
Base ARObject, TransportProtocolConfiguration
Attribute Type Mult. Kind Note
relative TimeValue 0..1 attr Defines the time when content shall be presented (in
Representation seconds). The actual absolute time is creation time plus
Time relative presentation time.
streamIdentifier PositiveInteger 1 attr IEEE 1722 stream identifier
subType PositiveInteger 0..1 attr Protocol type.
version PositiveInteger 0..1 attr Revision of Ieee1722 standard

Table 6.137: Ieee1722Tp

Class HttpTp
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Http over TCP as transport protocol.
Base ARObject, TransportProtocolConfiguration
Attribute Type Mult. Kind Note
5

400 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class HttpTp
contentType String 0..1 attr Descriptor for the transported content.
protocolVersion String 1 attr HTTP Protocol version (e.g. 1.1)
requestMethod RequestMethodEnum 0..1 attr HTTP request method to be used.
tcpTpConfig TcpTp 1 aggr TcpTp Configuration.
uri UriString 0..1 attr URI to be called.

Table 6.138: HttpTp

Class TpPort
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Dynamic or direct assignment of a PortNumber.
Base ARObject
Attribute Type Mult. Kind Note
dynamically Boolean 0..1 attr Indicates whether the source port is dynamically
Assigned assigned.
Tags:atp.Status=obsolete
portNumber PositiveInteger 0..1 attr Port Number.

Table 6.139: TpPort

[TPS_SYST_02215] Usage of portNumber with value 0 dThe setting of the port-

Number to 0 means that the portNumber is assigned dynamically at runtime.c()
There are different use cases for the usage of portNumber value 0. This setting can
be used to describe that the remotePort is dynamically assigned and will be set by the
Service Discovery. The localPort can also be set to the value 0 to define that TcpIp
need to select an ephemeral port for communication.
[TPS_SYST_01131] TCP/IP and UDP/IP communication over Ethernet dThe Sys-
tem Template supports the description of TCP/IP and UDP/IP communication over
Ethernet.c(RS_SYST_00039)
[TPS_SYST_01089] ApplicationEndpoint priority dThe priority at the Ap-
plicationEndpoint shall be used as Ethernet Header information together with the
vlanIdentifier. If defined the priority overwrites the defaultPriority that
is defined in the VlanMembership and the priority that is defined at the Net-
workEndpoint.c(RS_SYST_00039)

401 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.7.5.2 NetworkEndpoint

Class NetworkEndpoint
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note The network endpoint defines the network addressing (e.g. IP-Address or MAC multicast address).
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
fullyQualified String 0..1 attr Defines the fully qualified domain name (FQDN) e.g.
DomainName some.example.host.
infrastructure InfrastructureServices 0..1 aggr Defines the network infrastructure services provided or
Services consumed.
ipSecConfig IPSecConfig 0..1 aggr Optional IPSec configuration that provides security
services for IP packets.
network NetworkEndpoint 1..* aggr Definition of a Network Address.
Endpoint Address
Tags:xml.name
Address
Plural=NETWORK-ENDPOINT-ADDRESSES
priority PositiveInteger 0..1 attr Defines the frame priority where values from 0 (best
effort) to 7 (highest) are allowed.

Table 6.140: NetworkEndpoint

The NetworkEndpoint defines the network addressing. The network endpoint may
have a priority and a FQDN (Fully Qualified Domain Name) that is used for the Service
Discovery (e.g. some.example.host.).
[TPS_SYST_01090] valid NetworkEndpoint dTo build a valid NetworkEndpoint
at least one of the following options shall be defined in the role NetworkEndpoint.
networkEndpointAddress:
• a MacMulticastConfiguration with a reference to a MacMulticastGroup
• Ipv4Configuration
• Ipv6Configuration
c(RS_SYST_00039)

402 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Identifiable
NetworkEndpoint

+ fullyQualifiedDomainName: String [0..1]

+ priority: PositiveInteger [0..1]

+networkEndpointAddress 1..*

NetworkEndpointAddress

Ipv4Configuration Ipv6Configuration MacMulticastConfiguration

+ assignmentPriority: PositiveInteger [0..1] + assignmentPriority: PositiveInteger [0..1]

+ defaultGateway: Ip4AddressString [0..1] + defaultRouter: Ip6AddressString [0..1]
+ dnsServerAddress: Ip4AddressString [0..*] + dnsServerAddress: Ip6AddressString [0..*]
+ ipAddressKeepBehavior: IpAddressKeepEnum [0..1] + enableAnycast: Boolean [0..1]
+ ipv4Address: Ip4AddressString [0..1] + hopCount: PositiveInteger [0..1]
+ ipv4AddressSource: Ipv4AddressSourceEnum [0..1] + ipAddressKeepBehavior: IpAddressKeepEnum [0..1]
+ networkMask: Ip4AddressString [0..1] + ipAddressPrefixLength: PositiveInteger [0..1]
+ ttl: PositiveInteger [0..1] + ipv6Address: Ip6AddressString [0..1]
+ ipv6AddressSource: Ipv6AddressSourceEnum [0..1]
+macMulticastGroup 1

«enumeration» «enumeration» «enumeration» Identifiable

Ipv4AddressSourceEnum Ipv6AddressSourceEnum IpAddressKeepEnum MacMulticastGroup

dhcpv4 dhcpv6 forget + macMulticastAddress: MacAddressString

autoIp linkLocal storePersistently
fixed fixed
autoIp_doip routerAdvertisement
linkLocal_doip

Figure 6.39: Network Endpoint

The attribute NetworkEndpoint.networkEndpointAddress defines whether an

IPv4, IPv6 or MAC multicast address is assigned to the NetworkEndpoint.
The reference of the MacMulticastConfiguration.macMulticastGroup defines
the mapping of IP multicast to MAC multicast.
[TPS_SYST_01088] NetworkEndpoint priority dThe priority at the Network-
Endpoint shall be used as Ethernet Header information together with the vlanIden-
tifier. If defined the priority overwrites the defaultPriority that is defined
in the VlanMembership.c(RS_SYST_00039)
Class NetworkEndpointAddress (abstract)
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note To build a valid network endpoint address there has to be either one MAC multicast group reference or an
ipv4 configuration or an ipv6 configuration.
Base ARObject
Subclasses Ipv4Configuration, Ipv6Configuration, MacMulticastConfiguration
Attribute Type Mult. Kind Note
– – – – –
Table 6.141: NetworkEndpointAddress

403 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class Ipv4Configuration
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Internet Protocol version 4 (IPv4) configuration.
Base ARObject, NetworkEndpointAddress
Attribute Type Mult. Kind Note
assignment PositiveInteger 0..1 attr Priority of assignment (1 is highest). If a new address
Priority from an assignment method with a higher priority is
available, it overwrites the IP address previously assigned
by an assignment method with a lower priority.
defaultGateway Ip4AddressString 0..1 attr IP address of the default gateway.
dnsServer Ip4AddressString * attr IP addresses of preconfigured DNS servers.
Address
Tags:xml.namePlural=DNS-SERVER-ADDRESSES
ipAddressKeep IpAddressKeepEnum 0..1 attr Defines the lifetime of a dynamically fetched IP address.
Behavior
ipv4Address Ip4AddressString 0..1 attr IPv4 Address. Notation: 255.255.255.255. The IP
Address shall be declared in case the ipv4AddressSource
is FIXED and thus no auto-configuration mechanism is
used.
ipv4Address Ipv4AddressSource 0..1 attr Defines how the node obtains its IP address.
Source Enum
networkMask Ip4AddressString 0..1 attr Network mask. Notation 255.255.255.255
ttl PositiveInteger 0..1 attr Lifespan of data (0..255). The purpose of the TimeToLive
field is to avoid a situation in which an undeliverable
datagram keeps circulating on a system.

Table 6.142: Ipv4Configuration

Enumeration Ipv4AddressSourceEnum
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Defines how the node obtains its IPv4-Address.
Literal Description
autoIp AutoIP is used to dynamically assign IP addresses at device startup.
Tags:atp.EnumerationLiteralIndex=0
autoIp_doip Linklocal IPv4 Address Assignment using DoIP Parameters
Tags:atp.EnumerationLiteralIndex=2
dhcpv4 DHCP is a service for the automatic IP configuration of a client.
Tags:atp.EnumerationLiteralIndex=3
fixed The IP Address shall be declared manually.
Tags:atp.EnumerationLiteralIndex=4

Table 6.143: Ipv4AddressSourceEnum

Enumeration IpAddressKeepEnum
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Defines the behavior after a dynamic IP address has been assigned.
Literal Description
forget After a dynamic IP address has been assigned just use it for this session.
Tags:atp.EnumerationLiteralIndex=0
5

404 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Enumeration IpAddressKeepEnum
storePersistently After a dynamic IP address has been assigned store the address persistently.
Tags:atp.EnumerationLiteralIndex=1

Table 6.144: IpAddressKeepEnum

Class Ipv6Configuration
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Internet Protocol version 6 (IPv6) configuration.
Base ARObject, NetworkEndpointAddress
Attribute Type Mult. Kind Note
assignment PositiveInteger 0..1 attr Priority of assignment (1 is highest). If a new address
Priority from an assignment method with a higher priority is
available, it overwrites the IP address previously assigned
by an assignment method with a lower priority.
defaultRouter Ip6AddressString 0..1 attr IP address of the default router.
dnsServer Ip6AddressString * attr IP addresses of pre configured DNS servers.
Address
Tags:xml.namePlural=DNS-SERVER-ADDRESSES
enableAnycast Boolean 0..1 attr This attribute is used to enable anycast addressing (i.e. to
one of multiple receivers).
hopCount PositiveInteger 0..1 attr The distance between two hosts. The hop count n means
that n gateways separate the source host from the
destination host (Range 0..255)
ipAddressKeep IpAddressKeepEnum 0..1 attr Defines the lifetime of a dynamically fetched IP address.
Behavior
ipAddressPrefix PositiveInteger 0..1 attr IPv6 prefix length defines the part of the IPv6 address
Length that is the network prefix.
ipv6Address Ip6AddressString 0..1 attr IPv6 Address. Notation: FFFF:...:FFFF. The IP Address
shall be declared in case the ipv6AddressSource is
FIXED and thus no auto-configuration mechanism is
used.
ipv6Address Ipv6AddressSource 0..1 attr Defines how the node obtains its IP address.
Source Enum
Table 6.145: Ipv6Configuration

[constr_5263] NetworkEndpoint.networkEndpointAddress restriction for

IPv4 dA NetworkEndpoint shall not aggregate several Ipv4Configurations that
have their ipv4AddressSource set to fixed.c()
[constr_5264] NetworkEndpoint.networkEndpointAddress restriction for
IPv6 dA NetworkEndpoint shall not aggregate several Ipv6Configurations that
have their ipv6AddressSource set to fixed.c()
[constr_5265] NetworkEndpoint.networkEndpointAddress restriction dA
NetworkEndpoint shall not aggregate an Ipv4Configuration and an
Ipv6Configuration as networkEndpointAddress at the same time.c()
[TPS_SYST_03002] Keep behavior of DHCP clients dThe attribute IpAddress-
KeepEnum defines for the DHCP client to either

405 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• persistently store an assigned IP address (storePersistently) after it has

been fetched, or
• learn it after each start-up (forget).
c(RS_SYST_00052)
[constr_3298] Ipv6Configuration.ipv6Address range in case of enableAny-
cast dIf Ipv6Configuration.enableAnycast is set to true then the
Ipv6Configuration.ipv6Address needs to be in the unicast addressing range.c()
Enumeration Ipv6AddressSourceEnum
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Defines how the node obtains its IPv6-Address.
Literal Description
dhcpv6 DHCP is a service for the automatic IP configuration of a client.
Tags:atp.EnumerationLiteralIndex=0
fixed The IP Address shall be declared manually.
Tags:atp.EnumerationLiteralIndex=1
linkLocal LinkLocal is intended only for communications within the segment of a local network (a link) or a
point-to-point connection that a host is connected to.
Tags:atp.EnumerationLiteralIndex=2
linkLocal_doip Linklocal IPv6 Address Assignment using DoIP Parameters
Tags:atp.EnumerationLiteralIndex=3
router IPv6 Stateless Autoconfiguration.
Advertisement
Tags:atp.EnumerationLiteralIndex=4

Table 6.146: Ipv6AddressSourceEnum

Class MacMulticastConfiguration
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note References a per cluster globally defined MAC-Multicast-Group.
Base ARObject, NetworkEndpointAddress
Attribute Type Mult. Kind Note
macMulticast MacMulticastGroup 1 ref Reference to a macMulticastGroup.
Group

Table 6.147: MacMulticastConfiguration

Primitive Ip4AddressString
Package M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::PrimitiveTypes
Note This is used to specify an IP4 address. Notation: 255.255.255.255
Tags:
xml.xsd.customType=IP4-ADDRESS-STRING
xml.xsd.pattern=(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4]
[0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)|ANY
xml.xsd.type=string

Table 6.148: Ip4AddressString

406 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Primitive Ip6AddressString
Package M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::PrimitiveTypes
Note This is used to specify an IP6 address. Notation: FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF
Alternative notations, short-cuts with duplicate colons like ::, etc. or mixtures using colons and dots, are
not allowed.
Tags:
xml.xsd.customType=IP6-ADDRESS-STRING
xml.xsd.pattern=[0-9A-Fa-f]{1,4}(:[0-9A-Fa-f]{1,4}){7,7}|ANY
xml.xsd.type=string

Table 6.149: Ip6AddressString

In addition, infrastructure services may be provided or consumed by the Network-

Endpoints.
Identifiable
NetworkEndpoint TimeSynchronization
TimeSyncClientConfiguration
+timeSyncClient
+ fullyQualifiedDomainName: String [0..1] + timeSyncTechnology: TimeSyncTechnologyEnum
+ priority: PositiveInteger [0..1] 0..1

0..*
+orderedMaster {ordered}
+infrastructureServices 0..1
OrderedMaster
InfrastructureServices
+ index: PositiveInteger

+timeSynchronization
+timeSyncServer 1
0..1
Referrable
+timeSyncServer TimeSyncServerConfiguration

0..1 + priority: PositiveInteger [0..1]

+ syncInterval: TimeValue
+ timeSyncServerIdentifier: String [0..1]
+ timeSyncTechnology: TimeSyncTechnologyEnum

+doIpEntity DoIpEntity

0..1 + doIpEntityRole: DoIpEntityRoleEnum

«enumeration» «enumeration»
TimeSyncTechnologyEnum DoIpEntityRoleEnum

ntp_rfc958 node
ptp_ieee1588_2002 gateway
ptp_ieee1588_2008 edgeNode
avb_ieee802_1AS

Figure 6.40: Network Endpoint Infrastructure Services

Class InfrastructureServices
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Defines the network infrastructure services provided or consumed.
Base ARObject
Attribute Type Mult. Kind Note
doIpEntity DoIpEntity 0..1 aggr Defines whether a infrastructure service that runs on the
network endpoint is a DoIP-Entity.
time TimeSynchronization 0..1 aggr Defines the servers / clients in a time synchronised
Synchronization network.

Table 6.150: InfrastructureServices

407 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

The TimeSyncServerConfiguration provides a time synchronization service.

[constr_3257] TimeSyncTechnology of servers and clients in a time synchro-
nized network. dTimeSyncClientConfiguration.timeSyncTechnology shall
have the same value as the TimeSyncServerConfiguration.timeSyncTech-
nology that is referenced in the TimeSyncClientConfiguration.orderedMas-
ter list.c()
Please note that there may be several timeSyncServers defined in the TimeSync-
ClientConfiguration.orderedMaster list, but only one is accepted at runtime.
In case that a master is not available anymore, a master transition will be processed ac-
cording to the defined TimeSyncClientConfiguration.orderedMaster list. The
next defined timeSyncServer in the OrderedMaster list will take over the master
functionality.
Class TimeSynchronization
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Defines the servers / clients in a time synchronised network.
Base ARObject
Attribute Type Mult. Kind Note
timeSyncClient TimeSyncClient 0..1 aggr Configuration of the time synchronisation client.
Configuration
timeSyncServer TimeSyncServer 0..1 aggr Configuration of the time synchronisation server.
Configuration

Table 6.151: TimeSynchronization

Class TimeSyncClientConfiguration
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Defines the configuration of the time synchronisation client.
Base ARObject
Attribute Type Mult. Kind Note
orderedMaster OrderedMaster * aggr Defines a list of ordered NetworkEndpoints.
(ordered)
Tags:xml.namePlural=ORDERED-MASTER-LIST
timeSync TimeSyncTechnology 1 attr Defines the time synchronisation technology used.
Technology Enum

Table 6.152: TimeSyncClientConfiguration

Class TimeSyncServerConfiguration
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Defines the configuration of the time synchronisation server.
Base ARObject, Referrable
Attribute Type Mult. Kind Note
priority PositiveInteger 0..1 attr Server Priority.
syncInterval TimeValue 1 attr Synchronisation interval used by the time synchronisation
server (in seconds).
5

408 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class TimeSyncServerConfiguration
timeSyncServer String 0..1 attr Identifier of the TimeSyncServer.
Identifier
timeSync TimeSyncTechnology 1 attr Defines the time synchronisation technology used.
Technology Enum Possible values are: NTP_RFC958, PTP_
IEEE1588_2002, PTP_IEEE1588_2008, AVB_
IEEE802_1AS and others.

Table 6.153: TimeSyncServerConfiguration

Class OrderedMaster
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Element in the network endpoint list.
Base ARObject
Attribute Type Mult. Kind Note
index PositiveInteger 1 attr Defines the order of the network endpoint list (e.g. 0, 1, 2,
...).
timeSyncServer TimeSyncServer 1 ref Reference to a master (Time Sync Server).
Configuration

Table 6.154: OrderedMaster

Enumeration TimeSyncTechnologyEnum
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Timesynchronization. Server/Client configuration.
Literal Description
avb_ieee802_1AS Ethernet AVB compliant IEEE802.1AS Precision Time Protocol
Tags:atp.EnumerationLiteralIndex=0
ntp_rfc958 Network Time Protocol (NTP)
Tags:atp.EnumerationLiteralIndex=1
ptp_ieee1588_2002 Precision Time Protocol (PTP) IEEE 1588-2002
Tags:atp.EnumerationLiteralIndex=2
ptp_ieee1588_2008 Precision Time Protocol (PTP) IEEE 1588-2008
Tags:atp.EnumerationLiteralIndex=3

Table 6.155: TimeSyncTechnologyEnum

The DoIpEntity (Diagnostics over Internet Protocol, ISO 13400) defines the DoIp
role this NetworkEndpoint has.
Class DoIpEntity
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note ECU providing this infrastructure service is a DoIP-Entity.
Base ARObject
Attribute Type Mult. Kind Note
doIpEntityRole DoIpEntityRoleEnum 1 attr Identifies the role in terms of DoIP this network-node has.

Table 6.156: DoIpEntity

409 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Enumeration DoIpEntityRoleEnum
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note DoIP role a network-node has.
Literal Description
edgeNode Network node is a DoIP gateway that accepts external connections.
Tags:atp.EnumerationLiteralIndex=0
gateway Network node is a Gateway between the DoIP network and other networks.
Tags:atp.EnumerationLiteralIndex=1
node Network node is a DoIp node.
Tags:atp.EnumerationLiteralIndex=2

Table 6.157: DoIpEntityRoleEnum

6.7.5.3 SOME/IP Service Instances

The AUTOSAR protocol SOME/IP is a Service Discovery protocol that is used to com-
municate the availability of functional entities called services in the in-vehicle communi-
cation and to control the send behavior of event messages to receivers that subscribed
to receive these events (Publish/Subscribe). A Service may also provide methods that
a client is able to call (Request/Response).
Please note that the AUTOSAR Classic Platform does not support Service Inter-
faces. To mimic a Service Interface in the classic platform any combination of
ClientServerInterfaces, SenderReceiverInterfaces or TriggerInter-
faces may be used to describe a service to which later a SOME/IP Service Id is
assigned.
The assignment of SOME/IP Service Ids is done on the Service Instance level in the
System Description. An AbstractServiceInstance collected in the ServiceIn-
stanceCollectionSet is describing such a Service Instance.
A SOME/IP serialized message is represented by an ISignal that aggregates the
SOMEIPTransformationISignalProps that in turn references the Transforma-
tionTechnology with the protocol set to SOMEIP. The ISignal is mapped into
an ISignalIPdu and the PduTriggering that instantiates the ISignalIPdu on the
VLAN is related to a ProvidedServiceInstance or ConsumedServiceInstance
via a PduActivationRoutingGroup. The ProvidedServiceInstance.ma-
jorVersion or ConsumedServiceInstance.majorVersion describes the Ser-
vice Interface Version that is transported in the Header of the SOME/IP message to
identify the source of the message.
[TPS_SYST_02377] Consistent setting of Service Interface Version dThe Service
Interface Version represented by the SOMEIPTransformation (either via SOMEIP-
TransformationISignalProps.interfaceVersion of the ISignal or via

410 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

SOMEIPTransformationDescription.interfaceVersion of the Transfor-

mationTechnology that is referenced by the SOMEIPTransformationISignal-
Props of the ISignal) shall be equal to the corresponding ProvidedServiceIn-
stance.majorVersion or ConsumedServiceInstance.majorVersion.c()
Class ServiceInstanceCollectionSet
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::ServiceInstances
Note Collection of ServiceInstances
Tags:atp.recommendedPackage=ServiceInstanceCollectionSets
Base ARObject, CollectableElement, FibexElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
serviceInstance AbstractService * aggr ServiceInstances that are part of the collection.
Instance
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild

Table 6.158: ServiceInstanceCollectionSet

Class AbstractServiceInstance (abstract)

Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::ServiceInstances
Note Provided and Consumed Ethernet Service Instances that are available at the ApplicationEndpoint.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Subclasses ConsumedServiceInstance, ProvidedServiceInstance
Attribute Type Mult. Kind Note
capability TagWithOptionalValue * aggr A sequence of records to store arbitrary name/value pairs
Record conveying additional information about the named
service.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
majorVersion PositiveInteger 0..1 attr Major Version of the ServiceInterface. Value can be set to
a number that represents the Major Version of the service.
method PduActivationRouting 0..1 aggr The ServiceDiscovery module is able to activate and
Activation Group deactivate the PDU routing for ClientServerOperations
RoutingGroup (SOME/IP methods).
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
routingGroup SoAdRoutingGroup * ref The ServiceDiscovery module is able to activate and
deactivate the PDU routing from and to TCP/IP-sockets.
Tags:atp.Status=obsolete

Table 6.159: AbstractServiceInstance

411 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

CommunicationConnector Identifiable

EthernetCommunicationConnector NetworkEndpoint

+ maximumTransmissionUnit: PositiveInteger [0..1] + fullyQualifiedDomainName: String [0..1]

+ neighborCacheSize: PositiveInteger [0..1] + priority: PositiveInteger [0..1]
+ pathMtuEnabled: Boolean [0..1]

+networkEndpoint
1
+ pathMtuTimeout: TimeValue [0..1] Identifiable
+ pncFilterDataMask: PositiveUnlimitedInteger [0..1] +connector SocketAddress

0..1 + differentiatedServiceField: PositiveInteger [0..1]

+ flowLabel: PositiveInteger [0..1]
+multicastConnector + pathMtuDiscoveryEnabled: Boolean [0..1]
+ pduCollectionMaxBufferSize: PositiveInteger [0..1]
0..* + pduCollectionTimeout: TimeValue [0..1]
+ udpChecksumHandling: UdpChecksumCalculationEnum [0..1]

+applicationEndpoint 0..1

Identifiable
+eventMulticastAddress ApplicationEndpoint
+eventMulticastAddress
0..1 + maxNumberOfConnections: PositiveInteger [0..1]
+ priority: PositiveInteger [0..1] 0..*

+remoteUnicastAddress
+localUnicastAddress
+remoteUnicastAddress

+localUnicastAddress
0..* 0..2 FibexElement 0..2 0..2
ServiceInstanceCollectionSet

«atpVariation»
+serviceInstance 0..*

Identifiable
AbstractServiceInstance

+ majorVersion: PositiveInteger [0..1]

«atpVariation» «atpVariation» «atpVariation» «atpVariation»
«atpVariation» «atpVariation»

ProvidedServiceInstance
ConsumedServiceInstance
+ autoAvailable: Boolean [0..1]
+ instanceIdentifier: PositiveInteger [0..1] + autoRequire: Boolean [0..1]
+ loadBalancingPriority: PositiveInteger [0..1] + instanceIdentifier: AnyServiceInstanceId [0..1]
+ loadBalancingWeight: PositiveInteger [0..1] + minorVersion: AnyVersionString [0..1]
+ minorVersion: PositiveInteger [0..1] + serviceIdentifier: PositiveInteger [0..1]
+ priority: PositiveInteger [0..1] + versionDrivenFindBehavior: ServiceVersionAcceptanceKindEnum [0..1]
+ serviceIdentifier: PositiveInteger [0..1]
«atpVariation»
«atpVariation» «atpVariation» +blacklistedVersion 0..*
+consumedEventGroup 0..*
+eventHandler 0..*
SomeipServiceVersion Identifiable
Identifiable ConsumedEventGroup
+ majorVersion: PositiveInteger [0..1]
EventHandler
+ minorVersion: PositiveInteger + autoRequire: Boolean [0..1]
+ eventGroupIdentifier: PositiveInteger [0..1] + eventGroupIdentifier: PositiveInteger [0..1]
+ multicastThreshold: PositiveInteger [0..1] + priority: PositiveInteger [0..1]

+pduActivationRoutingGroup 0..* +methodActivationRoutingGroup 0..1 +pduActivationRoutingGroup 0..*

Identifiable
PduActivationRoutingGroup

+ eventGroupControlType: EventGroupControlTypeEnum [0..1]

«enumeration» «enumeration»
Identifiable EventGroupControlTypeEnum PduCollectionSemanticsEnum
PduTriggering
+iPduIdentifierUdp

activationUnicast lastIsBest
+iPduIdentifierTcp

activationMulticast queued
+pduTriggering 0..1 triggerUnicast
activationAndTriggerUnicast «enumeration»
PduCollectionTriggerEnum

0..* 0..* always

never
Referrable
SoConIPduIdentifier
+iPduIdentifier FibexElement
+ headerId: PositiveInteger [0..1]
SocketConnectionIpduIdentifierSet
+ pduCollectionPduTimeout: TimeValue [0..1] 0..*
+ pduCollectionSemantics: PduCollectionSemanticsEnum [0..1]
+ pduCollectionTrigger: PduCollectionTriggerEnum [0..1]

Figure 6.41: Provided and Consumed Service Instances

SOME/IP allows for the specification of additional information about the Abstract-
ServiceInstance with the Capability Record that allows to transport arbitrary con-
figuration strings (key/value pairs). This allows to encode additional information like the
name of a service or its configuration.

412 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_02216] Configuration of capabilityRecords dA Capability Record

(key/value pair) is configurable with the AbstractServiceInstance.capabili-
tyRecord and the two attributes key and value.c()
Class TagWithOptionalValue
Package M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::TagWithOptionalValue
Note A tagged value is a combination of a tag (key) and a value that gives supplementary information that is
attached to a model element. Please note that keys without a value are allowed.
Base ARObject
Attribute Type Mult. Kind Note
key String 1 attr Defines a key.
sequenceOffset Integer 0..1 attr The sequenceOffset attribute supports the use case
where TagWithOptionalValue is aggregated as splitable. If
multiple aggregations define the same value of attribute
key then the order in which the value collection is merged
might be significant. As an example consider the
modeling of the $PATH environment variable by means of
a meta class TagWithOptionalValue. The sequenceOffset
describes the relative position of each contribution in the
concatenated value. The contributions are sorted in
increasing integer order.
value String 0..1 attr Defines the corresponding value.

Table 6.160: TagWithOptionalValue

[TPS_SYST_01094] allowed key/value TagWithOptionalValue combinations

dThe following key/value combinations are supported:
• key present, with no value (e.g. "passreq" -> password required for this service)
• key present, with empty value (e.g. "PlugIns=" -> server supports plugins, but
none are presently installed)
• key present, with non-empty value (e.g. "PlugIns=JPEG,MPEG2,MPEG4")
c(RS_SYST_00039)
The following chapters are describing the configuration of SOME/IP ProvidedServi-
ceInstances and ConsumedServiceInstances in more detail. Please note that
currently the communication between a ProvidedServiceInstance and a Con-
sumedServiceInstance is restricted to a VLAN (see also [constr_5079]).

6.7.5.4 Multicast Subscription

The established approach for service subscription is that a client uses an unicast end-
point to subscribe to a server and the server acknowledges the subscription providing
a multicast endpoint. The client has a unicast socket where the events are received
in case the server distributes its events in unicast mode and the client has a multicast
socket where the events are received in case the server switches to multicast sending
(based on the multicastThreshold).

413 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

An extended approach is to allow a client to subscribe using a multicast endpoint (com-

bination of multicast IP-Address and port). Thus, in the event group subscription a mul-
ticast endpoint is sent from the client to the server. The server handles this multicast
endpoint as it would be an unicast endpoint. But the server collects identical multicast
endpoints and handles them as ONE client.
The goal of this approach is to be able to have a group of clients subscribing to a com-
mon multicast endpoint, while other clients still are able to subscribe using a unicast
endpoint.
This feature is called multicast subscription.
If, for example, THREE clients subscribe to an event group with the same multicast
endpoint and ONE client subscribes with an unicast endpoint to the same event group,
then the server would consider this as having TWO clients. The events of this event
group will be sent every time once to the multicast endpoint (where it actually would be
received by THREE clients) and once to the unicast endpoint for the unicast client.
Note that, in case PduActivationRoutingGroup.eventGroupControlType is
defined as triggerUnicast or activationAndTriggerUnicast there will be an
initial event sent every time another client subscribes using the same multicast end-
point. Thus, already subscribed clients on that multicast endpoint will get that initial
event as well.
Even if further clients subscribe to the already used multicast endpoint the number of
clients counted for the calculation of the multicastThreshold is not increased. In
the sketched example there would still be TWO clients registered for subscription.
Of course, if further clients subscribe to the very same event group with different multi-
cast or unicast endpoints, these additional clients are considered in the multicast-
Threshold count. Thus, at exceeding the multicastThreshold, count the server
will switch to the one multicast endpoint which the server distributed to all of its clients
in the subscribe acknowledge message. At this point ALL subscribed clients (regard-
less whether they subscribed using an unicast or multicast endpoint) will receive the
events on the subscribe acknowledge multicast endpoint provided by the server.
The server keeps track of how many clients subscribed to a dedicated multicast end-
point.
In case of unsubscribe or expiration of a subscription which was subscribed using a
multicast endpoint the server needs to decrement the count of subscriptions for that
specific multicast endpoint. If the last subscriber unsubscribes the subscription to that
multicast endpoint is removed.
Note that each multicast endpoint has an own subscription count to be kept by the
server.
For details on the multicast subscription feature refer to the protocol specifica-
tion [26] and functional specification [27].
Enabling the multicast subscription:

414 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_03064] Enabling of multicast subscription dThe multicast

subscription is enabled when a ConsumedServiceInstance defines a event-
MulticastSubscriptionAddress reference to an ApplicationEndpoint.c()
[constr_3669] eventMulticastSubscriptionAddress shall refer to a mul-
ticast address dThe reference ConsumedServiceInstance.eventMulticast-
SubscriptionAddress shall refer to an ApplicationEndpoint which in turn
refers to a NetworkEndpoint that represents a multicast address.c()
If the multicast subscription is enabled for a client then it is not allowed to have
also a unicast subscription defined.
[constr_3670] No support for parallel localUnicastAddress and eventMul-
ticastSubscriptionAddress dIf a eventMulticastSubscriptionAddress is
defined for a ConsumedServiceInstance then there shall not be a localUnicas-
tAddress defined at the same ConsumedServiceInstance.c()
In case of a static configuration it is also possible to define a set of predefined mul-
ticast client endpoints at the server. This is supported also in a mixed configuration,
where one part of the statically defined clients is defined using ProvidedServiceIn-
stance.remoteUnicastAddress and the other part of the statically defined clients
is defined using ProvidedServiceInstance.remoteMulticastSubscription-
Address. The server takes the union of both sets as the set of statically defined clients.
[TPS_SYST_03065] Static definition of multicast subscription at the
server dThe ProvidedServiceInstance.remoteMulticastSubscriptionAd-
dress defines a set of remote multicast addresses which are handled by the server as
predefined subscribed clients.c()
[TPS_SYST_03066] Mix of static definition consisting of multicast subscrip-
tion clients and unicast subscription clients at the server dIt is well supported to
define both, a set of ProvidedServiceInstance.remoteUnicastAddress and
a set of ProvidedServiceInstance.remoteMulticastSubscriptionAddress
references. The server is then configured to handle the union of both sets as the
predefined clients.c()
[constr_3671] remoteMulticastSubscriptionAddress shall refer to a mul-
ticast address dThe reference ProvidedServiceInstance.remoteMulticas-
tSubscriptionAddress shall refer to an ApplicationEndpoint which in turn
refers to a NetworkEndpoint that represents a multicast address.c()

415 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

CommunicationConnector Identifiable

EthernetTopology::EthernetCommunicationConnector EthernetTopology::NetworkEndpoint

+ maximumTransmissionUnit: PositiveInteger [0..1] + fullyQualifiedDomainName: String [0..1]

+ neighborCacheSize: PositiveInteger [0..1] + priority: PositiveInteger [0..1]
+ pathMtuEnabled: Boolean [0..1]

+networkEndpoint
1
+ pathMtuTimeout: TimeValue [0..1] Identifiable
+ pncFilterDataMask: PositiveUnlimitedInteger [0..1] +connector SocketAddress

0..1 + differentiatedServiceField: PositiveInteger [0..1]

+applicationEndpoint 0..1

Identifiable
+eventMulticastAddress EthernetTopology::ApplicationEndpoint
+eventMulticastAddress
0..1 + maxNumberOfConnections: PositiveInteger [0..1]
+ priority: PositiveInteger [0..1] 0..*
+remoteMulticastSubscriptionAddress

+remoteUnicastAddress
+localUnicastAddress

+eventMulticastSubscriptionAddress
+remoteUnicastAddress

0..* 0..* 0..2 FibexElement 0..1 0..2

ServiceInstanceCollectionSet

«atpVariation»
+serviceInstance 0..*

Identifiable
AbstractServiceInstance

+ majorVersion: PositiveInteger [0..1]

«atpVariation» «atpVariation» «atpVariation»
«atpVariation» «atpVariation» «atpVariation» «atpVariation»

+pduActivationRoutingGroup 0..* +methodActivationRoutingGroup 0..1 +pduActivationRoutingGroup 0..*

Identifiable
PduActivationRoutingGroup

+ eventGroupControlType: EventGroupControlTypeEnum [0..1]

«enumeration» «enumeration»
Identifiable EventGroupControlTypeEnum PduCollectionSemanticsEnum
CoreCommunication::
+iPduIdentifierUdp

activationUnicast lastIsBest
+iPduIdentifierTcp

PduTriggering
activationMulticast queued
+pduTriggering 0..1 triggerUnicast
activationAndTriggerUnicast «enumeration»
PduCollectionTriggerEnum

0..* 0..* always

Figure 6.42: Multicast Subscribe

There are several constrains to be considered when using the multicast sub-
scription feature:
If a ConsumedServiceInstance has methods defined, then the multicast sub-
scription is not possible.

416 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_3672] No support for methods in multicast subscription at the

client dIf a ConsumedServiceInstance aggregates a PduActivationRouting-
Group in the role methodActivationRoutingGroup, then the ConsumedServi-
ceInstance shall not define a eventMulticastSubscriptionAddress.c()
A server is able to define a set of statically configured client addresses using
the ProvidedServiceInstance.remoteMulticastSubscriptionAddress ref-
erence. But if the server also provides methods it is not possible to define static multi-
cast receivers for that server.
[constr_3673] No support for methods in multicast subscription at
the server static configuration dIf a ProvidedServiceInstance aggre-
gates a PduActivationRoutingGroup in the role methodActivationRout-
ingGroup, then the ProvidedServiceInstance.remoteMulticastSubscrip-
tionAddress shall not be defined.c()
There are some features of AUTOSAR which need to be carefully considered when
used in combination with multicast subscription:
• communication which relies on sequence counting might not operate properly
(e.g. E2E or SecOC) if initial events are sent on every subscription to an multicast
endpoint
• communication which requires point-to-point interaction may not operate properly
(e.g. IPSec or TLS)

6.7.5.5 ProvidedServiceInstance

The ProvidedServiceInstance is used to define a Service provider.

[TPS_SYST_02217] SOME/IP Service offer dThe EcuInstance on which the Pro-
videdServiceInstance is deployed offers the Service Instance over SOME/IP with
the serviceIdentifier and instanceIdentifier. The version of the Service
that is offered is described by the attributes majorVersion and minorVersion.c
(RS_SYST_00039)
[constr_5062] SOME/IP ProvidedServiceInstances of the same serviceInter-
face on one EcuInstance dDifferent ProvidedServiceInstances with the same
serviceIdentifier and the same majorVersion and different instanceIden-
tifiers shall not be mapped to the same UDP/TCP port number and IP address
combination that is represented by referenced ApplicationEndpoint and its refer-
enced NetworkEndpoint.c()

417 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

The reason for this restriction is that the Instance IDs are only used for Service Discov-
ery but are not contained in the SOME/IP header. So if for example two Provided-
ServiceInstances of the same ServiceInterface are provided on the same EcuIn-
stance and a client wants to call a method of one of these ProvidedServiceIn-
stances the only possibility for the client to distinguish the ProvidedServiceIn-
stances is the port number over which the individual ProvidedServiceInstances
are provided.
[constr_5063] ProvidedServiceInstance.serviceIdentifier is mandatory
dThe ProvidedServiceInstance.serviceIdentifier is mandatory.c()
[constr_5064] ProvidedServiceInstance.majorVersion is mandatory dThe
ProvidedServiceInstance.majorVersion is mandatory.c()
[constr_5065] ProvidedServiceInstance.minorVersion is mandatory dThe
ProvidedServiceInstance.minorVersion is mandatory.c()
[constr_5066] ProvidedServiceInstance.instanceIdentifier is manda-
tory dThe ProvidedServiceInstance.instanceIdentifier is mandatory.c()
[constr_5067] ProvidedServiceInstance shall be unique in respect of servi-
ceIdentifier, instanceIdentifier, majorVersion dOn a VLAN each Pro-
videdServiceInstance shall have a different serviceIdentifier, instan-
ceIdentifier and majorVersion value combination.c()
The reason for this constraint is that the Service Discovery messages have to be un-
ambiguous on the VLAN.
In other words no two ProvidedServiceInstances in a variant bound model shall
have the same serviceIdentifier, instanceIdentifier and majorVersion
value combination.
Class ProvidedServiceInstance
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::ServiceInstances
Note Service instances that are provided by the ECU that is connected via the ApplicationEndpoint to a
CommunicationConnector.
Base ARObject, AbstractServiceInstance, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
autoAvailable Boolean 0..1 attr Defines that this ProvidedServiceInstance shall be
offered by the service discovery at ECU start.
eventHandler EventHandler * aggr Collection of event groups provided by the Provided
ServiceInstance
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
instance PositiveInteger 0..1 attr Instance identifier. Can be used for e.g. service discovery
Identifier to identify the instance of the service.
loadBalancing PositiveInteger 0..1 attr Defines the value to be used for load balancing priority in
Priority the service offer. Lower value means higher priority.
loadBalancing PositiveInteger 0..1 attr Defines the value to be used for load balancing weight in
Weight the service offer. Higher value means higher probability to
be chosen.
5

418 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class ProvidedServiceInstance
localUnicast ApplicationEndpoint 0..2 ref The local address over which the PSI is provided (udp,
Address tcp or both).
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
minorVersion PositiveInteger 0..1 attr Minor Version of the Service that is provided by this
ProvidedServiceInstance.
priority PositiveInteger 0..1 attr Defines the frame priority where values from 0 (best
effort) to 7 (highest) are allowed.
remoteMulticast ApplicationEndpoint * ref This reference defines the remote multicast subscribed
Subscription addresses of service consumers. This reference shall
Address ONLY be used if the remote address of the clients is
determined from the configuration and not at runtime.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
remoteUnicast ApplicationEndpoint * ref This reference defines the remote addresses of service
Address consumers. This reference shall ONLY be used if the
remote address of the clients is determined from the
configuration and not at runtime.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
sdServerConfig SdServerConfig 0..1 aggr Service Discovery Server configuration.
Tags:atp.Status=obsolete
sdServerTimer SomeipSdServer 0..1 ref Server specific configuration settings relevant for the
Config ServiceInstanceConfig SOME/IP service discovery.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
serviceIdentifier PositiveInteger 0..1 attr This attribute represents the ability to describe the SOME/
IP service ID that is offered.
Table 6.161: ProvidedServiceInstance

[TPS_SYST_02218] ProvidedServiceInstance deployment dThe deployment of

a ProvidedServiceInstance to an EcuInstance is realized with the localU-
nicastAddress reference. The referenced ApplicationEndpoint defines the
TCP/UDP Port and the NetworkEndpoint that is referenced by the Applicatio-
nEndpoint defines the IP Address on which the Service can be reached. This End-
point information is transported in the SOME/IP Service Offer message to the clients.
With the SocketAddress.connector reference the deployment to an EcuInstance
is achieved.c(RS_SYST_00039)
The AUTOSAR BswM is used to aggregate the availability of all entities which make
up a service instance. When all entities are available, the service instance as such
is available. When a service instance becomes available the SD Module will usually
send an announcement message so other ECUs can learn about the availability and
the location (IP address and UDP or TCP Port) of that service instance.
Please note that the Service provider and the Service consumer do not need to find
each other if the ProvidedServiceInstance contains a remoteUnicastAddress
reference to an ApplicationEndpoint. If this reference is set the Server will not get
Clients address from the connection request. The server knows the address from the
Client from the configuration and all necessary socket connections can be set up from

419 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

this configuration information. The client still need to subscribe to event groups that
are of interest for him in this setup.
[TPS_SYST_02219] Static configuration between ProvidedServiceInstance
and ConsumedServiceInstance dIf the ProvidedServiceInstance contains a
remoteUnicastAddress reference to an ApplicationEndpoint the SoAd will
setup one single SocketConnection between the localUnicastAddress and the
remoteUnicastAddress.c(RS_SYST_00039)
[TPS_SYST_02220] Maximal number of clients that may connect to the local
server address dIf the ProvidedServiceInstance references an Applicatio-
nEndpoint in the role localUnicastAddress then the attribute Applicatio-
nEndpoint.maxNumberOfConnections defines the maximal number of clients (with
a dynamic address) that will be able to connect to this local server address. The SoAd
will setup a SocketConnection for each potential client with localUnicastAddress
and ANY remote Address (ANY Port and ANY IP-Address).c(RS_SYST_00039)
[constr_5068] ProvidedServiceInstance.localUnicastAddress shall be IP
Unicast dIf defined, the ProvidedServiceInstance.localUnicastAddress
shall point to an IP Unicast address.c()
[constr_5069] ProvidedServiceInstance.remoteUnicastAddress shall be IP
Unicast dThe ProvidedServiceInstance.remoteUnicastAddress shall point
to an IP Unicast address.c()
In other words the localUnicastAddress and remoteUnicastAddress are not
allowed to point to an IP Multicast address. Please note that an IP Unicast address can
be defined as a fixed address or be retrieved via dynamic mechanisms, e.g. DHCP.
Please note that a Service may provide some portions (Events, Methods) over TCP and
other portions over UDP. This is the reason why the ProvidedServiceInstance is
able to reference up to two localUnicastAddresses.
[TPS_SYST_02221] ProvidedServiceInstance.localUnicastAddress refer-
ence target dThe ProvidedServiceInstance is allowed to have:
• a localUnicastAddress reference to an ApplicationEndpoint that de-
fines a UDP Port,
• a localUnicastAddress reference to an ApplicationEndpoint that de-
fines a TCP Port,
• a localUnicastAddress reference to an ApplicationEndpoint that de-
fines a UDP Port and a localUnicastAddress reference to an Applicatio-
nEndpoint that defines a TCP Port.
c(RS_SYST_00039)
[constr_3379] Multiple SocketAddress entries with the same IP Address, Pro-
tocol and Port in the context of a given EcuInstance dIf there are two or more
SocketAddress entities within the scope of one SoAdConfig in the scope of one

420 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

EcuInstance that have the same static (fixed at configuration time) IP Address, Pro-
tocol and Port in the aggregated ApplicationEndpoint and NetworkEndpoint,
(e.g., 192.168.1.1, Tcp and 10000, respectively) then only one of these SocketAd-
dress elements shall be referenced by ProvidedServiceInstances/Consumed-
ServiceInstances in the role localUnicastAddress.c()
Rationale for [constr_3379]: There can be only one representation of the Provid-
edServiceInstance/ConsumedServiceInstance using the given IP Address,
Protocol and Port in the Sd module configuration in the context of a given EcuIn-
stance. Therefore, defining ProvidedServiceInstance/ConsumedServiceIn-
stance and assign it to several ApplicationEndpoints would in this case require
a merge of potentially different attribute values of the ProvidedServiceInstances
and/or ConsumedServiceInstances in the System Description and such situation
is avoided by this constraint.
Class PduActivationRoutingGroup
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::ServiceInstances
Note Group of Pdus that can be activated or deactivated for transmission over a socket connection.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
eventGroup EventGroupControlType 0..1 attr This attribute defines the type of a RoutingGroup. There
ControlType Enum are RoutingGroups that activate the data path for unicast
or multicast events of an event group. And there are
RoutingGroups that activate the data path for initial
events that are triggered, namely events that are sent out
on the server side after a client got subscribed. Please
note that this attribute is only valid for event
communication (Sender Receiver communication) and
shall be omitted in MethodActivationRoutingGroups.
iPduIdentifier SoConIPduIdentifier * ref PduIdentifiers assigned for transmission over Tcp in case
Tcp that the referencing PduActivationRoutingGroup is
activated.
iPduIdentifier SoConIPduIdentifier * ref PduIdentifiers assigned for transmission over Udp in case
Udp that the referencing PduActivationRoutingGroup is
activated.
Table 6.162: PduActivationRoutingGroup

Enumeration EventGroupControlTypeEnum
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::ServiceInstances
Note Types of a RoutingGroups for the event communication.
Literal Description
activationAnd Activate the data path for unicast events and triggered unicast events that are sent out after a client
TriggerUnicast got subscribed.
Tags:atp.EnumerationLiteralIndex=0
activationMulticast Activate the data path for multicast events of an EventGroup.
Tags:atp.EnumerationLiteralIndex=1
activationUnicast Activate the data path for unicast events of an EventGroup.
Tags:atp.EnumerationLiteralIndex=2
5

421 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Enumeration EventGroupControlTypeEnum
triggerUnicast Activate the data path for triggered unicast events that are sent out after a client got subscribed.
Tags:atp.EnumerationLiteralIndex=3

Table 6.163: EventGroupControlTypeEnum

Class SoConIPduIdentifier
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::ServiceInstances
Note Identification of Pdu content on a socket connection. This Identifier is required in case that multiple Pdus
are transmitted over the same socket connection.
Base ARObject, Referrable
Attribute Type Mult. Kind Note
headerId PositiveInteger 0..1 attr If multiple Pdus are transmitted over the same connection
this headerId can be used to distinguish between the
different Pdus.
pduCollection TimeValue 0..1 attr Defines the timeout in seconds the PDU collection shall
PduTimeout be transmitted at the latest after this PDU has been put
into the buffer.
pduCollection PduCollection 0..1 attr Specifies if the referenced PduTriggering shall be
Semantics SemanticsEnum collected using a queued (i.e. all PDU instances) or
last-is-best (i.e. only the last PDU instance) semantics. If
this attribute is not present the behavior of "queued" is
assumed.
pduCollection PduCollectionTrigger 0..1 attr Defines whether the referenced Pdu contributes to the
Trigger Enum triggering of the socket transmission if Pdu collection is
enabled for this socket.
pduTriggering PduTriggering 0..1 ref Reference to a Pdu that is transmitted over a socket
connection.
Table 6.164: SoConIPduIdentifier

Class SocketConnectionIpduIdentifierSet
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::ServiceInstances
Note Collection of PduIdentifiers used for transmission over a Socket Connection with the header option.
Tags:atp.recommendedPackage=SocketConnectionIpduIdentiferSets
Base ARObject, CollectableElement, FibexElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
iPduIdentifier SoConIPduIdentifier * aggr Collection of IPduIdentifiers that are transmitted over
Socket Connections.

Table 6.165: SocketConnectionIpduIdentifierSet

Enumeration PduCollectionSemanticsEnum
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::ServiceInstances
Note Defines the collection semantics for the PDU collection feature.
Literal Description
lastIsBest Only the latest PDU instances are transmitted.
Tags:atp.EnumerationLiteralIndex=0
5

422 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Enumeration PduCollectionSemanticsEnum
queued All instances of PDUs are transmitted.
Tags:atp.EnumerationLiteralIndex=1

Table 6.166: PduCollectionSemanticsEnum

[TPS_SYST_02222] Usage of headerId dIf multiple SoConIPduIdentifiers are

referenced by PduActivationRoutingGroup in the role iPduIdentifierTcp or
in the role iPduIdentifierUdp then the headerId information shall be used to
distinguish between the different Pdus.c(RS_SYST_00039)
Please note that a Method Call and a Method Return may use the same headerId for
identification since the communication direction is different in this case.
[constr_3322] Consistent setting of SoConIPduIdentifier.pduCollection-
Semantics in the context of one SocketAddress dThe value of the attribute
SoConIPduIdentifier.pduCollectionSemantics shall be identical for all ref-
erenced SoConIPduIdentifiers within the context of a given SocketAddress.c
()
[TPS_SYST_02223] Activation/Deactivation of PduActivationRoutingGroups
dThe routing of Pdus to and from a socket may be activated or deactivated with a
PduActivationRoutingGroup depending on the availability of AbstractServi-
ceInstances, EventHandlers or ConsumedEventGroups that send or receive the
data.c(RS_SYST_00039)
The Routing Group Activation Table is controlled in AUTOSAR by the Service Discovery
module.
[TPS_SYST_02224] Methods provided by a ProvidedServiceInstance dIf the
ProvidedServiceInstance is offered by the Service Discovery protocol then the
PduActivationRoutingGroup that is aggregated in the role methodActiva-
tionRoutingGroup is activated. All Methods that are provided by the Provided-
ServiceInstance can by called by the interested clients and the server will respond
to these calls. If the ProvidedServiceInstance offer is stopped then the Pdu-
ActivationRoutingGroup is deactivated.c(RS_SYST_00039)
Please note that according to [TPS_SYST_02151] the relationship between the call
and return is achieved by means of meta data items attached to the Pdus by the Socket
Adapter.
[TPS_SYST_02081] PduTriggering that is used for ClientServer Communica-
tion dA PduTriggering that points to an ISignalIPdu that aggregates an
ISignalToIPduMapping that in turn references an ISignal that refers to
a ClientServerToSignalMapping.callSignal or to ClientServerToSig-
nalMapping.returnSignal is designated as PduTriggering that is used for
ClientServer Communication.c()

423 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_02225] Service methods provided over UDP dMethod Pdus (Call and
Return ISignalIPdus) of a ProvidedServiceInstance that are offered for ac-
cess over UDP are described by SoConIPduIdentifiers referenced by the iP-
duIdentifierUdp reference from the PduActivationRoutingGroup that is ag-
gregated in the role methodActivationRoutingGroup by the ProvidedServi-
ceInstance.c(RS_SYST_00039)
[TPS_SYST_02226] Service methods provided over TCP dMethod Pdus (Call and
Return ISignalIPdus) of a ProvidedServiceInstance that are offered for ac-
cess over TCP are described by SoConIPduIdentifiers referenced by the iP-
duIdentifierTcp reference from the PduActivationRoutingGroup that is ag-
gregated in the role methodActivationRoutingGroup by the ProvidedServi-
ceInstance.c(RS_SYST_00039)
[TPS_SYST_02227] Publishing of a SOME/IP Event group dA ProvidedServi-
ceInstance publishes an event group for each EventHandler that is aggregated
in the role eventHandler. The eventGroupIdentifier identifies the SOME/IP
Event Group in the context of the ProvidedServiceInstance. With the publishing
of an event group the server offers to push notifications about updates to all clients that
are subscribed to the event group.c(RS_SYST_00039)
Class EventHandler
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::ServiceInstances
Note This element represents an event group as part of the Provided Service Instance.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
consumedEvent ConsumedEventGroup * ref All consumers of the event are referenced here.
Group
Tags:atp.Status=obsolete
eventGroup PositiveInteger 0..1 attr Unique Identifier that identifies the EventGroup in SOME/
Identifier IP. This Identifier is sent as Eventgroup ID in SOME/IP
Service Discovery messages.
eventMulticast ApplicationEndpoint 0..1 ref Multicast Address that is used for event communication in
Address the IP-Multicast case. It is the destination address to
which the server sends the multicast event messages if
the mulicastThreshold is exceeded.
This address is transmitted in the SD-SubscribeEvent
GroupAck Message to client (answer to SD-Subscribe
EventGroup).
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
multicast PositiveInteger 0..1 attr Specifies the number of subscribed clients that trigger the
Threshold server to change the transmission of events to multicast.
If configured to 0 only unicast will be used. If configured
to 1 the first client will be already served by multicast. If
configured to 2 the first client will be server with unicast
and as soon as the second client arrives both will be
served by multicast.
This does not influence the handling of initial events,
which are served using unicast only.
pduActivation PduActivationRouting * aggr The ServiceDiscovery module is able to activate and
RoutingGroup Group deactivate the PDU routing for events.
5

424 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class EventHandler
routingGroup SoAdRoutingGroup * ref The ServiceDiscovery module is able to activate and
deactivate the PDU routing for events.
Tags:atp.Status=obsolete
sdServerConfig SdServerConfig 0..1 aggr Server configuration parameter for Service-Discovery.
Tags:atp.Status=obsolete
sdServerEg SomeipSdServerEvent 0..1 ref Server Timing configuration settings that are EventGroup
TimingConfig GroupTimingConfig specific.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild

Table 6.167: EventHandler

[TPS_SYST_02228] Transmission of events over UDP/TCP Port dThe events of an

event group that are described by an EventHandler are transmitted either:
• via IP Unicast on the UDP/TCP Port that is defined by the ApplicationEnd-
point that is referenced by the ProvidedServiceInstance in the role lo-
calUnicastAddress if the eventMulticastAddress is not set or the mul-
ticastThreshold is not reached, or
• via IP Multicast on the local UDP/TCP Port that is defined by the Applicatio-
nEndpoint that is referenced by the ProvidedServiceInstance in the role
localUnicastAddress to the IP Multicast remote Address that is defined by
the ApplicationEndpoint that is referenced by the EventHandler in the
role eventMulticastAddress if the multicastThreshold is reached.
c(RS_SYST_00039)
[TPS_SYST_02180] Usage of EventHandler.multicastThreshold dThe switch-
ing between IP-Unicast and IP-Multicast is guided by the server with the Even-
tHandler.multicastThreshold attribute and by the number of subscribed clients
to the EventHandler.
The Server will change the transmission of events to Multicast if the multicast-
Threshold of the corresponding EventHandler is reached by the number of sub-
scribed clients. If the number of subscribed clients is smaller then the configured
multicastThreshold, the transmission of events takes place via unicast communi-
cation.c()
[constr_5071] EventHandler.eventMulticastAddress reference target dThe
ApplicationEndpoint that is referenced by an EventHandler in the role event-
MulticastAddress shall reference a NetworkEndpoint that defines an IP Multi-
cast Address.c()
[constr_5072] EventHandler without defined eventMulticastAddress dIf an
EventHandler that is aggregated by a ProvidedServiceInstance does not have
a defined eventMulticastAddress then the multicastThreshold shall be set
to the value 0 (IP Unicast only).c()

425 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_02229] Event groups provided by a ProvidedServiceInstance dIf

the ProvidedServiceInstance publishes an event group then the PduActiva-
tionRoutingGroup that is aggregated in the role pduActivationRoutingGroup
by an EventHandler is activated. The interested clients can subscribe to the pub-
lished event groups until the offer is stopped.c(RS_SYST_00039)
[TPS_SYST_02230] PduActivationRoutingGroups for event groups dThe Pdu-
ActivationRoutingGroup that is aggregated by the EventHandler in the role
pduActivationRoutingGroup enables the routing of a group of Pdus that are re-
lated with the PduActivationRoutingGroup via the referenced SoConIPduIden-
tifiers.
• The PduActivationRoutingGroup with the PduActivationRouting-
Group.eventGroupControlType set to activationUnicast enables the
routing over IP Unicast.
• The PduActivationRoutingGroup with the PduActivationRouting-
Group.eventGroupControlType set to activationMulticast enables the
routing over IP Multicast.
• The PduActivationRoutingGroup with the PduActivationRouting-
Group.eventGroupControlType set to triggerUnicast enables the rout-
ing of initial events that are sent out by the server immediately after a client got
subscribed. This PduActivationRoutingGroup can used for SOME/IP Field
notifiers.
• The PduActivationRoutingGroup with the PduActivationRouting-
Group.eventGroupControlType set to activationAndTriggerUnicast
enables the routing over IP Unicast and makes sure that initial events are sent
out by the server immediately after a client got subscribed. This PduActiva-
tionRoutingGroup can be used for SOME/IP Field notifiers.
c()
[TPS_SYST_02231] PduActivationRoutingGroups for methods dThe Pdu-
ActivationRoutingGroup enables the routing of a group of Pdus that are related
with the PduActivationRoutingGroup via the referenced SoConIPduIdenti-
fiers. The eventGroupControlType attribute is irrelevant for the PduActiva-
tionRoutingGroup that is aggregated by the AbstractServiceInstance in the
role methodActivationRoutingGroup.c()
[constr_5073] PduActivationRoutingGroup with eventGroupControlType
set to activationUnicast or triggerUnicast or activationAndTrig-
gerUnicast that is aggregated by an EventHandler dAn EventHandler that
aggregates a PduActivationRoutingGroup with the PduActivationRouting-
Group.eventGroupControlType set to activationUnicast or triggerUni-
cast or activationAndTriggerUnicast shall be aggregated by a Provided-
ServiceInstance that has a localUnicastAddress reference that points to an
IP Unicast Address.c()

426 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_5074] PduActivationRoutingGroup with eventGroupControlType

set to activationMulticast that is aggregated by an EventHandler dAn
EventHandler that aggregates a PduActivationRoutingGroup with the Pdu-
ActivationRoutingGroup.eventGroupControlType set to activationMul-
ticast shall have an eventMulticastAddress reference that points to a “remote”
IP Multicast Address. The ProvidedServiceInstance that aggregates the Even-
tHandler shall have a localUnicastAddress reference to a “local” UDP Appli-
cationEndpoint.c()
[constr_5075] Allowed references of SoConIPduIdentifiers by PduActiva-
tionRoutingGroup with eventGroupControlType set to activationMulti-
cast and allowed SoConIPduIdentifier references dA PduActivationRout-
ingGroup with eventGroupControlType set to activationMulticast is al-
lowed to reference SoConIPduIdentifiers only in the iPduIdentifierUdp role.c
()
[TPS_SYST_02232] Events provided over UDP dPdus of an EventHandler that
are provided over UDP are described by SoConIPduIdentifiers referenced by
the iPduIdentifierUdp reference from the PduActivationRoutingGroup that
is aggregated in the role pduActivationRoutingGroup by the EventHandler.c
(RS_SYST_00039)
[TPS_SYST_02233] Events provided over TCP dPdus of an EventHandler that are
provided over TCP are described by SoConIPduIdentifiers referenced by the iP-
duIdentifierTcp reference from the PduActivationRoutingGroup that is ag-
gregated in the role pduActivationRoutingGroup by the EventHandler.c(RS_-
SYST_00039)
[constr_5076] PduActivationRoutingGroup with iPduIdentifierTcp refer-
ence that is aggregated by a ProvidedServiceInstance dIf the PduActiva-
tionRoutingGroup contains the iPduIdentifierTcp reference then the aggre-
gating ProvidedServiceInstance shall contain a localUnicastAddress refer-
ence to an ApplicationEndpoint that defines a TCP address.c()
[constr_5077] PduActivationRoutingGroup with iPduIdentifierUdp refer-
ence that is aggregated by a ProvidedServiceInstance dIf the PduActiva-
tionRoutingGroup contains the iPduIdentifierUdp reference then the aggre-
gating ProvidedServiceInstance shall contain a localUnicastAddress refer-
ence to an ApplicationEndpoint that defines a UDP address.c()
[constr_5078] PduTriggerings referenced by a PduActivationRoutingGroup
shall be on the same VLAN as the referencing PduActivationRoutingGroup
dEach PduTriggering referenced by a PduActivationRoutingGroup via So-
ConIPduIdentifier shall be aggregated by the same VLAN (EthernetPhysi-
calChannel) to which the AbstractServiceInstance that aggregates the Pdu-
ActivationRoutingGroup belongs via the localUnicastAddress.c()

427 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_5079] Service communication is restricted to one VLAN dAll SocketAd-

dress elements that are referenced by a AbstractServiceInstance with the lo-
calUnicastAddress and remoteUnicastAddress shall belong to the same VLAN
(EthernetPhysicalChannel).c()
[constr_5080] ApplicationEndpoints referenced by EventHandlers and by
the aggregating ProvidedServiceInstance shall be in the same VLAN dThe
ApplicationEndpoint that is referenced by an EventHandler in the role event-
MulticastAddress shall belong to the same VLAN (EthernetPhysicalChan-
nel) as the ApplicationEndpoint that is referenced by the localUnicastAd-
dress reference from the ProvidedServiceInstance that aggregates the Even-
tHandler.c()
[constr_3456] Existence of ProvidedServiceInstance.loadBalancingPri-
ority and ProvidedServiceInstance.loadBalancingWeight dThe attributes
ProvidedServiceInstance.loadBalancingPriority and ProvidedServi-
ceInstance.loadBalancingWeight shall either not exist or be defined both.c()
[TPS_SYST_01108] ProvidedServiceInstance priority dThe priority in the
ProvidedServiceInstance shall be used as Ethernet Header information together
with the vlanIdentifier. If defined the priority overwrites the defaultPrior-
ity that is defined in the VlanMembership, the priority that is defined at the Net-
workEndpoint and the priority that is defined at the ApplicationEndpoint.c
(RS_SYST_00039)

428 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

:NetworkEndpoint :Ipv4Configuration

ipv4Address = 192.172.1.100
ipv4AddressSource = fixed

ecu1_Unicast_SocketAddress: ecu1_Unicast_AEP: :UdpTp :TpPort

SocketAddress ApplicationEndpoint
portNumber = 8001
maxNumberOfConnections = 3

+localUnicastAddress

PSI_25_1: ProvidedServiceInstance

loadBalancingPriority = 1
loadBalancingWeight = 1
minorVersion = 0
majorVersion = 1
instanceIdentifier = 1
serviceIdentifier = 0x19

EG1: EventHandler EG2: EventHandler

eventGroupIdentifier = 1 eventGroupIdentifier = 2
multicastThreshold = 1 multicastThreshold = 0

Event1: SoConIPduIdentifier +iPduIdentifierUdp

Event1: EG2_PSI_25_1: PduActivationRoutingGroup
PduTriggering headerId = 0x00198001
eventGroupControlType = activationUnicast

+iPduIdentifierUdp
Event2: SoConIPduIdentifier
Event2:
PduTriggering headerId = 0x00198002
+iPduIdentifierUdp
EG1_PSI_25_1: PduActivationRoutingGroup

eventGroupControlType = activationMulticast

Method1_Call:
Method1_Call: SoConIPduIdentifier
PduTriggering +iPduIdentifierUdp PSI_25_1_Methods: PduActivationRoutingGroup
headerId = 0x00190001

Method1_Return: +iPduIdentifierUdp
Method1_Return: SoConIPduIdentifier
PduTriggering
headerId = 0x00190001

+eventMulticastAddress

ecu1_Multicast_SocketAddress: ecu1_Multicast_AEP: :UdpTp :TpPort

SocketAddress ApplicationEndpoint
portNumber = 30491

:NetworkEndpoint :Ipv4Configuration

ipv4Address = 239.192.255.251
ipv4AddressSource = fixed

Figure 6.43: Example for the modeling of a ProvidedServiceInstance that is deployed

on a local Unicast Endpoint

The example in Figure 6.43 shows a ProvidedServiceInstance named

PSI_25_1 that is provided on Udp Port 8001 and IPv4 address 192.172.1.100.
The Service that is represented by the ProvidedServiceInstance contains one

429 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

method (named Method1) and two events (named Event1 and Event2). In addition
the service contains two different event groups that are represented by two Even-
tHandlers EG1 and EG2.
On VFB level the method is represented by a ClientServerOperation and each
event by a VariableDataPrototype in a SenderReceiverInterface.
The ClientServerOperation is mapped by a ClientServerToSignalMapping
to a callSignal and to a returnSignal that in turn are mapped via ISignals
into an ISignalIPdu. Each VariableDataPrototype is mapped by the Sender-
ReceiverToSignalMapping or by the SenderReceiverToSignalGroupMap-
ping to one or several SystemSignals that in turn are mapped via ISignals into
an ISignalIPdu.
The PduTriggerings of these ISignalIPdus are referenced by the SoConIP-
duIdentifier that assigns a headerId to each ISignalIPdu.
The event group EG2 contains Event1 and Event2 and the PduActivationRout-
ingGroup named EG2_PSI_25_1 activates the SoConIPduIdentifiers that are
representing these two events for transmission over IP Unicast since the event-
GroupControlType is set to activationUnicast.
The event group EG1 contains Event1 and the PduActivationRoutingGroup
named EG1_PSI_25_1 activates the SoConIPduIdentifier for transmission over
IP Multicast since the eventGroupControlType is set to activationMulticast.
EventHandler EG1 has the multicastThreshold attribute set to 1. This means
that the first client that will subscribe to this event group will be served via IP Multicast.
This is the reason why the EventHandler EG1 points with the eventMulticastAd-
dress to an IP Multicast address to which the event will be transmitted.
In the SoAd configuration such a System Description will result in a SoAdSocketCon-
nectionGroup with a SoAdSocketLocalPort and SoAdSocketLocalAddress-
Ref that are derived from the ApplicationEndpoint referenced in the localUni-
castAddress role by the ProvidedServiceInstance.
The SoAdSocketConnectionGroup will contain three SoAdSocketConnections
since the maxNumberOfConnections is set to 3 in this example. The Provided-
ServiceInstance does not contain a remoteUnicastAddress reference. This
means that Service Discovery is used and that the SoAdSocketRemoteIpAddress
needs to be configured to ANY and the SoAdSocketRemotePort to 0 in all three
SoAdSocketConnections.
In addition one multicast SoAdSocketConnection will be added to the SoAdSock-
etConnectionGroup since the EventHandler EG1 points with the eventMulti-
castAddress to a multicast address.

430 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.7.5.6 ConsumedServiceInstance

The ConsumedServiceInstance is used to define a SOME/IP Service consumer.

Please note that in the AUTOSAR model all necessary information about the searched
service is configurable on the client side. A model that contains only the Consumed-
ServiceInstance description is sufficient for the configuration of the EcuInstance
to which the ConsumedServiceInstance is deployed. This is different to former ver-
sions of the System Template. The design criterion for the model was to disentangle
the ProvidedServiceInstance and the ConsumedServiceInstance from each
other.
[TPS_SYST_02234] SOME/IP Service search dA defined ConsumedServiceIn-
stance is searching for a SOME/IP Service Instance that fulfills all of the following
conditions:
• Service Identifier that matches the value set in serviceIdentifier,
• Service Instance Identifier that matches the value set in instanceIdentifier
• Service major version that matches the value set in majorVersion,
• Service minor version:
– in case versionDrivenFindBehavior = exactOrAnyMinorVersion:
Service minor version that matches the value set in minorVersion or ANY
minor version of the Service Instance in case the minorVersion is set to
ANY
– in case versionDrivenFindBehavior = minimumMinorVersion: Ser-
vice minor version that matches at least the value set in minorVersion or
is higher
c(RS_SYST_00039)
[constr_5110] Search for a collection of ServiceInstances is not supported dThe
ConsumedServiceInstance.instanceIdentifier is not allowed to be set to the
value ANY or ALL.c()
The reason for [constr_5110] is that the AUTOSAR SD module is only able to send
wildcard finds for a Minor Version. The search for a collection of ServiceInstances is
not supported by the Classic Platform Basic Software.
[constr_5081] ConsumedServiceInstance.serviceIdentifier is mandatory
dThe ConsumedServiceInstance.serviceIdentifier is mandatory.c()
[constr_5082] ConsumedServiceInstance.majorVersion is mandatory dThe
ConsumedServiceInstance.majorVersion is mandatory.c()
[constr_5083] ConsumedServiceInstance.minorVersion is mandatory dThe
ConsumedServiceInstance.minorVersion is mandatory.c()

431 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_3560]{DRAFT} minimumMinorVersion and ConsumedServiceIn-

stance.minorVersion value dThe ConsumedServiceInstance.minorVersion
shall not have the value ANY if versionDrivenFindBehavior = minimumMi-
norVersion.c()
[constr_5084] ConsumedServiceInstance.instanceIdentifier is manda-
tory dThe ConsumedServiceInstance.instanceIdentifier is mandatory.c()
Class ConsumedServiceInstance
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::ServiceInstances
Note Service instances that are consumed by the ECU that is connected via the ApplicationEndpoint to a
CommunicationConnector.
Base ARObject, AbstractServiceInstance, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
autoRequire Boolean 0..1 attr Defines that this ConsumedServiceInstance shall be
required (searched for) by the service discovery at ECU
start.
blacklisted SomeipServiceVersion * aggr Collection of blacklisted versions.
Version
Tags:atp.Status=draft
consumedEvent ConsumedEventGroup * aggr Selection of event-groups the consumer wants to
Group subscribe for.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
eventMulticast ApplicationEndpoint 0..1 ref Multicast Address that is used by the client to subscribe
Subscription to the server: This enables the multicast subscription
Address feature.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
instance AnyServiceInstanceId 0..1 attr This attribute represents the ability to describe the
Identifier required service instance ID.
localUnicast ApplicationEndpoint 0..2 ref The local address over which the CSI is consumed (udp,
Address tcp or both).
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
minorVersion AnyVersionString 0..1 attr Minor Version of the ServiceInterface. Value can be set to
a number that represents the Minor Version of the
searched service or to ANY.
providedService ProvidedService 0..1 ref Reference to a providedServiceInstance to get the
Instance Instance instanceIdentifier information from the ProvidedService
Instance.
Tags:atp.Status=obsolete
remoteUnicast ApplicationEndpoint 0..2 ref This reference defines the remote address where the
Address service provider is located. This reference shall ONLY be
used if the remote address is determined from the
configuration and not at runtime from the Service
Discovery.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
sdClientConfig SdClientConfig 0..1 aggr Service Discovery Client configuration.
Tags:atp.Status=obsolete
sdClientTimer SomeipSdClientService 0..1 ref Client specific configuration settings relevant for the
Config InstanceConfig SOME/IP service discovery.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
5

432 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class ConsumedServiceInstance
serviceIdentifier PositiveInteger 0..1 attr This attribute represents the ability to describe the SOME/
IP service ID that is searched.
versionDriven ServiceVersion 0..1 attr Defines the service discovery find behavior.
FindBehavior AcceptanceKindEnum
Tags:atp.Status=draft

Table 6.168: ConsumedServiceInstance

[TPS_SYST_03050]{DRAFT} Usage of ConsumedServiceInstance.black-

listedVersion dA service connection of a ConsumedServiceInstance to a Pro-
videdServiceInstance is not considered for service discovery if the SomeipSer-
viceVersion.minorVersion exists in the collection of SomeipServiceVersions
aggregated at the ConsumedServiceInstance in the role blacklistedVersion.c
()
A typical scenario for using a blacklist may be: For a certain ConsumedServiceIn-
stance a certain compatible provider service version inside a system may not work
which may have been identified after the design phase. In order to keep the system
running this certain provider version won’t be considered in the service search if it has
been blacklisted. Therefore, the ConsumedServiceInstance may connect only to
ProvidedServiceInstances that fulfill the search criteria and are not blacklisted.
[constr_3559]{DRAFT} ConsumedServiceInstance.blacklistedVersion is
restricted to the usage of minorVersion dThe majorVersion attribute shall not
be used in the SomeipServiceVersion that is aggregated by the ConsumedSer-
viceInstance in the role blacklistedVersion.c()
[TPS_SYST_02235] ConsumedServiceInstance deployment dThe deployment of
a ConsumedServiceInstance to an EcuInstance is realized in two ways:
• if the localUnicastAddress reference is available then the referenced Ap-
plicationEndpoint defines the TCP/UDP Port and the NetworkEndpoint
that is referenced by the ApplicationEndpoint defines the IP Address on
which the service consumer is located. Over the defined TCP/UDP port the ser-
vice consumer sends out the method calls to a service provider that was found
by the Service Discovery search. The endpoint information is also transported
in the SOME/IP SubscribeEventGroup message to the server to indicate on
which address the incoming events are expected. With the SocketAddress.
connector reference the deployment to an EcuInstance is achieved.
• if the localUnicastAddress reference is not available (in case Events are
received via IP Multicast only as described by [TPS_SYST_02302] and the ag-
gregating ConsumedServiceInstance does not define any methods) then the
ApplicationEndpoint that is referenced by the eventMulticastAddress
reference from the ConsumedEventGroup shall be EcuInstance specific and
the SocketAddress that contains the referenced ApplicationEndpoint is
allowed to reference only a single EthernetCommunicationConnector in the

433 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

multicastConnector role. With this SocketAddress.multicastConnec-

tor reference the deployment to an EcuInstance is achieved.
c(RS_SYST_00039)
Please note that the Service provider and the Service consumer do not need to find
each other if the ConsumedServiceInstance contains a remoteUnicastAddress
reference to an ApplicationEndpoint. If this reference is set the client will not get
server’s address from the Service Offer message. The client already knows the ad-
dress from the service provider from the configuration and all necessary socket con-
nections can be set up from this configuration information. The client still needs to
subscribe to event groups that are of interest for him in this setup.
[TPS_SYST_02236] Static configuration between ConsumedServiceInstance
and ProvidedServiceInstance dIf the ConsumedServiceInstance contains a
remoteUnicastAddress reference to an ApplicationEndpoint the SoAd will
setup one single SocketConnection between the localUnicastAddress and the
remoteUnicastAddress.c(RS_SYST_00039)
[TPS_SYST_02237] Maximal number of servers that may connect to the local
client address dIf the ConsumedServiceInstance references an Applicatio-
nEndpoint in the role localUnicastAddress and the remoteUnicastAddress
is not defined then the attribute ApplicationEndpoint.maxNumberOfConnec-
tions defines the maximal number of remote endpoints that will be able to connect to
this local client address. The SoAd will setup a SocketConnection for each poten-
tial remote endpoint. The local Address of the SocketConnection is derived from
ConsumedServiceInstance.localUnicastAddress. The remote Address is set
to ANY address in case that the remoteUnicastAddress is not used.c(RS_SYST_-
00039)
[constr_5085] ConsumedServiceInstance.localUnicastAddress shall be IP
Unicast dIf defined, the ConsumedServiceInstance.localUnicastAddress
shall point to an IP Unicast address.c()
In other words the localUnicastAddress is not allowed to point to a IP Multicast ad-
dress. Please note that the ConsumedServiceInstance.localUnicastAddress
does not need to be set in all cases as specified in [TPS_SYST_02238].
[constr_5086] ConsumedServiceInstance.remoteUnicastAddress shall be IP
Unicast dThe ConsumedServiceInstance.remoteUnicastAddress shall point
to an IP Unicast address.c()
Please note that a Service may provide some portions (Events, Methods) over TCP
and and other portions over UDP. This is the reason why the ConsumedServiceIn-
stance is able to reference up to two localUnicastAddresses.
[TPS_SYST_02238] ConsumedServiceInstance.localUnicastAddress refer-
ence target dThe ConsumedServiceInstance is allowed to have:
• a localUnicastAddress reference to an ApplicationEndpoint that de-
fines a UDP Port,

434 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• a localUnicastAddress reference to an ApplicationEndpoint that de-

fines a TCP Port,
• a localUnicastAddress reference to an ApplicationEndpoint that de-
fines a UDP Port and a localUnicastAddress reference to an Applicatio-
nEndpoint that defines a TCP Port.
• no configured localUnicastAddress.
c(RS_SYST_00039)
The Routing Group Activation is controlled in AUTOSAR by the Service Discovery mod-
ule.
[TPS_SYST_02239] Methods consumed by a ConsumedServiceInstance dIf the
ConsumedServiceInstance finds the searched service then the PduActivation-
RoutingGroup that is aggregated in the role methodActivationRoutingGroup is
activated. All Methods that are provided by the found ProvidedServiceInstance
can by called by ConsumedServiceInstance.c(RS_SYST_00039)
Please note that according to [TPS_SYST_02151] the relationship between the call
and return is achieved by means of meta data items attached to the Pdus by the Socket
Adapter.
[TPS_SYST_02240] Service methods consumed over UDP dMethod Pdus (Call and
Return ISignalIPdus) of a ConsumedServiceInstance that are accessed over
UDP are described by SoConIPduIdentifiers referenced by the iPduIdenti-
fierUdp reference from the PduActivationRoutingGroup that is aggregated in
the role methodActivationRoutingGroup by the ConsumedServiceInstance.c
(RS_SYST_00039)
[TPS_SYST_02241] Service methods consumed over TCP dMethod Pdus (Call and
Return ISignalIPdus) of a ConsumedServiceInstance that are accessed over
TCP are described by SoConIPduIdentifiers referenced by the iPduIdenti-
fierTcp reference from the PduActivationRoutingGroup that is aggregated in
the role methodActivationRoutingGroup by the ConsumedServiceInstance.c
(RS_SYST_00039)
[TPS_SYST_02242] Subscription to a SOME/IP Event group dA ConsumedSer-
viceInstance subscribes to a published event group via a ConsumedEventGroup
that is aggregated in the role consumedEventGroup. The eventGroupIdenti-
fier identifies the SOME/IP Event Group in the context of the ConsumedService-
Instance to which the consumer subscribes.c(RS_SYST_00039)
Class ConsumedEventGroup
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::ServiceInstances
Note This element represents an event-group to which the service consumer wants to subscribe.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
5

435 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class ConsumedEventGroup
Attribute Type Mult. Kind Note
application ApplicationEndpoint 0..1 ref Defines the application endpoint where the events of the
Endpoint event group are received in case of multicast reception.
Tags:atp.Status=obsolete
autoRequire Boolean 0..1 attr Defines that this ConsumedEventGroup shall be
requested (subscribed) as soon as the corresponding
ConsumedServiceInstance is requested. This could be at
ECU start, if ConsumedServiceInstance.autoRequire is
set to TRUE or as soon as the ConsumedServiceInstance
is requested by the application, if ConsumedService
Instance.autoRequire is set to FALSE.
eventGroup PositiveInteger 0..1 attr EventGroup ID. Shall be unique within one system to
Identifier allow service discovery.
eventMulticast ApplicationEndpoint * ref This reference defines the multicast address or a
Address multicast address resource where the events of the event
group are received.
If the multicast address is determined via configuration
and not at runtime via service discovery this reference
points to the multicast address over which the events will
be received.
If the multicast address is determined at runtime via
service discovery this reference shall be used to define
the necessary local multicast address resources, i.e.
RAM space in the TcpIp module in which the multicast
address is stored at runtime. Please note that in this case
the referenced address may be defined as ANY UDP port
and ANY IP address since the multicast address will be
received at runtime. If several multicast addresses are
considered to be used the ConsumedEventGroup shall
point to different ApplicationEndpoint objects to reserve
the necessary resources in the configuration.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
pduActivation PduActivationRouting * aggr The ServiceDiscovery module is able to activate and
RoutingGroup Group deactivate the PDU routing for receiving events.
priority PositiveInteger 0..1 attr Defines the frame priority where values from 0 (best
effort) to 7 (highest) are allowed.
routingGroup SoAdRoutingGroup * ref The ServiceDiscovery module is able to activate and
deactivate the PDU routing for receiving events.
Tags:atp.Status=obsolete
sdClientConfig SdClientConfig 0..1 aggr The readiness to receive events is defined by the Service
Discovery of the ConsumedEventGroup. The Event
Handler shall know about this announcement to decide
about the submission of events. Therefore the Event
Handler may be configured with Service-Discovery Client
attributes.
Tags:atp.Status=obsolete
sdClientTimer SomeipSdClientEvent 0..1 ref Client Timing configuration settings that are EventGroup
Config GroupTimingConfig specific.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild

Table 6.169: ConsumedEventGroup

[TPS_SYST_02243] Reception of events over UDP/TCP Port in case of Service

Discovery dThe events of an event group that are described by an ConsumedEvent-
Group are received either:

436 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• via IP Unicast on the UDP/TCP Port that is defined by the ApplicationEnd-

point that is referenced by the ConsumedServiceInstance in the role lo-
calUnicastAddress or
• via IP Multicast:
– in case of dynamic SD configuration the Multicast IP Address and UDP Port
to which the events are transmitted will be provided by the server at runtime
in the SOME/IP SubscribeEventGroupAck message,
– in case of static configuration the Multicast IP Address and UDP Port to
which the events are transmitted shall be configured by ConsumedEvent-
Group.eventMulticastAddress.
c(RS_SYST_00039)
Please note that the ConsumedEventGroup.eventMulticastAddress shall also
be used in case of a dynamic SD Configuration where the client learns the multicast
address at runtime. In this case the ApplicationEndpoint and the correspond-
ing NetworkEndpoint that are referenced by eventMulticastAddress define a
resource in the TcpIp module where the multicast address that will be determined at
runtime will be stored. Since the referenced ApplicationEndpoint and the corre-
sponding NetworkEndpoint are placeholders the configured TP Port and IP address
shall be set to ANY.
There are different scenarios that are considered:
• The same multicast address is used by all potential servers. On the client a
resource for this single multicast address needs to be reserved. All ConsumedE-
ventGroups need to reference the same placeholder ApplicationEndpoint
with eventMulticastAddress. In the Ecu Configuration one TcpIpLocal-
Addr container is created from the placeholder ApplicationEndpoint. In
addition one SoAdSocketConnectionGroup is created that points with the
SoAdSocketLocalAddressRef to the TcpIpLocalAddr container. All Pdus
received over multicast are assigned to this SoAdSocketConnectionGroup.
• The server is using different multicast addresses, e.g. Multicast Address A for
EventHandler A and Multicast Address B for EventHandler B. On the client
side resources for all used multicast addresses need to be reserved. In the
example the ConsumedEventGroup A needs to reference one placeholder
ApplicationEndpoint with eventMulticastAddress. The ConsumedE-
ventGroup B needs to reference a second placeholder ApplicationEnd-
point with eventMulticastAddress. In the Ecu Configuration a TcpI-
pLocalAddr container is created for each used placeholder. In addition one
SoAdSocketConnectionGroup per placeholder is created. In the example the
Pdus of ConsumedEventGroup A are assigned to one SoAdSocketConnec-
tionGroup and Pdus of ConsumedEventGroup B are assigned to the second
SoAdSocketConnectionGroup. With this approach it is possible to define at
configuration time which Pdus share the same multicast address, and which ones
are going over different multicast addresses.

437 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

If more than one multicast address is used it is not known at configuration time which
server will publish which address at which point in time. The configuration needs to
be prepared for all possible scenarios. Please be aware that this comes with a high
resource consumption.
[constr_3262] ConsumedEventGroup.eventGroupIdentifier is mandatory
dThe ConsumedEventGroup.eventGroupIdentifier is mandatory.c()
[constr_3457] Uniqueness of ConsumedEventGroup.eventGroupIdentifier in
the scope of a ConsumedServiceInstance dEach ConsumedEventGroup that is
aggregated by a ConsumedServiceInstance shall have a unique eventGroupI-
dentifier value in the scope of the aggregating ConsumedServiceInstance.c
()
[TPS_SYST_02245] Event groups consumed by a ConsumedServiceInstance
dIf the ConsumedServiceInstance subscribes to an event group then the Pdu-
ActivationRoutingGroup that is aggregated in the role pduActivationRout-
ingGroup by an ConsumedEventGroup is activated.c(RS_SYST_00039)
[TPS_SYST_02246] PduActivationRoutingGroups for ConsumedEvent-
Groups dThe PduActivationRoutingGroup that is aggregated by the Con-
sumedEventGroup in the role pduActivationRoutingGroup enables the routing
of a group of Pdus that are related to the PduActivationRoutingGroup via the
referenced SoConIPduIdentifiers.
• The PduActivationRoutingGroup with the PduActivationRouting-
Group.eventGroupControlType set to activationUnicast enables the
receiving of events over IP Unicast.
• The PduActivationRoutingGroup with the PduActivationRouting-
Group.eventGroupControlType set to activationMulticast enables the
receiving of events over IP Multicast.
• The PduActivationRoutingGroup with the PduActivationRouting-
Group.eventGroupControlType set to triggerUnicast enables the re-
ceiving of initial events that are sent out by the server immediately after the client
got subscribed. This PduActivationRoutingGroup can used for SOME/IP
Field notifiers.
• The PduActivationRoutingGroup with the PduActivationRouting-
Group.eventGroupControlType set to activationAndTriggerUnicast
enables the routing over IP Unicast and makes sure that initial events are sent
out by the server immediately after the client got subscribed. This PduActiva-
tionRoutingGroup can be used for SOME/IP Field notifiers.
c()

438 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_5087] PduActivationRoutingGroup with eventGroupControlType

set to activationUnicast or triggerUnicast or activationAndTrig-
gerUnicast that is referenced by a ConsumedEventGroup dA ConsumedEvent-
Group that aggregates a PduActivationRoutingGroup with the PduActiva-
tionRoutingGroup.eventGroupControlType set to activationUnicast or
triggerUnicast or activationAndTriggerUnicast shall be aggregated by a
ConsumedServiceInstance that has a localUnicastAddress reference that
points to an IP Unicast Address.c()
[TPS_SYST_02247] Events consumed over UDP dPdus of an ConsumedEvent-
Group that are consumed over UDP are described by SoConIPduIdentifiers ref-
erenced by the iPduIdentifierUdp reference from the PduActivationRouting-
Group that is aggregated in the role pduActivationRoutingGroup by the Con-
sumedEventGroup.c(RS_SYST_00039)
[TPS_SYST_02248] Events consumed over TCP dPdus of an ConsumedEvent-
Group that are consumed over TCP are described by SoConIPduIdentifiers refer-
enced by the iPduIdentifierTcp reference from the PduActivationRouting-
Group that is aggregated in the role pduActivationRoutingGroup by the Con-
sumedEventGroup.c(RS_SYST_00039)
[constr_5088] PduActivationRoutingGroup with iPduIdentifierTcp refer-
ence that is aggregated by a ConsumedServiceInstance dIf the PduActiva-
tionRoutingGroup contains the iPduIdentifierTcp reference then the aggre-
gating ConsumedServiceInstance shall contain a localUnicastAddress refer-
ence to an ApplicationEndpoint that defines a TCP address.c()
[constr_5089] PduActivationRoutingGroup with iPduIdentifierUdp refer-
ence that is aggregated by a ConsumedServiceInstance dIf the PduActiva-
tionRoutingGroup contains the iPduIdentifierUdp reference then the aggre-
gating ConsumedServiceInstance shall contain a localUnicastAddress refer-
ence to an ApplicationEndpoint that defines a UDP address.c()
[TPS_SYST_02014] ConsumedEventGroup priority dThe priority in the Con-
sumedEventGroup shall be used as Ethernet Header information together with the
vlanIdentifier. If defined the priority overwrites the defaultPriority that is
defined in the VlanMembership, the priority that is defined at the NetworkEnd-
point and the priority that is defined at the ApplicationEndpoint.c()
[constr_5090] ApplicationEndpoints referenced by ConsumedEventGroups
and by the aggregating ConsumedServiceInstance shall be in the same VLAN
dThe ApplicationEndpoint that is referenced by an ConsumedEventGroup in the
role eventMulticastAddress shall belong to the same VLAN (EthernetPhysi-
calChannel) as the ApplicationEndpoint that is referenced by the localUni-
castAddress reference from the ConsumedServiceInstance that aggregates the
ConsumedEventGroup.c()

439 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

:NetworkEndpoint :Ipv4Configuration

ipv4Address = 192.172.1.76
ipv4AddressSource = fixed

ecu2_Unicast_AEP: :UdpTp :TpPort :Ipv4Configuration

ApplicationEndpoint
portNumber = 8008 ipv4Address = ANY
ipv4AddressSource = fixed
+localUnicastAddress

CSI_25_1: ConsumedServiceInstance :NetworkEndpoint

instanceIdentifier = 1
minorVersion = 0
majorVersion = 1
serviceIdentifier = 0x19

EG1: ConsumedEventGroup +eventMulticastAddress

EG2: ConsumedEventGroup ANY_Multicast_AEP:
eventGroupIdentifier = 1 ApplicationEndpoint
eventGroupIdentifier = 2

EG2_CSI_25_1: PduActivationRoutingGroup EG1_CSI_25_1: PduActivationRoutingGroup :UdpTp

eventGroupControlType = activationUnicast eventGroupControlType = activationMulticast

+iPduIdentifierUdp +iPduIdentifierUdp
Event2:
Event2: SoConIPduIdentifier PduTriggering :TpPort
headerId = 0x00198002 portNumber = 0
+iPduIdentifierUdp

Event1: SoConIPduIdentifier Event1:

PduTriggering
headerId = 0x00198001

Method1_Call:
Method1_Call: CSI_1_Methods:
SoConIPduIdentifier +iPduIdentifierUdp
PduTriggering PduActivationRoutingGroup
headerId = 0x00190001

Method1_Return:
Method1_Return: SoConIPduIdentifier +iPduIdentifierUdp
PduTriggering
headerId = 0x00190001

Figure 6.44: Example for the modeling of a ConsumedServiceInstance that is deployed

on a local Unicast Endpoint

The example in Figure 6.44 shows a ConsumedServiceInstance named

CSI_25_1 that is deployed on Udp Port 8008 and IPv4 address 192.172.1.76.
The Service that is represented by the ConsumedServiceInstance contains one
method (named Method1) and two events (named Event1 and Event2). In addi-
tion the service contains two different event groups that are represented by two Con-
sumedEventGroups EG1 and EG2.
The PduTriggerings for the ISignalIPdus that transport the events, the method
call and the method response are referenced by the SoConIPduIdentifier that
assigns a headerId to each ISignalIPdu.

440 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

The event group EG2 contains Event1 and Event2 and the PduActivationRout-
ingGroup named EG2_CSI_25_1 activates the SoConIPduIdentifiers that are
representing these two events for transmission over IP Unicast since the event-
GroupControlType is set to activationUnicast.
The event group EG1 contains Event1 and the PduActivationRoutingGroup
named EG1_CSI_25_1 activates the SoConIPduIdentifier for transmission over
IP Multicast since the eventGroupControlType is set to activationMulticast.
In the SoAd configuration such a System Description will result in a SoAdSocketCon-
nectionGroup with a SoAdSocketLocalPort and SoAdSocketLocalAddress-
Ref that are derived from the ApplicationEndpoint referenced in the localUni-
castAddress role by the ConsumedServiceInstance.
The SoAdSocketConnectionGroup will contain one single SoAdSocketConnec-
tion since the maxNumberOfConnections is not set in this example. The Pro-
videdServiceInstance does not contain a remoteUnicastAddress reference.
This means that Service Discovery is used and that the SoAdSocketRemoteIpAd-
dress needs to be configured to ANY and the SoAdSocketRemotePort to 0 in the
SoAdSocketConnection.
Since only a single multicast placeholder ApplicationEndpoint is referenced with
the eventMulticastAddress by all existing ConsumedEventGroups one multi-
cast SoAdSocketConnectionGroup needs to be created with two SoAdSocket-
Connections.

6.7.5.6.1 ConsumedServiceInstance with multicast only reception

A ProvidedServiceInstance may be configured to directly use multicast for the

transport of the Events of an EventGroup (EventHandler.multicastThreshold
= 1). In this case it is not required for a Client to have a unicast socket prepared if the
server will always use the multicast transport.
In order to take benefit of a “multicast only event transport” on Client side, the Client
needs the system knowledge that a specific EventGroup will be transported by
the Server using multicast only. Such an approach weakens the service discovery
paradigm / disentangle approach, where Client and Server do not need to know the
transport details. However, if there is the knowledge available, the Clients can be con-
figured for “multicast only event transport”.
Note that a Server that is not configured to provide “only multicast event transport”
for an EventGroup will reject a subscription with no unicast option configured, during
runtime.
While the configuration of “multicast only event transport” on the ProvidedServi-
ceInstance / EventHandler is obvious, the setup on the ConsumedServiceIn-
stance has several implications.

441 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

The indication that a ConsumedEventGroup shall be received using multicast only

transport is given by having only ConsumedEventGroup.pduActivationRout-
ingGroup aggregated where PduActivationRoutingGroup.eventGroupCon-
trolType is only set to activationMulticast.
[TPS_SYST_02302] Definition of multicast only reception of an EventGroup dIf
a ConsumedEventGroup has aggregated one or several PduActivationRout-
ingGroups in the role pduActivationRoutingGroup and all of these PduActi-
vationRoutingGroups have PduActivationRoutingGroup.eventGroupCon-
trolType set to activationMulticast then this ConsumedEventGroup is de-
fined to only receive Events via multicast.c(RS_SYST_00039)
[TPS_SYST_02244] ConsumedServiceInstance without a defined localUni-
castAddress dIf a ConsumedServiceInstance does not have a defined localU-
nicastAddress then the events will be received over IP Multicast only.c(RS_SYST_-
00039)
If the ConsumedServiceInstance receives events over IP Multicast only and
does not define any methods (i.e. the ConsumedServiceInstance does not ag-
gregate any PduActivationRoutingGroups in the role methodActivation-
RoutingGroup) that request the unicast configuration then the ConsumedServi-
ceInstance.localUnicastAddress reference can be skipped as described by
[TPS_SYST_02244]. In this case the SOME/IP message SubscribeEventGroup will
not contain any endpoint options. But since the ConsumedServiceInstance is cre-
ated for a specific EcuInstance and the localUnicastAddress is missing the con-
nection of the ConsumedServiceInstance to a specific EcuInstance needs to be
established in a different way. In this case the ApplicationEndpoint that is refer-
enced by the eventMulticastAddress reference from the ConsumedEventGroup
shall be EcuInstance specific. In other words the SocketAddress that contains the
referenced ApplicationEndpoint shall reference only a single EthernetCommu-
nicationConnector in the multicastConnector role.

442 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

:Ipv4Configuration

ipv4Address = ANY
ipv4AddressSource = fixed
CSI_25_1:
ConsumedServiceInstance

instanceIdentifier = 1
minorVersion = 0 :NetworkEndpoint
Vlan_1: EthernetPhysicalChannel
majorVersion = 1
serviceIdentifier = 0x19

:SoAdConfig

EG1: ConsumedEventGroup +eventMulticastAddress ANY_Multicast_AEP:

eventGroupIdentifier = 1 ApplicationEndpoint :SocketAddress

+multicastConnector

Connector_ecu1:
EG1_CSI_25_1: PduActivationRoutingGroup EthernetCommunicationConnector
:UdpTp
eventGroupControlType = activationMulticast

+iPduIdentifierUdp

Event2: SoConIPduIdentifier
:TpPort
headerId = 0x00198002
portNumber = 0

Event2:
PduTriggering

Figure 6.45: Example for the modeling of a ConsumedServiceInstance that is receiving

Events over multicast only

6.7.5.7 Service Discovery Server Configuration

For every ProvidedServiceInstance on a Server different phases are existing

where a suitable Service Discovery Message sending behavior is configurable:
• Down
• Available
– Initial Wait Phase
– Repetition Phase
– Main Phase
[TPS_SYST_02249] Service Discovery Message sending behavior on Provid-
edServiceInstance dThe Service Discovery Message sending behavior on a Pro-
videdServiceInstance is configurable with the SomeipSdServerServiceIn-
stanceConfig that is referenced in the role sdServerTimerConfig.c()

443 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Identifiable
TagWithOptionalValue
AbstractServiceInstance +capabilityRecord
+ key: String
+ majorVersion: PositiveInteger [0..1] «atpVariation» 0..*
+ sequenceOffset: Integer [0..1]
+ value: String [0..1]

ProvidedServiceInstance

+ autoAvailable: Boolean [0..1]

+ instanceIdentifier: PositiveInteger [0..1]
+ loadBalancingPriority: PositiveInteger [0..1]
+ loadBalancingWeight: PositiveInteger [0..1]
+ minorVersion: PositiveInteger [0..1]
+ priority: PositiveInteger [0..1]
+ serviceIdentifier: PositiveInteger [0..1]

«atpVariation»
+eventHandler 0..*
Identifiable
EventHandler
«atpVariation»
+ eventGroupIdentifier: PositiveInteger [0..1]
+ multicastThreshold: PositiveInteger [0..1]

«atpVariation»
+sdServerEgTimingConfig 0..1 +sdServerTimerConfig 0..1

ARElement ARElement
SomeipSdServerEventGroupTimingConfig SomeipSdServerServiceInstanceConfig

+ offerCyclicDelay: TimeValue [0..1]

+ priority: PositiveInteger [0..1]
+ serviceOfferTimeToLive: PositiveInteger

+requestResponseDelay 0..1 +requestResponseDelay 0..1 +initialOfferBehavior 0..1

RequestResponseDelay InitialSdDelayConfig

+ maxValue: TimeValue + initialDelayMaxValue: TimeValue

+ minValue: TimeValue + initialDelayMinValue: TimeValue
+ initialRepetitionsBaseDelay: TimeValue [0..1]
+ initialRepetitionsMax: PositiveInteger [0..1]

Figure 6.46: Model of SD Server Timing

Class SomeipSdServerServiceInstanceConfig
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::ServiceInstances
Note Server specific settings that are relevant for the configuration of SOME/IP Service-Discovery.
Tags:atp.recommendedPackage=SomeipSdTimingConfigs
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
initialOffer InitialSdDelayConfig 0..1 aggr Controls offer behavior of the server.
Behavior
offerCyclicDelay TimeValue 0..1 attr Optional attribute to define cyclic offers. Cyclic offer is
active, if the delay is set (in seconds).
priority PositiveInteger 0..1 attr This attribute defines the VLAN frame priority for Service
Discovery messages that result from ProvidedSomeip
ServiceInstances that are referencing the SomeipSd
ServerServiceInstanceConfig (OfferService, StopOffer
Service, SubscribeEventGroupAck). Values from 0 (best
effort) to 7 (highest) are allowed.
request RequestResponseDelay 0..1 aggr Maximum/Minimum allowable response delay to entries
ResponseDelay received by multicast in seconds. The Service Discovery
shall delay answers to entries that were transported in a
multicast SOME/IP-SD message (e.g. FindService).
serviceOffer PositiveInteger 1 attr Defines the time in seconds the service offer is valid.
TimeToLive
Table 6.170: SomeipSdServerServiceInstanceConfig

444 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class InitialSdDelayConfig
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::ServiceInstances
Note This element is used to configure the offer behavior of the server and the find behavior on the client.
Base ARObject
Attribute Type Mult. Kind Note
initialDelayMax TimeValue 1 attr Max Value in seconds to delay randomly the first offer (if
Value aggregated by SdServerConfig) or the transmission of a
find message (if aggregated by SdClientConfig).
initialDelayMin TimeValue 1 attr Min Value in seconds to delay randomly the first offer or
Value the transmission of a find message (if aggregated by Sd
ClientConfig).
initial TimeValue 0..1 attr The base delay for offer repetitions (if aggregated by Sd
Repetitions ServerConfig) or find repetitions (if aggregated by Sd
BaseDelay ClientConfig). Successive find messages have an
exponential back off delay.
initial PositiveInteger 0..1 attr Describes the maximum amount of offer repetitions (if
RepetitionsMax aggregated by SdServerConfig) or the maximum amount
of find repetitions (if aggregated by SdClientConfig).

Table 6.171: InitialSdDelayConfig

Class RequestResponseDelay
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::ServiceInstances
Note Time to wait before answering the query.
Base ARObject
Attribute Type Mult. Kind Note
maxValue TimeValue 1 attr Maximum allowable response delay to entries received by
multicast in seconds.
minValue TimeValue 1 attr Minimum allowable response delay to entries received by
multicast in seconds.
Table 6.172: RequestResponseDelay

[TPS_SYST_02174] Initial Wait Phase configuration for a ProvidedServiceIn-

stance dThe Initial Wait Phase for a ProvidedServiceInstance is configured with
the initialOfferBehavior and the two attributes initialDelayMinValue and
initialDelayMaxValue.c()
When a calculated random timer based on these min and max values expires, the first
OfferService message will be sent out.
[TPS_SYST_02258] Shared random timer for ProvidedServiceInstance ser-
vice discovery dIf several ProvidedServiceInstances reference the same
SomeipSdServerServiceInstanceConfig in the role of sdServerTimerCon-
fig and if it is ensured that all ProvidedServiceInstances are requested / re-
leased in the same point in time (e.g. assigned to the same ConsumedProvided-
ServiceInstanceGroup and referenced only by one ConsumedProvidedServi-
ceInstanceGroup, or all referencing ProvidedServiceInstances has set au-
toAvailable to TRUE and no runtime changes to the availability is performed),
then the timing behavior is shared between the referencing ProvidedServiceIn-
stances. Thus, if the calculated random timer based on the min and max values of

445 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

the InitialSdDelayConfig expires, then OfferService entries of all referencing

ProvidedServiceInstances shall be sent out.c()
[TPS_SYST_02259] Shared random timer for ProvidedServiceInstance ser-
vice discovery dIf several ProvidedServiceInstances reference the same
SomeipSdServerServiceInstanceConfig in the role of sdServerTimerCon-
fig and if it cannot be ensured that all ProvidedServiceInstances are requested
/ released in the same point in time, then the timing behavior is handled per Pro-
videdServiceInstance. The timing behavior shall be derived from the referenced
SomeipSdServerServiceInstanceConfig for each referencing ProvidedSer-
viceInstance.c()
Note: [TPS_SYST_02259] supports an efficient modeling if timing behaviors are equal
for the referencing ProvidedServiceInstances.
[TPS_SYST_02260] Individual random timer for ProvidedServiceInstance
service discovery dIf ProvidedServiceInstances reference their own SomeipS-
dServerServiceInstanceConfig in the role of sdServerTimerConfig, then
the timing behavior is handled per ProvidedServiceInstance. Thus, every Pro-
videdServiceInstance has its own calculated random timer based on the min and
max value of the InitialSdDelayConfig. If the calculated random timer expires,
then a OfferService entry of the referencing ProvidedServiceInstance shall be
sent out.c()
Note: [TPS_SYST_02260] enables a scattering of OfferService within the configured
min and max value of the InitialSdDelayConfig of different ProvidedServi-
ceInstances.
[TPS_SYST_02175] Repetition Wait Phase configuration for a ProvidedServi-
ceInstance dThe Repetition Wait Phase for a ProvidedServiceInstance is con-
figured with the initialOfferBehavior and the two attributes initialRepeti-
tionsMax and initialRepetitionsBaseDelay.c()
If the Repetition Phase is entered the Service Discovery waits for the initialRep-
etitionsBaseDelay and transmits an OfferService entry. If the amount of sent
OfferService entries reaches initialRepetitionsMax the Main Phase will be
entered.
If initialRepetitionsMax is configured to 0 the Repetition Phase will be skipped
and the Main Phase will be entered.
[TPS_SYST_02176] Main Phase configuration for a ProvidedServiceInstance
dThe Main Phase for a ProvidedServiceInstance is configured with the offer-
CyclicDelay attribute of SomeipSdServerServiceInstanceConfig.c()
The OfferService entry will be sent cyclically with an interval that is defined by the
value of attribute offerCyclicDelay.
[TPS_SYST_02177] TTL for Offer Service Entries dThe lifetime of a Provided-
ServiceInstance is configurable with the serviceOfferTimeToLive attribute of
SomeipSdServerServiceInstanceConfig.c()

446 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

If the time that is configured by serviceOfferTimeToLive expires the Provided-

ServiceInstance will no longer be offered.
[TPS_SYST_02178] Servers RequestResponseDelay for received FindService
entries dThe Server will delay the OfferService answer to a received multicast
FindService entry by the configured SomeipSdServerServiceInstanceCon-
fig.requestResponseDelay.
The actual delay will be randomly chosen between the maxValue and minValue.c()
The ProvidedServiceInstance aggregates an EventHandler in the role even-
tHandler that allows to define service instance specific configuration settings for a
SOME/IP EventGroup. The EventGroup specific timing settings are configured in
the SomeipSdServerEventGroupTimingConfig that is referenced by the Even-
tHandler in the role sdServerEgTimingConfig.
Class SomeipSdServerEventGroupTimingConfig
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::ServiceInstances
Note EventGroup specific timing configuration settings.
Tags:atp.recommendedPackage=SomeipSdTimingConfigs
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
request RequestResponseDelay 0..1 aggr The Service Discovery shall delay answers to unicast
ResponseDelay messages triggered by multicast messages (e.g.
Subscribe Eventgroup after Offer Service).

Table 6.173: SomeipSdServerEventGroupTimingConfig

[TPS_SYST_02182] Servers RequestResponseDelay for received Sub-

scribeEventGroup entries dThe Server will delay the SubscribeEventGroupAck
answer to a received SubscribeEventGroup message that was triggered by a
multicast ServiceOffer by the configured SomeipSdServerEventGroupTim-
ingConfig.requestResponseDelay that is referenced by the EventHandler in
the role sdServerEgTimingConfig.
The actual delay will be randomly chosen between the maxValue and minValue.c()

6.7.5.8 Service Discovery Client Configuration

For every ConsumedServiceInstance on a Client different phases are existing:

• Down
• Requested
– Initial Wait Phase
– Repetition Phase
– Main Phase

447 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_02250] Service Discovery Message sending behavior on Consumed-

ServiceInstance dThe Service Discovery Message sending behavior on a Con-
sumedServiceInstance is configurable with the SomeipSdClientServiceIn-
stanceConfig that is referenced in the role sdClientTimerConfig.c()
Identifiable
+capabilityRecord TagWithOptionalValue
AbstractServiceInstance
+ key: String
+ majorVersion: PositiveInteger [0..1] «atpVariation» 0..*
+ sequenceOffset: Integer [0..1]
+ value: String [0..1]

ConsumedServiceInstance

+ autoRequire: Boolean [0..1]

+ instanceIdentifier: AnyServiceInstanceId [0..1]
+ minorVersion: AnyVersionString [0..1]
+ serviceIdentifier: PositiveInteger [0..1]
+ versionDrivenFindBehavior: ServiceVersionAcceptanceKindEnum [0..1]

«atpVariation»

+consumedEventGroup 0..*

Identifiable
ConsumedEventGroup

+ autoRequire: Boolean [0..1] «atpVariation»

+ eventGroupIdentifier: PositiveInteger [0..1]
+ priority: PositiveInteger [0..1]

«atpVariation»
+sdClientTimerConfig 0..1 +sdClientTimerConfig 0..1
ARElement ARElement
SomeipSdClientEventGroupTimingConfig SomeipSdClientServiceInstanceConfig

+ subscribeEventgroupRetryDelay: TimeValue [0..1] + priority: PositiveInteger [0..1]

+ subscribeEventgroupRetryMax: PositiveInteger [0..1] + serviceFindTimeToLive: PositiveInteger
+ timeToLive: PositiveInteger

+initialFindBehavior 0..1
+requestResponseDelay 0..1
InitialSdDelayConfig
RequestResponseDelay
+ initialDelayMaxValue: TimeValue
+ maxValue: TimeValue + initialDelayMinValue: TimeValue
+ minValue: TimeValue + initialRepetitionsBaseDelay: TimeValue [0..1]
+ initialRepetitionsMax: PositiveInteger [0..1]

Figure 6.47: Model of SD Client Timing

[TPS_SYST_02183] Initial Wait Phase configuration for a ConsumedServiceIn-

stance dThe Initial Wait Phase for a ConsumedServiceInstance is configured with
the initialFindBehavior and the two attributes initialDelayMinValue and
initialDelayMaxValue.c()
If a calculated random timer based on these min and max values expires the first
FindService entry will be sent out. When the calculated random timer expires and
no OfferService is received the Repetition Phase will be entered.
[TPS_SYST_02261] Shared random timer for ConsumedServiceInstance ser-
vice discovery dIf several ConsumedServiceInstances reference the same
SomeipSdClientServiceInstanceConfig in the role of sdClientTimerCon-
fig and if it is ensured that all ConsumedServiceInstances are requested / re-
leased in the same point in time (e.g. assigned to the same ConsumedProvidedSer-
viceInstanceGroup and referenced only by one ConsumedProvidedService-
InstanceGroup, or all referencing ConsumedServiceInstance has set autoRe-
quire to TRUE and no runtime changes to the require state is performed), then the
timing behavior is shared between the referencing ConsumedServiceInstances.

448 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Thus, if the calculated random timer based on the min and max values of the Ini-
tialSdDelayConfig expires, then FindService entries of all referencing Consumed-
ServiceInstances shall be sent out.c()
[TPS_SYST_02262] Shared random timer for ConsumedServiceInstance ser-
vice discovery dIf several ConsumedServiceInstances reference the same
SomeipSdClientServiceInstanceConfig in the role of sdClientTimerCon-
fig and if it cannot be ensured that all ConsumedServiceInstances are requested
/ released in the same point in time, then the timing behavior is handled per Con-
sumedServiceInstance. The timing behavior shall be derived from the referenced
SomeipSdClientServiceInstanceConfig for each referencing ConsumedSer-
viceInstance.c()
Note: [TPS_SYST_02262] support an efficient modeling if timing behaviors are equal
for the referencing ConsumedServiceInstances.
[TPS_SYST_02263] Individual random timer for ConsumedServiceInstance
service discovery dIf ConsumedServiceInstances reference their own SomeipS-
dClientServiceInstanceConfig in the role of sdClientTimerConfig, then
the timing behavior is handled per ConsumedServiceInstance. Thus, every Con-
sumedServiceInstance has its own calculated random timer based on the min and
max value of the InitialSdDelayConfig. Thus, if the calculated random timer ex-
pires, then a FindService entry of the referencing ConsumedServiceInstance shall
be sent out.c()
Note: [TPS_SYST_02263] enables a scattering of FindServices within the configured
min and max value of the InitialSdDelayConfig, respectively of different Con-
sumedServiceInstances.
[TPS_SYST_02184] Repetition Wait Phase configuration for a ConsumedServi-
ceInstance dThe Repetition Wait Phase for a ConsumedServiceInstance is con-
figured with the initialFindBehavior and the two attributes initialRepeti-
tionsMax and initialRepetitionsBaseDelay.c()
If the Repetition Phase is entered, the Service Discovery waits the initialRepeti-
tionsBaseDelay and sends a FindService entry.
If the amount of sent FindService entries reaches initialRepetitionsMax and
no OfferService is received the Main Phase will be entered. In the Main Phase no
further FindService entries are sent by the client.
[TPS_SYST_02185] TTL for Find Service Entries dThe lifetime of a Consumed-
ServiceInstance is configurable with the serviceFindTimeToLive attribute of
SomeipSdClientServiceInstanceConfig.c()
If the time that is configured by serviceFindTimeToLive expires the FindService
entry shall be considered not existing.
The ConsumedServiceInstance aggregates a ConsumedEventGroup in the role
consumedEventGroup that allows to define service instance specific configuration
settings for a SOME/IP EventGroup. The EventGroup specific timing settings are

449 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

configured in the SomeipSdClientEventGroupTimingConfig that is referenced

by the ConsumedEventGroup in the role sdClientTimerConfig.
Class SomeipSdClientEventGroupTimingConfig
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::ServiceInstances
Note This meta-class is used to specify configuration related to service discovery in the context of an event
group on SOME/IP.
Tags:atp.recommendedPackage=SomeipSdTimingConfigs
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
request RequestResponseDelay 0..1 aggr The Service Discovery shall delay answers to unicast
ResponseDelay messages triggered by multicast messages (e.g.
Subscribe Eventgroup after Offer Service).
subscribe TimeValue 0..1 attr This attribute defines the interval in seconds to re-trigger
Eventgroup a subscription to a Eventgroup, if a retry to subscribe to a
RetryDelay Eventgroup is configured (subscribeEventgroupRetryMax
> 0).
subscribe PositiveInteger 0..1 attr This attribute define the maximum counts of retries to
Eventgroup subscribe to an Eventgroup. If the value is set to 0 no
RetryMax retry shall be done. If the value is set to 255 the retry
shall be done as along as the Eventgroup is requested
and no SubscribeEventGroupAck was received.
timeToLive PositiveInteger 1 attr Defines the time in seconds the subscription of this event
is expected by the client. this value is sent from the client
to the server in the SD-subscribeEvent message.

Table 6.174: SomeipSdClientEventGroupTimingConfig

[TPS_SYST_02187] SomeipSdClientEventGroupTimingConfig.timeToLive
for SubscribeEventGroup Entries dThe lifetime of an event subscription is con-
figurable with the timeToLive attribute of SomeipSdClientEventGroupTiming-
Config that is aggregated by an ConsumedEventGroup in the role sdClient-
TimerConfig.
If the time that is configured by timeToLive expires the event subscription is can-
celed.c()
It is possible to define a retry for subscription to a ConsumedEventGroup. The retry
is optional and used by a ConsumedServiceInstance. It could be used to speed up
the recovery if a SOME/IP-SD message is lost (e.g. SubscribeEventGroupAck) and
the interval between cyclic offers (SomeipSdServerServiceInstanceConfig.of-
ferCyclicDelay) of the corresponding ProvidedServiceInstance are to large
to get a fast recovery, or to speed up the subscription to a ConsumedEventGroup if
an ConsumedEventGroup is requested somewhere between two cyclic offers.
The retry is configurable within SomeipSdServerServiceInstanceConfig by set-
ting the subscribeEventgroupRetryMax value greater than 0 to define how of-
ten a retry shall be triggered and subscribeEventgroupRetryDelay to define
the timing interval the retries shall be triggered. If subscribeEventgroupRetry-
Max is set to 255, the retry to subscribe to a ConsumedEventGroup shall be
done as long as the ConsumedEventGroup is requested and no acknowledgment
(SubscribeEventGroupAck) from the ProvidedServiceInstance was received.

450 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_5095] Relationship between the timing behavior of the ConsumedE-

ventGroup retry and the timing behavior of an Offer message dThe timing
behavior for a retry to a ConsumedEventGroup (subscribeEventgroupRetry-
Max, subscribeEventgroupRetryDelay) shall not overlap to the timing behav-
ior (SomeipSdServerServiceInstanceConfig.offerCyclicDelay) of the cor-
responding ProvidedServiceInstance.c()
[constr_5096] ConsumedEventGroup with value subscribeEventgroupRetry-
Max set to 255 dRetry to a ConsumedEventGroup with value subscribeEvent-
groupRetryMax set to 255 is only allowed if the SomeipSdServerServiceIn-
stanceConfig.offerCyclicDelay is set 0 and serviceOfferTimeToLive is
set to 0xffffff of the corresponding ProvidedServiceInstance.c()
[TPS_SYST_02188] Clients RequestResponseDelay for received ServiceOf-
fer entries dThe Client will delay the SubscribeEventGroup answer to a re-
ceived ServiceOffer message by the configured SomeipSdClientEventGroup-
TimingConfig.requestResponseDelay that is aggregated by the ConsumedE-
ventGroup in the role sdClientTimerConfig.
The actual delay will be randomly chosen between the maxValue and minValue.c()

6.7.5.9 Group of ConsumedServiceInstances and ProvidedServiceInstances

The AUTOSAR ServiceDiscovery provide a mechanism of starting/stopping Con-

sumedProvidedServiceInstanceGroups. Therefore, several ConsumedServi-
ceInstances and ProvidedServiceInstances, respectively, could by enclosed
to a ConsumedProvidedServiceInstanceGroup.
Class ConsumedProvidedServiceInstanceGroup
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::ServiceInstances
Note The AUTOSAR ServiceDiscovery is able to start and to stop ClientServices and Server
Services,respectively, at runtime. A SdServiceGroup contains several ClientServices and Server
Services, respectively.
Tags:atp.recommendedPackage=ConsumedProvidedServiceInstanceGroups
Base ARObject, CollectableElement, FibexElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
consumed ConsumedService * ref This reference assigns a set of ProvidedServiceInstances
ServiceInstance Instance to the ConsumedProvidedServiceInstanceGroup.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
providedService ProvidedService * ref This reference assigns a set of ConsumedService
Instance Instance Instances to the ConsumedProvidedServiceInstance
Group.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild

Table 6.175: ConsumedProvidedServiceInstanceGroup

451 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

The ConsumedProvidedServiceInstanceGroup is mapped to a SdService-

Group within the ECUC configuration. The SdServiceGroups could be accessed
via dedicated APIs within the AUTOSAR ServiceDiscovery (Sd) module to start and
stop the requested SdServiceGroup. For example, the SdServiceGroups could be
switched according the requested partial network similar to ComISignalIPduGroup
and therefore the PncMapping refers the ConsumedProvidedServiceInstance-
Group in the role pncConsumedProvidedServiceInstanceGroup.
FibexElement
EcuInstance

+ comConfigurationGwTimeBase: TimeValue [0..1]

+ comConfigurationRxTimeBase: TimeValue [0..1]
+ comConfigurationTxTimeBase: TimeValue [0..1]
+ comEnableMDTForCyclicTransmission: Boolean [0..1]
+ ethSwitchPortGroupDerivation: Boolean [0..1]
+ pncPrepareSleepTimer: TimeValue [0..1]
Describable
+ pncSynchronousWakeup: Boolean [0..1]
PncMapping + pnResetTime: TimeValue [0..1]
+relevantForDynamicPncMapping + sleepModeSupported: Boolean
+ pncIdentifier: PositiveInteger
+ v2xSupported: V2xSupportEnum [0..1]
+ pncWakeupEnable: Boolean [0..1] 0..* + wakeUpOverBusSupported: Boolean
+ shortLabel: Identifier [0..1]

«atpVariation» «atpVariation»

0..* +pncConsumedProvidedServiceInstanceGroup 0..* +associatedConsumedProvidedServiceInstanceGroup

FibexElement
ConsumedProvidedServiceInstanceGroup

«atpVariation» «atpVariation»
+providedServiceInstance 0..*
+consumedServiceInstance 0..*
AbstractServiceInstance
AbstractServiceInstance
ProvidedServiceInstance
ConsumedServiceInstance
+ autoAvailable: Boolean [0..1]
+ autoRequire: Boolean [0..1]
+ instanceIdentifier: PositiveInteger [0..1]
+ instanceIdentifier: AnyServiceInstanceId [0..1]
+ loadBalancingPriority: PositiveInteger [0..1]
+ minorVersion: AnyVersionString [0..1]
+ loadBalancingWeight: PositiveInteger [0..1]
+ serviceIdentifier: PositiveInteger [0..1]
+ minorVersion: PositiveInteger [0..1]
+ versionDrivenFindBehavior: ServiceVersionAcceptanceKindEnum [0..1]
+ priority: PositiveInteger [0..1]
+ serviceIdentifier: PositiveInteger [0..1]

Figure 6.48: ConsumedProvidedServiceInstanceGroup

Starting a ConsumedProvidedServiceInstanceGroup would trigger the referenc-

ing ConsumedServiceInstances to sent out FindService entries on the network
and stopping a ConsumedProvidedServiceInstanceGroup would trigger the ref-
erencing ConsumedServiceInstances to unsubscribe from the subscribed Event
Groups and sent out an unsubscribe entry on the network.
Starting a ConsumedProvidedServiceInstanceGroup would trigger the referenc-
ing ProvidedServiceInstances to sent out OfferService entries on the network
and stopping a ConsumedProvidedServiceInstanceGroup would trigger the ref-
erencing ProvidedServiceInstances to sent out a StopOffer entries on the net-
work.

6.7.5.10 StaticSocketConnection

Only the SOME/IP data communication is described with ProvidedServiceIn-

stances and ConsumedServiceInstances as described in chapter 6.7.5.3. But

452 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

there is also the need to describe non-SOME/IP data exchange between two Socke-
tAddresses.
[TPS_SYST_02251] Non-SOME/IP data exchange between two communication
endpoints dNon-SOME/IP data exchange between two SocketAddresses is de-
scribed with the StaticSocketConnection element that is aggregated by a Sock-
etAddress in the role StaticSocketConnection. The aggregating SocketAd-
dress describes one communication endpoint. The referenced StaticSocketCon-
nection.remoteAddress defines the second communication endpoint.c()
Class StaticSocketConnection
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::ServiceInstances
Note Definition of static SocketConnection between the Socket that is defined by the aggregating Socket
Address and the remoteAddress.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
iPduIdentifier SoConIPduIdentifier * ref Assignment of IPduIdentifiers that are transmitted over
the static SocketConnection.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
remoteAddress SocketAddress 0..1 ref RemoteAddress of the static SocketConnection.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
tcpConnect TimeValue 0..1 attr Specifies the time in seconds how long TCP connect
Timeout attempts are repeated to reach SOAD_SOCON_ONLINE.
This attribute is restricted to socket connection groups
which are initiating a TCP connection and are under
control of SoAd.
tcpRole TcpRoleEnum 0..1 attr Defines whether the local Address (that is aggregating
the StaticSocketConnection) does a listen or a connect.

Table 6.176: StaticSocketConnection

453 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

CommunicationConnector
EthernetCommunicationConnector Identifiable
NetworkEndpoint
+ maximumTransmissionUnit: PositiveInteger [0..1]
+ neighborCacheSize: PositiveInteger [0..1] + fullyQualifiedDomainName: String [0..1]
+ pathMtuEnabled: Boolean [0..1] + priority: PositiveInteger [0..1]
+ pathMtuTimeout: TimeValue [0..1]
+networkEndpoint 1
+ pncFilterDataMask: PositiveUnlimitedInteger [0..1]

+connector 0..1 +multicastConnector 0..*

Identifiable
SocketAddress

+ differentiatedServiceField: PositiveInteger [0..1]

+ flowLabel: PositiveInteger [0..1]
+ pathMtuDiscoveryEnabled: Boolean [0..1] Identifiable
+ pduCollectionMaxBufferSize: PositiveInteger [0..1] +applicationEndpoint ApplicationEndpoint
+ pduCollectionTimeout: TimeValue [0..1]
+ udpChecksumHandling: UdpChecksumCalculationEnum [0..1] 0..1 + maxNumberOfConnections: PositiveInteger [0..1]
+ priority: PositiveInteger [0..1]

+remoteAddress 0..1
«enumeration»
«atpVariation» «atpVariation» TcpRoleEnum
0..* +staticSocketConnection connect
Identifiable
Identifiable listen
PduTriggering
StaticSocketConnection

+ tcpConnectTimeout: TimeValue [0..1]

+ tcpRole: TcpRoleEnum [0..1]
+pduTriggering 0..1

«atpVariation»
+iPduIdentifier 0..*

Referrable
SoConIPduIdentifier
+iPduIdentifier FibexElement
+ headerId: PositiveInteger [0..1] SocketConnectionIpduIdentifierSet
+ pduCollectionPduTimeout: TimeValue [0..1] 0..*
+ pduCollectionSemantics: PduCollectionSemanticsEnum [0..1]
+ pduCollectionTrigger: PduCollectionTriggerEnum [0..1]

Figure 6.49: Model of StaticSocketConnection

UDP doesn’t establish a connection before sending data, it is Connectionless. TCP on

the other hand establishes a TCP connection. The client initiates the TCP communi-
cation and therefore it needs to be configured which endpoint acts as client and which
acts as server.
[TPS_SYST_02252] Description of a TCP Client dThe SocketAddress that aggre-
gates the StaticSocketConnection with tcpRole set to connect defines the
TCP client.c()
[TPS_SYST_02253] Description of a TCP Server dThe SocketAddress that aggre-
gates the StaticSocketConnection with tcpRole set to listen defines the TCP
server.c()
[constr_5091] Relevance of tcpRole attribute dThe attribute tcpRole is only rel-
evant if the StaticSocketConnection is aggregated by a SocketAddress that
defines a TCP Port in the aggregated ApplicationEndpoint.c()
[constr_5092] Local and remoteAddress of a StaticSocketConnection shall de-
fine the same transport protocol dThe transport protocol that is defined by the
SocketAddress that aggregates the StaticSocketConnection shall be the same
in the SocketAddress that is referenced by the same StaticSocketConnection
in the role remoteAddress.c()

454 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_02254] Pdus transported over the StaticSocketConnection dA

Pdu that is transported over the StaticSocketConnection is described by So-
ConIPduIdentifier that is referenced in the role iPduIdentifier.c()
Please note that the remoteAddress is allowed to be defined as ANY (TpPort = 0
and ipv4address/ipv6address = ANY). In other words the remote port and/or remote
IP address is configured at runtime and the ECU is able to receive all packets that are
addressed to its local address no matter what the remote address is.

455 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

:NetworkEndpoint :Ipv4Configuration

ipv4Address = 192.172.1.100
ipv4AddressSource = fixed

ecu1_UnicastSocketAddress: +applicationEndpoint ecu1_Tcp_Unicast: :TcpTp :TpPort

SocketAddress ApplicationEndpoint
portNumber = 23232

+staticSocketConnection

ecu1_to_ecu2_SocketConnection: +iPduIdentifier Pdu_berta: :Ipv4Configuration

:
StaticSocketConnection SocketConnectionIpduIdentifier NetworkEndpoint
ipv4Address = 192.172.1.22
tcpRole = listen ipv4AddressSource = fixed

ecu2_UnicastSocketConnection: +staticSocketConnection ecu2_Udp_Unicast:

SocketAddress ApplicationEndpoint
+remoteAddress

:TpPort
:TcpTp
portNumber = 16345

:NetworkEndpoint :Ipv4Configuration

ipv4Address = 192.169.1.22
ipv4AddressSource = fixed

ecu2_UnicastSocketAddress: ecu2_Tcp_Unicast: :TcpTp :TpPort

+applicationEndpoint
SocketAddress ApplicationEndpoint portNumber = 16345

+staticSocketConnection

ecu2_to_ecu1_SocketConnection: +iPduIdentifier Pdu_berta: :Ipv4Configuration

StaticSocketConnection :NetworkEndpoint
SocketConnectionIpduIdentifier
ipv4Address = 192.169.1.100
tcpRole = connect ipv4AddressSource = fixed

ecu1_UnicastSocketConnection: +staticSocketConnection ecu1_Udp_Unicast:

SocketAddress ApplicationEndpoint
+remoteAddress

:TpPort
:TcpTp
portNumber = 23232

Figure 6.50: Example for the modeling of TCP StaticSocketConnections in TCP server
role and TCP client role

The example in Figure 6.50 shows a StaticSocketConnection with the name

ecu2_to_ecu1_SocketConnection on ecu1_UnicastSocketAddress that defines the
TCP server. The socket connection is established to to ecu2_UnicastSocketAddress
remoteAddress.

456 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

It also shows the StaticSocketConnection with the name

ecu1_to_ecu2_SocketConnection on ecu2_UnicastSocketAddress that defines the
TCP client. The socket connection is established to the ecu1_UnicastSocketAddress
remoteAddress.

6.7.5.11 Service Discovery Message Configuration

If Service Discovery is used a Service Discovery Instance is configurable on an

EcuInstance for a certain VLAN using the respective ApplicationEndpoint. The
Service Discovery Instance refers to the configuration of a Service Discovery for a
VLAN.
[TPS_SYST_02116] Modeling of Service Discovery Pdus dA Service Discovery In-
stance configuration requires:
• one Tx Pdu that is modeled as GeneralPurposePdu with category = SD
• one Rx Pdu (unicast reception) that is modeled as GeneralPurposePdu with
category = SD
• one Rx Pdu (multicast reception) that is modeled as GeneralPurposePdu with
category = SD
c()
[TPS_SYST_02117] Length of GeneralPurposePdu with category SD dThe
length attribute for GeneralPurposePdus with category = SD shall be set to at
most EthernetCommunicationConnector.maximumTransmissionUnit minus
the sum of the length of the following headers:
• IP Header (for IpV4: 20 bytes, for IpV6: 40 bytes)
• IpV4 and IpV6 : any optional additional headers, e.g. for IPSec
• Udp Header (8 bytes)
• Socket Adaptor PDU Header (8 bytes)
c()
[TPS_SYST_02118] Rules for the creation of references to IPduPorts from
PduTriggerings related to GeneralPurposePdus with category SD dFor each
GeneralPurposePdu with category SD a PduTriggering needs to be defined on
the EthernetPhysicalChannel (VLAN) that is referenced from the Communica-
tionConnector of the EcuInstance on which the Service Discovery Instance is
configured:
• the PduTriggering for the Tx GeneralPurposePdu references the OUT
IPduPort of the EcuInstance

457 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• the PduTriggering for the Rx GeneralPurposePdu (unicast reception) refer-

ences the IN IPduPort of the EcuInstance
• the PduTriggering for the Rx GeneralPurposePdu (multicast reception) ref-
erences the IN IPduPort of the EcuInstance
c()
[TPS_SYST_02119] StaticSocketConnections for GeneralPurposePdus with
category SD dUDP Sockets are used for the transmission of SD messages and the
following StaticSocketConnections shall be created:
• StaticSocketConnection A for all Tx and unicast Rx GeneralPur-
posePdus
• StaticSocketConnection B for multicast Rx GeneralPurposePdu
The PduTriggering for the Tx GeneralPurposePdu and the PduTriggering for
the Rx GeneralPurposePdu (unicast reception) are assigned to the StaticSock-
etConnection A via SoConIPduIdentifier. The PduTriggering for Rx Mul-
ticast GeneralPurposePdu is assigned to the StaticSocketConnection B via
SoConIPduIdentifier.c()
[constr_3267] PduTriggerings in Service Discovery StaticSocketConnec-
tions dSD StaticSocketConnections defined in [TPS_SYST_02119] shall only
refer to PduTriggerings which point to GeneralPurposePdus of category SD.c()
[constr_3268] Service Discovery StaticSocketConnection aggregation by
an ApplicationEndpoint dEach SD StaticSocketConnection defined in
[TPS_SYST_02119] shall be aggregated by an ApplicationEndpoint that defines
a Udp Port.c()
[constr_3269] Service Discovery StaticSocketConnection remoteAddress
reference to a TpPort dEach SD StaticSocketConnection defined in
[TPS_SYST_02119] shall refer with the remoteAddress reference to an Applica-
tionEndpoint with Udp Port portNumber set to 0. This means that the port number
is dynamically assigned at runtime.c()
[constr_3270] Service Discovery SocketConnection remoteAddress refer-
ence to an IP Address dEach SD StaticSocketConnection defined in
[TPS_SYST_02119] shall refer with the remoteAddress reference to an Applica-
tionEndpoint that points to a NetworkEndpoint that defines an IP Address ANY
(IPv4 or IPv6).c()
[constr_3272] SoConIPduIdentifier.headerId setting for SD StaticSock-
etConnections dThe SoConIPduIdentifier.headerId of SD StaticSocket-
Connections defined in [TPS_SYST_02119] shall always be set to 0xFFFF8100 for
SD messages.c()
[constr_3273] Service Discovery multicast StaticSocketConnection’s aggre-
gation by an ApplicationEndpoint dThe SD StaticSocketConnection for

458 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

multicast defined in [TPS_SYST_02119] shall be aggregated by an Applicatio-

nEndpoint that points to a NetworkEndpoint that defines an IP Multicast Address.c
()
[constr_3274] Service Discovery unicast StaticSocketConnection’s aggrega-
tion by an ApplicationEndpoint dThe SD StaticSocketConnection for uni-
cast defined in [TPS_SYST_02119] shall be aggregated by an ApplicationEnd-
point that points to a NetworkEndpoint that defines an IP Unicast Address.c()
:NetworkEndpoint :Ipv4Configuration

ipv4Address = 192.169.1.100
ipv4AddressSource = fixed

ecu1_SD_UnicastSocketAddress: ecu1_SD_Unicast_AEP: :UdpTp :TpPort

+applicationEndpoint
SocketAddress ApplicationEndpoint
portNumber = 30490

+staticSocketConnection
SD_Rx_Unicast_Ecu1:
ecu1_SD_RxTxUnicast: +iPduIdentifier SocketConnectionIpduIdentifier
StaticSocketConnection
headerId = 0xFFFF8100

SD_Tx_UnicastAndMulticast_Ecu1:
+iPduIdentifier SocketConnectionIpduIdentifier

headerId = 0xFFFF8100

+remoteAddress :Ipv4Configuration
ANY: SocketAddress ANY_IP:
NetworkEndpoint ipv4AddressSource = fixed
ipv4Address = ANY

ecu1_SD_RxMulticast: +remoteAddress ANY_Udp: :UdpTp

StaticSocketConnection ApplicationEndpoint

SD_RX_Multicast_Ecu1:
+iPduIdentifier SocketConnectionIpduIdentifier
:TpPort
headerId = 0xFFFF8100 portNumber = 0

+staticSocketConnection

:NetworkEndpoint :Ipv4Configuration

ipv4Address = 239.192.255.52
ipv4AddressSource = fixed

ecu1_SD_MulticastSocketAddress: +applicationEndpoint ecu1_AEP: ApplicationEndpoint :UdpTp :TpPort

SocketAddress
portNumber = 30490

Figure 6.51: Example for the modeling of SD StaticSocketConnections

459 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.7.5.12 NmPdu data exchange over StaticSocketConnection

The data exchange of NmPdu on an Ethernet channel is described with the Static-
SocketConnection as defined in chapter 6.7.5.10.
ecu1_UnicastSocketAddress: :Ipv4Configuration
:NetworkEndpoint
SocketAddress
ipv4Address = 192.172.1.100
ipv4AddressSource = fixed

+applicationEndpoint

:UdpTp :TpPort
ecu1_SD_Unicast_AEP:
ApplicationEndpoint portNumber = 6690

+staticSocketConnection

:NetworkEndpoint :Ipv4Configuration
ecu1_Nm_ActiveNode: +iPduIdentifier NmTxPdu:
StaticSocketConnection SocketConnectionIpduIdentifier ipv4Address = 239.192.255.52
ipv4AddressSource = fixed

ecu1_SD_MulticastSocketAddress: +staticSocketConnection ecu1_AEP: ApplicationEndpoint

SocketAddress
+remoteAddress

:TpPort :UdpTp
portNumber = 6690

ecu2_SD_MulticastSocketAddress: +applicationEndpoint ecu2_AEP: ApplicationEndpoint :NetworkEndpoint

SocketAddress

:UdpTp :TpPort :Ipv4Configuration

+staticSocketConnection
portNumber = 6690 ipv4Address = 239.192.255.52
ecu2_NM_PassiveNode: ipv4AddressSource = fixed
StaticSocketConnection

+iPduIdentifier NmRxPdu:
SocketConnectionIpduIdentifier

ANY_IP: :Ipv4Configuration
NetworkEndpoint ipv4AddressSource = fixed
ipv4Address = ANY

+remoteAddress

Nm_Rx: SocketAddress NmRx: ApplicationEndpoint :UdpTp :TpPort

portNumber = 6690

Figure 6.52: Example for the modeling of NM StaticSocketConnections

460 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

The example in Figure 6.52 shows a possible configuration where the active NmNode
sends the NmPdu to a remote multicast address. Each passive and active NmNode re-
ceives the NmPdu over a local multicast address from all other nodes (remote Address
= ANY).

6.7.5.13 Diagnostics over IP

DoIpConfig defines a DoIP module configuration for a specific EcuInstance. DoIP

supports the communication of internal testers and external testers with an ECU/DoIP
Node. Each DoIP node might define several logical DoIpInterfaces that may share
the same physical Ethernet interface/MAC Address. The DoIP node is able to commu-
nicate on each of its DoIpInterfaces independently. I.e. the DoIP functionalities on
each DoIpInterface are isolated from each other.
More details about DoIpInterfaces can be found in
AUTOSAR_SWS_DiagnosticOverIP [28].
Class DoIpConfig
Package M2::AUTOSARTemplates::SystemTemplate::DoIP
Note This element defines the DoIp configuration for a specific Ecu.
Base ARObject
Attribute Type Mult. Kind Note
doipInterface DoIpInterface * aggr DoIP node consists of one or several DoIPInterfaces over
which the ECU is able to communicate via DoIP
independently. I.e. DoIP functionalities on each IP
interface are isolated from each other.
logicAddress DoIpLogicAddress 0..1 aggr Describes the logical address of the DoIP entity, i.e. the
Local Address that will route diagnostic requests to the
Dcm of the DoIP entity.

Table 6.177: DoIpConfig

Class DoIpInterface
Package M2::AUTOSARTemplates::SystemTemplate::DoIP
Note A logical interface over which the DoIP Node is able to communicate via DoIP independently from other
existing DoIpInterfaces.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
aliveCheck TimeValue 0..1 attr This attribute defines the timeout in seconds for waiting
Response for response to an Alive Check request before the
Timeout connection is considered to be disconnected. Represents
parameter T_TCP_AliveCheck of ISO 13400-2:2012.
doipChannel DoIpTpConfig 0..1 ref Configuration of DoIPChannels available in an DoIp
Collection Interface. Each DoIPChannel describes a connection
between a doIpSourceAddress and a doIpTargetAddress
and the exchange of DcmIPdus between the PduR and
DoIP. A DoIP channel is constituted by the set of all DoIp
TpConnection elements via which the configured Ecu
Instance sends or receives SDUs that are sharing the
same local diagnosis address and tester address.
5

461 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class DoIpInterface
doipConnection SocketConnection * ref DoIP Connections in the DoIpInterface that define the Do
Bundle IP Pdus that are sent and received via SoAd over TCP or
UDP.
Tags:atp.Status=obsolete
doIpRouting DoIpRoutingActivation * aggr Collection of DoIpRoutingActivation possibilities defined
Activation in the DoIpInterface.
generalInactivity TimeValue 0..1 attr This attribute defines the timeout in seconds for maximum
Time inactivity of a TCP socket connection before the DoIP
module will close the according socket connection.
Represents parameter T_TCP_General_Inactivity of ISO
13400-2:2012
initialInactivity TimeValue 0..1 attr This attribute defines the timeout in seconds used for
Time initial inactivity of a connected TCP socket connection
directly after socket connection. Represents parameter
T_TCP_Initial_Inactivity of ISO 13400-2:2012
initialVehicle TimeValue 0..1 attr This attribute defines the waiting time in seconds for
Announcement sending first vehicle announcement message after IP
Time address assignment. Represents parameter A_DoIP_
Announce_Wait of ISO 13400-2:2012
isActivationLine Boolean 1 attr This attribute defines whether the network interface
Dependent
• is started "on-demand" when an activation line is
sensed or
• is always available.
maxTester PositiveInteger 0..1 attr Maximum amount of tester connections that shall be
Connections maintained at one time before alive check is performed.
socket StaticSocketConnection * ref DoIP Connections in the DoIpInterface that define the Do
Connection IP Pdus that are sent and received via SoAd over TCP or
UDP.
useMacAddress Boolean 0..1 attr This attribute defines whether a configured EID at vehicle
ForIdentification identification response/vehicle announcement is used or
the MAC address. TRUE: Use MAC Address instead of
EID for Vehicle identification/announcement. FALSE: Use
configured EID for vehicle identification/announcement.
useVehicle Boolean 0..1 attr This attribute defines if the optional VIN/GID
Identification synchronization status is used additionally in the vehicle
SyncStatus identification/announcement.
vehicle PositiveInteger 0..1 attr This attribute defines the number of vehicle
Announcement announcement messages on IP address assignment.
Count Represents parameter A_DoIP_Announce_Num of ISO
13400-2:2012.
vehicle TimeValue 0..1 attr This attribute defines the waiting time in seconds for
Announcement sending subsequent vehicle announcement messages.
Interval Represents parameter A_DoIP_Announce_Interval of
ISO 13400-2:2012

Table 6.178: DoIpInterface

Class DoIpRoutingActivation
Package M2::AUTOSARTemplates::SystemTemplate::DoIP
Note This meta-class defines a DoIP routing activation possibility that activates the routing to the referenced
doIPTargetAddress. This means that the diagnostic request messages related to the specified do
IPTargetAddress received by socketConnections that are referenced by the same DoIpInterface that
aggregates this DoIpRoutingActivation are activated.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
5

462 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class DoIpRoutingActivation
Attribute Type Mult. Kind Note
doIpTarget DoIpLogicTarget * ref Reference to DoIPTargetAddress which is activated on
Address AddressProps this DoIpRoutingActivation.

Table 6.179: DoIpRoutingActivation

The DoIpInterface defines DoIpChannels with the doipChannelCollection

reference that points to a DoIpTpConfig element that collects a number of DoIpTp-
Connections.
DoIpTpConnection describes a unidirectional connection between a doIp-
SourceAddress and a doIpTargetAddress and the exchange of a DcmIPdu that
is defined with the tpSdu between the PduR and DoIP. The DiagnosticConnection
with references to the DoIpTpConnection defines the related request and response
messages.
A DoIpChannel in the Ecu configuration is constituted by the set of all DoIpTpCon-
nection elements via which the EcuInstance that aggregates the DoIpConfig
that references the DoIpTpConnection via the DoIpInterface sends or receives
tpSdus that share the same local diagnosis address and tester address.

463 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

+functionalRequest
ARElement Referrable
FibexElement DiagnosticConnection 0..*
TpConnectionIdent
EcuInstance

+ comConfigurationGwTimeBase: TimeValue [0..1] +response

+ comConfigurationRxTimeBase: TimeValue [0..1]
0..1
+ comConfigurationTxTimeBase: TimeValue [0..1]
+ comEnableMDTForCyclicTransmission: Boolean [0..1]
+ ethSwitchPortGroupDerivation: Boolean [0..1] +responseOnEvent
+ pncPrepareSleepTimer: TimeValue [0..1]
+ pncSynchronousWakeup: Boolean [0..1] 0..1
+ pnResetTime: TimeValue [0..1]
+ sleepModeSupported: Boolean
+ v2xSupported: V2xSupportEnum [0..1] +physicalRequest
+ wakeUpOverBusSupported: Boolean
0..1

+ident 0..1

+doIpConfig 0..1
FibexElement
DoIpConfig TpConfig

TpConnection

+doipInterface 0..*

Identifiable
DoIpTpConfig +tpConnection DoIpTpConnection
DoIpInterface +doipChannelCollection
1..*
+ aliveCheckResponseTimeout: TimeValue [0..1] 0..1
+ generalInactivityTime: TimeValue [0..1]
+ initialInactivityTime: TimeValue [0..1]
+ initialVehicleAnnouncementTime: TimeValue [0..1]
+ isActivationLineDependent: Boolean
+ maxTesterConnections: PositiveInteger [0..1] +doIpSourceAddress 1 +doIpTargetAddress 1
+ useMacAddressForIdentification: Boolean [0..1]
Identifiable
+ useVehicleIdentificationSyncStatus: Boolean [0..1] +doIpLogicAddress
+ vehicleAnnouncementCount: PositiveInteger [0..1] DoIpLogicAddress
+ vehicleAnnouncementInterval: TimeValue [0..1] 0..*
+logicAddress + address: Integer

0..1

0..* +doIpRoutingActivation +doIpLogicAddressProps 0..1

Identifiable +doIpTargetAddress
Identifiable
DoIpLogicTargetAddressProps
DoIpRoutingActivation 0..* AbstractDoIpLogicAddressProps

+doIpTesterRoutingActivation
DoIpLogicTesterAddressProps
0..*

0..* +socketConnection Referrable

Identifiable SoConIPduIdentifier
StaticSocketConnection +iPduIdentifier
+ headerId: PositiveInteger [0..1]
+ tcpConnectTimeout: TimeValue [0..1] «atpVariation» 0..* + pduCollectionPduTimeout: TimeValue [0..1]
+ tcpRole: TcpRoleEnum [0..1] + pduCollectionSemantics: PduCollectionSemanticsEnum [0..1]
+ pduCollectionTrigger: PduCollectionTriggerEnum [0..1]

+pduTriggering 0..1
+tpSdu
Identifiable
PduTriggering 1

+periodicResponseUudt

0..*

Figure 6.53: DoIP

Diagnostic messages are passed from a tester, through a DoIP gateway to the internal
vehicle network. Before this happens the routing on a socket in the DoIP gateway
needs to be activated. The tester sends a routing activation request and the DoIP
entity responds to it. After the routing is activated the diagnostic communication starts.
[TPS_SYST_02303] Modeling of DoIpRoutingActivations dThe DoIP routing ac-
tivation possibilities in a DoIpInterface are described by the DoIpRoutingActi-
vation that is aggregated in the role doIpRoutingActivation in the DoIpInter-
face.c()

464 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class DoIpTpConfig
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note This element defines exactly one DoIpTp Configuration that is used to configure all DoIPChannels
available in a DoIpInterface. Each DoIPChannel describes a connection between a doIpSourceAddress
and a doIpTargetAddress and the exchange of DcmIPdus between the PduR and DoIP.
Tags:atp.recommendedPackage=TpConfigs
Base ARObject, CollectableElement, FibexElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable, TpConfig
Attribute Type Mult. Kind Note
doIpLogic DoIpLogicAddress * aggr Collection of logical DoIP Addresses.
Address
tpConnection DoIpTpConnection 1..* aggr Collection of unidirectional connections between a source
address and a target address.

Table 6.180: DoIpTpConfig

Class DoIpTpConnection
Package M2::AUTOSARTemplates::SystemTemplate::DiagnosticConnection
Note A connection identifies the sender and the receiver of this particular communication. The DoIp module
routes a tpSdu through this connection.
Base ARObject, TpConnection
Attribute Type Mult. Kind Note
doIpSource DoIpLogicAddress 1 ref Reference to the address of the sender of the tpSdu.
Address
doIpTarget DoIpLogicAddress 1 ref Reference to the address of the receiver of the tpSdu.
Address
tpSdu PduTriggering 1 ref This reference is used to describe the data exchange
between DoIp and the PduR.

Table 6.181: DoIpTpConnection

Class DoIpLogicAddress
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note The logical DoIP address.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
address Integer 1 attr The logical DoIP address.
doIpLogic AbstractDoIpLogic 0..1 aggr Collection of additional LogicAddress properties.
AddressProps AddressProps

Table 6.182: DoIpLogicAddress

Class AbstractDoIpLogicAddressProps (abstract)

Package M2::AUTOSARTemplates::SystemTemplate::DoIP
Note Abstract meta-class that collects common properties for all specialized DoIpLogicAddressProps.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Subclasses DoIpLogicTargetAddressProps, DoIpLogicTesterAddressProps
Attribute Type Mult. Kind Note
5

465 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class AbstractDoIpLogicAddressProps (abstract)
– – – – –
Table 6.183: AbstractDoIpLogicAddressProps

Class DoIpLogicTargetAddressProps
Package M2::AUTOSARTemplates::SystemTemplate::DoIP
Note This meta-class acts as a target for references to the DoIpLogicTargetAddress and collects DoIpLogic
TargetAddress specific settings.
Base ARObject, AbstractDoIpLogicAddressProps, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
– – – – –
Table 6.184: DoIpLogicTargetAddressProps

Class DoIpLogicTesterAddressProps
Package M2::AUTOSARTemplates::SystemTemplate::DoIP
Note This meta-class acts as a target for references to the DoIpLogicTesterAddress and collects DoIpLogic
TesterAddress specific settings.
Base ARObject, AbstractDoIpLogicAddressProps, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
doIpTester DoIpRoutingActivation * ref Reference to a DoIPRoutingActivation describing the
Routing possible routing activations of the DoIPTester.
Activation
Table 6.185: DoIpLogicTesterAddressProps

[constr_3212] Limitation of DoIpTpConnection.tpSdu dDoIpTpConnection shall

only reference PduTriggerings of DcmIPdus or UserDefinedIPdus in the role
tpSdu.c()
The diagnostic data is routed from the DoIP module to SoAd and back. The communi-
cation of diagnostic data over IP is described with StaticSocketConnections that
contain SoConIPduIdentifiers with references to PduTriggerings of Gener-
alPurposePdus of category DoIP.
Please note that there is no connection between GeneralPurposePdus of category
DoIP and the DoIpTpConnection in the System Description. The DoIP module eval-
uates the header of an incoming GeneralPurposePdu and knows from the included
information the further processing.

466 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Dcm

DcmIPdu

PduR

DcmIPdu
No formal description
On M2 of how to
DoIp convert between

GeneralPurposePdu of category DoIP

SoAd

Figure 6.54: Routing of Dcm Pdus in AUTOSAR Stack for communication over IP

The DoIpInterface.socketConnection defines which StaticSocketConnec-

tion belongs to which DoIpInterface.

6.7.5.14 Transport Layer Security

AUTOSAR supports the configuration of Transport Layer Security for the information
exchange between two sockets2 that are modeled as ApplicationEndpoints.
Please note that currently the DTLS (Datagram Transport Layer Security ) variant is
not supported on the AUTOSAR classic platform.
It is a common use case that only one end of a TLS-based connection is actually mod-
eled in an AUTOSAR model. The other end may exist off-board, e.g. as a diagnostic
tester.
It is therefore important that the modeling does not rely on or imply knowledge about
both ends of such a TLS-based connection.
An AUTOSAR model that only describes one end of the communication is positively
required to work, independently of the availability of a formal modeling of the other
end.
AUTOSAR provides two alternatives for modeling TLS in System Models:

2
TLS connections are - by design - limited to a 1:1 pattern. A 1:n or n:1 communication pattern is not
supported by TLS

467 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• Modeling using CryptoServicePrimitives (see section 6.7.5.14.1)

• Modeling using IANA [29] Parameters (see section 6.7.5.14.2).
ARElement
CryptoServicePrimitive

+ algorithmFamily: String [0..1]

+ algorithmMode: String [0..1]
+ algorithmSecondaryFamily: String [0..1]

+keyExchange 0..* +keyExchangeAuthentication 0..* +authentication 0..1 +encryption 0..1 +keyExchange 0..*

Identifiable
TlsCryptoCipherSuite

+ cipherSuiteId: PositiveInteger [0..1]

+ cipherSuiteShortLabel: String [0..1]
+ priority: PositiveInteger [0..1]
+ version: TlsVersionEnum

+tlsCipherSuite 0..*
Identifiable
SystemMapping
+certificate 0..1 +remoteCertificate 0..1

ARElement
CryptoServiceCertificate
«atpVariation,atpSplitable»
+ algorithmFamily: CryptoCertificateAlgorithmFamilyEnum [0..1]
+ format: CryptoCertificateFormatEnum [0..1] 0..* +cryptoServiceMapping
+ maximumLength: PositiveInteger [0..1] Identifiable
+ serverNameIdentification: String [0..1]
CryptoServiceMapping
+nextHigherCertificate 0..1

+pskIdentity 0..1

ARElement +tlsConnection
TlsPskIdentity TlsCryptoServiceMapping
TlsConnectionGroup
+ pskIdentity: String 0..* + useClientAuthenticationRequest: Boolean [0..1]
+ pskIdentityHint: String [0..1] + useSecurityExtensionRecordSizeLimit: Boolean [0..1]

+tlsCryptoMapping 0..1
+preSharedKey 1

ARElement Identifiable
CryptoServiceKey ApplicationEndpoint

+ algorithmFamily: String + maxNumberOfConnections: PositiveInteger [0..1]

+ keyGeneration: CryptoServiceKeyGenerationEnum [0..1] + priority: PositiveInteger [0..1]
+ keyStorageType: String [0..1]
+ length: PositiveInteger
«enumerati...
«enumeration» «enumeration» TlsVersionEnum
CryptoCertificateAlgorithmFamilyEnum CryptoCertificateFormatEnum
tls12
rsa x509 tls13
ecc cvc

Figure 6.55: Modeling of crypto infrastructure for Transport Layer Security

Class TlsCryptoServiceMapping
Package M2::AUTOSARTemplates::SystemTemplate::SecureCommunication
Note This meta-class has the ability to represent a crypto service mapping for the socket-based configuration
of Transport Layer Security (TLS).
Base ARObject, CryptoServiceMapping, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
keyExchange CryptoServicePrimitive * ref This reference identifies the shared(i.e. applicable for
each of the aggregated cipher suites) crypto service
primitive for the execution of key exchange during the
handshake phase.
tlsCipherSuite TlsCryptoCipherSuite * aggr This aggregation represents the collection of supported
cipher suites.
useClient Boolean 0..1 attr Defines if client authentication shall be applied for this
Authentication TLS connection.
Request
5

468 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class TlsCryptoServiceMapping
useSecurity Boolean 0..1 attr Defines if the security extension for max_fragment_length
Extension shall be supported as defined in IETF RFC 8449, chapter
RecordSize 4.1.
Limit
Table 6.186: TlsCryptoServiceMapping

The attribute TlsCryptoServiceMapping.useSecurityExtensionRecord-

SizeLimit is defining the behavior for IETF RFC 8449 [30].
A TLS connection is established between two communication endpoints that assume
the dedicated roles of server and client.
These roles cannot be swapped while the connection exists, i.e. a server remains the
server for the full amount of time the connection exists.
[TPS_SYST_05029] Semantics of meta-class TlsCryptoServiceMapping dAs
a sub-class of CryptoServiceMapping, meta-class TlsCryptoServiceMapping
has the ability to collect the TLS-related configuration aspects from either the perspec-
tive of the client or the server.
In the case of TLS, the collection boils down to the aggregation of meta-class
TlsCryptoCipherSuite in the role tlsCipherSuite plus the ability (by means
of the role keyExchange) to define handshake properties that are shared for each of
the aggregated tlsCipherSuites.c()
[constr_1670] Prohibition of usage of tlsCryptoMapping in case of UDP socket
connections dA TlsCryptoServiceMapping may only be referenced by an Ap-
plicationEndpoint in the role tlsCryptoMapping if that ApplicationEnd-
point aggregates a TcpTp in the role tpConfiguration.c()
[constr_1671] Supported values of TlsCryptoServiceMapping.category dThe
only supported values of attribute TlsCryptoServiceMapping.category are:
• TLS_SERVER: the TlsCryptoServiceMapping assumes the role of the server
in the TLS connection.
• TLS_CLIENT: the TlsCryptoServiceMapping assumes the role of the client
in the TLS connection.
c()
[constr_5319] TCP endpoint using TLS_SERVER role can only serve provided
service instances dAn ApplicationEndpoint that refers to TlsCryptoSer-
viceMapping with category TLS_SERVER in the role tlsCryptoMapping is only
allowed to be referenced by ProvidedServiceInstances in the role localUni-
castAddress in case that the ProvidedServiceInstance does not have a re-
moteUnicastAddress defined.c()

469 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_5320] TCP endpoint using TLS_CLIENT role can only serve consumed
service instances dAn ApplicationEndpoint that refers to TlsCryptoSer-
viceMapping with category TLS_CLIENT in the role tlsCryptoMapping is only
allowed to be referenced by ConsumedServiceInstances in the role localUni-
castAddress in case that the ConsumedServiceInstance does not have a re-
moteUnicastAddress defined.c()
The reason for [constr_5319] and [constr_5320] is that in the Service Discovery case
the TLS client needs to establish the TLS connection and a TCP endpoint can only take
one role: TLS_CLIENT or TLS_SERVER. If a TlsCryptoServiceMapping would act
as TLS_CLIENT and would refer to a ProvidedServiceInstance then this TLS_-
CLIENT would need to establish the TLS connection. But in this case the TLS_CLIENT
would not know to which remote service client a connection needs to be established
since different ConsumedServiceInstances may directly call methods of the Pro-
videdServiceInstance without any registration.
The usage of a cipher suite in the context of setting up a TLS connection is formalized
by means of meta-class TlsCryptoCipherSuite.
[TPS_SYST_05030] Semantics of TlsCryptoCipherSuite dThe creation of a TLS
connection requires the usage of a suite of cryptographic operations in specific roles,
also known as a cipher suite.
Meta-class TlsCryptoCipherSuite represents a given cipher suite for a TLS con-
nection. TlsCryptoCipherSuite references meta-class CryptoServicePrimi-
tive in three dedicated roles that represent the steps of the creation of a TLS connec-
tion.
More specifically, the cryptographic operations for setting up a TLS connection involve
the following steps:
• Key exchange: these CryptoServicePrimitives may be used for the hand-
shake phase of the TLS connection. Different alternatives exist for executing this
phase and therefore the multiplicity of this reference is 0..*.
• Authentication of communication partners during the operational phase of the
TLS connection. This part is similar to freshness calculation for SecOC-based
communication. For this purpose a single CryptoServicePrimitive is used
on each end of the communication.
• Encryption of content exchanged between the communication partners that
have established the TLS connection. For this purpose a single CryptoSer-
vicePrimitive is used on each end of the communication.
c()

470 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class TlsCryptoCipherSuite
Package M2::AUTOSARTemplates::SystemTemplate::SecureCommunication
Note This meta-class represents a cipher suite for describing cryptographic operations in the context of
establishing a connection of ApplicationEndpoints that is protected by TLS.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
authentication CryptoServicePrimitive 0..1 ref This reference identifies the crypto service primitive for
the generation and verification of MACs.
certificate CryptoService 0..1 ref This reference identifies the applicable local certificate.
Certificate
cipherSuiteId PositiveInteger 0..1 attr Identification of the CipherSuite according to the IANA
assignments list.
cipherSuite String 0..1 attr Name of the CipherSuite according to the IANA
ShortLabel assignments list.
ellipticCurve CryptoEllipticCurve * ref This references point to the properties of elliptic curves.
Props
encryption CryptoServicePrimitive 0..1 ref This reference identifies the crypto service primitive for
the execution of encryption.
keyExchange CryptoServicePrimitive * ref This reference identifies the individual (i.e. per cipher
suite) crypto service primitive for the execution of key
exchange during the handshake phase.
keyExchange CryptoServicePrimitive * ref This reference identifies the crypto service primitives for
Authentication the generation and verification of signatures during the
key exchange algorithm.
priority PositiveInteger 0..1 attr This attribute identifies the priority of the cipher suite.
Range: 1..65535. Lower values represent higher
priorities.
props TlsCryptoCipherSuite 0..1 aggr The aggregated TlsCryptoCipherSuiteProps provide
Props details for the TLS Cipher Suite.
pskIdentity TlsPskIdentity 0..1 aggr Pre-shared key identity shared during the handshake
among the communication parties, to establish a TLS
connection if the handshake is based on the existence of
a pre-shared key.
remote CryptoService 0..1 ref This reference identifies the applicable remote certificate.
Certificate Certificate
signature CryptoSignature * ref This reference points to the properties of a TLS Signature
Scheme Scheme Scheme.
version TlsVersionEnum 1 attr This attribute supports the definition of the applicable
version of TLS.

Table 6.187: TlsCryptoCipherSuite

Enumeration TlsVersionEnum
Package M2::AUTOSARTemplates::SystemTemplate::SecureCommunication
Note This meta-class has the ability to identify a specific version of the transport-layer security (TLS)
protocol.
Literal Description
tls12 TLS version 1.2
Tags:atp.EnumerationLiteralIndex=0
tls13 TLS version 1.3
Tags:atp.EnumerationLiteralIndex=2

Table 6.188: TlsVersionEnum

471 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class TlsPskIdentity
Package M2::AUTOSARTemplates::SystemTemplate::SecureCommunication
Note This element is used to describe the pre-shared key shared during the handshake among the
communication parties, to establish a TLS connection if the handshake is based on the existence of a
pre-shared key.
Base ARObject
Attribute Type Mult. Kind Note
preSharedKey CryptoServiceKey 1 ref This reference identifies the applicable cryptographic key.
pskIdentity String 1 attr This attribute provides the key identification.
pskIdentityHint String 0..1 attr This attribute provides the identity hint for a pre-shared
key.

Table 6.189: TlsPskIdentity

Class TlsCryptoCipherSuiteProps
Package M2::AUTOSARTemplates::SystemTemplate::SecureCommunication
Note This meta-class provides attributes to specify details of TLS Cipher Suites.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
tcpIpTlsUse Boolean 0..1 attr Defines if the security extension according to IETF RFC
Security 7366 shall be supported. This is useful for cipher suites
ExtensionForce using CBC mode.
EncryptThen
Mac
Table 6.190: TlsCryptoCipherSuiteProps

Class CryptoEllipticCurveProps
Package M2::AUTOSARTemplates::SystemTemplate::SecureCommunication
Note This meta-class provides attributes to specify the properties of elliptic curves.
Tags:atp.recommendedPackage=CryptoEllipticCurveProps
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
namedCurveId PositiveInteger 0..1 attr Defines the value of one specific NamedCurve Id.

Table 6.191: CryptoEllipticCurveProps

Class CryptoSignatureScheme
Package M2::AUTOSARTemplates::SystemTemplate::SecureCommunication
Note This meta-class provides attributes to specify the TLS Signature Scheme.
Tags:atp.recommendedPackage=CryptoSignatureSchemas
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
signature PositiveInteger 0..1 attr Defines the value of one specific TLS Signature Scheme.
SchemeId

Table 6.192: CryptoSignatureScheme

472 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_05031] Existence of TlsCryptoCipherSuite.keyExchange vs.

TlsCryptoServiceMapping.keyExchange dThe role TlsCryptoServiceMap-
ping.keyExchange has been introduced as an optimization.
It is assumed that the references for key exchange look pretty similar if not identical for
many concrete TlsCryptoCipherSuites.
Adding these references in an identical form to a bunch of TlsCryptoCipherSuites
does not really make sense. Therefore, TlsCryptoServiceMapping allows to de-
fine these references as well with the intention to make them valid for all TlsCryp-
toServiceMapping.tlsCipherSuite.
A mixture of references in the role TlsCryptoCipherSuite.keyExchange and
TlsCryptoServiceMapping.keyExchange is supported for the case of a given col-
lection of TlsCryptoCipherSuitesc()
[TPS_SYST_05032] Semantics of CryptoServiceCertificate dMeta-class
CryptoServiceCertificate represents a cryptographic certificate needed for the
creation of a TLS connection between server and client.c()
Class CryptoServiceCertificate
Package M2::AUTOSARTemplates::SystemTemplate::SecureCommunication
Note This meta-class represents the ability to model a cryptographic certificate.
Tags:atp.recommendedPackage=CryptoServiceCertificates
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
algorithmFamily CryptoCertificate 0..1 attr This attribute represents a description of the family of
AlgorithmFamilyEnum crypto algorithm used to generate public key and
signature of the cryptographic certificate.
format CryptoCertificateFormat 0..1 attr This attribute can be used to provide information about
Enum the format used to create the certificate
maximum PositiveInteger 0..1 attr This attribute represents the ability to define the
Length maximum length of the certificate.
nextHigher CryptoService 0..1 ref The reference identifies the next higher certificate in the
Certificate Certificate certificate chain.
serverName String 0..1 attr Server Name Indication (SNI) is needed if the IP address
Identification hosts multiple servers (on the same port), each of them
using a different certificate.
If the client sends the SNI to the Server in the client hello,
the server looks the SNI up in its certificate list and uses
the certificate identified by the SNI.

Table 6.193: CryptoServiceCertificate

Enumeration CryptoCertificateAlgorithmFamilyEnum
Package M2::AUTOSARTemplates::SystemTemplate::SecureCommunication
Note This meta-class defies possible cryptographic algorithm families used to create public keys and
signatures within the certificate.
Literal Description
5

473 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Enumeration CryptoCertificateAlgorithmFamilyEnum
ecc The cryptographic operations in the certificate are executed using elliptic curves (ecc)
Tags:atp.EnumerationLiteralIndex=2
rsa The cryptographic operations in the certificate are executed using the RSA approach.
Tags:atp.EnumerationLiteralIndex=1

Table 6.194: CryptoCertificateAlgorithmFamilyEnum

Enumeration CryptoCertificateFormatEnum
Package M2::AUTOSARTemplates::SystemTemplate::SecureCommunication
Note This meta-class defines possible formats of cryptographic certificates.
Literal Description
cvc The certificate has been created in Card Verifiable Certificate (CVC) format
Tags:atp.EnumerationLiteralIndex=2
x509 The certificate is created in X.509 format.
Tags:atp.EnumerationLiteralIndex=1

Table 6.195: CryptoCertificateFormatEnum

[constr_1672] Existence of TlsCryptoCipherSuite.certificate and

TlsCryptoCipherSuite.pskIdentity in the server role dEither
• the reference to CryptoServiceCertificate in the role TlsCryptoCi-
pherSuite.certificate
• the aggregation of TlsPskIdentity in the role TlsCryptoCipherSuite.
pskIdentity
shall exist if the TlsCryptoCipherSuite is aggregated by a TlsCryptoSer-
viceMapping that has attribute category set to the value TLS_SERVER.c()
In other words two different approaches are supported by TLS for the handling of key
exchange: Pre-shared secret and certificate.
The server may optionally request a certificate from the client. If this option is not used
then other documented approaches for completing the handshake phase are foreseen
for the specific case.
[TPS_SYST_05033] Existence of TlsCryptoCipherSuite.certificate and
TlsCryptoCipherSuite.pskIdentity in the client role dThe client (TlsCryp-
toServiceMapping has the attribute category set to the value TLS_CLIENT) has
the following authentication options:
• the reference to CryptoServiceCertificate in the role TlsCryptoCi-
pherSuite.certificate exists,
• the aggregation of TlsPskIdentity in the role TlsCryptoCipherSuite.
pskIdentity exists,

474 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• neither TlsCryptoCipherSuite.certificate nor TlsCryptoCipher-

Suite.pskIdentity exists and TlsCryptoServiceMapping.useClien-
tAuthenticationRequest is set to false. In this case the handshake is pro-
vided on the basis of the server certificate only.
c()
In the pre-shared Key approach the client indicates which key to use by includ-
ing a pskIdentity in the ClientKeyExchange message. To help the client in se-
lecting which identity to use, the server can provide a pskIdentityHint in the
ServerKeyExchange message. Please note that the usage of pskIdentityHints
is restricted for usage with TLS 1.2.
ARElement
Identifiable CryptoSignatureScheme
TlsCryptoCipherSuiteProps
+ signatureSchemeId:
+ tcpIpTlsUseSecurityExtensionForceEncryptThenMac: Boolean [0..1] PositiveInteger [0..1]

+props 0..1 +signatureScheme 0..*

Identifiable ARElement
TlsCryptoCipherSuite +ellipticCurve CryptoEllipticCurveProps

+ cipherSuiteId: PositiveInteger [0..1] 0..* + namedCurveId:

+ cipherSuiteShortLabel: String [0..1] PositiveInteger [0..1]
+ priority: PositiveInteger [0..1]
+ version: TlsVersionEnum

+tlsCipherSuite 0..*
Identifiable
SystemMapping
+certificate 0..1 +remoteCertificate 0..1

ARElement
CryptoServiceCertificate
«atpVariation,atpSplitable»
+ algorithmFamily: CryptoCertificateAlgorithmFamilyEnum [0..1]
+ format: CryptoCertificateFormatEnum [0..1] +cryptoServiceMapping 0..*
+ maximumLength: PositiveInteger [0..1]
Identifiable
+ serverNameIdentification: String [0..1]
CryptoServiceMapping
+nextHigherCertificate 0..1

0..1 +pskIdentity
ARElement +tlsConnection
TlsPskIdentity TlsCryptoServiceMapping
TlsConnectionGroup
+ pskIdentity: String 0..* + useClientAuthenticationRequest: Boolean [0..1]
+ pskIdentityHint: String [0..1] + useSecurityExtensionRecordSizeLimit: Boolean [0..1]

+preSharedKey 1
+tlsCryptoMapping 0..1
ARElement
CryptoServiceKey Identifiable
+ algorithmFamily: String ApplicationEndpoint
+ keyGeneration: CryptoServiceKeyGenerationEnum [0..1]
+ maxNumberOfConnections: PositiveInteger [0..1]
+ keyStorageType: String [0..1]
+ priority: PositiveInteger [0..1]
+ length: PositiveInteger

Figure 6.56: Modeling of crypto infrastructure for Transport Layer Security

AUTOSAR provides two alternatives for modeling TLS in System Models:

6.7.5.14.1 Modeling TLS using CryptoServicePrimitives

Instances of TlsCryptoServiceMapping and TlsCryptoCipherSuite allow to

refer to CryptoServicePrimitives via
• TlsCryptoServiceMapping.keyExchange
• TlsCryptoCipherSuite.keyExchange

475 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• TlsCryptoCipherSuite.keyExchangeAuthentication
• TlsCryptoCipherSuite.authentication
• TlsCryptoCipherSuite.encryption.
Setting up these references to CryptoServicePrimitives with specific properties
allows to define how a TLS Connection and its associated TLS cipher suites are work-
ing by defining the CryptoServicePrimitive they employ. Instances of the Cryp-
toServicePrimitive class directly map to CsmPrimitive containers in the Csm
configuration, which makes the translation into Csm configurations straightforward.
Using CryptoServicePrimitive elements for modeling TLS, however, makes it
hard to infer what a TLS Connection and its associated TLS cipher suites are from the
information how they work. It is, for instance, difficult to determine the IANA id [29]
of a TLS cipher suite by examining the properties of the CryptoServicePrimitive
elements the associated TlsCryptoCipherSuite is referencing.
Defining CryptoServicePrimitive elements couples the TLS configuration of the
System Model tightly to the Csm module configuration which demands deep knowl-
edge of the Csm for setting up the TLS part of the system model. Moreover, software
suppliers might deviate from the Csm standard when it comes to the configuration of
CsmPrimitive containers. As a consequence, two stack vendors might require differ-
ently configured CryptoServicePrimitive elements for modeling the same cipher
suite.
For all these shortcomings, it is recommended to define TLS connections that use
standard cipher suites by defining IANA parameters [29] instead of referencing to
CryptoServicePrimitives . Defining CryptoServicePrimitives can be the
solution to model non-standard cipher suites, however they still require custom support
from vendors.

6.7.5.14.2 Modeling TLS using IANA Parameters

IANA provides a set of TLS Parameters [29] to specify the properties of standardized
cipher suites, which are partly also available in the TLS part of AUTOSAR System
Models:
• TlsCryptoCipherSuite.cipherSuiteId
• TlsCryptoCipherSuite.cipherSuiteShortLabel
and, if the cipher suite requires key exchange:
• CryptoEllipticCurveProps.namedCurveId
• CryptoSignatureScheme.signatureSchemeId.

476 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

The specification of these parameters defines what a TLS Connection and their cipher
suites are in contrast to the first approach which defines how they operate. The spec-
ification of a standardized cipher suite allows to derive the CsmPrimitives required
for its operation without tight coupling to the specifics of the Csm configuration.
[constr_3668] Existence of TlsCryptoCipherSuite.cipherSuiteShortLabel
dIf a TlsCryptoCipherSuite.cipherSuiteShortLabel is defined then:
• the attribute TlsCryptoCipherSuite.cipherSuiteId shall be defined as
well
• the value of TlsCryptoCipherSuite.cipherSuiteShortLabel shall match
the Description value corresponding to the Value field defined in TlsCryptoCi-
pherSuite.cipherSuiteId according to TlsCryptoCipherSuite Parame-
ter set defined in [29].
c()
Common parameters:
The TLS part of the system model specifies a set of entities and parameters that can
be configured in both alternatives. They allow the definition of certificates or pre-shared
Keys which the cipher suites are using and the definition of extensions e.g. for increas-
ing the security of a TLS connection:
• TlsCryptoCipherSuite.priority
• TlsCryptoCipherSuite.version
• TlsCryptoCipherSuite.pskIdentity
• TlsCryptoCipherSuite.certificate
• TlsCryptoCipherSuite.remoteCertificate
• TlsCryptoServiceMapping.useClientAuthenticationRequest
• TlsCryptoServiceMapping.useSecurityExtensionRecordSizeLimit
• All parameters specified in TlsCryptoCipherSuiteProps.
For Details on TlsCryptoCipherSuite.cipherSuiteId and TlsCryptoCi-
pherSuite.cipherSuiteShortLabel see [29] section "TLS Cipher Suites".
For Details on CryptoEllipticCurveProps and namedCurveId see [29] section
"TLS Supported Groups".
For Details on CryptoSignatureScheme and signatureSchemeId see [29] sec-
tion "TLS SignatureScheme".

477 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.7.5.15 IPsec

IPsec is a protocol suite that provides cryptographic protection for IP datagrams in IPv4
and IPv6 network packets.
IPsec uses a security association to specify security properties that are shared be-
tween the communicating parties. The security association defines a relationship be-
tween two or more parties and determines which security services will be used to
communicate securely. In other words the security association serves as a “contract”
between the different devices.
A single security association protects data in one communication direction. Two se-
curity associations shall be present to secure traffic in both directions. Each security
association can provide encryption, data integrity and data authentication.
In addition the senders and receivers of IP datagrams can determine the required
protection for an IP packet according to IPsec security policies.
These are rules that define how datagrams are processed that are received by a device.
For example, security policies are used to decide if a particular packet needs to be
dropped or needs to be processed by IPsec.

478 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Identifiable
NetworkEndpointAddress
NetworkEndpoint +networkEndpointAddress

+ fullyQualifiedDomainName: String [0..1] 1..*

+ priority: PositiveInteger [0..1]

+remoteIpAddress 0..*

+ipSecConfig 0..1

IPSecConfig Ipv6Configuration

+ assignmentPriority: PositiveInteger [0..1]

+ defaultRouter: Ip6AddressString [0..1]
+ dnsServerAddress: Ip6AddressString [0..*]
+ enableAnycast: Boolean [0..1]
+ hopCount: PositiveInteger [0..1]
+ ipAddressKeepBehavior: IpAddressKeepEnum [0..1]
+ipSecRule 0..* + ipAddressPrefixLength: PositiveInteger [0..1]
Identifiable + ipv6Address: Ip6AddressString [0..1]
+ ipv6AddressSource: Ipv6AddressSourceEnum [0..1]
IPSecRule

+ direction: CommunicationDirectionType [0..1]

+ headerType: IPsecHeaderTypeEnum [0..1] Ipv4Configuration
+ ipProtocol: IPsecIpProtocolEnum [0..1]
+ localId: String [0..1] + assignmentPriority: PositiveInteger [0..1]
+ localPortRangeEnd: PositiveInteger [0..1] + defaultGateway: Ip4AddressString [0..1]
+ localPortRangeStart: PositiveInteger [0..1] + dnsServerAddress: Ip4AddressString [0..*]
+ mode: IPsecModeEnum [0..1] + ipAddressKeepBehavior: IpAddressKeepEnum [0..1]
+ policy: IPsecPolicyEnum [0..1] + ipv4Address: Ip4AddressString [0..1]
+ priority: PositiveInteger [0..1] + ipv4AddressSource: Ipv4AddressSourceEnum [0..1]
+ remoteId: String [0..1] + networkMask: Ip4AddressString [0..1]
+ remotePortRangeEnd: PositiveInteger [0..1] + ttl: PositiveInteger [0..1]
+ remotePortRangeStart: PositiveInteger [0..1]

ARElement
IPSecConfigProps

+localCertificate 0..* +remoteCertificate 0..* + ahCipherSuiteName: String [0..*]

+ dpdAction: IPsecDpdActionEnum [0..1]
ARElement + dpdDelay: TimeValue [0..1]
+ipSecConfigProps
CryptoServiceCertificate + espCipherSuiteName: String [0..*]
0..1 + ikeCipherSuiteName: String [0..1]
+ algorithmFamily: + ikeOverTime: TimeValue [0..1]
CryptoCertificateAlgorithmFamilyEnum [0..1] + ikeRandTime: PositiveInteger [0..1]
+ format: CryptoCertificateFormatEnum [0..1] + ikeReauthTime: TimeValue [0..1]
+ maximumLength: PositiveInteger [0..1] + ikeRekeyTime: TimeValue [0..1]
+ serverNameIdentification: String [0..1] + saOverTime: PositiveInteger [0..1]
+ saRandTime: TimeValue [0..1]
+nextHigherCertificate 0..1
+ saRekeyTime: TimeValue [0..1]

+preSharedKey 0..1
«enumeration» ARElement
IPsecHeaderTypeEnum
CryptoServiceKey
ah
esp + algorithmFamily: String
none + keyGeneration: CryptoServiceKeyGenerationEnum [0..1]
+ keyStorageType: String [0..1]
+ length: PositiveInteger
«enumerati... «enumeration»
«enumeration» IPsecPolicyEnum IPsecIpProtocolEnum
IPsecDpdActionEnum «enumeration» «enumeration»
ipsec udp
CommunicationDirectionType IPsecModeEnum tcp
clear passthrough
trap drop in any
tunnel
restart reject out icmp
transport

Figure 6.57: IPsec configuration model

[TPS_SYST_02265] Configuration of IPsec dThe IPSecConfig meta-class that is

aggregated by a NetworkEndpoint in the role ipSecConfig provides the ability to
define IPsec settings that are necessary to configure IPsec security associations and
IPsec security policies.c()
[TPS_SYST_02266] Definition of IPSecRules dThe IPSecConfig meta-class may
contain one or several IPSecRules. Each IPSecRule defines the network connec-
tion that is monitored by IPsec by defining the local endpoint and the remote endpoint.
Each endpoint is defined by the IP Address and the Tcp/Udp Port. The communication
direction for which the IPSecRule is valid is defined by the direction attribute.c()

479 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class IPSecConfig
Package M2::AUTOSARTemplates::SystemTemplate::SecureCommunication
Note IPsec is a protocol that is designed to provide "end-to-end" cryptographically-based security for IP
network connections.
Base ARObject
Attribute Type Mult. Kind Note
ipSecConfig IPSecConfigProps 0..1 ref Global IPsec configuration settings that are valid for all
Props IPSecRules that are defined on the NetworkEndpoint.
ipSecRule IPSecRule * aggr IPSec rules and filters that are defined in the IPSecConfig
for a specific NetworkEndpoint.

Table 6.196: IPSecConfig

Class IPSecRule
Package M2::AUTOSARTemplates::SystemTemplate::SecureCommunication
Note This element defines an IPsec rule that describes communication traffic that is monitored, protected and
filtered.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
direction Communication 0..1 attr This attribute defines the direction in which the traffic is
DirectionType monitored. If this attribute is not set a bidirectional traffic
monitoring is assumed.
headerType IPsecHeaderTypeEnum 0..1 attr Header type specifying the IPsec security mechanism.
ipProtocol IPsecIpProtocolEnum 0..1 attr This attribute defines the relevant IP protocol used in the
Security Policy Database (SPD) entry.
localCertificate CryptoService * ref This reference identifies the applicable certificate used for
Certificate a local authentication.
localId String 0..1 attr This attribute defines how the local participant should be
identified for authentication.
localPortRange PositiveInteger 0..1 attr This attribute restricts the traffic monitoring and defines
End an end value for the local port range.
If this attribute is not set then this rule shall be effective
for all local ports.
Please note that port ranges are currently not supported
in the AUTOSAR AP’s operating system backend. If AP
systems are involved, each IPsec rule may only contain a
single port.
localPortRange PositiveInteger 0..1 attr This attribute restricts the traffic monitoring and defines a
Start start value for the local port range.
If this attribute is not set then this rule shall be effective
for all local ports.
Please note that port ranges are currently not supported
in the AUTOSAR AP’s operating system backend. If AP
systems are involved, each IPsec rule may only contain a
single port.
mode IPsecModeEnum 0..1 attr This attribute defines the type of the connection.
policy IPsecPolicyEnum 0..1 attr An IPsec policy defines the rules that determine which
type of IP traffic needs to be secured using IPsec and
how that traffic is secured.
preSharedKey CryptoServiceKey 0..1 ref This reference identifies the applicable cryptograhic key
used for authentication.
priority PositiveInteger 0..1 attr This attribute defines the priority of the IPSecRule (SPD
entry). The processing of entries is based on priority,
starting with the highest priority "0".
5

480 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class IPSecRule
remote CryptoService * ref This reference identifies the applicable certificate used for
Certificate Certificate a remote authentication.
remoteId String 0..1 attr This attribute defines how the remote participant should
be identified for authentication.
remoteIp NetworkEndpoint * ref Definition of the remote NetworkEndpoint. With this
Address reference the connection between the local Network
Endpoint and the remote NetworkEndpoint is described
on which the traffic is monitored.
remotePort PositiveInteger 0..1 attr This attribute restricts the traffic monitoring and defines
RangeEnd an end value for the remote port range.
If this attribute is not set then this rule shall be effective
for all local ports.
Please note that port ranges are currently not supported
in the AUTOSAR AP’s operating system backend. If AP
systems are involved, each IPsec rule may only contain a
single port.
remotePort PositiveInteger 0..1 attr This attribute restricts the traffic monitoring and defines a
RangeStart start value for the remote port range.
If this attribute is not set then this rule shall be effective
for all local ports.
Please note that port ranges are currently not supported
in the AUTOSAR AP’s operating system backend. If AP
systems are involved, each IPsec rule may only contain a
single port.

Table 6.197: IPSecRule

Class IPSecConfigProps
Package M2::AUTOSARTemplates::SystemTemplate::SecureCommunication
Note This element holds all the attributes for configuration of IPsec that are independent of specific IPsec rules.
Tags:atp.recommendedPackage=IPSecConfigProps
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
ahCipherSuite String * attr AH (Authentication Header) algorithm to be used for the
Name connection, e.g. HMAC/SHA2-256
dpdAction IPsecDpdActionEnum 0..1 attr This attribute defines what to do if the peer is considered
dead.
If not configured "restart" shall be assumed.
dpdDelay TimeValue 0..1 attr This attribute describes the interval to check the liveness
of a peer actively using IKEv2 INFORMATIONAL
exchanges. Active DPD checking is only enforced if no
IKE or ESP/AH packet has been received for the
configured DPD delay.
In not configured the value "5 minutes" shall be assumed.
espCipherSuite String * attr ESP (Encapsulating Security Payload) algorithm that
Name provides encryption and optional authentication for the
connection, e.g. AES-128+SHA2-256.
ikeCipherSuite String 0..1 attr IKE encryption/authentication algorithms to be used for
Name the connection.
5

481 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class IPSecConfigProps
ikeOverTime TimeValue 0..1 attr This attribute describes the hard deadline when an SA
becomes invalid in percentage.
Example: ikeOverTime of max(ikeReauthTime, ikeRekey
Time).
Default: 10 %
ikeRandTime PositiveInteger 0..1 attr This attribute defines in percentage by how long before
the expiration of ikeReauthTime and ikeRekeyTime will be
rekeyed/reauthenticated.
Default: 10%
ikeReauthTime TimeValue 0..1 attr This attribute defines the absolute time after which an IKE
SA will be reauthenticated.
0 means reauthentication is disabled.
ikeRekeyTime TimeValue 0..1 attr This attribute defines the absolute time after which an IKE
SA will be rekeyed.
0 means rekey is disabled.
saOverTime PositiveInteger 0..1 attr This attribute describes the hard deadline when an IPsec
SA becomes invalid in percentage.
Example: saOverTime * saRekeyTime.
Default: 110%
saRandTime TimeValue 0..1 attr This attribute defines by how long before the expiration of
saRekeyTime will be rekeyed.
saRekeyTime TimeValue 0..1 attr This attribute defines the absolute time after which an
IPsec SA will be rekeyed.
0 means rekey is disabled.

Table 6.198: IPSecConfigProps

Enumeration IPsecIpProtocolEnum
Package M2::AUTOSARTemplates::SystemTemplate::SecureCommunication
Note Definition of supported TcpIp protocols that are supported in Security Policy Database (SPD) entries
in IPSec configurations.
Literal Description
any ANY protocol
Tags:atp.EnumerationLiteralIndex=3
icmp Internet Control Message Protocol (ICMP)
Tags:atp.EnumerationLiteralIndex=2
tcp TCP Protocol
Tags:atp.EnumerationLiteralIndex=1
udp UDP Protocol
Tags:atp.EnumerationLiteralIndex=0

Table 6.199: IPsecIpProtocolEnum

[TPS_SYST_02270] Definition of general IPsec configuration settings dGeneral

configuration properties that are independent of particular IPSecRules are collected
in the IPSecConfigProps element that is referenced from the IPSecConfig in the
role ipSecConfigProps.c()

482 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_02267] IPsec policy dThe IPSecRule.policy attribute defines how IP

packets are handled that are going over the network connection defined by the IPSe-
cRule. In detail it defines whether the IP packet is processed by IPsec or not.c()
Enumeration IPsecPolicyEnum
Package M2::AUTOSARTemplates::SystemTemplate::SecureCommunication
Note Defines the filter actions that are supported by IPsec.
Literal Description
drop Signifying that packets should be discarded
Tags:atp.EnumerationLiteralIndex=3
ipsec Signifying that packets should be protected.
Tags:atp.EnumerationLiteralIndex=1
passthrough Signifying that no IPsec processing should be done at all.
Tags:atp.EnumerationLiteralIndex=2
reject Signifying that packets should be discarded and a diagnostic ICMP returned.
Tags:atp.EnumerationLiteralIndex=4

Table 6.200: IPsecPolicyEnum

IPsec can be configured to operate in two different modes, Tunnel and Transport mode.
With tunnel mode, the entire IP packet is protected by IPsec. IPsec wraps the original
packet, encrypts it and adds a new IP header to it. The tunnel mode is most com-
monly used between VPN gateways and the IP addresses of the newly added outer IP
header are that of the VPN Gateways. In other words the traffic between the two VPN
Gateways is protected and each gateway acts as a proxy for the hosts behind it.
The transport mode provides the protection of the Data Payload of the IP datagram
with an AH or ESP header. The IP Header remains the same and IPsec inserts its
header between the IP header and the upper level headers. The IPsec transport mode
can be used when securing traffic between two hosts or between a host and a VPN
gateway.
[TPS_SYST_02268] IPsec mode dThe IPSecRule.mode attribute defines whether
the IP packet is processed in the transport or tunnel mode.c()
Please note that AUTOSAR currently supports only the transport mode as configu-
ration option.
Enumeration IPsecModeEnum
Package M2::AUTOSARTemplates::SystemTemplate::SecureCommunication
Note This enumeration describes the supported IPSec modes.
Literal Description
transport Signifying that the IPSec transport mode is used. With the transport mode the original IP header is
retained and only the IP payload and ESP trailer is encrypted.
Tags:atp.EnumerationLiteralIndex=1
5

483 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Enumeration IPsecModeEnum
tunnel Signifying that the IPSec tunnel mode is used. With tunnel mode, the entire original IP packet is
protected by IPSec. This means IPSec wraps the original packet, encrypts it, adds a new IP header
and sends it to the other side.
Tags:atp.EnumerationLiteralIndex=0

Table 6.201: IPsecModeEnum

IPsec uses two protocols:

• AH - Authentication Header
• ESP - Encapsulating Security Payload
The AH protocol provides a mechanism for authentication only and authenticates the
entire IP packet, including the outer IP header.
The ESP protocol provides data confidentiality (encryption) and/or authentication (data
integrity, data origin authentication, and replay protection).
When ESP is used in transport mode, the IP payload is encrypted and the original IP
header is moved to the front of the message. The ESP header is inserted after the
IP header and is signed together with the IP payload. The original IP header remains
unprotected.
When ESP is used in tunnel mode a new IP Header is created and the ESP header is
added in front of the original IP Packet. The entire original IP packet is encrypted and
signed in this mode.
[TPS_SYST_02269] IPsec AH and ESP protocol configuration dIn the IPSecRule
it is possible to define the IPsec protocol that shall be used to protect IP packets that
are going over the defined network connection. The attribute headerType defines
whether AH, ESP or neither one is used.c()
Enumeration IPsecHeaderTypeEnum
Package M2::AUTOSARTemplates::SystemTemplate::SecureCommunication
Note IPsec Header Type options
Literal Description
ah Authentication Header (AH)
Tags:atp.EnumerationLiteralIndex=0
esp Encapsulating Security Payloads (ESP)
Tags:atp.EnumerationLiteralIndex=1
none No header
Tags:atp.EnumerationLiteralIndex=2

Table 6.202: IPsecHeaderTypeEnum

[TPS_SYST_02271] IPsec AH and ESP CipherSuites dThe attributes ahCipher-

SuiteName and espCipherSuiteName define the supported AH and ESP algo-
rithms.c()

484 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

The naming convention for ahCipherSuiteName, espCipherSuiteName and

IPSecConfigProps.ikeCipherSuiteName shall follow the naming convention for
cryptographic primitives that is defined in [31].
[TPS_SYST_02272] IPsec Internet Key Exchange protocol configuration dIn the
IPSecRule it is possible to define how IKE protocol authenticates the remote party
and how the local party authenticates itself to the remote party. In other words both
sides use the same method. The usage of the IPSecRule.preSharedKey reference
defines that the pre-shared key is used. The usage of the IPSecRule.localCer-
tificate and IPSecRule.remoteCertificate defines that Digital Signature Au-
thentication is used.c()
[constr_5163] Existence of attribute IPSecRule.headerType dFor each IPSe-
cRule, the attribute headerType shall exist at the time when the COM Stack is gen-
erated.c()
[constr_5164] Existence of attribute IPSecRule.ipProtocol dFor each IPSe-
cRule, the attribute ipProtocol shall exist at the time when the COM Stack is gen-
erated.c()
[constr_5165] Existence of attribute IPSecRule.policy dFor each IPSecRule,
the attribute policy shall exist at the time when the COM Stack is generated.c()
Please note that the supported IKE CipherSuites are configured with the IPSec-
ConfigProps.ikeCipherSuiteName. The IPSecConfigProps contains addi-
tional IKE specific configuration settings.
Enumeration IPsecDpdActionEnum
Package M2::AUTOSARTemplates::SystemTemplate::SecureCommunication
Note Potential Dead Peer Detection (Dpd) Actions
Literal Description
clear Deletes the SA.
Tags:atp.EnumerationLiteralIndex=0
restart Immediately tries to establish the connection.
Tags:atp.EnumerationLiteralIndex=2
trap tries to establish the connection after traffic is sent to the peer.
Tags:atp.EnumerationLiteralIndex=1

Table 6.203: IPsecDpdActionEnum

[TPS_SYST_02273] Protection of ProvidedServiceInstance by IPsec dTo de-

scribe the protection of an ProvidedServiceInstance by IPsec the Provided-
ServiceInstance needs to point to an ApplicationEndpoint in the localUni-
castAddress role and this ApplicationEndpoint shall point to a NetworkEnd-
point that aggregates the IPSecConfig and describes the IPsec Security Associa-
tions.c()

485 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_02274] Protection of ConsumedServiceInstance by IPsec dTo de-

scribe the protection of an ConsumedServiceInstance by IPsec the Consumed-
ServiceInstance needs to point to an ApplicationEndpoint in the localUni-
castAddress role and this ApplicationEndpoint shall point to a NetworkEnd-
point that aggregates the IPSecConfig and describes the IPsec Security Associa-
tions.c()
Please note that IP Multicast protection by IPsec is not supported.

6.7.5.16 EthernetFrameType based communication

Please note that with the introduction of the TcpIp Bsw module the description of Ab-
stractEthernetFrames is no longer necessary for configuration of the AUTOSAR
TcpIp Stack.
Nevertheless it may be useful to describe the Ethernet FrameType based communica-
tion in some cases, e.g. if a new basic software module like Ieee1722Tp is used that
is located above the EthDrv and parallel to the TcpIp Stack. The Ethernet FrameType
based communication shall be described without Pdus.
[constr_3113] AbstractEthernetFrame shall not have a PduToFrameMapping
dIt is not allowed to map Pdus into AbstractEthernetFrames.c()
Identifiable
EthernetFrameTriggering
FrameTriggering

+frame 1

FibexElement
AbstractEthernetFrame
Frame

+ frameLength: Integer [0..1]

GenericEthernetFrame UserDefinedEthernetFrame

Ieee1722TpEthernetFrame

+ relativeRepresentationTime: TimeValue
+ streamIdentifier: PositiveInteger
+ subType: PositiveInteger
+ version: PositiveInteger

Figure 6.58: EthernetFrameType based communication

Class AbstractEthernetFrame (abstract)

Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetFrame
Note Ethernet specific attributes to the Frame.
5

486 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class AbstractEthernetFrame (abstract)
Base ARObject, CollectableElement, FibexElement, Frame, Identifiable, MultilanguageReferrable,
PackageableElement, Referrable
Subclasses GenericEthernetFrame, Ieee1722TpEthernetFrame, UserDefinedEthernetFrame
Attribute Type Mult. Kind Note
– – – – –
Table 6.204: AbstractEthernetFrame

Class EthernetFrameTriggering
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetFrame
Note Ethernet specific Frame element.
Base ARObject, FrameTriggering, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
– – – – –
Table 6.205: EthernetFrameTriggering

Class GenericEthernetFrame
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetFrame
Note This element is used for EthernetFrames without additional attributes that are routed by the EthIf.
Tags:atp.recommendedPackage=Frames
Base ARObject, AbstractEthernetFrame, CollectableElement, FibexElement, Frame, Identifiable,
MultilanguageReferrable, PackageableElement, Referrable
Attribute Type Mult. Kind Note
– – – – –
Table 6.206: GenericEthernetFrame

Class UserDefinedEthernetFrame
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetFrame
Note UserDefinedEthernetFrame allows the description of a frame-based communication to Complex Drivers
that are located above the EthDrv.
Tags:atp.recommendedPackage=Frames
Base ARObject, AbstractEthernetFrame, CollectableElement, FibexElement, Frame, Identifiable,
MultilanguageReferrable, PackageableElement, Referrable
Attribute Type Mult. Kind Note
– – – – –
Table 6.207: UserDefinedEthernetFrame

Class Ieee1722TpEthernetFrame
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetFrame
Note Ieee1722Tp Ethernet Frame
Tags:atp.recommendedPackage=Frames
Base ARObject, AbstractEthernetFrame, CollectableElement, FibexElement, Frame, Identifiable,
MultilanguageReferrable, PackageableElement, Referrable
5

487 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class Ieee1722TpEthernetFrame
Attribute Type Mult. Kind Note
relative TimeValue 1 attr Defines the time when content shall be presented (in
Representation seconds). The actual absolute time is creation time plus
Time relative presentation time
streamIdentifier PositiveInteger 1 attr IEEE 1722 stream identifier.
subType PositiveInteger 1 attr Protocol type.
version PositiveInteger 1 attr Revision of Ieee1722 standard.

Table 6.208: Ieee1722TpEthernetFrame

6.7.5.17 Restriction in usage of ProvidedServiceInstance.majorVersion

If several ProvidedServiceInstances are defined with the same serviceIden-

tifier and different majorVersions and these ProvidedServiceInstances are
referencing the same ApplicationEndpoint with the localUnicastAddress (
ProvidedServiceInstances are located on the same Socket) then particular re-
strictions apply for the system configuration.
In such a scenario the same MessageId (headerId) may be used for ServiceIn-
terface elements like an Event in the different ProvidedServiceInstances that
have different majorVersions. It may happen that the same headerId is used for
Pdus that represent the same ServiceInterface element even if the Pdu layout dif-
fers in the different MajorVersion ProvidedServiceInstances because for exam-
ple the dataType of the Service Interface element was changed from one MajorVersion
to the other.
The reason for these restrictions is the AUTOSAR Architecture in the Classic Plat-
form where one part of the SOME/IP Header is evaluated in the SOME/IP Transformer
(RequestId, Protocol Version, Interface Version, Message Type, Return Code) and the
other part in the SocketAdaptor (MessageId, Length). This means that the Socket
Adaptor is not able to evaluate the MajorVersion in the Pdu.
The following restrictions apply in case of ClientServer communication (Service In-
terface Methods, Field Getter, Field Setter): If two or more ProvidedServiceIn-
stances are defined using the same serviceIdentifier and different majorVer-
sions and these ProvidedServiceInstances are referencing the same Appli-
cationEndpoint via localUnicastAddress then the destination IP address, the
destination port number, and the Level 4 protocol (Udp/Tcp) fields of header of IP
packets containing call PDUs that are sent to the ProvidedServiceInstances are
identical. In such a scenario, the ProvidedServiceInstances may still use identi-
cal method Ids (thus identical Header Ids) if the following condition applies:
At any point in time only one of the ProvidedServiceInstances is active, and only
clients of that ProvidedServiceInstance send request PDUs to the Provided-
ServiceInstance.

488 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

In all other cases, the method ids of the two ProvidedServiceInstances should
not overlap.
The following restrictions apply in case of SenderReceiver communication (Service
Interface Events and Notifier): If two or more ProvidedServiceInstances are de-
fined using the same serviceIdentifier and different majorVersions, and these
ProvidedServiceInstances are referencing the same ApplicationEndpoint
via localUnicastAddress then the source IP address, the source port number, and
the Level 4 protocol (Udp) fields of header of IP packets containing event PDUs that
are sent to the clients of the ProvidedServiceInstances are identical. In such a
scenario, the ProvidedServiceInstances may use identical event Ids (i.e. iden-
tical Header Ids) if at least one of the following conditions holds for any pair of the
ProvidedServiceInstances:
a) At any point in time only one of the ProvidedServiceInstances is active
b) If two or more ProvidedServiceInstances can send Events at the same time,
the ProvidedServiceInstances may still use identical event Ids if at least one
of the following IP header fields of the IP packet containing the event is different
for any pair of Event PDUs identified by the same Event Id:
b1) Destination IP address (== IP address of client)
b2) Destination port number (== client port number)
In all other cases, the event ids of the two PSIs should not overlap.
In other words if several ProvidedServiceInstances with the same serviceI-
dentifier and different majorVersions are located on the same Socket for trans-
mission of particular Events, then the different ProvidedServiceInstances need
to use a different client Addresses (different Port or IP Address) or the Events of all
those ProvidedServiceInstances need to have unique EventIds.

489 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.8 Transport Layer

In AUTOSAR, the Transport Layer has two main purposes: The segmentation and re-
assembly of messages that are too long to fit into one frame on the underlying commu-
nication cluster, and the re-use of fixed frame identifiers for different message content.
According to the AUTOSAR Layered Software Architecture [15], each type of
communication cluster has its own definition of the Transport Layer. Consequently,
the peculiarities of the cluster types are addressed in the System Template by having
different detailed models for FlexRay, CAN, LIN and J1939. However, all models are
embedded into the communication model: They use specialized classes of TpConfig
as a root element into the TP configuration.
[TPS_SYST_01099] Context of TpConfig dA TpConfig element is existing always
in the context of exactly one CommunicationCluster.c(RS_SYST_00014)
All Transport Layers will take IPdus as input elements, which will be transferred in
the form of one or more NPdus. A TpConnection (FlexrayTpConnection, CanT-
pConnection, LinTpConnection, J1939TpConnection) identifies a connection
link between different communication nodes and routes the Pdus between them.
ARElement PackageableElement
AtpStructureElement +fibexElement
FibexElement
System «atpVariation» *

TpConfig «atpVariation»
+communicationCluster CommunicationCluster

CanTpConfig J1939TpConfig FlexrayArTpConfig DoIpTpConfig

LinTpConfig EthTpConfig FlexrayTpConfig

Figure 6.59: Transport Layer Overview

Examples in chapter 6.8.9 and chapter 6.8.10 illustrate the usage of the TP model.
Class TpConfig (abstract)
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note Contains all configuration elements for AUTOSAR TP.
Base ARObject, CollectableElement, FibexElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Subclasses CanTpConfig, DoIpTpConfig, EthTpConfig, FlexrayArTpConfig, FlexrayTpConfig, J1939TpConfig, LinTp
Config, SomeipTpConfig
5

490 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class TpConfig (abstract)
Attribute Type Mult. Kind Note
communication CommunicationCluster 1 ref A TpConfig is existing always in the context of exactly one
Cluster CommunicationCluster.

Table 6.209: TpConfig

Class TpAddress
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note An ECUs TP address on the referenced channel. This represents the diagnostic Address.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
tpAddress Integer 1 attr An ECUs TP address on the referenced channel. This
represents the diagnostic Address.

Table 6.210: TpAddress

[constr_3025] Usage of NPdus in TpConnections dIn case several TpConnec-

tions use the same Frame ID for their communication needs only one NPdu element
per Frame Id shall exist. This constraint applies for all supported AUTOSAR transport
protocols (CanTp, LinTp, FrTp, FrArTp and J1939Tp).c()
Note: Depending on the capabilities of the Basic Software implementations of Tp and
Interface the ECU Configuration of the respective BSW Modules may utilize more com-
munication elements (NPdus).
Example for an allowed System Template description where the same FrameId is used
by two different TpConnections:

TpConnection1 --(dataPdu)--> NPdu1 ----> FrameId1

TpConnection1 --(flowControl)--> NPdu2 ----> FrameId2
TpConnection2 --(dataPdu)--> NPdu2 ----> FrameId2
TpConnection2 --(flowControl)--> NPdu1 ----> FrameId1

The following Ecu configuration with additional NPdus can still be derived from the
above system description:

TpConnection1 --(dataPdu)--> NPdu1 ----> FrameId1

TpConnection1 --(flowControl)--> NPdu2 ----> FrameId2
TpConnection2 --(dataPdu)--> NPdu3 ----> FrameId2
TpConnection2 --(flowControl)--> NPdu4 ----> FrameId1

[constr_3090] TpSdu transmission on a PhysicalChannel dThe IPdu that is ref-

erenced by a TpConnection in the role tpSdu shall be referenced by exactly one
PduTriggering aggregated on the PhysicalChannel of the TpConnection.c()
The corresponding PduTriggering for the IPdu referenced from the TpConnec-
tion in the role tpSdu is aggregated by the PhysicalChannel which points to the
same CommunicationConnector which is referenced by TpNode that this TpCon-
nection points to.

491 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Please note that with [constr_3090] the multiple transmission of the same TpSdu over
a specific channel using TP is only possible if several IPdus and TpConnections are
created.

6.8.1 Transport Layer Routing

The transformations in the TP modules take a significant amount of time and re-
sources and therefore two different Transport Layer routing approaches are supported
by AUTOSAR.
[TPS_SYST_01100] TP routing without using transport protocol modules (low-
level routing) dThe behavior can be optimized if source and target use the same
transport protocol (e.g. CanTp-to-CanTp routing). In this case the inbound NPDU can
be directly forwarded to the PduR and then sent on the outbound bus without any
(resource consuming) TP module involvement.c(RS_SYST_00014)
[TPS_SYST_01101] TP routing using transport protocol modules dIn case that
transport protocol modules are involved in the routing operation the incoming NPDUs
need to be:
• forwarded to corresponding inbound TP module and reassembled into an SDU
(represented as IPdu)
• the SDU needs to be forwarded to the PduR
• the PduR routes the SDU to the outgoing TP module
• the outbound TP module segments the SDU into NPDUs which are then sent on
the target bus.
c(RS_SYST_00014)

6.8.2 FlexRay ISO Transport Layer

The FlexRay ISO 10681-2 Transport Layer supports multiple sessions, i.e. multiple
segmented transfers can be handled at the same time. Thus, multiple FlexrayTp-
Connections can be defined on the same ECU. Each FlexrayTpConnection is
controlled by configuration parameters defined in FlexrayTpConnectionControl.
[TPS_SYST_01102] FlexrayTpConnectionControl reuse dThe same
FlexrayTpConnectionControl may be reused for an arbitrary number of
FlexrayTpConnections.c(RS_SYST_00014)
A FlexrayTpConnection defines the way of communication between a sender and
a receiver and uses a FlexrayTpPduPool of NPdus to transmit data to the FlexRay
Interface.

492 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_01103] FlexrayTpConnection shall specify one txPduPool dEach

FlexrayTpConnection shall specify one txPduPool with at least one nPdu.c(RS_-
SYST_00014)
In order to achieve a higher bandwidth a txPduPool may contain more than one trans-
mit NPdu, e.g. if all referenced NPdus are transmitted in different FlexrayFrames in
the same cycle.
FibexElement FlexrayTpEcu FibexElement
+ecuInstance TpConfig
EcuInstance
+ cancellation: Boolean [0..1]
1 + cycleTimeMainFunction: TimeValue [0..1]
+ fullDuplexEnabled: Boolean

+tpEcu 1..*
«atpVariation»

FlexrayTpConfig

«atpVariation» «atpVariation» «atpVariation»

+tpNode 0..*
+tpConnection 0..*
+transmitter Identifiable
TpConnection
1 FlexrayTpNode
FlexrayTpConnection
+receiver
+ bandwidthLimitation: Boolean
1..*
«atpVariation»
«atpVariation»

+reversedTpSdu 0..1 +directTpSdu 1 +rxPduPool 0..1 +txPduPool 0..1 0..1 +tpAddress 0..1
+multicast
Pdu Identifiable Identifiable
IPdu FlexrayTpPduPool TpAddress +tpAddress
+pduPool

1..* + tpAddress: Integer 1..*

+tpConnectionControl
0..*

Identifiable
FlexrayTpConnectionControl +nPdu 1..*
«enumeration»
+ ackType: TpAckType [0..1] NPdu
TpAckType
+ maxFcWait: Integer [0..1]
+ maxNumberOfNpduPerCycle: Integer [0..1] noAck
+ maxRetries: Integer [0..1] ackWithRt
+ separationCycleExponent: Integer [0..1]
+ timeBr: TimeValue [0..1]
+ timeBuffer: TimeValue [0..1]
+ timeCs: TimeValue [0..1]
+ timeoutAr: TimeValue [0..1]
+ timeoutAs: TimeValue [0..1]
+ timeoutBs: TimeValue [0..1] +tpConnectionControl
+ timeoutCr: TimeValue [0..1]
1

Figure 6.60: FlexRay ISO Transport Layer Configuration (TransportProtocols: FlexRay-

IsoTransportProtocol)

FlexrayTpConnections are specifically used for communication between one

source and one or several target devices. These communication partners are specified
using the transmitter and receiver associations to FlexrayTpNodes, providing
the diagnostic tpAddress and the connection to the topology.

493 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_01104] FlexrayTpConnection with several receivers dIn case of

several receivers a multicast tpAddress shall be used.c(RS_SYST_00014)
The actual payload to be transported by the FlexrayTpConnection is specified by
using either one or two references to IPdus, depending on whether the connection
shall be used unidirectional (one reference) or bidirectional (two references).
Class FlexrayTpConfig
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note This element defines exactly one FlexRay ISO TP Configuration.
One FlexRayTpConfig element shall be created for each FlexRay Network in the System that uses Flex
Ray Iso Tp.
Tags:atp.recommendedPackage=TpConfigs
Base ARObject, CollectableElement, FibexElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable, TpConfig
Attribute Type Mult. Kind Note
pduPool FlexrayTpPduPool 1..* aggr Configuration of FlexRay TP Pdu Pools.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
tpAddress TpAddress 1..* aggr Collection of TpAddresses.
atpVariation: Derived, because EcuInstance can vary.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
tpConnection FlexrayTpConnection * aggr Configuration of FlexRay TP Connections.
atpVariation: Derived, because TpNode can vary.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
tpConnection FlexrayTpConnection * aggr Configuration of FlexRay TP Connection Controls.
Control Control
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
tpEcu FlexrayTpEcu 1..* aggr Collection of TP Ecus
atpVariation: Derived, because EcuInstance can vary.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
tpNode FlexrayTpNode * aggr Senders and receivers of FlexRay TP messages.
atpVariation: Derived, because EcuInstance can vary.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild

Table 6.211: FlexrayTpConfig

Class FlexrayTpConnectionControl
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note Configuration parameters to control a FlexRay TP connection.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
ackType TpAckType 0..1 attr This parameter defines the type of acknowledgement
which is used for the specific channel.
5

494 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class FlexrayTpConnectionControl
maxFcWait Integer 0..1 attr This attribute defines the maximum number of Flow
Control N-PDUs with FlowState "WAIT".
maxNumberOf Integer 0..1 attr This parameter limits the number of N-Pdus the sender is
NpduPerCycle allowed to transmit within a FlexRay cycle.
maxRetries Integer 0..1 attr This parameter defines the maximum number of retries (if
retry is configured for the particular channel).
separationCycle Integer 0..1 attr Exponent to calculate the minimum number of
Exponent "Separation Cycles" the sender has to wait for the next
transmission of an FrTp N-Pdu.
timeBr TimeValue 0..1 attr Time (in seconds) until transmission of the next Flow
Control N-PDU.
timeBuffer TimeValue 0..1 attr This parameter defines the time of waiting for the next try
to get a Tx or Rx buffer.
This parameter is equivalent to the temporal distance
between two FC.WT N-Pdus in case the buffer request
returns busy.
Specified in seconds.
timeCs TimeValue 0..1 attr Time (in seconds) until transmission of the next
ConsecutiveFrame NPdu / LastFrame NPdu.
timeoutAr TimeValue 0..1 attr This parameter states the timeout between the PDU
transmit request of the Transport Layer to the FlexRay
Interface and the corresponding confirmation of the Flex
Ray Interface on the receiver side (for FC or AF).
Specified in seconds.
timeoutAs TimeValue 0..1 attr This attribute states the timeout between the PDU
transmit request for the first PDU of the group used in the
current connection of the Transport Layer to the FlexRay
Interface and the corresponding confirmation of the Flex
Ray Interface (when having sent the last PDU of the
group used in this connection) on the sender side (SF-x,
FF-x, CF or FC (in case of Transmit Cancellation)).
Specified in seconds.
timeoutBs TimeValue 0..1 attr This parameter defines the timeout in seconds for waiting
for an FC or AF on the sender side in a 1:1 connection.
timeoutCr TimeValue 0..1 attr This parameter defines the timeout value in seconds for
waiting for a CF or FF-x (in case of retry) after receiving
the last CF or after sending an FC or AF on the receiver
side. Specified in seconds.

Table 6.212: FlexrayTpConnectionControl

Class FlexrayTpConnection
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note A connection identifies the sender and the receiver of this particular communication. The FlexRayTp
module routes a Pdu through this connection.
In a System Description the references to the PduPools are mandatory. In an ECU Extract these
references can be optional: On unicast connections these references are always mandatory. On
multicast the txPduPool is mandatory on the sender side. The rxPduPool is mandatory on the receiver
side. On Gateway ECUs both references are mandatory.
Base ARObject, TpConnection
Attribute Type Mult. Kind Note
bandwidth Boolean 1 attr Specifies whether the connection requires a bandwidth
Limitation limitation or not.
5

495 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class FlexrayTpConnection
directTpSdu IPdu 1 ref Reference to the IPdu that is segmented by the Transport
Protocol.
multicast TpAddress 0..1 ref TP address for 1:n connections.
receiver FlexrayTpNode 1..* ref The target of the TP connection.
reversedTpSdu IPdu 0..1 ref Reference to the IPdu that is segmented by the Transport
Protocol. If support of both sending and receiving is used,
this association references the IPdu used for the
additional second direction.
rxPduPool FlexrayTpPduPool 0..1 ref A connection has a reference to a set of NPdus (FrTpRx
PduPool) which are defined for receiving data via this
particular connection.
The following constraint is valid only for the System
Extract/ECU Extract: In case this connection is applied to
the transmitter the rxPduPool holds the actually received
NPdus. In case this connection is applied to the receiver
the rxPduPool holds the actually sent NPdus.
tpConnection FlexrayTpConnection 1 ref Reference to the connection control.
Control Control
transmitter FlexrayTpNode 1 ref The source of the TP connection.
txPduPool FlexrayTpPduPool 0..1 ref A connection has a reference to a set of NPdus (FrTpTx
PduPool) which are defined for sending data via this
particular connection.
The following constraint is valid only for the System
Extract/ECU Extract: In case this connection is applied to
the transmitter the txPduPool holds the actually sent
NPdus. In case this connection is applied to the receiver
the txPduPool holds the actually received NPdus.

Table 6.213: FlexrayTpConnection

The FlexrayTpConnection refers to the FlexrayTpPduPool in two roles: rx-

PduPool and txPduPool.
[TPS_SYST_01064] Transmit/Receive Semantics of Pdu Pools dThe transmit/re-
ceive semantics of Pdu Pools depends on the role of the regarded ECU:
• If the ECU is the transmitter then the txPduPool holds the sent NPdus and the
rxPduPool holds the received NPdus.
• If the ECU is the receiver then the the txPduPool holds the received NPdus and
the rxPduPool holds the sent NPdus.
c()
The following example shows how this differentiation may be used:
System Description:
SENDER = A
RECEIVER = B
TxPool = PDU_1
RxPool = PDU_2

496 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

ECU Extract of A:
SENDER = A
TxPool = PDU_1 -> sent Pdus
RxPool = PDU_2 -> received Pdus

Since on receiver side the PDU_1 is received and PDU_2 is sent (from a local point of
view) the export shall look like this:
ECU Extract of B:
RECEIVER = B
TxPool = PDU_1 -> received Pdus
RxPool =IsoPDU_2 -> sent Pdus
Tp Example

IsoTpConnection
transmitter receiver

TxPduPool RxPduPool

tx Pdu1
ECU A rx ECU B
Pdu2

Figure 6.61: IsoTp Example

Class FlexrayTpPduPool
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note FlexrayTpPduPool is a set of N-PDUs which are defined for FrTp sending or receiving purpose.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Note -
Kind Confidential
- AUTOSAR
1 20.03.2007 AUTOSAR_SystemTemplate
nPdu NPdu 1..* ref Reference to NPdus that are part of the PduPool.

Table 6.214: FlexrayTpPduPool

Class FlexrayTpNode
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note TP Node (Sender or Receiver) provides the TP Address and the connection to the Topology description.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
connector Communication * ref Association to one or more physical connectors (max
Connector number of connectors for FlexRay: 2).
In a System Description this reference is mandatory. In
an ECU Extract this reference is optional (references to
ECUs that are not part of the ECU Extract shall be
avoided).
5

497 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class FlexrayTpNode
tpAddress TpAddress 0..1 ref Reference to the TP Address that is used by the TpNode.
This reference is optional in case that the multicast TP
Address is used (reference from TpConnection).

Table 6.215: FlexrayTpNode

Class FlexrayTpEcu
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note ECU specific TP configuration parameters. Each TpEcu element has a reference to exactly one
ECUInstance in the topology.
Base ARObject
Attribute Type Mult. Kind Note
cancellation Boolean 0..1 attr With this switch Tx and Rx Cancellation can be turned on
or off.
cycleTimeMain TimeValue 0..1 attr The period between successive calls to the Main Function
Function of the AUTOSAR TP. Specified in seconds.
ecuInstance EcuInstance 1 ref Connection to the ECUInstance in the Topology
fullDuplex Boolean 1 attr The full duplex mechanisms is enabled if this attribute is
Enabled set to true. Otherwise half duplex is enabled.

Table 6.216: FlexrayTpEcu

498 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.8.3 FlexRay AUTOSAR Transport Layer

This section describes a Non-ISO FlexRay TP protocol that is supported by AUTOSAR

in addition to the FlexRay ISO 10681-2 TP (see section 6.8.2). The Non-ISO FlexRay
Transport Layer supports multiple sessions, i.e. multiple segmented transfers can be
handled at the same time.
A FlexrayArTpChannel provides a Tx and an Rx pool of NPdus which are used by
the associated FlexrayArTpConnections.
FlexrayArTpConnections are used for communication between one source and
one or more target device(s). These communication partners are specified by the
source and target associations to FlexrayArTpNodes, providing the diagnostic
TpAddresses and the connection to the topology description. The actual payload
to be transported by the FlexrayArTpConnection is identified by the references
directTpSdu and reversedTpSdu to IPdus. When one of the two SDUs is omitted,
the connection shall be used unidirectional.
[constr_5315] FlexrayArTpConnections within the same FlexrayArTpChan-
nel not allowed to have the same address information dFlexrayArTpConnec-
tions that are aggregated by the same or reverse FlexrayArTpChannel are not
allowed to reference the same pair of FlexrayArTpNodes at the time when the Ecu
configuration of the COM stack is created.c()

499 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

FibexElement
TpConfig

FlexrayArTpConfig

«atpVariation» «atpVariation»
+tpAddress 0..*
+tpNode 0..*
Identifiable
Identifiable CommunicationConnector
TpAddress +tpAddress +connector
FlexrayArTpNode FlexrayCommunicationConnector
«atpVariation»
+ tpAddress: Integer 0..1 0..*
+ nmReadySleepTime: Float [0..1]
+ pncFilterDataMask: PositiveUnlimitedInteger [0..1]
+multicast 0..1 + wakeUpChannel: Boolean
+source 1 +target 1..*

+tpChannel 0..*

FlexrayArTpChannel

+ ackType: FrArTpAckType
+ cancellation: Boolean [0..1]
+ extendedAddressing: Boolean
+ maxAr: Integer [0..1]
+directTpSdu + maxAs: Integer [0..1]
Pdu TpConnection
+tpConnection + maxBs: Integer [0..1]
IPdu 1 FlexrayArTpConnection + maxFcWait: PositiveInteger [0..1]
+ connectionPrioPdus: Integer [0..1] 1..* + maximumMessageLength: MaximumMessageLengthType
+reversedTpSdu
+ maxRetries: Integer [0..1]
0..1 + minimumMulticastSeperationTime: TimeValue [0..1]
+ minimumSeparationTime: TimeValue
+ multicastSegmentation: Boolean
«enumeration» + timeBr: TimeValue [0..1]
MaximumMessageLengthType + timeCs: TimeValue [0..1]
+ timeoutAr: TimeValue [0..1]
iso6 + timeoutAs: TimeValue [0..1]
iso + timeoutBs: TimeValue [0..1]
I4g + timeoutCr: TimeValue [0..1]

«enumeration»
FrArTpAckType

noAck
ackWithRt
ackWithoutRt +nPdu 0..*

NPdu

Figure 6.62: FlexRay Autosar Transport Layer Configuration (TransportProtocols:

FlexRayAutosarTransportProtocol)

Class FlexrayArTpConfig
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note This element defines exactly one FlexRay Autosar TP Configuration.
One FlexrayArTpConfig element shall be created for each FlexRay Network in the System that uses Flex
Ray Autosar TP.
Tags:atp.recommendedPackage=TpConfigs
Base ARObject, CollectableElement, FibexElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable, TpConfig
Attribute Type Mult. Kind Note
tpAddress TpAddress * aggr Collection of TpAddresses.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
5

500 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class FlexrayArTpConfig
tpChannel FlexrayArTpChannel * aggr Configuration of FlexRay Autosar Transport Protocol
channels.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
tpNode FlexrayArTpNode * aggr Senders and receivers of TP messages.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild

Table 6.217: FlexrayArTpConfig

Class FlexrayArTpChannel
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note A channel is a group of connections sharing several properties.
The FlexRay AutosarTransport Layer supports several channels. These channels can work concurrently,
thus each of them requires its own state machine and management data structures and its own PDU-IDs.
Base ARObject
Attribute Type Mult. Kind Note
ackType FrArTpAckType 1 attr Type of Acknowledgement.
cancellation Boolean 0..1 attr With this switch Tx and Rx Cancellation can be turned on
or off.
extended Boolean 1 attr Adressing Type of this connection:
Addressing
true: Two Bytes
false: One Byte
maxAr Integer 0..1 attr This attribute defines the maximum number of trying to
send a frame when a TIMEOUT AR occurs (depending
on whether retry is configured).
maxAs Integer 0..1 attr This attribute defines the maximum number of trying to
send a frame when a TIMEOUT AS occurs (depending on
whether retry is configured).
maxBs Integer 0..1 attr This attribute defines the number of consecutive CFs
between two FCs (block size). Valid values are 1 .. 16
when retry is activated, and 0 .. 255 otherwise.
maxFcWait PositiveInteger 0..1 attr This attribute defines the maximal number of wait frames
to be sent for a pending connection. Range is 0..255.
maximum MaximumMessage 1 attr This specifies the maximum message length for the
MessageLength LengthType particular channel.
maxRetries Integer 0..1 attr This attribute defines the maximum number of retries (if
retry is configured for the particular channel).
minimum TimeValue 0..1 attr This attribute defines the minimum amount of time
Multicast between two succeeding CFs of a 1:n segmented
SeperationTime transmission in seconds. Valid values are 0, 100µs,
200µs ... 900µs, 1ms, 2ms .. 127ms. The value can be
changed at runtime using the FrArTp_ChangeParameter
interface.
minimumMulticastSeparationTime shall be an integer
multiple of the cycle length multiplied with the multiplexing
factor, i.e. minimumMulticastSeparationTime = n * cycle *
m, where n is an integer >= 0, cycle is Flexray
Cluster.cycle, and m is the cycle multiplexor of those
cycles where PDUs of the PDU pool are scheduled.
Please note: Due to the scheduling strategies of FrTp,
5

501 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class FlexrayArTpChannel
4
minimumMulticastSeparationTime can only be kept to a
degree defined by the maximum temporal distance of the
PDUs of a PDU pool within one FlexRay cycle.
Range: 0 .. 0.127
minimum TimeValue 1 attr This attribute defines the minimum amount of time
SeparationTime between two succeeding CFs of a 1:1 segmented
transmission in seconds. Valid values are 0, 100µs,
200µs .. 900µs, 1ms, 2ms .. 127ms. The value can be
changed at runtime using the FrArTp_ChangeParameter
interface.
The minimumSeparationTime shall be an integer multiple
of the cycle length multiplied with the multiplexing factor,
i.e. minimumSeparationTime = n * cycle * m, where n is
an integer >=0, cycle is FlexrayCluster.cycle, and m is the
cycle multiplexor of those cycles where PDUs of the PDU
pool are scheduled.
Please note: Due to the scheduling strategies of FrTp,
minimumSeparationTime can only be kept to a degree
defined by the maximum temporal distance of the PDUs
of a PDU pool within one FlexRay cycle.
Range: 0 .. 0.127
multicast Boolean 1 attr This attribute defines whether segmentation within a 1:n
Segmentation connection is allowed or not.
nPdu NPdu * ref A FlexRayTpChannel references a set of NPdus. These
NPdus are logically assembled into a pool of Rx NPdus
and another pool of Tx NPdus. It shall be ensured that a
second channel either references all NPdus of such a
pool, or none.
timeBr TimeValue 0..1 attr This attribute defines the time in seconds between
receiving the last CF of a block or an FF-x (or SF-x) and
sending out an FC or AF.
timeCs TimeValue 0..1 attr This attribute defines the time in seconds between the
sending of two consecutive frames or between a
consecutive frame and a flow control (for Transmit
Cancellation) or between reception of an flow control or
Acknowledgement Frame and sending of the next
consecutive frame or a flow control (for Transmit
Cancellation).
timeoutAr TimeValue 0..1 attr This attribute states the timeout in seconds between the
PDU transmit request of the Transport Layer to the Flex
Ray Interface and the corresponding confirmation of the
FlexRay Interface on the receiver side (for FC or AF).
timeoutAs TimeValue 0..1 attr This attribute states the timeout in seconds between the
PDU transmit request for the first PDU of the group used
in the current connection of the Transport Layer to the
FlexRay Interface and the corresponding confirmation of
the FlexRay Interface (when having sent the last PDU of
the group used in this connection) on the sender side
(SF-x, FF-x, CF).
timeoutBs TimeValue 0..1 attr This attribute defines the timeout in seconds for waiting
for an FC or AF on the sender side in a 1:1 connection.
timeoutCr TimeValue 0..1 attr This attribute defines the timeout value in seconds for
waiting for a CF or FF-x (in case of retry) after receiving
the last CF or after sending an FC or AF on the receiver
side.
tpConnection FlexrayArTpConnection 1..* aggr Group of connections that can be used in this channel.

Table 6.218: FlexrayArTpChannel

502 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class FlexrayArTpNode
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note TP Node (Sender or Receiver) provides the TP Address and the connection to the Topology description.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
connector FlexrayCommunication * ref Association to one or more physical connectors (max
Connector number of connectors for FlexRay: 2).
In a System Description this reference is mandatory. In
an ECU Extract this reference is optional (references to
ECUs that are not part of the ECU Extract shall be
avoided).
tpAddress TpAddress 0..1 ref Reference to the TP Address that is used by the TpNode.
This reference is optional in case that the multicast TP
Address is used (reference from TpConnection).

Table 6.219: FlexrayArTpNode

Class FlexrayArTpConnection
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note A connection within a channel identifies the sender and the receiver of this particular communication.
The FlexRay Autosar Tp module routes a Pdu through this connection.
Base ARObject, TpConnection
Attribute Type Mult. Kind Note
connectionPrio Integer 0..1 attr This parameter defines the number of PDUs that shall be
Pdus reserved for this connection when it is active. The range
is 1-255.
directTpSdu IPdu 1 ref Reference to the IPdu that is segmented by the Transport
Protocol.
The source address of the transmitted NPdu is
determined by the configured source Communication
Connector. The target address of the transmitted NPdu is
determined by the configured target Communication
Connector.
multicast TpAddress 0..1 ref TP address for 1:n connections.
reversedTpSdu IPdu 0..1 ref Reference to the IPdu that is segmented by the Transport
Protocol. If support of both sending and receiving is used,
this association references the IPdu used for the
additional second direction.
The source address of the transmitted NPdu is
determined by the configured target Communication
Connector. The target address of the transmitted NPdu is
determined by the configured source Communication
Connector.
source FlexrayArTpNode 1 ref The source of the TP connection.
target FlexrayArTpNode 1..* ref The target of the TP connection.

Table 6.220: FlexrayArTpConnection

Enumeration FrArTpAckType
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note Type of Acknowledgement.
5

503 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Enumeration FrArTpAckType
Literal Description
ackWithoutRt Acknowledgement without retry.
Tags:atp.EnumerationLiteralIndex=0
ackWithRt Acknowledgement with retry.
Tags:atp.EnumerationLiteralIndex=1
noAck No acknowledgement.
Tags:atp.EnumerationLiteralIndex=2

Table 6.221: FrArTpAckType

Enumeration MaximumMessageLengthType
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note Type of Acknowledgement.
Literal Description
I4g SF-E allowed (SF of arbitrary length depending on FrTpPduLength), up to (2**32)-1 byte message
length (all FF-x allowed).
Tags:atp.EnumerationLiteralIndex=0
iso Up to (2**12)-1 Byte message length (No FF-Ex or SF-E or AF shall be used and recognized).
Tags:atp.EnumerationLiteralIndex=1
iso6 As ISO, but the maximum payload length is limited to 6 byte (SF-I, FF-I, CF). This is necessary to
route TP on CAN when using Extended Addressing or Mixed Addressing on CAN.
Tags:atp.EnumerationLiteralIndex=2

Table 6.222: MaximumMessageLengthType

504 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.8.4 CAN Transport Layer

The CAN Transport Layer supports multiple sessions by means of CanTpChannels:

Each CanTpChannel uses its own resources, such as internal buffer, timer, state ma-
chine and thus can operate independently and simultaneously to other CanTpChan-
nels. The same session can be reused for an arbitrary number of CanTpConnec-
tions.
Each CanTpConnection uses its own pair of NPdus: One NPdu, the dataPdu is
mandatory for each CanTpConnection, the flowControlPdu is optional depending
whether only Single Frames are transferred over the connection.
A CanTpConnection is specifically used for communication between source and tar-
get devices. These communication partners are specified using the transmitter
and receiver associations to CanTpNode, providing the diagnostic tpAddress and
the connection to the topology.
[TPS_SYST_01146] Generic CanTpConnections dIf the transmitter or the re-
ceiver of a CanTpConnection is not specified then the CanTpConnection is a
generic one (address information is not determined).c()
[TPS_SYST_01105] CanTpConnection with several receivers dIn case of several
receivers a multicast tpAddress shall be used.c(RS_SYST_00014)
FibexElement
FibexElement CanTpEcu
+ecuInstance TpConfig
EcuInstance
+ cycleTimeMainFunction: TimeValue [0..1]
1

+tpEcu 1..*
«atpVariation»

CanTpConfig

«atpVariation» «atpVariation» «atpVariation»

+tpChannel 1..* +tpConnection 1..* +tpNode 1..*

Identifiable TpConnection +transmitter Identifiable

CanTpChannel CanTpConnection CanTpNode

0..1
+ channelId: PositiveInteger + addressingFormat: CanTpAddressingFormatType + maxFcWait: Integer [0..1]
+ cancellation: Boolean [0..1] + stMin: TimeValue [0..1]
+ maxBlockSize: Integer [0..1] + timeoutAr: TimeValue [0..1]
+ paddingActivation: Boolean +receiver + timeoutAs: TimeValue [0..1]
+ taType: NetworkTargetAddressType [0..1]
+canTpChannel 1 0..*
+ timeoutBr: TimeValue [0..1]
+ timeoutBs: TimeValue [0..1]
«enumeration» + timeoutCr: TimeValue [0..1]
CanTpAddressingFormatType + timeoutCs: TimeValue [0..1]
«atpVariation»
standard
mixed
extended +tpAddress
+multicast 0..1 0..1 +tpAddress 1..*
mixed29bit
normalfixed 0..1 +flowControlPdu +dataPdu Identifiable
1
CanTpAddress
«enumeration» NPdu
NetworkTargetAddressType + tpAddress: Integer
+ tpAddressExtensionValue: Integer [0..1]
functional
physical +tpSdu 1

Pdu
IPdu

Figure 6.63: CAN Transport Layer Configuration (TransportProtocols: CanTransportPro-

tocol)

505 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

The actual payload to be transported by the CanTpConnection is specified by the

reference tpSdu to IPdu.
The N_TAtype communication models as defined in ISO 15765-2 [32] can be ex-
pressed using a combination of the attributes addressingFormat (CanTpAddress-
ingFormatType) and taType (NetworkTargetAddressType).
Class CanTpConfig
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note This element defines exactly one CAN TP Configuration.
One CanTpConfig element shall be created for each CAN Network in the System.
Tags:atp.recommendedPackage=TpConfigs
Base ARObject, CollectableElement, FibexElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable, TpConfig
Attribute Type Mult. Kind Note
tpAddress CanTpAddress 1..* aggr Collection of TP Addresses.
atpVariation: Derived, because EcuInstance can vary.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
tpChannel CanTpChannel 1..* aggr Configuration of CAN TP channels.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
tpConnection CanTpConnection 1..* aggr Senders and receivers of CAN TP messages.
atpVariation: Derived, because TpNode can vary.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
tpEcu CanTpEcu 1..* aggr Collection of TP Ecus
atpVariation: Derived, because EcuInstance can vary.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
tpNode CanTpNode 1..* aggr Senders and receivers of Can TP messages.
atpVariation: Derived, because EcuInstance can vary.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild

Table 6.223: CanTpConfig

Class CanTpChannel
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note Configuration parameters of the CanTp channel.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
channelId PositiveInteger 1 attr The id of the channel. The value shall be unique for each
channel.
Table 6.224: CanTpChannel

506 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class CanTpConnection
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note A connection identifies the sender and the receiver of this particular communication. The CanTp module
routes a Pdu through this connection.
atpVariation: Derived, because TpNode can vary.
Base ARObject, TpConnection
Attribute Type Mult. Kind Note
addressing CanTpAddressing 1 attr Declares which communication addressing mode is
Format FormatType supported.
cancellation Boolean 0..1 attr With this switch Tx Cancellation can be turned on or off.
Please note that the Rx Cancellation is always enabled.
canTpChannel CanTpChannel 1 ref Reference to the CanTpChannel on which this CanTp
Connection is realized.
dataPdu NPdu 1 ref Reference to an Data NPdu.
flowControlPdu NPdu 0..1 ref Reference to the Flow Control NPdu.
maxBlockSize Integer 0..1 attr The maximum number of N-PDUs the CanTp receiver
allows the sender to send, before waiting for an
authorization to continue transmission of the following
N-PDUs. For further details on this parameter value see
ISO 15765-2 specification.
Note: For reasons of buffer length, the CAN Transport
Layer can adapt the BS value within the limit of this
maximum BS
multicast CanTpAddress 0..1 ref TP address for 1:n connections.
padding Boolean 1 attr This specifies whether or not Sfs, FCs and the last CF
Activation shall be padded to 8 bytes length in case it contains less
payload.
true: The N-PDU received uses padding for SF, FC and
the last CF. (N-PDU length is always 8 bytes)
false: The N-PDU received does not use padding for SF,
CF and the last CF. (N-PDU length is dynamic)
receiver CanTpNode * ref The target of the TP connection.
taType NetworkTargetAddress 0..1 attr Network Target Address type.
Type
timeoutBr TimeValue 0..1 attr Value in seconds of the performance requirement for (N_
Br + N_Ar). N_Br is the elapsed time between the
receiving indication of a FF or CF or the transmit
confirmation of a FC, until the transmit request of the next
FC.
timeoutBs TimeValue 0..1 attr This parameter defines the timeout for waiting for an FC
or AF on the sender side in an 1:1 connection. Specified
in seconds.
timeoutCr TimeValue 0..1 attr This parameter defines the timeout value for waiting for a
CF or FF-x (in case of retry) after receiving the last CF or
after sending an FC or AF on the receiver side. Specified
in seconds.
timeoutCs TimeValue 0..1 attr The attribute timeoutCs represents the time (in seconds)
which elapses between the transmit request of a CF
N-PDU until the transmit request of the next CF N-PDU.
tpSdu IPdu 1 ref Reference to an IPdu that is segmented by the Transport
Protocol.
transmitter CanTpNode 0..1 ref The source of the TP connection.

Table 6.225: CanTpConnection

507 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Enumeration CanTpAddressingFormatType
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note Declares which communication addressing mode is supported.
Literal Description
extended To use extended addressing format.
Tags:atp.EnumerationLiteralIndex=0
mixed To use mixed 11bit addressing format.
Tags:atp.EnumerationLiteralIndex=1
mixed29bit To use mixed 29bit addressing format
Tags:atp.EnumerationLiteralIndex=2
normalfixed To use normal fixed addressing format
Tags:atp.EnumerationLiteralIndex=3
standard To use normal addressing format.
Tags:atp.EnumerationLiteralIndex=4

Table 6.226: CanTpAddressingFormatType

Class CanTpAddress
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note An ECUs TP address on the referenced channel. This represents the diagnostic Address.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
tpAddress Integer 1 attr An ECUs TP address on the referenced channel. This
represents the diagnostic Address.
tpAddress Integer 0..1 attr If the mixed addressing format is used, this parameter
ExtensionValue contains the transport protocol address extension value.

Table 6.227: CanTpAddress

Class CanTpEcu
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note ECU specific TP configuration parameters. Each TpEcu element has a reference to exactly one
ECUInstance in the topology.
Base ARObject
Attribute Type Mult. Kind Note
cycleTimeMain TimeValue 0..1 attr The period between successive calls to the Main Function
Function of the AUTOSAR TP. Specified in seconds.
ecuInstance EcuInstance 1 ref Connection to the ECUInstance in the Topology

Table 6.228: CanTpEcu

Class CanTpNode
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note TP Node (Sender or Receiver) provides the TP Address and the connection to the Topology description.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
5

508 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class CanTpNode
connector Communication 0..1 ref Association to a CommunicationConnector in the
Connector topology description. In a System Description this
reference is mandatory. In an ECU Extract this reference
is optional (references to ECUs that are not part of the
ECU Extract shall be avoided).
maxFcWait Integer 0..1 attr This attribute defines the maximum number of flow control
PDUs that can be consecutively be transmitted by a
receiver.
stMin TimeValue 0..1 attr Sets the duration of the minimum time the CanTp sender
shall wait between the transmissions of two CF N-PDUs.
timeoutAr TimeValue 0..1 attr This attribute states the timeout between the PDU
transmit request of the Transport Layer to the Can
Interface and the corresponding confirmation of the Can
Interface on the receiver side (for FC or AF). Specified in
seconds.
timeoutAs TimeValue 0..1 attr This attribute states the timeout between the PDU
transmit request for the first PDU of the group used in the
current connection of the Transport Layer to the Can
Interface and the corresponding confirmation of the Can
Interface (when having sent the last PDU of the group
used in this connection) on the sender side (SF-x, FF-x,
CF or FC (in case of Transmit Cancellation)). Specified in
seconds.
tpAddress CanTpAddress 0..1 ref Reference to the TP Address that is used by the TpNode.
This reference is optional in case that the multicast TP
Address is used (reference from TpConnection).

Table 6.229: CanTpNode

Enumeration NetworkTargetAddressType
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note Network Target Address type (see ISO 15765-2).
Literal Description
functional Functional request type
Tags:atp.EnumerationLiteralIndex=0
physical Physical request type
Tags:atp.EnumerationLiteralIndex=2

Table 6.230: NetworkTargetAddressType

509 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.8.5 LIN Transport Layer

LinTpConnection is used for modeling communication resources required for using

the LIN Transport Layer. Contrary to the FlexRay and CAN Transport Layers, LIN TP
only supports one session per PhysicalChannel.
An arbitrary number of LinTpConnections per LinTpConfig can be defined since
the transmission of data from master to slave, using the MasterRequest frame,
and the transmission of data from slave to master, using the SlaveResponse frame,
needs to be described per NAD the LinMaster uses to address one or more of its
LinSlaves.
LinTpConnection uses the dataPdu reference for specifying exactly one NPdu
which is to be used for transmitting the data, and it optionally references a flow-
Control NPdu in order to handle Flow Control Frames if required.
One LinTpConnection is specifically used for communication between one source
and one or several target devices. These communication partners are specified using
the transmitter and receiver associations to LinTpNode, providing the diag-
nostic tpAddress and the connection to the topology. In case of several receivers a
multicast tpAddress shall be used.
The actual payload to be transported by the LinTpConnection is specified by the
reference linTpNSdu to IPdu.

510 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

FibexElement
TpConfig

LinTpConfig

«atpVariation»
+tpAddress 1..*
«atpVariation»
Identifiable
«atpVariation» TpAddress
+tpConnection 0..*
+multicast + tpAddress: Integer
TpConnection
LinTpConnection 0..1
+tpAddress 0..1
+ timeoutAs: TimeValue [0..1] +tpNode 0..*
+ timeoutCr: TimeValue [0..1]
+ timeoutCs: TimeValue [0..1] +transmitter Identifiable
LinTpNode
1
+ dropNotRequestedNad: Boolean [0..1]
+receiver + maxNumberOfRespPendingFrames: Integer [0..1]
+ p2Max: TimeValue [0..1]
1..* + p2Timing: TimeValue [0..1]

FibexElement
EcuInstance
+flowControl 0..1 1 +dataPdu +connector 0..1
+ comConfigurationGwTimeBase: TimeValue [0..1]
Identifiable + comConfigurationRxTimeBase: TimeValue [0..1]
NPdu
CommunicationConnector + comConfigurationTxTimeBase: TimeValue [0..1]
+connector

+ comEnableMDTForCyclicTransmission: Boolean [0..1]

+ createEcuWakeupSource: Boolean [0..1] + ethSwitchPortGroupDerivation: Boolean [0..1]
+ dynamicPncToChannelMappingEnabled: Boolean [0..1] + pncPrepareSleepTimer: TimeValue [0..1]
+ pncFilterArrayMask: PositiveInteger [0..*] {ordered} + pncSynchronousWakeup: Boolean [0..1]
+ pncGatewayType: PncGatewayTypeEnum [0..1] + pnResetTime: TimeValue [0..1]
1 +linTpNSdu *
+commConnector 0..* «atpVariation» + sleepModeSupported: Boolean
Pdu + v2xSupported: V2xSupportEnum [0..1]
IPdu + wakeUpOverBusSupported: Boolean
«atpVariation»

«atpVariation»
+commController 1 +commController 1..*
Identifiable
PhysicalChannel Identifiable
«atpVariation»
CommunicationController
+managedPhysicalChannel 0..*
+ wakeUpByControllerSupported: Boolean [0..1]

LinCommunicationController

+ protocolVersion: String

LinMaster LinSlave

+ timeBase: TimeValue [0..1] + assignNad: Boolean [0..1]

+ timeBaseJitter: TimeValue [0..1] + configuredNad: Integer
+ functionId: PositiveInteger
+ initialNad: Integer [0..1]
+ nasTimeout: TimeValue [0..1]
+ supplierId: PositiveInteger
+ variantId: PositiveInteger

Figure 6.64: LIN Transport Layer Configuration

511 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class LinTpConfig
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note This element defines exactly one Lin TP Configuration.
One LinTpConfig element shall be created for each Lin Network in the System.
Tags:atp.recommendedPackage=TpConfigs
Base ARObject, CollectableElement, FibexElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable, TpConfig
Attribute Type Mult. Kind Note
tpAddress TpAddress 1..* aggr Collection of TpAddresses.
atpVariation: Derived, because EcuInstance can vary.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
tpConnection LinTpConnection * aggr Configuration of LIN TP channels.
atpVariation: Derived, because TpNode can vary.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
tpNode LinTpNode * aggr Senders and receivers of LIN TP messages.
atpVariation: Derived, because EcuInstance can vary.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild

Table 6.231: LinTpConfig

Class LinTpNode
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note TP Node (Sender or Receiver) provides the TP Address and the connection to the Topology description.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
connector Communication 0..1 ref Association to a CommunicationConnector in the
Connector topology description.
In a System Description this reference is mandatory. In
an ECU Extract this reference is optional (references to
ECUs that are not part of the ECU Extract shall be
avoided).
dropNot Boolean 0..1 attr Configures if TP Frames of not requested LIN-Slaves are
RequestedNad dropped or not.
maxNumberOf Integer 0..1 attr Configures the maximum number of allowed response
RespPending pending frames.
Frames
p2Max TimeValue 0..1 attr After reception of a response pending frame the P2
timeout counter is reloaded with the timeout time P2max.
p2Timing TimeValue 0..1 attr P2 timeout observation parameter.
tpAddress TpAddress 0..1 ref Reference to the TP Address that is used by the TpNode.
This reference is optional in case that the multicast TP
Address is used (reference from TpConnection).

Table 6.232: LinTpNode

512 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class LinTpConnection
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note A LinTP channel represents an internal path for the transmission or reception of a Pdu via LinTp and
describes the sender and the receiver of this particular communication.
LinTp supports (per Lin Cluster) the configuration of one Rx Tp-SDU and one Tx Tp-SDU per NAD the
LinMaster uses to address one or more of its Lin Slaves. To support this an arbitrary number of LinTp
Connections shall be described.
Base ARObject, TpConnection
Attribute Type Mult. Kind Note
dataPdu NPdu 1 ref Reference to an NPdu (Single Frame, First Frame or
Consecutive Frame).
The Single Frame network protocol data unit (SF N_PDU)
shall be sent out by the sending network entity and can
be received by one or multiple receiving network entities.
The Single Frame (SF N_PDU) shall be sent out to
transfer a service data unit that can be transferred via a
single service request to the data link layer. This network
protocol data unit shall be sent to transfer unsegmented
messages.
The First Frame network protocol data unit (FF N_PDU)
identifies the first network protocol data unit (N_PDU) of a
segmented message transmitted by a network sending
entity and received by a receiving network entity.
The Consecutive Frame network protocol data unit (CF
N_PDU) transfers segments (N_Data) of the service data
unit message data (<MessageData>). All network
protocol data units (N_PDUs) transmitted by the sending
entity after the First Frame network protocol data unit (FF
N_PDU) shall be encoded as Consecutive Frames
network protocol data units (CF N_PDUs).
flowControl NPdu 0..1 ref Reference to the Flow Control NPdu.
The Flow Control network protocol data unit (FC N_PDU)
is identified by the Flow Control protocol control
information (FC N_PCI). The Flow Control network
protocol data unit (FC N_PDU) instructs a sending
network entity to start, stop or resume transmission of CF
N_PDUs. The Flow Control network protocol data unit
shall be sent by the receiving network layer entity to the
sending network layer entity, when ready to receive more
data, after correct reception of:
a) First Frame network protocol data unit (FF N_PDU)
b) the last Consecutive Frame network protocol data unit
(CF N_PDU) of a block of Consecutive Frames (CF N_
PDU) if further Consecutive Frame network protocol data
unit (CF N_PDU) need(s) to be sent.
linTpNSdu IPdu 1 ref Reference to the IPdu that is segmented by the Transport
Protocol.
multicast TpAddress 0..1 ref TP address for 1:n connections.
receiver LinTpNode 1..* ref The target of the TP connection.
timeoutAs TimeValue 0..1 attr Time for transmission of the LIN frame (any N-PDU) on
the sender side. Specified in seconds.
timeoutCr TimeValue 0..1 attr This attribute defines the timeout value for waiting for a
CF or FF-x (in case of retry) after receiving the last CF or
after sending an FC or AF on the receiver side. Specified
in seconds.
timeoutCs TimeValue 0..1 attr The attribute timeoutCs represents the time (in seconds)
which elapses between the transmit request of a CF
N-PDU until the transmit request of the next CF N-PDU.
5

513 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class LinTpConnection
transmitter LinTpNode 1 ref The source of the TP connection.

Table 6.233: LinTpConnection

514 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.8.6 Ethernet Transport Layer

The Transport Layer in the AUTOSAR Ethernet protocol stack is defined by the TcpIp
module. For the transmission of an upper layer module Pdu via an UDP or TCP socket,
the AUTOSAR Socket Adaptor specifies a Pdu route which is linked to a socket con-
nection. The upper layer module of the SoAd may use the Interface (IF) API or the
Transport Protocol (TP) API for the transmit request and data provision respectively.
With the EthTpConnection it is possible to describe in a System Description that the
TP API shall be used for a specific Pdu route. If a PduTriggering is not referenced
by a EthTpConnection the IF API will be used.
FibexElement
TpConfig

EthTpConfig

+tpConnection 0..*

TpConnection Identifiable
EthTpConnection +tpSdu CoreCommunication::
PduTriggering
0..*

Figure 6.65: Modeling of EthTpConnection

Class EthTpConfig
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note This element defines which PduTriggerings shall be handled using "TP" semantics.
Tags:atp.recommendedPackage=TpConfigs
Base ARObject, CollectableElement, FibexElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable, TpConfig
Attribute Type Mult. Kind Note
tpConnection EthTpConnection * aggr Senders and receivers of SOME/IP TP messages.

Table 6.234: EthTpConfig

Class EthTpConnection
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note A connection identifies which PduTriggerings shall be handled using the "TP" semantics.
Base ARObject, TpConnection
Attribute Type Mult. Kind Note
tpSdu PduTriggering * ref Reference to a PduTriggering that shall be transported
using the "TP" semantics.

Table 6.235: EthTpConnection

515 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.8.7 SOME/IP segmenter

On the transmission side SOME/IP TP segments an incoming SOME/IP IPdu that

does not fit into a single UDP Package into smaller GeneralPurposeIPdus with cat-
egory SOMEIP_SEGMENTED_IPDU and allows to transport SOME/IP messages over
UDP that are greater than 128KB. On the reception side the large IPdu is reassembled
again. The Message Type field of the SOME/IP header contains a bit, which marks the
SOME/IP message as a segment of an original SOME/IP message. Every segmented
SOME/IP message adds SOME/IP TP specific fields to the SOME/IP header. These
fields contain control information for the segmentation and the reassembly of original,
large SOME/IP messages.
FibexElement
TpConfig

SomeipTpConfig

+tpChannel 0..*
+tpConnection 0..*
Identifiable
SomeipTpConnection SomeipTpChannel
+tpChannel
+ burstSize: PositiveInteger [0..1]
0..1
+ rxTimeoutTime: TimeValue [0..1]
+ separationTime: TimeValue [0..1]

+tpSdu 0..1 +transportPdu 0..1

Identifiable
PduTriggering

Figure 6.66: SOME/IP Segmenter

Class SomeipTpConfig
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note This element defines exactly one SOME/IP TP Configuration.
Tags:atp.recommendedPackage=TpConfigs
Base ARObject, CollectableElement, FibexElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable, TpConfig
Attribute Type Mult. Kind Note
tpChannel SomeipTpChannel * aggr Definition of SomeipTpChannels that are collecting
configuration properties that are valid for a collection of
SomeipTpConnections.
tpConnection SomeipTpConnection * aggr Senders and receivers of SOME/IP TP messages.

Table 6.236: SomeipTpConfig

516 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class SomeipTpConnection
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note A connection identifies the sender and the receiver of this particular communication. The SOME/IP TP
module routes a Pdu through this connection.
Base ARObject
Attribute Type Mult. Kind Note
tpChannel SomeipTpChannel 0..1 ref Assignment of configuration properties valid for this
SomeipTpConnection.
tpSdu PduTriggering 0..1 ref Reference to an IPdu that is segmented by the Transport
Protocol.
transportPdu PduTriggering 0..1 ref Reference to the segmented IPdu.

Table 6.237: SomeipTpConnection

Class SomeipTpChannel
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note This element is used to assign properties to SomeipTpConnections that are referencing this SomeipTp
Channel.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
burstSize PositiveInteger 0..1 attr Specifies the number of segments that shall be
transmitted in a burst ignoring separationTime.
SeparationTime will then only be applied between bursts.
If not configured, SeparationTime will be applied between
all frames.
rxTimeoutTime TimeValue 0..1 attr Timer to monitor the successful reception. It is started
when the first NPdu is received, restarted after reception
of intermediate NPdus, and is stopped when the last
NPdu has been received.
separationTime TimeValue 0..1 attr Sets the duration of the minimum time in seconds the
SOME/IP TP module shall wait between the
transmissions of NPdus.
Table 6.238: SomeipTpChannel

[constr_3328] SomeipTpConnection.transportPdu reference restriction

dA PduTriggering that is referenced by a SomeipTpConnection in the
role transportPdu shall reference a GeneralPurposeIPdu with category
SOMEIP_SEGMENTED_IPDU in the role iPdu.c()
[constr_3329] SomeipTpConnection.tpSdu reference restriction dA PduTrig-
gering that is referenced by a SomeipTpConnection in the role tpSdu shall refer-
ence an IPdu in the role iPdu.c()
[TPS_SYST_02156] Length of GeneralPurposeIPdu with category
SOMEIP_SEGMENTED_IPDU dThe length of GeneralPurposeIPdu with
category SOMEIP_SEGMENTED_IPDU that is referenced by a PduTriggering
in the role iPdu that in turn is referenced by a SomeipTpConnection in the role
transportPdu defines the maximum size in bytes of a segment.c(RS_SYST_00050,
RS_SYST_00039, RS_SYST_00014)

517 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Please note that the length of a GeneralPurposeIPdu with category

SOMEIP_SEGMENTED_IPDU covers 8 bytes of the SOME/IP header, 4 bytes of the
TP header, and the segment itself.
[constr_3330] Same transportPdu shall not be used in different SomeipTp-
Connections dA PduTriggering that is referencing a GeneralPurposeIPdu with
category SOMEIP_SEGMENTED_IPDU in the role iPdu shall be referenced at most
once by a SomeipTpConnection in the role transportPdu.c()

518 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.8.8 SAE J1939 Transport Layer

There are two transport protocol variants defined by J1939: BAM (Broadcast Announce
Message), which is a broadcast protocol that does not use any flow control, and CMDT
(Connection Mode Data Transfer), which is a point-to-point protocol with flow control
and acknowledgment.
BAM uses two NPdus for transport, TP.CM (Transport Protocol Command, flowCon-
trolPdu) and TP.DT (Transport Protocol Data, dataPdu). CMDT uses three NPdus,
because an additional TP.CM (flowControlPdu) in reverse direction is needed for
flow control. The length of TP.CM and TP.DT NPdus is fixed to 8 bytes.
[TPS_SYST_01106] Usage of additional directPdu in case of variable length sdu
dIn case of variable length sdu (with system signals of variable length) an additional
directPdu is required:
• it is used if the current length of this sdu is up to 8 bytes.
• if the current length of this sdu is higher than 8 bytes the sdu will be transported
via the dataPdu.
c(RS_SYST_00014, RS_SYST_00038)

519 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

TpConfig
J1939TpConfig

«atpVariation»
+tpConnection 1..* «atpVariation» «atpVariation»
TpConnection
J1939TpConnection +tpNode 1..* +tpAddress 1..*
+receiver
Identifiable Identifiable
+ broadcast: Boolean
0..* J1939TpNode +tpAddress TpAddress
+ bufferRatio: PositiveInteger [0..1]
+ cancellation: Boolean [0..1] +transmitter 0..1 + tpAddress: Integer
+ dynamicBs: Boolean [0..1]
+ maxBs: PositiveInteger [0..1] 0..1
+ maxExpBs: PositiveInteger [0..1]
+ retry: Boolean [0..1]
+managedPhysicalChannel
0..*
Identifiable
PhysicalChannel

«atpVariation»
+connector 0..1 +commConnector 0..*

Identifiable
CommunicationConnector

+ createEcuWakeupSource: Boolean [0..1]

+flowControlPdu 1..2 +dataPdu 1 + dynamicPncToChannelMappingEnabled: Boolean [0..1]
+ pncFilterArrayMask: PositiveInteger [0..*] {ordered}
Pdu
NPdu + pncGatewayType: PncGatewayTypeEnum [0..1]
IPdu
+connector *
«atpVariation»

+sdu 0..* +directPdu 0..1 FibexElement

EcuInstance
+tpPg 0..*
+ comConfigurationGwTimeBase: TimeValue [0..1]
J1939TpPg + comConfigurationRxTimeBase: TimeValue [0..1]
+ comConfigurationTxTimeBase: TimeValue [0..1]
+ pgn: Integer [0..1]
+ comEnableMDTForCyclicTransmission: Boolean [0..1]
+ requestable: Boolean [0..1]
+ ethSwitchPortGroupDerivation: Boolean [0..1]
+ pncPrepareSleepTimer: TimeValue [0..1]
+ pncSynchronousWakeup: Boolean [0..1]
+ pnResetTime: TimeValue [0..1]
+ sleepModeSupported: Boolean
+ v2xSupported: V2xSupportEnum [0..1]
+ wakeUpOverBusSupported: Boolean

Figure 6.67: J1939 Transport Layer Configuration

A J1939TpConnection is specifically used for communication between source and

target devices. These communication partners are specified using the transmitter
and receiver associations to J1939TpNode, providing the diagnostic tpAddress
and the connection to the topology.
[TPS_SYST_02190] J1939TpConnection.transmitter reference in case of
broadcast connection dIn case of a broadcast connection the J1939TpConnection
shall only reference the J1939TpNode in the role transmitter. The reason is that
BAM (Broadcast Announce Message) is always directed at the target address 0xff
and therefore no receiver reference is necessary.c(RS_SYST_00014, RS_SYST_-
00038)
[TPS_SYST_02191] J1939TpConnection.transmitter reference in case that
the source is an unknown node dIn case that the source is an unknown node, e.g.
an arbitrary tester, the J1939TpConnection is allowed to omit the transmitter
reference to J1939TpNode.c(RS_SYST_00014, RS_SYST_00038)
[TPS_SYST_02192] J1939TpConnection.receiver reference in case that the
destination is an unknown node dIn case that the destination is an unknown node,

520 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

e.g. an arbitrary tester, the J1939TpConnection is allowed to omit the receiver

reference to J1939TpNode.c(RS_SYST_00014, RS_SYST_00038)
[TPS_SYST_02193] J1939TpConnection.receiver reference in case that the
destination is connected to a configured J1939NmNode dIn case that the desti-
nation is connected to a configured J1939NmNode, the J1939TpConnection shall
reference the J1939TpNode in the role receiver. It means that the receiving
J1939TpNode is associated with an EcuInstance via the CommunicationCon-
nector and this EcuInstance is associated with a J1939NmNode via the NmEcu. In
this case the nmNodeId of the J1939NmNode corresponds to the TpAddress defined
by J1939TpNode.c(RS_SYST_00014, RS_SYST_00038)
The Parameter Group (PG) to be transported by the J1939TpConnection is specified
by the tpPg aggregation.
[TPS_SYST_01147] Generic J1939TpConnections dIf the transmitter or the
receiver of a J1939TpConnection is not specified then the J1939TpConnection
is a generic one (address information is not determined).c()
Class J1939TpConfig
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note This element defines exactly one J1939 TP Configuration.
One J1939TpConfig element shall be created for each J1939 Network in the System.
Tags:atp.recommendedPackage=TpConfigs
Base ARObject, CollectableElement, FibexElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable, TpConfig
Attribute Type Mult. Kind Note
tpAddress TpAddress 1..* aggr Collection of TP Adresses.
atpVariation: Derived, because EcuInstance can vary.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
tpConnection J1939TpConnection 1..* aggr Configuration of J1939 TP connections.
atpVariation: Derived, because TpNode can vary.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
tpNode J1939TpNode 1..* aggr Senders and receivers of J1939 TP messages.
atpVariation: Derived, because EcuInstance can vary.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild

Table 6.239: J1939TpConfig

521 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class J1939TpConnection
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note A J1939TpConnection represents an internal path for the transmission or reception of a Pdu via J1939Tp
and describes the sender and the receiver of this particular communication. The J1939Tp module routes
a Pdu (J1939 PGN) through the connection.
Base ARObject, TpConnection
Attribute Type Mult. Kind Note
broadcast Boolean 1 attr BAM (Broadcast Announce Message) is a broadcast
protocol. If this attribute is set to true broadcast is used.
Since address FF is the only broadcast address, there’s
no reason to configure it.
bufferRatio PositiveInteger 0..1 attr Defines usage of available data for dynamic block size
calculation when protocol retry is enabled. This attribute
describes in percent of available buffer that shall be used
for retry.
cancellation Boolean 0..1 attr Enable support for Tx/Rx cancellation.
dataPdu NPdu 1 ref Data Message (TP.DT) used by CMDT and BAM.
The DataNPdu has a fixed length of 8 bytes.
dynamicBs Boolean 0..1 attr Enable support for dynamic block size calculation.
flowControlPdu NPdu 1..2 ref Reference to the Command NPdus (TP.CM) that are used
in the CMDT (Connection Mode Data Transfer) in both
directions.
BAM uses one TP.CM (Transport Protocol Command).
The flowControlNPdu has a fixed length of 8 bytes.
Please note that the role name "flowControlIPdu" is
misleading and is kept for backward compatibilty reasons.
maxBs PositiveInteger 0..1 attr Set maximum block size (number of packets in TP.CM_
CTS).
maxExpBs PositiveInteger 0..1 attr Set maximum for expected block size (maximum number
of packets in TP.CM_RTS).
receiver J1939TpNode * ref The target of the TP connection.
retry Boolean 0..1 attr Enable support for protocol retry.
tpPg J1939TpPg * aggr J1939 messages (parameter groups, PGs) that can be
transferred via this connection.
transmitter J1939TpNode 0..1 ref The source of the TP connection.

Table 6.240: J1939TpConnection

Class J1939TpPg
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note A J1939TpPg represents one J1939 message (parameter group, PG) identified by the PGN (parameter
group number) that can be received or transmitted via J1939Tp.
Base ARObject
Attribute Type Mult. Kind Note
directPdu NPdu 0..1 ref In case of variable length IPdus (with system signals of
variable length), an additional NPdu (with the PGN in the
CAN ID) is used for messages with up to 8 bytes.
5

522 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class J1939TpPg
pgn Integer 0..1 attr Parameter group number (PGN) of a J1939 message
(parameter group, PG) that can be received or
transmitted via J1939Tp. The PGN may be omitted when
the a directPdu is referenced and is mapped into a Can
FrameTriggering with an identifier.
requestable Boolean 0..1 attr Parameter Group can be triggered by the J1939 request
message.
sdu IPdu * ref Reference to IPdus that are segmented by the Transport
Protocol. If more than one IPdu is referenced, the IPdus
are used when the same PGN is received in parallel via
different transport protocols (BAM, CMDT, direct) on the
same J1939TpConnection.

Table 6.241: J1939TpPg

Class J1939TpNode
Package M2::AUTOSARTemplates::SystemTemplate::TransportProtocols
Note TP Node (Sender or Receiver) provides the TP Address and the connection to the Topology description.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
connector Communication 0..1 ref Association to a CommunicationConnector in the
Connector topology description. In a System Description this
reference is mandatory. In an ECU Extract this reference
is optional (references to ECUs that are not part of the
ECU Extract shall be avoided).
tpAddress TpAddress 0..1 ref Reference to the TP Address that is used by the TpNode.
This reference is optional only when no TP is sent and
only BAM is received.

Table 6.242: J1939TpNode

[constr_3210] J1939TpPgs with identical pgn value dFor all J1939TpPgs where
the attribute pgn has an identical value the attribute requestable shall also have an
identical value.c()

523 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.8.9 Unicast TP Example

The example in Figure 6.68 illustrate the usage of the System Template TP model.
In this System Description example the Sender ECU (Tester) communicates with the
Receiver ECU (Diagnostic Server) via two Gateways (GW1 and GW2).

CAN Bus 2

Receiver
GW2 ECU
TpAddress: 5
FlexRay Bus

GW1

CAN Bus 1

Sender
ECU
TpAddress:1

Figure 6.68: TP unicast Example

CAN Bus 1 (CanTpConfig 1):

CanTpConnection (CanTpConnection1)
transmitter TpNode: Sender ECU, TpAddress: 1
receiver TpNode: GW1, TpAddress: 5
CanTpConnection (CanTpConnection2):
transmitter TpNode: GW1, TpAddress: 5
receiver TpNode: Sender ECU, TpAddress: 1

FlexRay Bus (FlexRayTpConfig):

FlexRayTpConnection (FlexrayTpConnection1):
transmitter TpNode: GW1, TpAddress: 1
receiver TpNode: GW2, TpAddress: 5

CAN Bus 2 (CanTpConfig 2):

CanTpConnection (CanTpConnection3):
transmitter TpNode: GW2, TpAddress: 1
receiver TpNode: Receiver ECU, TpAddress: 5
CanTpConnection (CanTpConnection4):
transmitter TpNode: Receiver ECU, TpAddress: 5
receiver TpNode: GW2, TpAddress: 1

DiagnosticConnection:
physicalRequest TpConnection: CanTpConnection3
response TpConnection: CanTpConnection4

524 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Please note that two different CanTpConfig elements are created for the two CAN
networks. The TpAddress of the transmitter TpNode is always 1 and the TpAddress
of the receiver TpNode is always 5, even in the FlexrayTpConfig where Gateway
ECU1 communicates with Gateway ECU2. The original transmitter and the final re-
ceiver are addressed in each connection. Please note that for CanTp for each direction
an own CanTpConnection is used.
The DiagnosticConnection is modeled only for the the last segment to which the
Receiver ECU that represents the diagnostic server is connected.

6.8.10 Multicast TP Example

A second example illustrates the usage of the multicast reference.

CAN Bus 2

Receiver Receiver
GW2 ECU1 ECU2
multicast multicast
FlexRay Bus TpAddress: 10 TpAddress: 10

GW1

CAN Bus 1

Sender
ECU
TpAddress:1

Figure 6.69: TP multicast Example

Can Bus 1 (CanTpConfig1):

CanTpConnection
source TpNode: Sender ECU, TpAddress: 1
target TpNode: GW1
multicast TpAddress: 10

FlexRay Bus (FlexRayTpConfig):

FlexRayTpConnection
source TpNode: GW1, TpAddress: 1
target TpNode: GW2
multicast TpAddress: 10

CAN Bus 2 (CanTpConfig 2):

CanTpConnectionChannel
source TpNode: GW2, TpAddress: 1
target TpNode: Receiver ECU1
target TpNode: Receiver ECU2

525 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

multicast TpAddress: 10

Please note that the target TpNode does not contain a reference to the TpAddress.
The multicast TpAddress is described by a direct reference from the connection.

526 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.8.11 Diagnostic Connection

A prominent use of the TP in automotive systems is the implementation of diagnostic

communication. Data send from and to the tester frequently exceeds the native size of
a communication package on typical bus systems used for this purpose.
However, the mere usage of TP channels for diagnostic purposes is missing one im-
portant aspect: TP channels, as defined by the AUTOSAR standard, are unidirectional
by nature.
For diagnostic communication, it is very important to be able to define pairs of TP
connections that can be taken to send related request and response messages.
In order to support this use case the meta-class DiagnosticConnection has been
introduced.

527 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

+functionalRequest
Referrable ARElement
TpConnection
+ident TpConnectionIdent 0..* DiagnosticConnection

0..1
+response

0..1

FlexrayArTpConnection
+responseOnEvent
+ connectionPrioPdus: Integer [0..1]
0..1

+physicalRequest

J1939TpConnection 0..1

+ broadcast: Boolean
+ bufferRatio: PositiveInteger [0..1]
+ cancellation: Boolean [0..1]
+ dynamicBs: Boolean [0..1]
+ maxBs: PositiveInteger [0..1]
+ maxExpBs: PositiveInteger [0..1]
+ retry: Boolean [0..1]

LinTpConnection

+ timeoutAs: TimeValue [0..1]

+ timeoutCr: TimeValue [0..1]
+ timeoutCs: TimeValue [0..1]

CanTpConnection

+ addressingFormat: CanTpAddressingFormatType
+ cancellation: Boolean [0..1]
+ maxBlockSize: Integer [0..1]
+ paddingActivation: Boolean
+ taType: NetworkTargetAddressType [0..1]
+ timeoutBr: TimeValue [0..1]
+ timeoutBs: TimeValue [0..1]
+ timeoutCr: TimeValue [0..1]
+ timeoutCs: TimeValue [0..1]

FlexrayTpConnection

+ bandwidthLimitation: Boolean

+periodicResponseUudt 0..*

Identifiable
DoIpTpConnection
+tpSdu PduTriggering

+doIpSourceAddress 1 +doIpTargetAddress 1

Identifiable
DoIpLogicAddress

+ address: Integer

Figure 6.70: Modeling of DiagnosticConnection

[TPS_SYST_05003] Usage of DiagnosticConnection in combination with a TP

dDiagnosticConnection allows for the dedicated identification of TP connections
used for the various diagnostic message sending use cases:
• functionalRequest
• physicalRequest
• responseOnEvent
• response

528 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

c()
[TPS_SYST_05004] Usage of DiagnosticConnection in combination with
UUDT dIn addition to the usage of TP connections, the DiagnosticConnection
foresees the transmission of UUDT message for periodic response. For this purpose,
the role periodicResponseUudt is supported.c()
[constr_1367] periodicResponseUudt.periodicResponseUudt shall only re-
fer to a DcmIPdu dIf the role periodicResponseUudt exists then every PduTrig-
gering referenced in the role periodicResponseUudt shall only refer to a
DcmIPdu.c()
Please note that the meta-class TpConnectionIdent (derived from Referrable)
has been introduced for the purpose of allowing sub-classes of TpConnection to
become the target of a reference while preserving full backwards-compatibility to the
previous modeling.
This means in particular that the existence of a shortName is only required if the sub-
class of TpConnection shall actually represent the target of a reference in the context
of the definition of a DiagnosticConnection.
This, however, is kind of self-evident (because the reference would not work without the
existence of a shortName at the reference target) and therefore it is not necessary to
formulate an explicit constraint that clarifies this issue.
[constr_1368] Limitation of the target of references from DiagnosticConnec-
tion dDiagnosticConnection shall only reference (via the indirection created by
TpConnectionIdent) the following sub-classes of the meta-class TpConnection:
• CanTpConnection
• FlexrayTpConnection
• FlexrayArTpConnection
• DoIpTpConnection
c()
Class DiagnosticConnection
Package M2::AUTOSARTemplates::SystemTemplate::DiagnosticConnection
Note DiagnosticConncection that is used to describe the relationship between several TP connections.
Tags:atp.recommendedPackage=DiagnosticConnections
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
functional TpConnectionIdent * ref Reference to functional request messages.
Request
periodic PduTriggering * ref Reference to UUDT responses.
ResponseUudt
5

529 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class DiagnosticConnection
physical TpConnectionIdent 0..1 ref Reference to a physical request message.
Request
response TpConnectionIdent 0..1 ref In the vast majority of cases a response is required.
However, there are also cases where providing the
response is not possible and/or not allowed.
responseOn TpConnectionIdent 0..1 ref Reference to a ROE message.
Event
Table 6.243: DiagnosticConnection

Class TpConnection (abstract)

Package M2::AUTOSARTemplates::SystemTemplate::DiagnosticConnection
Note TpConnection Base Class.
Base ARObject
Subclasses CanTpConnection, DoIpTpConnection, EthTpConnection, FlexrayArTpConnection, FlexrayTp
Connection, J1939TpConnection, LinTpConnection
Attribute Type Mult. Kind Note
ident TpConnectionIdent 0..1 aggr This adds the ability to become referrable to Tp
Connection.

Table 6.244: TpConnection

Class TpConnectionIdent
Package M2::AUTOSARTemplates::SystemTemplate::DiagnosticConnection
Note This meta-class is created to add the ability to become the target of a reference to the non-Referrable Tp
Connection.
Base ARObject, Referrable
Attribute Type Mult. Kind Note
– – – – –
Table 6.245: TpConnectionIdent

530 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.9 Network Management

The NM specification of AUTOSAR consist of a Generic Network Management Inter-
face Module and of bus specific Network management adaptation layers (CanNm,
FrNm, UdpNm, J1939Nm). The AUTOSAR Generic NM Interface module acts as
a bus-independent adaptation layer between the bus-specific Network Management
modules and the AUTOSAR basic software module Communication Manager. The
AUTOSAR Generic NM Interface module is represented by NmCluster, NmEcu, Nm-
Coordinator and NmNode. The bus-specific Network Management attributes are
represented by BusspecificNmEcu. See also figure 6.71.
[constr_5032] Maximal one NmConfig per System is allowed to be defined dEach
System element is allowed to reference at most one NmConfig element with the
fibexElement reference.c()
[constr_3057] Maximal one BusspecificNmEcu per NmEcu and bus system is
allowed to be defined dFor each NmEcu at most one BusspecificNmEcu per bus
system (FlexRay/Can/Udp/J1939) is allowed to be defined.c()

531 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Identifiable
FibexElement NmEcu
NmConfig +nmIfEcu
+ nmBusSynchronizationEnabled: Boolean [0..1]
«atpVariation,atpSplitable» 0..* + nmComControlEnabled: Boolean [0..1]
+ nmCycletimeMainFunction: TimeValue [0..1]
+ nmPduRxIndicationEnabled: Boolean [0..1]
+ nmRemoteSleepIndEnabled: Boolean [0..1]
+ nmStateChangeIndEnabled: Boolean [0..1]
«atpVariation,atpSplitable» + nmUserDataEnabled: Boolean [0..1]
«atpVariation,atpSplitable»
+nmCluster 0..* +nmClusterCoupling 0..*
Identifiable
NmClusterCoupling
NmCluster

+ nmChannelSleepMaster: Boolean [0..1] 0..1

+nmIfEcu
+ nmNodeDetectionEnabled: Boolean [0..1]

+busDependentNmEcu
+ nmNodeIdEnabled: Boolean [0..1]
+ nmPncParticipation: Boolean [0..1]
+ nmRepeatMsgIndEnabled: Boolean [0..1]
+ nmSynchronizingNetwork: Boolean [0..1] +nmCoordinator 0..1
+ pncClusterVectorLength: PositiveInteger [0..1]
NmCoordinator

+ index: Integer [0..1] 0..*

+ nmCoordSyncSupport: Boolean [0..1]
+ nmGlobalCoordinatorTime: TimeValue [0..1] BusspecificNmEcu

«atpVariation» 0..*
+nmNode
Identifiable
NmNode
+nmNode
+ nmCoordCluster: PositiveInteger [0..1]
0..* + nmCoordinatorRole: NmCoordinatorRoleEnum [0..1]
+ nmNodeId: Integer [0..1]
+communicationCluster
+ nmPassiveModeEnabled: Boolean [0..1]
0..1

FibexElement
«atpVariation» +txNmPdu 0..* +rxNmPdu 0..* +controller 0..1
CommunicationCluster Pdu Identifiable
+ baudrate: PositiveUnlimitedInteger [0..1] NmPdu «atpVariation»
+ protocolName: String [0..1] CommunicationController
+ protocolVersion: String [0..1] + nmDataInformation: Boolean [0..1]
+ nmVoteInformation: Boolean [0..1] + wakeUpByControllerSupported: Boolean [0..1]
+ unusedBitPattern: Integer [0..1]

+iSignalToIPduMapping 0..*
Identifiable «enumeration»
NmCoordinatorRoleEnum
ISignalToIPduMapping
Active
+ packingByteOrder: ByteOrderEnum [0..1] Passive
+ startPosition: UnlimitedInteger [0..1]
+ transferProperty: TransferPropertyEnum [0..1]
+ updateIndicationBitPosition: UnlimitedInteger [0..1]

Figure 6.71: Generic Nm elements

The NmCluster contains a set of NmNodes.

The NmNodes are associated with the CommunicationController in the topology
and belong to exactly one NmEcu. The reception and transmission of NmPdus is speci-
fied with the rxNmPdu and txNmPdu associations to NmPdus.
[TPS_SYST_01107] Definition of NmCoordinator dAn nmCoordinator is con-
nected to two or more CommunicationClusters (via NmNodes) out of which at least
two contain the requirement to shutdown synchronously.c()

532 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Non Coordinator Master Coordinator

Non Coordinator
Active Channel Active Channel
NmNode12 CANChnl01 CANChnl02
Cluster01 NmNode11 NmNode21 Cluster02 NmNode22

NmNode23
NmNode13 Passive Channel
Passive Channel Slave Coordinator
CANChnl05
Slave Coordinator Active Channel Active Channel Cluster05
Active Channel NmNode41 NmNode51
NmNode31 NmNode42 NmNode52

Non Coordinator Non Coordinator

Non Coordinator
NmNode32
CANChnl03
Cluster03 CANChnl04
Cluster04
Passive NmNode53
Slave Coordinator NmNode43
NmNode33 Channel
Non Coordinator Non Coordinator
Active Channel
NmNode61

Non Coordinator NmNode62

CANChnl06
Cluster06
Non Coordinator NmNode44 NmNode54
NmNode63
Non Coordinator Non Coordinator
Non Coordinator
NmNode64

Figure 6.72: Nm Example

Figure 6.72 shows an example and the following section shows how the model shall
be used:
NmCluster: Cluster01
• NmNodes:
– NmNode11 (NmEcu1)
– NmNode12 (NmEcu2)
– NmNode13 (NmEcu3)
NmCluster: Cluster02
• NmNodes:
– NmNode21 (NmEcu1)
– NmNode22 (NmEcu4)
– NmNode23 (NmEcu5)
NmCluster: Cluster03
• NmNodes:
– NmNode31 (NmEcu3)
– NmNode32 (NmEcu6)

533 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

– NmNode33 (NmEcu7)
...
NmEcu1: NmCoordinator (MasterCoordinator)
• NmNode11 (nmCoordinatorRole: Active)
• NmNode21 (nmCoordinatorRole: Active)
NmEcu3: NmCoordinator (SlaveCoordinator)
• NmNode13 (nmCoordinatorRole: Passive)
• NmNode31 (nmCoordinatorRole: Active)
...

534 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class NmConfig
Package M2::AUTOSARTemplates::SystemTemplate::NetworkManagement
Note Contains the all configuration elements for AUTOSAR Nm.
Tags:atp.recommendedPackage=NmConfigs
Base ARObject, CollectableElement, FibexElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
nmCluster NmCluster * aggr Collection of NM Clusters
atpVariation: Derived, because cluster can be variable.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=nmCluster.shortName, nmCluster.variation
Point.shortLabel
vh.latestBindingTime=postBuild
nmCluster NmClusterCoupling * aggr Collection of NmClusterCouplings
Coupling
atpVariation: Derived, because NmCluster can vary.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=nmClusterCoupling, nmCluster
Coupling.variationPoint.shortLabel
vh.latestBindingTime=postBuild
nmIfEcu NmEcu * aggr Collection of NM ECUs
atpVariation: Derived, because EcuInstance can be
variable.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=nmIfEcu.shortName, nmIfEcu.variation
Point.shortLabel
vh.latestBindingTime=preCompileTime

Table 6.246: NmConfig

Class NmCluster (abstract)

Package M2::AUTOSARTemplates::SystemTemplate::NetworkManagement
Note Set of NM nodes coordinated with use of the NM algorithm.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Subclasses CanNmCluster, FlexrayNmCluster, J1939NmCluster, UdpNmCluster
Attribute Type Mult. Kind Note
communication CommunicationCluster 0..1 ref Association to a CommunicationCluster in the topology
Cluster description.
nmChannel Boolean 0..1 attr This parameter shall be set to indicate if the sleep of this
SleepMaster network can be absolutely decided by the local node only
and that no other nodes can oppose that decision.
nmNode NmNode * aggr Collection of NmNodes of the NmCluster.
atpVariation: Derived, because NmNode can be variable.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
nmNode Boolean 0..1 attr Enables the Request Repeat Message Request support.
Detection Only valid if nmNodeIdEnabled is set to true.
Enabled
5

535 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class NmCluster (abstract)
nmNodeId Boolean 0..1 attr Enables the source node identifier.
Enabled
nmPnc Boolean 0..1 attr Defines whether this NmCluster contributes to the partial
Participation network mechanism.
nmRepeatMsg Boolean 0..1 attr Switch for enabling the Repeat Message Bit Indication.
IndEnabled
nm Boolean 0..1 attr If this parameter is true, then this network is a
Synchronizing synchronizing network for the NM coordination cluster
Network which it belongs to. The network is expected to call Nm_
SynchronizationPoint() at regular intervals.
pncCluster PositiveInteger 0..1 attr Optionally defines the length of the PNC Vector per
VectorLength CommunicationCluster (and VLAN in case of UdpNm). If
not defined then System.pncVectorLength applies.
Should only make the PNC Vector shorter (or same
length as defined in System.pncVectorLength).
Tags:atp.Status=draft

Table 6.247: NmCluster

For the placement of user data in an NmPdu several boundaries and constraints have
to be respected.
[TPS_SYST_03069] User data shall be defined within empty space of the NmPdu
dIf user data is defined it shall be located within the not already used bounds of the
NmPdu, specifically user data shall:
• not exceed NmPdu.length
• not be defined in the location where CBV and/or Nid are defined (nmCbvPosi-
tion and nmNidPosition are configured
• not be defined where the PncBitVector is located.
c()
[TPS_SYST_03070] User data shall be before the PncBitVector or after the
PncBitVector dIf NmCluster.nmPncParticipation is set to true then user data
shall be placed either:
• between CBV (control bit vector) and PncBitVector or
• after the PncBitVector.
There shall not be two sections with user data in one NmPdu if PncBitVector (one before
the PncBitVector and one after the PncBitVector).c()
[TPS_SYST_03071] Available space of user data with PncBitVector dIf NmClus-
ter.nmPncParticipation is set to true (i.e. partial network is enabled on that
NmCluster) then user data may be defined in the range:
• if the user data is mapped between the NM system bytes (CBV, Nid) and the
PncBitVector, then the size of user data range is determined by the difference

536 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

between System.pncVectorOffset and the length of the system bytes (Nid,

CBV).
• if the user data is mapped after the PncBitVector, then the size of user data range
is determined by the difference between NmPdu.length and the last byte position
of the PncBitVector.
c()
[TPS_SYST_03072] Available space of user data without PncBitVector dIf Nm-
Cluster.nmPncParticipation is set to false (i.e. no partial network is enabled on
that NmCluster) then user data may be defined in the range between the NM system
bytes (CBV, Nid) and the end of the NmPdu. The size of user data range is determined
by the difference between NmPdu.length and the length of the system bytes (Nid,
CBV).c()
[constr_3044] CBV configuration in case partial network is used dIn case a partial
network is used the control bit vector (CBV) shall be defined in Byte 0 of the NmPdu (
nmCbvPosition = 0).c()
[constr_3227] NmNode.nmPassiveModeEnabled setting dNmNode.nmPassive-
ModeEnabled shall be set to the same value in all NmClusters with the same bus
protocol in the scope of one NmEcu.c()
Class NmEcu
Package M2::AUTOSARTemplates::SystemTemplate::NetworkManagement
Note ECU on which NM is running.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
busDependent BusspecificNmEcu * aggr Cluster specific NmEcu attributes
NmEcu
ecuInstance EcuInstance 1 ref Association to an ECUInstance in the topology
description.
nmBus Boolean 0..1 attr Enables bus synchronization support.
Synchronization
Enabled
nmComControl Boolean 0..1 attr Enables the Communication Control support.
Enabled
nmCoordinator NmCoordinator 0..1 aggr Nm ECU may coordinate different clusters.
nmCycletime TimeValue 0..1 attr The period between successive calls to the Main Function
MainFunction of the NM Interface in seconds.
nmPduRx Boolean 0..1 attr Switch for enabling the PDU Rx Indication.
Indication
Enabled
nmRemote Boolean 0..1 attr Switch for enabling remote sleep indication support.
SleepInd
Enabled
nmStateChange Boolean 0..1 attr Enables the CAN Network Management state change
IndEnabled notification.
nmUserData Boolean 0..1 attr Switch for enabling user data support.
Enabled
Table 6.248: NmEcu

537 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class BusspecificNmEcu (abstract)

Package M2::AUTOSARTemplates::SystemTemplate::NetworkManagement
Note Busspecific NmEcu attributes.
Base ARObject
Subclasses CanNmEcu, FlexrayNmEcu, J1939NmEcu, UdpNmEcu
Attribute Type Mult. Kind Note
– – – – –
Table 6.249: BusspecificNmEcu

Class NmCoordinator
Package M2::AUTOSARTemplates::SystemTemplate::NetworkManagement
Note A NM coordinator is an ECU, which is connected to at least two busses, and where the requirement
exists that shutdown of NM of at least two of these busses (also referred to as coordinated busses) has
to be performed synchronously.
Base ARObject
Attribute Type Mult. Kind Note
index Integer 0..1 attr Identification of the NMCoordinator.
nmCoordSync Boolean 0..1 attr Switch for enabling NmCoordinatorSync (coordination of
Support nested busses) support.
nmGlobal TimeValue 0..1 attr This attribute defines the maximum shutdown time (in
Coordinator seconds) of a connected and coordinated NM-Cluster.
Time
nmNode NmNode * ref reference to busses (via NmNodes) that are coordinated
by the NmCoordinator.

Table 6.250: NmCoordinator

Class NmNode (abstract)

Package M2::AUTOSARTemplates::SystemTemplate::NetworkManagement
Note The linking of NmEcus to NmClusters is realized via the NmNodes.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Subclasses CanNmNode, FlexrayNmNode, J1939NmNode, UdpNmNode
Attribute Type Mult. Kind Note
controller Communication 0..1 ref Association to an CommunicationController in the
Controller topology description.
nmCoord PositiveInteger 0..1 attr NmCoordinationCluster identification number.
Cluster
nmCoordinator NmCoordinatorRole 0..1 attr This attribute indicates the role the NM Coordinator will
Role Enum have on this channel.
nmIfEcu NmEcu 0..1 ref Reference to the NmEcu that contains this NmNode.
(CommunicationController that is referenced by the Nm
Node shall be contained in the EcuInstance that is
referenced by the NmEcu).
nmNodeId Integer 0..1 attr Node identifier of local NmNode. Shall be unique in the
NmCluster.
nmPassive Boolean 0..1 attr Enables support of the Passive Mode. The passive mode
ModeEnabled is configurable per channel.
rxNmPdu NmPdu * ref receive NM Pdu.
txNmPdu NmPdu * ref transmit NM Pdu

Table 6.251: NmNode

538 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Enumeration NmCoordinatorRoleEnum
Package M2::AUTOSARTemplates::SystemTemplate::NetworkManagement
Note Supported NmCoordinator roles.
Literal Description
Active Coordinator which "actively" performs NmCoordinator functionality at this channel
Tags:atp.EnumerationLiteralIndex=0
Passive Coordinator which "passively" performs NmCoordinator functionality at this channel - used at Nm
CoordinatorSync use case.
Tags:atp.EnumerationLiteralIndex=1

Table 6.252: NmCoordinatorRoleEnum

Class NmClusterCoupling (abstract)

Package M2::AUTOSARTemplates::SystemTemplate::NetworkManagement
Note Attributes that are valid for each of the referenced (coupled) clusters.
Base ARObject
Subclasses CanNmClusterCoupling, FlexrayNmClusterCoupling, UdpNmClusterCoupling
Attribute Type Mult. Kind Note
– – – – –
Table 6.253: NmClusterCoupling

539 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.9.1 FlexRay Network Management

The following class tables specify the configuration parameters of FlexRay Nm.
Identifiable

FibexElement NmEcu

NmConfig +nmIfEcu + nmBusSynchronizationEnabled: Boolean [0..1]

«atpVariation,atpSplitable» 0..* + nmComControlEnabled: Boolean [0..1]
+ nmCycletimeMainFunction: TimeValue [0..1]
+ nmPduRxIndicationEnabled: Boolean [0..1]
+ nmRemoteSleepIndEnabled: Boolean [0..1]
+ nmStateChangeIndEnabled: Boolean [0..1]
+ nmUserDataEnabled: Boolean [0..1]
«atpVariation,atpSplitable» «atpVariation,atpSplitable»

+nmCluster +nmClusterCoupling 0..*

0..*
Identifiable NmClusterCoupling
NmCluster

+ nmChannelSleepMaster: Boolean [0..1] +nmCoordinator 0..1 +nmIfEcu 0..1

+ nmNodeDetectionEnabled: Boolean [0..1]
+ nmNodeIdEnabled: Boolean [0..1] NmCoordinator

+busDependentNmEcu
+ nmPncParticipation: Boolean [0..1] + index: Integer [0..1]
+ nmRepeatMsgIndEnabled: Boolean [0..1] + nmCoordSyncSupport: Boolean [0..1]
+ nmSynchronizingNetwork: Boolean [0..1] + nmGlobalCoordinatorTime: TimeValue [0..1]
+ pncClusterVectorLength: PositiveInteger [0..1]

0..*

FlexrayNmCluster FlexrayNmClusterCoupling BusspecificNmEcu

+ nmCarWakeUpBitPosition: PositiveInteger [0..1] + nmScheduleVariant: FlexrayNmScheduleVariant

+ nmCarWakeUpFilterEnabled: Boolean [0..1]
+ nmCarWakeUpFilterNodeId: PositiveInteger [0..1]
+ nmCarWakeUpRxEnabled: Boolean [0..1]
+ nmDataCycle: Integer
+ nmMainFunctionPeriod: TimeValue [0..1]
+ nmRemoteSleepIndicationTime: TimeValue FlexrayNmEcu
+ nmRepeatMessageTime: TimeValue
+ nmRepetitionCycle: Integer +coupledCluster + nmHwVoteEnabled: Boolean [0..1]
+ nmVotingCycle: Integer + nmMainFunctionAcrossFrCycle: Boolean [0..1]
*

«atpVariation»
+nmNode 0..*

Identifiable
NmNode

+ nmCoordCluster: PositiveInteger [0..1] FlexrayNmNode

+ nmCoordinatorRole: NmCoordinatorRoleEnum [0..1]
+nmNode + nmNodeId: Integer [0..1]
0..* + nmPassiveModeEnabled: Boolean [0..1]

FibexElement
«atpVariation»
CommunicationCluster +controller 0..1
+communicationCluster
+ baudrate: PositiveUnlimitedInteger [0..1] Identifiable
0..1 + protocolName: String [0..1] «atpVariation»
+ protocolVersion: String [0..1] CommunicationController

+ wakeUpByControllerSupported: Boolean [0..1]

Identifiable
+txNmPdu 0..* +rxNmPdu 0..*
ISignalToIPduMapping
Pdu «enumeration»
+ packingByteOrder: ByteOrderEnum [0..1]
NmPdu FlexrayNmScheduleVariant
+ startPosition: UnlimitedInteger [0..1]
+iSignalToIPduMapping
+ transferProperty: TransferPropertyEnum [0..1] + nmDataInformation: Boolean [0..1] scheduleVariant1
+ updateIndicationBitPosition: UnlimitedInteger [0..1] 0..* + nmVoteInformation: Boolean [0..1] scheduleVariant2
+ unusedBitPattern: Integer [0..1] scheduleVariant3
scheduleVariant4
scheduleVariant5
scheduleVariant6
scheduleVariant7

Figure 6.73: FlexRay Network Management Configuration (TransportProtocols: Nm-

FlexRayConfiguration)

540 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class FlexrayNmCluster
Package M2::AUTOSARTemplates::SystemTemplate::NetworkManagement
Note FlexRay specific NM cluster attributes.
Base ARObject, Identifiable, MultilanguageReferrable, NmCluster , Referrable
Attribute Type Mult. Kind Note
nmCarWakeUp PositiveInteger 0..1 attr Specifies the bit position of the CarWakeUp within the Nm
BitPosition Pdu.
nmCarWakeUp Boolean 0..1 attr If this attribute is set to true the CareWakeUp filtering is
FilterEnabled supported. In this case only the CarWakeUp bit within the
NmPdu with source node identifier nmCarWakeUpFilter
NodeId is considered as CarWakeUp request.
nmCarWakeUp PositiveInteger 0..1 attr Source node identifier for CarWakeUp filtering. If Car
FilterNodeId WakeUp filtering is supported (nmCarWakeUpFilter
Enabled), only the CarWakeUp bit within the NmPdu with
source node identifier nmCarWakeUpFilterNodeId is
considered as CarWakeUp request.
nmCarWakeUp Boolean 0..1 attr If set to true this attribute enables the support of CarWake
RxEnabled Up bit evaluation in received NmPdus.
nmDataCycle Integer 1 attr Number of FlexRay Communication Cycles needed to
transmit the Nm Data PDUs of all FlexRay Nm Ecus of
this FlexRayNmCluster.
nmMain TimeValue 0..1 attr Defines the processing cycle of the main function of FrNm
FunctionPeriod module.
nmRemote TimeValue 1 attr Timeout for Remote Sleep Indication in seconds. It
SleepIndication defines the time how long it shall take to recognize that all
Time other nodes are ready to sleep.
nmRepeat TimeValue 1 attr Timeout for Repeat Message State in seconds. Defines
MessageTime the time how long the NM shall stay in the Repeat
Message State.
nmRepetition Integer 1 attr Number of FlexRay Communication Cycles used to
Cycle repeat the transmission of the Nm vote Pdus of all Flex
Ray NmEcus of this FlexRayNmCluster. This value shall
be an integral multiple of nmVotingCycle.
nmVotingCycle Integer 1 attr Number of FlexRay CommunicationCycles needed to
transmit the Nm vote of Pdus of all FlexRay NmEcus of
this FlexRayNmCluster.

Table 6.254: FlexrayNmCluster

Class FlexrayNmEcu
Package M2::AUTOSARTemplates::SystemTemplate::NetworkManagement
Note FlexRay specific attributes.
Base ARObject, BusspecificNmEcu
Attribute Type Mult. Kind Note
nmHwVote Boolean 0..1 attr Switch for enabling the processing of FlexRay Hardware
Enabled aggregated NM-Votes.
nmMain Boolean 0..1 attr Parameter describing if the execution of the FrNm_Main
FunctionAcross function crosses theFlexRay cycle boundary or not.
FrCycle

Table 6.255: FlexrayNmEcu

541 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class FlexrayNmClusterCoupling
Package M2::AUTOSARTemplates::SystemTemplate::NetworkManagement
Note FlexRay attributes that are valid for each of the referenced (coupled) FlexRay clusters.
Base ARObject, NmClusterCoupling
Attribute Type Mult. Kind Note
coupledCluster FlexrayNmCluster * ref Reference to coupled FlexRay Clusters.
nmSchedule FlexrayNmSchedule 1 attr FrNm schedule variant according to FrNm SWS.
Variant Variant
Table 6.256: FlexrayNmClusterCoupling

Class FlexrayNmNode
Package M2::AUTOSARTemplates::SystemTemplate::NetworkManagement
Note FlexRay specific NM Node attributes.
Base ARObject, Identifiable, MultilanguageReferrable, NmNode, Referrable
Attribute Type Mult. Kind Note
– – – – –
Table 6.257: FlexrayNmNode

Enumeration FlexrayNmScheduleVariant
Package M2::AUTOSARTemplates::SystemTemplate::NetworkManagement
Note FrNm schedule variant according to FrNm SWS.
Literal Description
scheduleVariant1 NM-Vote and NM Data transmitted within one PDU in static segment. The NM-Vote has to be realized
as separate bit within the PDU.
Tags:atp.EnumerationLiteralIndex=0
scheduleVariant2 NM-Vote and NM-Data transmitted within one PDU in dynamic segment. The presence (or
non-presence) of the PDU corresponds to the NM-Vote
Tags:atp.EnumerationLiteralIndex=1
scheduleVariant3 NM-Vote and NM-Data are transmitted in the static segment in separate PDUs. This alternative is not
recommended => Alternative 1 should be used instead.
Tags:atp.EnumerationLiteralIndex=2
scheduleVariant4 NM-Vote transmitted in static and NM-Data transmitted in dynamic segment.
Tags:atp.EnumerationLiteralIndex=3
scheduleVariant5 NM-Vote is transmitted in dynamic and NM-Data is transmitted in static segment. This alternative is
not recommended => Variants 2 or 6 should be used instead.
Tags:atp.EnumerationLiteralIndex=4
scheduleVariant6 NM-Vote and NM-Data are transmitted in dynamic segment in separate PDUs.
Tags:atp.EnumerationLiteralIndex=5
scheduleVariant7 NM-Vote and a copy of the CBV are transmitted in the static segment (using the FlexRay NM Vector
support) and NM-Data is transmitted in the dynamic segment
Tags:atp.EnumerationLiteralIndex=6

Table 6.258: FlexrayNmScheduleVariant

542 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.9.2 CAN Network Management

The following class tables specify the configuration parameters of CAN Nm.
Identifiable
FibexElement NmEcu
NmConfig +nmIfEcu
+ nmBusSynchronizationEnabled: Boolean [0..1]
«atpVariation,atpSplitable» 0..* + nmComControlEnabled: Boolean [0..1]
+ nmCycletimeMainFunction: TimeValue [0..1]
+ nmPduRxIndicationEnabled: Boolean [0..1]
+ nmRemoteSleepIndEnabled: Boolean [0..1]
+ nmStateChangeIndEnabled: Boolean [0..1]
+ nmUserDataEnabled: Boolean [0..1]
«atpVariation,atpSplitable» «atpVariation,atpSplitable»
+nmCluster 0..* +nmClusterCoupling 0..*
Identifiable
NmClusterCoupling
NmCluster

+ nmChannelSleepMaster: Boolean [0..1] 0..1

+nmIfEcu
+ nmNodeDetectionEnabled: Boolean [0..1]

+busDependentNmEcu
+ nmNodeIdEnabled: Boolean [0..1]
+ nmPncParticipation: Boolean [0..1]
+ nmRepeatMsgIndEnabled: Boolean [0..1]
+ nmSynchronizingNetwork: Boolean [0..1] 0..1
+nmCoordinator
+ pncClusterVectorLength: PositiveInteger [0..1]
NmCoordinator

+ index: Integer [0..1] 0..*

+ nmCoordSyncSupport: Boolean [0..1]
CanNmCluster + nmGlobalCoordinatorTime: TimeValue [0..1] BusspecificNmEcu

+ nmBusloadReductionActive: Boolean
+ nmCarWakeUpBitPosition: PositiveInteger [0..1]
+ nmCarWakeUpFilterNodeId: PositiveInteger [0..1]
+ nmCbvPosition: Integer [0..1]
+ nmImmediateNmCycleTime: TimeValue [0..1] CanNmClusterCoupling
+ nmImmediateNmTransmissions: PositiveInteger
+ nmBusloadReductionEnabled: Boolean
+ nmMessageTimeoutTime: TimeValue
+ nmImmediateRestartEnabled: Boolean
+ nmMsgCycleTime: TimeValue
+ nmNetworkTimeout: TimeValue
CanNmEcu
+ nmNidPosition: Integer [0..1]
+ nmRemoteSleepIndicationTime: TimeValue
+ nmRepeatMessageTime: TimeValue +coupledCluster
+ nmWaitBusSleepTime: TimeValue
*

+nmNode 0..*
«atpVariation»
Identifiable
NmNode

+ nmCoordCluster: PositiveInteger [0..1]

+ nmCoordinatorRole: NmCoordinatorRoleEnum [0..1]
+nmNode + nmNodeId: Integer [0..1]
+ nmPassiveModeEnabled: Boolean [0..1]
+communicationCluster 0..*
0..1

FibexElement
+txNmPdu 0..* +rxNmPdu 0..*
«atpVariation»
CommunicationCluster Pdu CanNmNode
+ baudrate: PositiveUnlimitedInteger [0..1] NmPdu
+ allNmMessagesKeepAwake: Boolean [0..1]
+ protocolName: String [0..1] + nmDataInformation: Boolean [0..1] + nmCarWakeUpFilterEnabled: Boolean [0..1]
+ protocolVersion: String [0..1] + nmVoteInformation: Boolean [0..1] + nmCarWakeUpRxEnabled: Boolean [0..1]
+ unusedBitPattern: Integer [0..1] + nmMsgCycleOffset: TimeValue
+ nmMsgReducedTime: TimeValue

+iSignalToIPduMapping 0..*
Identifiable
ISignalToIPduMapping

+ packingByteOrder: ByteOrderEnum [0..1]

+ startPosition: UnlimitedInteger [0..1]
+ transferProperty: TransferPropertyEnum [0..1]
+ updateIndicationBitPosition: UnlimitedInteger [0..1]

Figure 6.74: CAN Network Management Configuration (TransportProtocols: NmCanCon-

figuration)

543 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class CanNmCluster
Package M2::AUTOSARTemplates::SystemTemplate::NetworkManagement
Note Can specific NmCluster attributes
Base ARObject, Identifiable, MultilanguageReferrable, NmCluster , Referrable
Attribute Type Mult. Kind Note
nmBusload Boolean 1 attr It determines if bus load reduction for the respective Can
ReductionActive Nm channel is active or not.
nmCarWakeUp PositiveInteger 0..1 attr Specifies the bit position of the CarWakeUp within the Nm
BitPosition Pdu.
nmCarWakeUp PositiveInteger 0..1 attr Source node identifier for CarWakeUp filtering.
FilterNodeId
nmCbvPosition Integer 0..1 attr Defines the position of the control bit vector within the Nm
Pdu (Byte position). If this attribute is not configured, the
Control Bit Vector is not used.
nmImmediate TimeValue 0..1 attr Defines the immediate NmPdu cycle time in seconds
NmCycleTime which is used for nmImmediateNmTransmissions NmPdu
transmissions. This parameter is only valid if CanNm
ImmediateNmTransmissions is greater one.
nmImmediate PositiveInteger 1 attr Defines the number of immediate NmPdus which shall be
Nm transmitted. If the value is zero no immediate NmPdus
Transmissions are transmitted. The cycle time of immediate NmPdus is
defined by nmImmediateNmCycleTime.
nmMessage TimeValue 1 attr Timeout of an NmPdu in seconds. It determines how long
TimeoutTime the NM shall wait with notification of transmission failure
while communication errors occur on the bus.
nmMsgCycle TimeValue 1 attr Period of a NmPdu in seconds. It determines the periodic
Time rate in the periodic transmission mode with bus load
reduction and is the basis for transmit scheduling in the
periodic transmission mode without bus load reduction.
nmNetwork TimeValue 1 attr Network Timeout for NmPdus in seconds It denotes the
Timeout time how long the CanNm shall stay in the Network Mode
before transition into Prepare Bus-Sleep Mode shall take
place.
nmNidPosition Integer 0..1 attr Defines the byte position of the source node identifier
within the NmPdu. If this attribute is not configured, the
Node Identification is not used.
nmRemote TimeValue 1 attr Timeout for Remote Sleep Indication in seconds. It
SleepIndication defines the time how long it shall take to recognize that all
Time other nodes are ready to sleep.
nmRepeat TimeValue 1 attr Timeout for Repeat Message State in seconds. Defines
MessageTime the time how long the NM shall stay in the Repeat
Message State.
nmWaitBus TimeValue 1 attr Timeout for bus calm down phase in seconds. It denotes
SleepTime the time how long the CanNm shall stay in the Prepare
Bus-Sleep Mode before transition into Bus-Sleep Mode
shall take place.

Table 6.259: CanNmCluster

[constr_3069] Allowed CanNmCluster.nmNidPosition values dIf defined, the

value of CanNmCluster.nmNidPosition shall only be set to either 0 or 1.c()
[constr_3070] Allowed CanNmCluster.nmCbvPosition values dIf defined, the
value of CanNmCluster.nmCbvPosition shall only be set to either 0 or 1.c()

544 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_3071] CanNmCluster.nmCbvPosition and CanNmCluster.nmNidPosi-

tion shall never have the same value dCanNmCluster.nmCbvPosition and Can-
NmCluster.nmNidPosition shall never have the same value.c()
Class CanNmEcu
Package M2::AUTOSARTemplates::SystemTemplate::NetworkManagement
Note CAN specific attributes.
Base ARObject, BusspecificNmEcu
Attribute Type Mult. Kind Note
– – – – –
Table 6.260: CanNmEcu

Class CanNmClusterCoupling
Package M2::AUTOSARTemplates::SystemTemplate::NetworkManagement
Note CAN attributes that are valid for each of the referenced (coupled) CAN clusters.
Base ARObject, NmClusterCoupling
Attribute Type Mult. Kind Note
coupledCluster CanNmCluster * ref Reference to coupled CAN Clusters.
nmBusload Boolean 1 attr Enables busload reduction support
Reduction
Enabled
nmImmediate Boolean 1 attr Enables the asynchronous transmission of a CanNm
RestartEnabled PDU upon bus-communication request in
Prepare-Bus-Sleep mode.

Table 6.261: CanNmClusterCoupling

Class CanNmNode
Package M2::AUTOSARTemplates::SystemTemplate::NetworkManagement
Note CAN specific NM Node attributes.
Base ARObject, Identifiable, MultilanguageReferrable, NmNode, Referrable
Attribute Type Mult. Kind Note
allNmMessages Boolean 0..1 attr Specifies if Nm drops irrelevant NM PDUs.
KeepAwake
false: Only NM PDUs with a Partial Network Information
Bit (PNI) = true and containing a Partial Network request
for this ECU trigger the standard RX indication handling
and thus keep the ECU awake
true: Every NM PDU triggers the standard RX indication
handling and keeps the ECU awake
nmCarWakeUp Boolean 0..1 attr If this attribute is set to true the CareWakeUp filtering is
FilterEnabled supported.
nmCarWakeUp Boolean 0..1 attr If set to true this attribute enables the support of CarWake
RxEnabled Up bit evaluation in received NmPdus.
nmMsgCycle TimeValue 1 attr Node specific time offset in the periodic transmission
Offset node. It determines the start delay of the transmission.
Specified in seconds.
nmMsg TimeValue 1 attr Node specific bus cycle time in the periodic transmission
ReducedTime mode with bus load reduction. Specified in seconds.

Table 6.262: CanNmNode

545 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.9.3 UDP Network Management

The UPD Nm model is similar to the Nm models of the other communication buses
but there are some specific characteristics due to the modeling of EthernetCluster
and EthernetPhysicalChannel (see also chapter 3.3.6).
The UdpNmCluster corresponds to one EthernetPhysicalChannel (VLAN).
Therefore it is required that for each EthernetPhysicalChannel on one Ether-
netCluster a respective UdpNmCluster with a reference to the EthernetPhysi-
calChannel is created. All of these UdpNmClusters point to the same Ethernet-
Cluster which the EthernetPhysicalChannels are contained in.
Thus, additionally to the reference from NmCluster to the CommunicationCluster
(which applies to all Nm models), there is need for an Ethernet specific reference from
the UdpNmCluster to the EthernetPhysicalChannel. This allows to specify for
which VLAN this UdpNmCluster applies.
FibexElement +physicalChannel Identifiable
+managedPhysicalChannel 0..*
«atpVariation» «atpVariation,atpSplitable» 1..* PhysicalChannel
CommunicationCluster

+ baudrate: PositiveUnlimitedInteger [0..1]

+ protocolName: String [0..1]
+ protocolVersion: String [0..1]

+communicationCluster 0..1

Identifiable
NmCluster EthernetPhysicalChannel
+ nmChannelSleepMaster: Boolean [0..1]
+ nmNodeDetectionEnabled: Boolean [0..1] +vlan 0..1
+ nmNodeIdEnabled: Boolean [0..1]
+ nmPncParticipation: Boolean [0..1]
+ nmRepeatMsgIndEnabled: Boolean [0..1]
+ nmSynchronizingNetwork: Boolean [0..1]
+ pncClusterVectorLength: PositiveInteger [0..1]

UdpNmCluster

+ nmCbvPosition: Integer [0..1]

+ nmImmediateNmCycleTime: TimeValue [0..1]
+ nmImmediateNmTransmissions: PositiveInteger [0..1]
+ nmMessageTimeoutTime: TimeValue [0..1]
+ nmMsgCycleTime: TimeValue [0..1]
+ nmNetworkTimeout: TimeValue [0..1]
+ nmNidPosition: Integer [0..1]
+ nmRemoteSleepIndicationTime: TimeValue [0..1]
+ nmRepeatMessageTime: TimeValue [0..1]
+ nmWaitBusSleepTime: TimeValue [0..1]

Figure 6.75: UdpNmCluster structure

The following class tables specify the configuration parameters of UDP Nm.

546 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

FibexElement
NmConfig

«atpVariation,atpSplitable» «atpVariation,atpSplitable»
+nmCluster 0..* +nmClusterCoupling 0..* «atpVariation,atpSplitable»

Identifiable
NmClusterCoupling +nmIfEcu 0..*
NmCluster
+nmIfEcu
Identifiable
+ nmChannelSleepMaster: Boolean [0..1]
+ nmNodeDetectionEnabled: Boolean [0..1] NmEcu 0..1
+ nmNodeIdEnabled: Boolean [0..1]
+ nmBusSynchronizationEnabled: Boolean [0..1]
+ nmPncParticipation: Boolean [0..1]
+ nmComControlEnabled: Boolean [0..1]
+ nmRepeatMsgIndEnabled: Boolean [0..1]
+ nmCycletimeMainFunction: TimeValue [0..1]
+ nmSynchronizingNetwork: Boolean [0..1]
+ nmPduRxIndicationEnabled: Boolean [0..1]
+ pncClusterVectorLength: PositiveInteger [0..1]
+ nmRemoteSleepIndEnabled: Boolean [0..1]
+ nmStateChangeIndEnabled: Boolean [0..1]
+ nmUserDataEnabled: Boolean [0..1]

PhysicalChannel
EthernetPhysicalChannel

+vlan 0..1

UdpNmCluster

+ nmCbvPosition: Integer [0..1]

+ nmImmediateNmCycleTime: TimeValue [0..1]
+ nmImmediateNmTransmissions: PositiveInteger [0..1] +nmCoordinator 0..1 +busDependentNmEcu 0..*
+ nmMessageTimeoutTime: TimeValue [0..1]
+ nmMsgCycleTime: TimeValue [0..1] NmCoordinator BusspecificNmEcu
+ nmNetworkTimeout: TimeValue [0..1]
+ nmNidPosition: Integer [0..1] + index: Integer [0..1]
+ nmRemoteSleepIndicationTime: TimeValue [0..1] + nmCoordSyncSupport: Boolean [0..1]
+ nmRepeatMessageTime: TimeValue [0..1] + nmGlobalCoordinatorTime: TimeValue [0..1]
+ nmWaitBusSleepTime: TimeValue [0..1]

UdpNmEcu
«atpVariation» +coupledCluster 0..*
+communicationCluster

UdpNmClusterCoupling

+ nmImmediateRestartEnabled: Boolean [0..1]

FibexElement
«atpVariation»
CommunicationCluster
0..1 + +nmNode 0..*
baudrate: PositiveUnlimitedInteger [0..1]
+ protocolName: String [0..1] Identifiable
+ protocolVersion: String [0..1] NmNode

+ nmCoordCluster: PositiveInteger [0..1]

+nmNode + nmCoordinatorRole: NmCoordinatorRoleEnum [0..1]
+ nmNodeId: Integer [0..1]
0..* + nmPassiveModeEnabled: Boolean [0..1]

Pdu +txNmPdu
NmPdu 0..* UdpNmNode
+rxNmPdu
+ nmDataInformation: Boolean [0..1] + allNmMessagesKeepAwake: Boolean [0..1]
+ nmVoteInformation: Boolean [0..1] 0..* + nmMsgCycleOffset: TimeValue [0..1]
+ unusedBitPattern: Integer [0..1]

+controller 0..1
+iSignalToIPduMapping 0..*
Identifiable
Identifiable
«atpVariation»
ISignalToIPduMapping CommunicationController
+ packingByteOrder: ByteOrderEnum [0..1] + wakeUpByControllerSupported: Boolean [0..1]
+ startPosition: UnlimitedInteger [0..1]
+ transferProperty: TransferPropertyEnum [0..1]
+ updateIndicationBitPosition: UnlimitedInteger [0..1]

Figure 6.76: UDP Network Management Configuration (TransportProtocols: NmUdpCon-

figuration)

547 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class UdpNmCluster
Package M2::AUTOSARTemplates::SystemTemplate::NetworkManagement
Note Udp specific NmCluster attributes
Base ARObject, Identifiable, MultilanguageReferrable, NmCluster , Referrable
Attribute Type Mult. Kind Note
nmCbvPosition Integer 0..1 attr Defines the position of the control bit vector within the Nm
Pdu (Byte position). If this attribute is not configured, the
Control Bit Vector is not used.
nmImmediate TimeValue 0..1 attr Defines the immediate NmPdu cycle time in seconds
NmCycleTime which is used for nmImmediateNmTransmissions NmPdu
transmissions. This attribute is only valid if nmImmediate
NmTransmissions is greater one.
nmImmediate PositiveInteger 0..1 attr Defines the number of immediate NmPdus which shall be
Nm transmitted. If the value is zero no immediate NmPdus
Transmissions are transmitted. The cycle time of immediate NmPdus is
defined by nmImmediateNmCycleTime.
nmMessage TimeValue 0..1 attr Timeout of a NmPdu in seconds. It determines how long
TimeoutTime the NM shall wait with notification of transmission failure
while communication errors occur on the bus.
nmMsgCycle TimeValue 0..1 attr Period of a NmPdu in seconds. It determines the periodic
Time rate in the periodic transmission mode with bus load
reduction and is the basis for transmit scheduling in the
periodic transmission mode without bus load reduction.
nmNetwork TimeValue 0..1 attr Network Timeout for NmPdus in seconds. It denotes the
Timeout time how long the UdpNm shall stay in the Network Mode
before transition into Prepare Bus-Sleep Mode shall take
place.
nmNidPosition Integer 0..1 attr Defines the byte position of the source node identifier
within the NmPdu. If this attribute is not configured, the
Node Identification is not used.
nmRemote TimeValue 0..1 attr Timeout for Remote Sleep Indication in seconds. It
SleepIndication defines the time how long it shall take to recognize that all
Time other nodes are ready to sleep.
nmRepeat TimeValue 0..1 attr Timeout for Repeat Message State in seconds. Defines
MessageTime the time how long the NM shall stay in the Repeat
Message State.
nmWaitBus TimeValue 0..1 attr Timeout for bus calm down phase in seconds. It denotes
SleepTime the time how long the CanNm shall stay in the Prepare
Bus-Sleep Mode before transition into Bus-Sleep Mode
shall take place.
vlan EthernetPhysical 0..1 ref Reference to the vlan (represented by the Ethernet
Channel PhysicalChannel) this UdpNmCluster shall apply to.

Table 6.263: UdpNmCluster

[constr_3078] Allowed UdpNmCluster.nmNidPosition values dIf defined, the

value of UdpNmCluster.nmNidPosition shall only be set to either 0 or 1.c()
[constr_3079] Allowed UdpNmCluster.nmCbvPosition values dIf defined, the
value of UdpNmCluster.nmCbvPosition shall only be set to either 0 or 1.c()
[constr_3080] UdpNmCluster.nmCbvPosition and UdpNmCluster.nmNidPosi-
tion shall never have the same value dUdpNmCluster.nmCbvPosition and Udp-
NmCluster.nmNidPosition shall never have the same value.c()

548 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_5222] Mandatory elements of UdpNmCluster dThe following attributes

shall always be defined for the UdpNmCluster:
• nmMsgCycleTime
• nmMessageTimeoutTime
• nmNetworkTimeout
• nmRemoteSleepIndicationTime
• nmRepeatMessageTime
• nmWaitBusSleepTime
• communicationCluster
c()
Class UdpNmEcu
Package M2::AUTOSARTemplates::SystemTemplate::NetworkManagement
Note Udp NM specific ECU attributes.
Base ARObject, BusspecificNmEcu
Attribute Type Mult. Kind Note
– – – – –
Table 6.264: UdpNmEcu

Class UdpNmClusterCoupling
Package M2::AUTOSARTemplates::SystemTemplate::NetworkManagement
Note Udp attributes that are valid for each of the referenced (coupled) UdpNm clusters.
Base ARObject, NmClusterCoupling
Attribute Type Mult. Kind Note
coupledCluster UdpNmCluster * ref Reference to coupled UdpNm Clusters.
nmImmediate Boolean 0..1 attr Enables the asynchronous transmission of a CanNm
RestartEnabled PDU upon bus-communication request in
Prepare-Bus-Sleep mode.

Table 6.265: UdpNmClusterCoupling

Class UdpNmNode
Package M2::AUTOSARTemplates::SystemTemplate::NetworkManagement
Note Udp specific NM Node attributes.
Base ARObject, Identifiable, MultilanguageReferrable, NmNode, Referrable
Attribute Type Mult. Kind Note
5

549 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class UdpNmNode
allNmMessages Boolean 0..1 attr Specifies if Nm drops irrelevant NM PDUs.
KeepAwake
false: Only NM PDUs with a Partial Network Information
Bit (PNI) = true and containing a Partial Network request
for this ECU trigger the standard RX indication handling
and thus keep the ECU awake
true: Every NM PDU triggers the standard RX indication
handling and keeps the ECU awake
nmMsgCycle TimeValue 0..1 attr Node specific time offset in the periodic transmission
Offset node. It determines the start delay of the transmission.
Specified in seconds.

Table 6.266: UdpNmNode

[constr_5223] Mandatory elements of UdpNmNode dThe following attributes shall

always be defined for the UdpNmNode:
• nmMsgCycleOffset
c()
[constr_5224] UdpNmNode.nmMsgCycleOffset < UdpNmCluster.nmMsgCycle-
Time dThe value of UdpNmNode.nmMsgCycleOffset shall be smaller than the value
of UdpNmCluster.nmMsgCycleTime.c()
[constr_5225] UdpNmCluster.nmNetworkTimeout multiple of UdpNmCluster.
nmMsgCycleTime dThe value of UdpNmCluster.nmNetworkTimeout shall be n *
UdpNmCluster.nmMsgCycleTime with n > 1.c()
[constr_5226] UdpNmCluster.nmRepeatMessageTime multiple of UdpNmClus-
ter.nmMsgCycleTime dThe value of UdpNmCluster.nmRepeatMessageTime shall
be n * UdpNmCluster.nmMsgCycleTime.c()

550 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.9.4 J1939 Network Management

The following class tables specify the configuration parameters of J1939 Nm.
Identifiable
FibexElement NmEcu
NmConfig +nmIfEcu
+ nmBusSynchronizationEnabled: Boolean [0..1]
«atpVariation,atpSplitable» 0..* + nmComControlEnabled: Boolean [0..1]
+ nmCycletimeMainFunction: TimeValue [0..1]
+ nmPduRxIndicationEnabled: Boolean [0..1]
+ nmRemoteSleepIndEnabled: Boolean [0..1]
+ nmStateChangeIndEnabled: Boolean [0..1]
+ nmUserDataEnabled: Boolean [0..1]
«atpVariation,atpSplitable»
+nmCluster 0..*
Identifiable
NmCluster

+ nmChannelSleepMaster: Boolean [0..1] 0..1

+busDependentNmEcu
+ nmNodeDetectionEnabled: Boolean [0..1] +nmIfEcu
+ nmNodeIdEnabled: Boolean [0..1]
+ nmPncParticipation: Boolean [0..1]
+ nmRepeatMsgIndEnabled: Boolean [0..1]
+ nmSynchronizingNetwork: Boolean [0..1]
+ pncClusterVectorLength: PositiveInteger [0..1]

0..*

BusspecificNmEcu
J1939NmCluster Identifiable
«atpVariation»
+ addressClaimEnabled: Boolean [0..1]
CommunicationController

+ wakeUpByControllerSupported: Boolean [0..1] J1939NmEcu

+controller 0..1
«atpVariation»

+nmNode Identifiable
NmNode
0..*
+ nmCoordCluster: PositiveInteger [0..1]
+ nmCoordinatorRole: NmCoordinatorRoleEnum [0..1]
+communicationCluster + nmNodeId: Integer [0..1]
0..1 + nmPassiveModeEnabled: Boolean [0..1]
FibexElement
+txNmPdu 0..* +rxNmPdu 0..*
«atpVariation»
CommunicationCluster Pdu
J1939NmNode
NmPdu
+ baudrate: PositiveUnlimitedInteger [0..1]
+ protocolName: String [0..1] + nmDataInformation: Boolean [0..1]
+ protocolVersion: String [0..1] + nmVoteInformation: Boolean [0..1]
+ unusedBitPattern: Integer [0..1]

+nodeName 0..1

J1939NodeName

+ arbitraryAddressCapable: Boolean
+ ecuInstance: Integer
+ function: Integer
+ functionInstance: Integer
+ identitiyNumber: Integer
+ industryGroup: Integer
+ manufacturerCode: Integer
+ vehicleSystem: Integer
+ vehicleSystemInstance: Integer

Figure 6.77: J1939 Network Management Configuration (TransportProtocols:

NmJ1939Configuration)

551 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class J1939NmCluster
Package M2::AUTOSARTemplates::SystemTemplate::NetworkManagement
Note J1939 specific NmCluster attributes
Base ARObject, Identifiable, MultilanguageReferrable, NmCluster , Referrable
Attribute Type Mult. Kind Note
addressClaim Boolean 0..1 attr This attribute specifies whether the J1939Nm Bsw
Enabled module is used or not. If this attribute is set to false then
the J1939Nm configuration shall not be derived from the
system description. But even in this case the nmNodeId
might still be necessary for the J1939Rm and J1939Tp.

Table 6.267: J1939NmCluster

Class J1939NmNode
Package M2::AUTOSARTemplates::SystemTemplate::NetworkManagement
Note J1939 specific NM Node attributes.
Base ARObject, Identifiable, MultilanguageReferrable, NmNode, Referrable
Attribute Type Mult. Kind Note
nodeName J1939NodeName 0..1 aggr NodeName configuration

Table 6.268: J1939NmNode

Class J1939NodeName
Package M2::AUTOSARTemplates::SystemTemplate::NetworkManagement
Note This element contains attributes to configure the J1939NmNode NAME.
Base ARObject
Attribute Type Mult. Kind Note
arbitrary Boolean 1 attr Arbitrary Address Capable field of the NAME of this node.
Address
Capable
ecuInstance Integer 1 attr ECU Instance field of the NAME of this node.
function Integer 1 attr Function field of the NAME of this node.
function Integer 1 attr Function Instance field of the NAME of this node.
Instance
identitiyNumber Integer 1 attr Identity Number field of the NAME of this node.
industryGroup Integer 1 attr Industry Group field of the NAME of this node.
manufacturer Integer 1 attr Manufacturer Code field of the NAME of this node.
Code
vehicleSystem Integer 1 attr Vehicle System field of the NAME of this node.
vehicleSystem Integer 1 attr Vehicle System Instance field of the NAME of this node.
Instance
Table 6.269: J1939NodeName

[constr_3102] Restriction on usage of J1939NodeName attributes dA

J1939NmCluster shall not aggregate two J1939NmNodes with identical
J1939NodeName attributes.c()

552 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_5029] J1939NmCluster is not allowed to reference a TtcanCluster dA

J1939NmCluster is not allowed to reference a TtcanCluster in the role commu-
nicationCluster.c()
[constr_3103] Range of ecuInstance dThe allowed values of ecuInstance range
from 0 to 7.c()
[constr_3104] Range of function dThe allowed values of function range from 0
to 255.c()
[constr_3105] Range of functionInstance dThe allowed values of functionIn-
stance range from 0 to 31.c()
[constr_3106] Range of identitiyNumber dThe allowed values of identi-
tiyNumber range from 0 to 2097151.c()
[constr_3107] Range of industryGroup dThe allowed values of industryGroup
range from 0 to 7.c()
[constr_3108] Range of manufacturerCode dThe allowed values of manufactur-
erCode range from 0 to 2047.c()
[constr_3109] Range of vehicleSystem dThe allowed values of vehicleSystem
range from 0 to 127.c()
[constr_3110] Range of vehicleSystemInstance dThe allowed values of vehi-
cleSystemInstance range from 0 to 15.c()
Class J1939NmEcu
Package M2::AUTOSARTemplates::SystemTemplate::NetworkManagement
Note J1939 NmEcu specific attributes.
Base ARObject, BusspecificNmEcu
Attribute Type Mult. Kind Note
– – – – –
Table 6.270: J1939NmEcu

6.9.4.1 J1939SharedAddressCluster

There are two ways of identifying source and target nodes in routing relations in J1939
networks (see [TPS_SYST_02107] and [TPS_SYST_02108]).

553 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

ARElement
AtpStructureElement
System

+ containerIPduHeaderByteOrder: ByteOrderEnum [0..1]

+ ecuExtractVersion: RevisionLabelString [0..1]
+ pncVectorLength: PositiveInteger [0..1]
+ pncVectorOffset: PositiveInteger [0..1]
+ systemVersion: RevisionLabelString

«atpVariation,atpSplitable»

+j1939SharedAddressCluster 0..*

Identifiable
J1939SharedAddressCluster

+participatingJ1939Cluster 0..*

AbstractCanCluster
J1939Cluster

+ networkId: PositiveInteger [0..1]

+ request2Support: Boolean [0..1]
+ usesAddressArbitration: Boolean [0..1]

Figure 6.78: J1939SharedAddressCluster

Class J1939SharedAddressCluster
Package M2::AUTOSARTemplates::SystemTemplate
Note This meta-class represents the ability to identify several J1939Clusters that share a common address
space for the routing of messages
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
participating J1939Cluster * ref This identifies the J1939Clusters that share a common
J1939Cluster address space

Table 6.271: J1939SharedAddressCluster

[TPS_SYST_02107] Shared address space for J1939 routing relations dAddress

claims are routed between several CommunicationClusters independent of
whether there are actual routings between individual nodes on respective Commu-
nicationClusters. This means that the overall number of nodes in the shared
CommunicationCluster cannot exceed 254, independently of the routing relations.c
(RS_SYST_00038)
[TPS_SYST_02108] Address proxying for J1939 routing relations dThe gateway
claims all addresses used in routed messages on those CommunicationClusters
to which the actual nodes are not connected. Thereby the address spaces are separate
and only the nodes participating in a routing appear on more than one Communica-
tionCluster. The total number of nodes in the participating CommunicationClus-
ters can be higher than 254, and the address arbitration is faster with less conflicts.c
(RS_SYST_00038)
[TPS_SYST_02109] Absence of participatingJ1939Cluster to a
J1939Cluster dIf J1939Clusters exist that participate in a routing relation but
are not referenced in the role J1939SharedAddressCluster.participat-
ingJ1939Cluster by the same J1939SharedAddressCluster then gateway

554 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

shall apply the address proxying according to [TPS_SYST_02108].c(RS_SYST_-

00038)

6.9.5 Managed Channels

There is the use case to transmit NM frames on one VLAN (EthernetPhysi-

calChannel) and the application data on different VLANs. At the same time it shall
be possible to indicate that a VLAN uses Network Management although no NmPdus
are defined on this channel.
A reference between PhysicalChannels is used to express such a setting: The
managing PhysicalChannel that contains configured NmPdus references Physi-
calChannels in the role managedPhysicalChannel.
Since the reference managedPhysicalChannel is available on the abstract Physi-
calChannel element it is not only usable in case of UdpNm and VLANs but also for
similar cases on other bus networks.
[constr_3479] PhysicalChannel is not allowed to be a managedPhysicalChan-
nel and a managing PhysicalChannel dIf a PhysicalChannel is referenced in
role managedPhysicalChannel, then it shall not be the source of another man-
agedPhysicalChannel relation.c()
[constr_3480] PhysicalChannel shall be referenced in the role managedPhys-
icalChannel only once dA PhysicalChannel shall be referenced in the role man-
agedPhysicalChannel only up to once.c()
[constr_3481] UdpNmCluster is not allowed to reference a managedPhysi-
calChannel in the role vlan dIf an EthernetPhysicalChannel is target of a
managedPhysicalChannel reference, then no UdpNmCluster shall reference this
managedPhysicalChannel in the role vlan.c()
[constr_3482] NmCluster is not allowed to reference a CommunicationCluster
that aggregates a managedPhysicalChannel dIf a PhysicalChannel, except
EthernetPhysicalChannel, is target of a managedPhysicalChannel, then the
aggregating CommunicationCluster shall not be referenced by any NmCluster in
the role communicationCluster.c()

6.10 Bus Mirroring

Many communication buses in a vehicle are not directly accessible by a tester. To allow
a tester to listen to the traffic on such internal communication buses the bus mirroring
is introduced. The bus mirroring collects traffic from such an internal communication
bus and forwards it to an intermediate destination bus or to a destination bus that is
accessible by the tester.

555 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Testers connected via CAN will receive unmodified CAN frames and LIN frames with
special CAN IDs. Testers connected via Ethernet will receive a stream containing
current time, identification, and content of CAN, LIN, and FlexRay frames.
On intermediate FlexRay buses, a set of PDUs is used to transport streams of mirrored
frames with the same layout as on Ethernet.
[TPS_SYST_02202] Modeling of bus mirroring dThe BusMirrorChannelMapping
defines the bus mirroring in which the communication traffic of the sourceChannel is
forwarded to the targetChannel.c()
Class BusMirrorChannelMapping (abstract)
Package M2::AUTOSARTemplates::SystemTemplate::BusMirror
Note This element defines a bus mirroring in which the traffic from one communication bus (sourceChannel) is
forwarded to another one (targetChannel).
Base ARObject, CollectableElement, FibexElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Subclasses BusMirrorChannelMappingCan, BusMirrorChannelMappingFlexray, BusMirrorChannelMappingIp, Bus
MirrorChannelMappingUserDefined
Attribute Type Mult. Kind Note
sourceChannel BusMirrorChannel 0..1 aggr Defines the sourceChannel from which frames are
received.
targetChannel BusMirrorChannel 0..1 aggr Defines the targetChannel to which frames are forwarded.
targetPdu PduTriggering * ref Reference to the PduTriggering that is used for
Triggering transmission of the mirrored frames on the targetChannel.
Please note that on FlexRay several targetPduTriggerings
may be used. For all other communication channels only
a single targetPduTriggering is supported.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild

Table 6.272: BusMirrorChannelMapping

[constr_3464] Allowed Pdu type on BusMirrorChannelMapping.targetChan-

nel dEach PduTriggering that is referenced by BusMirrorChannelMapping in
the role targetPduTriggering is only allowed to reference a GeneralPurpo-
seIPdu of category BUS_MIRRORING.c()
Class BusMirrorChannel
Package M2::AUTOSARTemplates::SystemTemplate::BusMirror
Note This element assigns a busMirrorNetworkId to the referenced channel.
Base ARObject
Attribute Type Mult. Kind Note
busMirror PositiveInteger 1 attr This attribute defines the networkId of the communication
NetworkId channel.
channel PhysicalChannel 0..1 ref Reference to PhysicalChannel that is used in the bus
mirroring as sourceChannel or targetChannel.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=systemDesignTime

Table 6.273: BusMirrorChannel

556 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

+managedPhysicalChannel 0..*

FibexElement +sourceChannel Identifiable

BusMirrorChannel
BusMirrorChannelMapping +channel PhysicalChannel
0..1
+ busMirrorNetworkId: PositiveInteger «atpVariation» 0..1
+targetChannel

0..1

«atpVariation,atpSplitable»

+pduTriggering 0..*
Identifiable
«atpVariation» +targetPduTriggering PduTriggering

0..*

+iPdu 1

FibexElement
Pdu

+ hasDynamicLength: Boolean [0..1]

+ length: UnlimitedInteger [0..1]

IPdu

GeneralPurposeIPdu

Figure 6.79: Bus mirroring

[constr_3465] Identical BusMirrorChannel.busMirrorNetworkId for BusMir-

rorChannels referencing the same PhysicalChannel dThe attribute BusMir-
rorChannel.busMirrorNetworkId shall be identical in all BusMirrorChannels
that are referencing the same PhysicalChannel in the scope of the System.c()
[constr_3466] Unique BusMirrorChannel.busMirrorNetworkIds for each spe-
cialization of PhysicalChannel dThe attribute BusMirrorChannel.busMirror-
NetworkId associated with PhysicalChannels that have the same specialization
(e.g. all CanPhysicalChannels) shall have unique BusMirrorChannel.busMir-
rorNetworkIds within the scope of the System).c()

6.10.1 CAN Destination Channel

[TPS_SYST_02203] BusMirroring to CAN destination channel dIn case of CAN to

CAN and LIN to CAN the BusMirrorChannelMappingCan meta-class shall be used
for the modeling of the bus mirroring.c()

557 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

+managedPhysicalChannel 0..*

FibexElement +sourceChannel Identifiable

BusMirrorChannel
BusMirrorChannelMapping PhysicalChannel
0..1 +channel
+ busMirrorNetworkId: PositiveInteger
+targetChannel «atpVariation» 0..1
0..1

«atpVariation,atpSplitable»

+pduTriggering 0..*

+targetPduTriggering Identifiable
«atpVariation»
PduTriggering
0..*

BusMirrorChannelMappingCan

+ mirrorSourceLinToCanRangeBaseId: PositiveInteger [0..1]

+ mirrorStatusCanId: PositiveInteger [0..1]

+canIdRangeMapping 0..* +canIdToCanIdMapping 0..* +linPidToCanIdMapping 0..*

BusMirrorCanIdRangeMapping BusMirrorCanIdToCanIdMapping BusMirrorLinPidToCanIdMapping

+ destinationBaseId: PositiveInteger + remappedCanId: PositiveInteger + remappedCanId: PositiveInteger
+ sourceCanIdCode: PositiveInteger
+ sourceCanIdMask: PositiveInteger

+souceCanId 0..1 +sourceLinPid 0..1

FrameTriggering FrameTriggering
CanFrameTriggering LinFrameTriggering

+ canAddressingMode: CanAddressingModeType + identifier: Integer [0..1]

+ canFrameRxBehavior: CanFrameRxBehaviorEnum [0..1] + linChecksum: LinChecksumType [0..1]
+ canFrameTxBehavior: CanFrameTxBehaviorEnum [0..1]
+ identifier: Integer [0..1]
+ j1939requestable: Boolean [0..1]
+ rxMask: PositiveInteger [0..1]
+ txMask: PositiveInteger [0..1]

Figure 6.80: Bus mirroring between a CAN or LIN sourceChannel and a CAN targetChan-
nel

Class BusMirrorChannelMappingCan
Package M2::AUTOSARTemplates::SystemTemplate::BusMirror
Note This element defines the bus mirroring between a CAN or LIN sourceChannel and a CAN targetChannel.
Tags:atp.recommendedPackage=BusMirrorChannelMappings
Base ARObject, BusMirrorChannelMapping, CollectableElement, FibexElement, Identifiable, Multilanguage
Referrable, PackageableElement, Referrable
Attribute Type Mult. Kind Note
canIdRange BusMirrorCanIdRange * aggr Rules for remapping of a set of CAN IDs.
Mapping Mapping
canIdToCanId BusMirrorCanIdToCanId * aggr Rules for remapping of single CanIds.
Mapping Mapping
linPidToCanId BusMirrorLinPidToCan * aggr Rules for remapping of single LIN Frames.
Mapping IdMapping
mirrorSourceLin PositiveInteger 0..1 attr Base ID merged with the LIN frame ID to form the CAN
ToCanRange ID.
BaseId
Only required when a BusMirrorChannel that refers to a
LinPhysicalChannel in the role channel is referenced in
the role sourceChannel.
5

558 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class BusMirrorChannelMappingCan
mirrorStatus PositiveInteger 0..1 attr CAN ID of the CAN status frame.
CanId
If configured, a status frame will be sent on the CAN
destination bus that contains the state of all active source
buses.
Table 6.274: BusMirrorChannelMappingCan

[constr_3467] CanPhysicalChannel as destination channel of BusMirror-

ChannelMappingCan dThe BusMirrorChannel that is aggregated by BusMir-
rorChannelMappingCan shall only reference a CanPhysicalChannel in the role
targetChannel.c()
[constr_3468] BusMirrorChannelMappingCan.targetPduTriggering restric-
tion dBusMirrorChannelMappingCan is allowed to reference only one single
PduTriggering in the role targetPduTriggering.c()
[constr_3469] CanFrameTriggering.txMask setting for the destination frame
dThe CanFrameTriggering of a Frame that contains a Pdu of which the PduTrig-
gering is referenced by BusMirrorChannelMappingCan in the role targetP-
duTriggering shall set the txMask to 0.c()
[constr_5051] Existence of CanFrameTriggering.identifier in case of bus
mirror target dThe CanFrameTriggering of a Frame that contains a Pdu of which
the PduTriggering is referenced by BusMirrorChannelMappingCan in the role
targetPduTriggering shall not define an identifier.c()
[constr_3470] PaddingValue used to transmit the Pdu on a Can-Fd destination
bus dIn case that the BusMirrorChannelMappingCan references a PduTrigger-
ing in the role targetPduTriggering and
• the CanFrameTriggering of the Frame that contains this targetPduTrig-
gering has the canFrameTxBehavior set to canFd and
• the CanFrameTriggering has a reference to an “out” FramePort (i.e. the
Frame is transmitted by an Ecu on a Can-Fd destination bus) and
• the CommunicationController of the transmitting EcuInstance that is ref-
erenced via the CommunicationConnector by the PhysicalChannel on
which the targetPduTriggering is located then the CanControllerFd-
Configuration.paddingValue or CanControllerFdConfigurationRe-
quirements.paddingValue shall have the value 0.
c()
Class BusMirrorCanIdRangeMapping
Package M2::AUTOSARTemplates::SystemTemplate::BusMirror
Note This element defines a rule for remapping a set of CAN IDs.
5

559 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class BusMirrorCanIdRangeMapping
Base ARObject
Attribute Type Mult. Kind Note
destinationBase PositiveInteger 1 attr Base ID merged with the masked parts of the original
Id CAN ID to form the mapped CAN ID.
sourceCanId PositiveInteger 1 attr Value to match masked original CAN IDs.
Code
sourceCanId PositiveInteger 1 attr Mask applied to original CAN IDs before comparison.
Mask
Table 6.275: BusMirrorCanIdRangeMapping

Class BusMirrorCanIdToCanIdMapping
Package M2::AUTOSARTemplates::SystemTemplate::BusMirror
Note This element defines a rule for remapping a single CAN ID.
Base ARObject
Attribute Type Mult. Kind Note
remappedCanId PositiveInteger 1 attr This attribute defines the CanId on the targetChannel.
souceCanId CanFrameTriggering 0..1 ref This reference points to the sourceFrame with sourceCan
Id on the sourceChannel.

Table 6.276: BusMirrorCanIdToCanIdMapping

Class BusMirrorLinPidToCanIdMapping
Package M2::AUTOSARTemplates::SystemTemplate::BusMirror
Note This element defines a rule for remapping a single LIN Frame.
Base ARObject
Attribute Type Mult. Kind Note
remappedCanId PositiveInteger 1 attr This attribute defines the CanId on the targetChannel.
sourceLinPid LinFrameTriggering 0..1 ref This reference points to the sourceFrame with sourceCan
Id on the sourceChannel.

Table 6.277: BusMirrorLinPidToCanIdMapping

6.10.2 FlexRay Destination Channel

[TPS_SYST_02204] BusMirroring to FlexRay destination channel dIn case of CAN

to FlexRay, LIN to FlexRay and FlexRay to FlexRay the BusMirrorChannelMap-
pingFlexray meta-class shall be used for the modeling of the bus mirroring.c()

560 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

+managedPhysicalChannel 0..*

FibexElement +sourceChannel Identifiable

BusMirrorChannel
BusMirrorChannelMapping PhysicalChannel
0..1 +channel
+ busMirrorNetworkId: PositiveInteger
+targetChannel «atpVariation»
0..1
0..1

«atpVariation,atpSplitable»
+pduTriggering 0..*
Identifiable
+targetPduTriggering PduTriggering

«atpVariation» 0..*

BusMirrorChannelMappingFlexray

+ transmissionDeadline: TimeValue [0..1]

+iPdu 1

FibexElement
Pdu

+ hasDynamicLength: Boolean [0..1]

+ length: UnlimitedInteger [0..1]

Figure 6.81: Bus mirroring between between a CAN, LIN or FlexRay sourceChannel and
a FlexRay targetChannel

Class BusMirrorChannelMappingFlexray
Package M2::AUTOSARTemplates::SystemTemplate::BusMirror
Note This element defines the bus mirroring between a CAN, LIN or FlexRay sourceChannel and a FlexRay
targetChannel.
Tags:atp.recommendedPackage=BusMirrorChannelMappings
Base ARObject, BusMirrorChannelMapping, CollectableElement, FibexElement, Identifiable, Multilanguage
Referrable, PackageableElement, Referrable
Attribute Type Mult. Kind Note
transmission TimeValue 0..1 attr Time in seconds after which the collection of source
Deadline frames into the destination frame is stopped and the
frame is sent at the latest.
If omitted, destination frames are only sent when full or
when the time stamp overflows.

Table 6.278: BusMirrorChannelMappingFlexray

[constr_3471] FlexrayPhysicalChannel as destination channel of BusMir-

rorChannelMappingFlexray dThe BusMirrorChannel that is aggregated by
BusMirrorChannelMappingFlexray shall only reference a FlexrayPhysi-
calChannel in the role targetChannel.c()
[constr_3472] Number of BusMirrorChannels derived for one FlexrayCluster
dFor each FlexrayCluster, only one BusMirrorChannel shall be derived. I.e. if
both channels A and B are derived, only one of the two FlexrayPhysicalChan-
nels of one FlexrayCluster shall be referenced by a BusMirrorChannel in the
System.c()
[constr_3473] BusMirrorChannelMappingFlexray.targetPduTriggering re-
striction dThe FlexrayFrameTriggering of a Frame that contains a Pdu of which
the PduTriggering is referenced by BusMirrorChannelMappingFlexray in the

561 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

role targetPduTriggering shall have the allowDynamicLSduLength attribute

set to true.c()

6.10.3 Ethernet Destination Channel

[TPS_SYST_02205] BusMirroring to Ethernet destination channel dIn case of CAN

to Ethernet, LIN to Ethernet and FlexRay to Ethernet the BusMirrorChannelMap-
pingIp meta-class shall be used for the modeling of the bus mirroring.c()
+managedPhysicalChannel 0..*
FibexElement +sourceChannel Identifiable
BusMirrorChannel
BusMirrorChannelMapping PhysicalChannel
0..1 +channel
+ busMirrorNetworkId: PositiveInteger
+targetChannel «atpVariation» 0..1
0..1

«atpVariation,atpSplitable»

+pduTriggering 0..*
Identifiable
«atpVariation» +targetPduTriggering PduTriggering
0..*
BusMirrorChannelMappingIp

+ transmissionDeadline: TimeValue [0..1]

Figure 6.82: Bus mirroring between between a CAN, LIN or FlexRay sourceChannel and
an Ethernet IP targetChannel

Class BusMirrorChannelMappingIp
Package M2::AUTOSARTemplates::SystemTemplate::BusMirror
Note This element defines the bus mirroring between a CAN, LIN or FlexRay sourceChannel and an Ethernet
IP targetChannel.
Tags:atp.recommendedPackage=BusMirrorChannelMappings
Base ARObject, BusMirrorChannelMapping, CollectableElement, FibexElement, Identifiable, Multilanguage
Referrable, PackageableElement, Referrable
Attribute Type Mult. Kind Note
transmission TimeValue 0..1 attr Time in seconds after which the collection of source
Deadline frames into the destination frame is stopped and the
frame is sent at the latest.
If omitted, destination frames are only sent when full or
when the time stamp overflows.

Table 6.279: BusMirrorChannelMappingIp

[constr_3474] EthernetPhysicalChannel as destination channel of BusMir-

rorChannelMappingIp dThe BusMirrorChannel that is aggregated by BusMir-
rorChannelMappingIp shall only reference an EthernetPhysicalChannel in
the role targetChannel.c()
[constr_3475] BusMirrorChannelMappingIp.targetPduTriggering restric-
tion dBusMirrorChannelMappingIp is allowed to reference only one single
PduTriggering in the role targetPduTriggering.c()

562 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.10.4 User Defined Destination Channel

[TPS_SYST_02206] BusMirroring to UserDefined destination channel dIn case of

CAN to UserDefinedPhysicalChannel, LIN to UserDefinedPhysicalChannel
and FlexRay to UserDefinedPhysicalChannel the BusMirrorChannelMap-
pingUserDefined meta-class shall be used for the modeling of the bus mirroring.c
()
+managedPhysicalChannel 0..*

FibexElement +sourceChannel Identifiable

BusMirrorChannel
BusMirrorChannelMapping PhysicalChannel
0..1 +channel
+ busMirrorNetworkId: PositiveInteger
+targetChannel «atpVariation»0..1
0..1

«atpVariation,atpSplitable»
+pduTriggering 0..*
Identifiable
«atpVariation» +targetPduTriggering
PduTriggering
0..*
BusMirrorChannelMappingUserDefined

+ transmissionDeadline: TimeValue [0..1]

Figure 6.83: Bus mirroring between between a CAN, LIN or FlexRay sourceChannel and
a UserDefined targetChannel

Class BusMirrorChannelMappingUserDefined
Package M2::AUTOSARTemplates::SystemTemplate::BusMirror
Note This element defines the bus mirroring between a CAN, LIN or FlexRay sourceChannel and a User
Defined targetChannel.
Tags:atp.recommendedPackage=BusMirrorChannelMappings
Base ARObject, BusMirrorChannelMapping, CollectableElement, FibexElement, Identifiable, Multilanguage
Referrable, PackageableElement, Referrable
Attribute Type Mult. Kind Note
transmission TimeValue 0..1 attr Time in seconds after which the collection of source
Deadline frames into the destination frame is stopped and the
frame is sent at the latest.
If omitted, destination frames are only sent when full or
when the time stamp overflows.

Table 6.280: BusMirrorChannelMappingUserDefined

[constr_3476] UserDefinedPhysicalChannel as destination channel of Bus-

MirrorChannelMappingUserDefined dThe BusMirrorChannel that is ag-
gregated by BusMirrorChannelMappingUserDefined shall only reference a
UserDefinedPhysicalChannel in the role targetChannel.c()
[constr_3477] BusMirrorChannelMappingUserDefined.targetPduTrigger-
ing restriction dBusMirrorChannelMappingUserDefined is allowed to refer-
ence only one single PduTriggering in the role targetPduTriggering.c()

563 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.11 Fan-out
AUTOSAR supports three different fan-outs:
• Signal fan-out
• Pdu fan-out
• Frame fan-out
Note that the specification in this section does not apply for Client/Server communica-
tion. The respective details are described in section 5.2.1.3.

6.11.1 Signal fan-out

A Signal fan-out can either be RTE fan-out or COM Signal Gateway fan-out. The details
are explained in the following subchapters.

6.11.1.1 RTE fan-out

The RTE supports a “signal fan-out” where two or more ISignals of the same Sys-
temSignal are sent in multiple ISignalIPdus to potentially multiple receivers.
[TPS_SYST_01109] RTE fan-out support for a SystemSignal dThe RTE fan-out
(signal fan-out) from a SystemSignal to multiple ISignals is enabled in the System
Description if the following conditions apply:
• several ISignals reference the SystemSignal in the role systemSignal and
• the SystemSignal is not referenced by a SystemSignalGroup
• a DataMapping references the SystemSignal and
• the DataMapping references an element in a PPortPrototype and
• the ISignals are transmitted by the EcuInstance on which the RTE is run-
ning, i.e. an ISignalTriggering exists that references the ISignal in the
role iSignal and references a ISignalPort of the EcuInstance with com-
municationDirection out.
c()
Figure 6.84 shows a scenario where the RTE does not need to perform a fan-out since
each SystemSignal is referenced by exactly one ISignal.
Please note that in all example scenarios that are shown in this chapter the ISignal-
ToIPduMappings shall be modeled for each ISignal or ISignalGroup. For sim-
plicity reasons, the following diagrams leave the ISignalToIPduMappings out and
just assume that they exist.

564 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

In addition for simplicity reasons the examples scenarios are showing always one OUT
EcuPort and/or one IN EcuPort. But the different ISignalTriggerings are also
allowed to reference own ISignalPorts that are defined on the EcuInstance.

P P SenderReceiverToSignalMapping SenderReceiverToSignalMapping

RTE
SystemSignal 1 SystemSignal 2

ISignal1 ISignal2 ISignal 1 ISignal 2

COM

Figure 6.84: Scenario where RTE does not perform a fan-out

Figure 6.85 shows a scenario where the RTE needs to perform a fan-out since the
SystemSignal is referenced by two ISignals, a SenderReceiverToSignalMap-
ping is defined that maps a VariableDataPrototype in a SenderReceiverIn-
terface of a PPortPrototype to the SystemSignal and the ISignals are both
transmitted by the EcuInstance.

P SenderReceiverToSignalMapping

SystemSignal
RTE

ISignal 1 ISignal 2
ISignal1 ISignal2
COM ISignalTriggering ISignalTriggering

ECU Port
OUT

Figure 6.85: Scenario where RTE does perform a fan-out

565 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Figure 6.86 shows a scenario where the RTE does not need to perform a fan-
out since one of the ISignals that is referencing the SystemSignal is trans-
mitted by the EcuInstance and the second ISignal is received. In addi-
tion the SenderReceiverToSignalMapping that references the SystemSig-
nal references a VariableDataPrototype in a RPortPrototype and therefore
[TPS_SYST_01109] is not fulfilled.

R SenderReceiverToSignalMapping

SystemSignal
RTE

ISignal 1 ISignal 2
ISignal1 ISignal2
COM ISignalTriggering ISignalTriggering

ECU Port ECU Port

IN OUT

Figure 6.86: Scenario where RTE does not perform a fan-out since one ISignal is re-
ceived and one is transmitted

[TPS_SYST_02309] RTE fan-out support for a SystemSignalGroup dThe RTE

fan-out (signal fan-out) from a SystemSignalGroup to multiple ISignalGroups is
enabled in the System Description if the following conditions apply:
• several ISignalGroups reference the SystemSignalGroup in the role sys-
temSignalGroup and
• a DataMapping references the SystemSignalGroup and
• the DataMapping references an element in a PPortPrototype and
• each of the contained ISignals of the ISignalGroup refers to its correspond-
ing SystemSignal which in turn is part of the SystemSignalGroup and
• the ISignalGroups are transmitted by the EcuInstance on which the RTE
is running, i.e. an ISignalTriggering exists that references the ISig-
nalGroup in the role iSignalGroup and references a ISignalPort of the
EcuInstance with communicationDirection out.
c()
In other words if two ISignalGroups reference the same SystemSignalGroup, but
one of the ISignalGroups is received and one is transmitted no RTE signal fan-out

566 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

is performed. Only if several ISignalGroups that are transmitted reference the same
SystemSignalGroup the RTE signal fan-out is performed.
Figure 6.87 shows a scenario where the RTE needs to perform a fan-out since the
SystemSignalGroup is referenced by two ISignalGroups, a SenderReceiver-
ToSignalGroupMapping is defined that maps a VariableDataPrototype in a
SenderReceiverInterface of a PPortPrototype to the SystemSignalGroup
and both ISignalGroups are transmitted by the EcuInstance.

SenderRecRecordTypeMapping

P SenderReceiverToSignalGroupMapping SenderRecRecordElementMapping

SystemSignalGroup SystemSignal
RTE

ISignalGroup1 ISignalGroup2 ISignal 1 ISignal 2

ISignalGroup1 ISignalGroup2
COM ISignalTriggering ISignalTriggering ISignalTriggering ISignalTriggering

ECU Port ECU Port

OUT OUT

Figure 6.87: Scenario where RTE does perform a fan-out for a SystemSignalGroup

6.11.1.2 COM Signal Gateway fan-out

In Com [22] the Signal Gateway supports a fan-out where an incoming signal is routed
to several destinations.
[TPS_SYST_01110] Com Signal Gateway fan-out support dA Signal Gateway
fan-out (1:n routing) is described with the definition of several ISignalMappings in
the Gateway description, which all refer to the same source ISignalTriggering.c
()
Note that [constr_3514] applies for the relation between ISignalToIPduMapping to
ISignal.
Figure 6.88 shows a scenario where a Signal Gateway is defined in which the same
source ISignalTriggering is mapped by two ISignalMappings to two dedicated
target ISignalTriggerings. Since a DataMapping is not defined for the System-
Signal that is referenced by the received and transmitted ISignals the RTE is not
involved.

567 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

RTE

Gateway

COM
ISignalMapping ISignalMapping
ISignal1 ISignal2 ISignal3

Pdu1 Pdu2 Pdu3 ECU Port Target Source Target ECU Port
IN ISignalTriggering 2 ISignalTriggering 1 ISignalTriggering 3 OUT
PduR

Pdu1 Pdu2 Pdu3 ISignal2 ISignal1 ISignal3

CanIf LinIf FrIf

SystemSignal

Figure 6.88: Scenario where the Com Gateway performs a fan-out and RTE is not in-
volved

Figure 6.89 shows a scenario where a Signal Gateway is defined in which the same
source ISignalTriggering is mapped by two ISignalMappings to two dedicated
target ISignalTriggerings. A DataMapping is defined for the SystemSignal
that is referenced by the received and transmitted ISignals. Therefore the RTE is
involved. But the rule for the RTE fan-out (see [TPS_SYST_01109] does not apply
since the DataMapping references an element in a RPortPrototype.

Gateway
R

ISignalMapping ISignalMapping
RTE

ECU Port Target Source Target ECU Port

IN ISignalTriggering 2 ISignalTriggering 1 ISignalTriggering 3 OUT

COM
ISignal2 ISignal1 ISignal3
ISignal1 ISignal2 ISignal3

Pdu1 Pdu2 Pdu3

PduR
SystemSignal

Pdu1 Pdu2 Pdu3

CanIf LinIf FrIf
SenderReceiverToSignalMapping

Figure 6.89: Scenario where the Com Gateway performs a fan-out and RTE is involved

568 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.11.2 Pdu fan-out

6.11.2.1 Pdu Router fan-out

The Pdu Router supports the "PDU fan-out" where one IPdu is sent to multiple des-
tinations.
[TPS_SYST_01111] Pdu Router fan-out support dThe Pdu Router fan-out is de-
scribed by several PduTriggering elements pointing to the same Pdu3 .
The sending ECU/PDU router has an output IPduPort that has the value of commu-
nicationDirection set to out and is referenced by the PduTriggering. Accord-
ing to the Cluster/Channel aggregation, the Pdu Router determines the clusters to
use in its routing.c()
[TPS_SYST_01112] FlexrayCluster Pdu Router interaction dThe following con-
dition applies only in case of FlexRay on the same FlexrayCluster if two PduTrig-
gerings refer to the same Pdu: this Pdu shall only be sent once to the FlexRay Inter-
face. In other words the Pdu Router sends only one Pdu Transmission request to the
FlexRay Interface.c()
COM ISignal
ISignal_S1
Pdu
PduR
Can_Pdu FlexRay_Pdu
ISignalToPDUMapping
S1ToIPdu
CanIf FlexRayIf

IPdu

PduTriggering PduTriggering

CAN Channel FlexRay Channel

Figure 6.90: Pdu Router fan-out

6.11.2.2 Flexray Interface fan-out

The Flexray interface supports a fan-out where one Pdu is mapped into more than one
frame on the same CommunicationCluster.
[TPS_SYST_01113] FlexRay Interface fan-out support dThe redundant transmis-
sion in the FlexRay Interface in the static segment is described by
• one FlexrayFrameTriggering on each PhysicalChannel
• both FlexrayFrameTriggerings refer to the same FlexrayFrame with the
same Pdu

3
AUTOSAR Layered Architecture [15] defines which Pdu types are routed by the Pdu Router

569 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• each FlexrayFrameTriggering aggregates the same number of

FlexrayAbsolutelyScheduledTimings
• for every FlexrayAbsolutelyScheduledTiming on one PhysicalChan-
nel a corresponding FlexrayAbsolutelyScheduledTiming with identical
values shall be defined on the other PhysicalChannel
c()
If the fan-out is specified between different FlexRay channels of the same cluster it
shall be handled by the FlexRay Interface.
The Flexray Interface does NOT handle fan-out/in between different clusters.
COM IPdu

Pdu
PduR PDUToFrameMapping

Pdu
FlexRayIf Frame
Frame1 Frame2

FlexRay FlexRay
Channel A Channel B
FrameTriggering FrameTriggering

Channel A Channel B

Figure 6.91: Bus Interface fan-out

6.11.3 Frame fan-out

[TPS_SYST_01114] Frame fan-out support dAUTOSAR supports the Frame fan-out

only on the FlexrayCluster (see [TPS_SYST_01113]).c()

6.12 Fan-in
AUTOSAR supports the following fan-ins:
• RTE Signal fan-in
• Pdu fan-in
• IPdu Container fan-in
Note that the specification in this section does not apply for Client/Server communica-
tion. The respective details are described in section 5.2.1.3.

570 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.12.1 RTE fan-in

The RTE supports a “signal fan-in” where two or more ISignals of the same Sys-
temSignal are received in multiple ISignalIPdus from potentially multiple senders,
as described in [SWS_Rte_03760] and [SWS_Rte_03761].
[TPS_SYST_02357] RTE fan-in support for a SystemSignal dRTE fan-in from mul-
tiple ISignals to a single SystemSignal is enabled in a System Description if the
following conditions apply:
• several ISignals reference the SystemSignal in the role systemSignal and
• the SystemSignal is not referenced by a SystemSignalGroup
• a DataMapping references the SystemSignal and
• the DataMapping references an element in a RPortPrototype and
• the ISignals are received by the EcuInstance on which the RTE is running,
i.e. an ISignalTriggering exists that references the ISignal in the role
iSignal and references a ISignalPort of the EcuInstance with communi-
cationDirection in.
c()
Figure 6.84 shows a scenario where the RTE does not need to perform a fan-in since
each SystemSignal is referenced by exactly one ISignal.
Please note that in all example scenarios that are shown in this chapter the ISignal-
ToIPduMappings shall be modeled for each ISignal or ISignalGroup. For sim-
plicity reasons, the following diagrams leave the ISignalToIPduMappings out and
just assume that they exist.
In addition for simplicity reasons the examples scenarios are showing always one OUT
EcuPort and/or one IN EcuPort. But the different ISignalTriggerings are also
allowed to reference own ISignalPorts that are defined on the EcuInstance.

R R SenderReceiverToSignalMapping SenderReceiverToSignalMapping

RTE
SystemSignal 1 SystemSignal 2

ISignal1 ISignal2 ISignal 1 ISignal 2

COM

Figure 6.92: Scenario where RTE does not perform a fan-in

571 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Figure 6.93 shows a scenario where the RTE needs to perform a fan-in since the
SystemSignal is referenced by two ISignals, a SenderReceiverToSignalMap-
ping is defined that maps a VariableDataPrototype in a SenderReceiverIn-
terface of a RPortPrototype to the SystemSignal and the ISignals are both
received by the EcuInstance.

R SenderReceiverToSignalMapping

SystemSignal
RTE

ISignal 1 ISignal 2

ISignal1 ISignal2
COM ISignalTriggering ISignalTriggering

ECU Port
IN

Figure 6.93: Scenario where RTE does perform a fan-in

A fan-in of two ISignalGroups can be modeled as well. In that case, two or more
ISignalGroups refer to the same SystemSignalGroup, and each of the contained
ISignals of the ISignalGroup needs to refer to its corresponding SystemSignal
which in turn is part of the SystemSignalGroup.
[TPS_SYST_02358] RTE fan-in support for a SystemSignalGroup dRTE fan-in
from multiple ISignalGroups to a single SystemSignalGroup is enabled in a Sys-
tem Description if the following conditions apply:
• several ISignalGroups reference the SystemSignalGroup in the role sys-
temSignalGroup and
• a DataMapping references the SystemSignalGroup and
• the DataMapping references an element in a RPortPrototype and
• each of the contained ISignals of the ISignalGroup refers to its correspond-
ing SystemSignal which in turn is part of the SystemSignalGroup and
• the ISignalGroups are received by the EcuInstance on which the RTE is run-
ning, i.e. an ISignalTriggering exists that references the ISignalGroup in
the role iSignalGroup and references a ISignalPort of the EcuInstance
with communicationDirection in.
c()

572 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Figure 6.94 shows a scenario where the RTE needs to perform a fan-in since the
SystemSignalGroup is referenced by two ISignalGroups, a SenderReceiver-
ToSignalGroupMapping is defined that maps a VariableDataPrototype in a
SenderReceiverInterface of a RPortPrototype to the SystemSignalGroup
and both ISignalGroups are transmitted by the EcuInstance.

SenderRecRecordTypeMapping

R SenderReceiverToSignalGroupMapping SenderRecRecordElementMapping

SystemSignalGroup SystemSignal
RTE

ISignalGroup1 ISignalGroup2 ISignal 1 ISignal 2

ISignalGroup1 ISignalGroup2
COM ISignalTriggering ISignalTriggering ISignalTriggering ISignalTriggering

ECU Port ECU Port

IN IN

Figure 6.94: Scenario where RTE does perform a fan-in for a SystemSignalGroup

6.12.2 Pdu fan-in

The Pdu Router supports the “PDU fan-in” where one IPdu is received from several
sources.
[TPS_SYST_02376] Pdu Router fan-in support dThe Pdu Router fan-in is described
by several PduTriggering elements that are referencing the same Pdu and each
of these PduTriggerings is referencing an IPduPort with communicationDi-
rection set to in of the same EcuInstance. According to the Cluster/Channel
aggregation, the Pdu Router determines the clusters to use in its routing.c()

573 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

COM ISignal

PduR ISignalToIPduMapping

CanIf FlexRayIf ISignalIPdu

PduTriggering PduTriggering

CAN channel FlexRay channel

IPduPort
IN

Figure 6.95: Scenario where PduR does perform a fan-in

6.12.3 IPdu Container fan-in

Using the ContainerIPdu (see section 6.3.1) it is possible to transport several Con-
tained IPdus in one ContainerIPdu.
It is also possible to accept a Contained IPdu from any ContainerIPdu with Con-
tainerIPdu.rxAcceptContainedIPdu set to RxAcceptContainedIPduEnum.
acceptAll.
The example in figure 6.96 illustrates a scenario where in the configuration the Con-
tainedIPdu is explicitly defined to be part of the two ContainerIPdus CIPdu1 and
CIpdu3. Both ContainerIPdus have rxAcceptContainedIPdu set to accep-
tAll.
But also ContainerIPdu CIPdu2 has rxAcceptContainedIPdu set to accep-
tAll. And there is no explicit placement of ContainedIPdu in CIPdu2.
Due to the nature of acceptAll, if ContainedIPdu is received in CIPdu2 it will also
be forwarded to the Pdu Router.

574 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
IpduM Container Fan-In:
AUTOSAR CP R21-11

ISignal
ISignal_S1

COM
ISignalToPDUMapping
ContainedIPdu
S1ToIPdu
PduR
ContainedIPdu
ContainedIPdu
IPduM (acceptAll)
CIPdu1 CIPdu2 CIPdu3 PduTriggering
PduR

CIPdu1 CIPdu3 CIPdu2

CanIf FlexRayIf (acceptAll) (acceptAll) (acceptAll)

PduTriggering PduTriggering PduTriggering

CAN Channel FlexRay Channel CAN Channel

Figure 6.96: Container acceptAll fan-in

6.13 Log and Trace

The Dlt module collects debug information from applications or other software modules,
adds metadata to the debug information, and sends the information to a Dlt sink.
The DltConfig element defines a Dlt module configuration for a specific EcuIn-
stance and uses elements from the Log And Trace Extract Template to describe the
source of log and trace messages (application or module that produces the logging
information) and the DltMessage that is sent out from the source to a sink.
[TPS_SYST_02373] Assignment of a Dlt Ecu Identifier to an EcuInstance dThe
EcuInstance is represented in the Log And Trace Extract by the DltEcu that is
referenced from the EcuInstance via the aggregated DltConfig in the role dltEcu.
The referenced DltEcu defines the ecuId that is transported in the standard header
of the log and trace message.c()
The DltApplication in the DltEcu is connected to a DltContext that is used
to group DltMessages that are generated by the DltApplication. The Physi-
calChannel on which the DltMessage is transported is represented by the Dlt-
LogChannel.

575 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Log And Trace Extract

«atpVariation,atpSplitable»
ARElement Identifiable
DltEcu +application DltApplication +context 0..*
«atpVariation,atpSplitable»
0..* + ARElement
+ ecuId: String [0..1] applicationDescription: String [0..1]
+ applicationId: String [0..1] DltContext
+dltEcu 0..1
+ contextDescription: String [0..1]
+ contextId: String [0..1]

«atpVariation,atpSplitable» +applicationContext 0..*

+dltMessage 0..*

Identifiable
ARElement DltMessage
LogAndTraceMessageCollectionSet +dltMessage +dltMessage
+ messageId: PositiveInteger [0..1]
«atpVariation,atpSplitable»
0..* + messageLineNumber: PositiveInteger [0..1] 0..*
+ messageSourceFile: String [0..1]
+ messageTypeInfo: String [0..1]

+dltArgument 0..* {ordered}

Identifiable
DltArgument

+dltArgumentEntry 0..* + length: PositiveInteger [0..1]

+ optional: Boolean [0..1]
+ predefinedText: Boolean [0..1]
+ variableLength: Boolean [0..1]

+networkRepresentation 0..1

«atpVariation»
SwDataDefProps

System Template

Identifiable
DltLogChannel
DltConfig + defaultTraceState: DltDefaultTraceStateEnum [0..1]
+dltLogChannel
+ sessionIdSupport: Boolean [0..1] + logChannelId: String [0..1]
+ timestampSupport: Boolean [0..1] 0..* + logTraceDefaultLogThreshold: LogTraceDefaultLogLevelEnum [0..1]
+ nonVerboseMode: Boolean [0..1]

+dltConfig 0..1

FibexElement
EcuInstance

+ comConfigurationGwTimeBase: TimeValue [0..1]

+ comConfigurationRxTimeBase: TimeValue [0..1]
+ comConfigurationTxTimeBase: TimeValue [0..1] +rxPduTriggering 0..1 +txPduTriggering 0..1
+ comEnableMDTForCyclicTransmission: Boolean [0..1]
+ ethSwitchPortGroupDerivation: Boolean [0..1] Identifiable
+ pncPrepareSleepTimer: TimeValue [0..1] PduTriggering
+ pncSynchronousWakeup: Boolean [0..1]
+ pnResetTime: TimeValue [0..1]
+ sleepModeSupported: Boolean
+ v2xSupported: V2xSupportEnum [0..1]
+ wakeUpOverBusSupported: Boolean

+iPdu 1

FibexElement
«enumeration» «enumeration»
LogTraceDefaultLogLevelEnum Pdu IPdu
DltDefaultTraceStateEnum
fatal + hasDynamicLength: Boolean [0..1]
DefaultTraceStateEnabled
error + length: UnlimitedInteger [0..1]
DefaultTraceStateDisabled
warn GeneralPurposeIPdu
info
debug
verbose
off

Figure 6.97: Dlt configuration of DltLogChannels and DltMessages

[TPS_SYST_02264] Usage of DltLogChannel dIn each DltConfig the Physi-

calChannels that are used to transport the DltMessages are configured by the
DltLogChannel elements.

576 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Each DltLogChannel points to one PduTriggering in the role txPduTriggering

to describe the Dlt Pdu that is transmitted by the DltLogChannel. The rxPduTrig-
gering role is used to describe the Dlt Pdu that is received by the DltLogChannel.c
()
[TPS_SYST_02374] Assignment of DltMessage to DltLogChannels dThe as-
signment of DltMessages to a DltLogChannel for log/trace output is created with
the dltMessage reference.c()
[TPS_SYST_02375] Definition of DltLogChannels source dThe DltLogChannel
references the DltContext in the role applicationContext to define the con-
textId and applicationId of the Software Component or Basic Software Module
that produces the DltMessage for transmission to the sink.c()
Class DltConfig
Package M2::AUTOSARTemplates::SystemTemplate::Dlt
Note This element defines a Dlt configuration for a specific Ecu.
Base ARObject
Attribute Type Mult. Kind Note
dltEcu DltEcu 0..1 ref Reference to the Ecu representation in the Log And Trace
Extract.
dltLogChannel DltLogChannel * aggr Describes the DltLogChannels that are configured for the
log/trace message output
sessionId Boolean 0..1 attr This attribute defines whether the sessionId is used or
Support not.
timestamp Boolean 0..1 attr This attribute defines whether a timestamp shall be added
Support to the Dlt messages or not.

Table 6.281: DltConfig

Class DltLogChannel
Package M2::AUTOSARTemplates::SystemTemplate::Dlt
Note This element contains the settings for the log/trace message output for a tuple of ApplicationId and
ContextId (verbose mode) or a SessionId (non-verbose mode).
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
application DltContext * ref Reference to the Swc that produces the log or trace
Context message. Please note that this reference shall not be set
in case that the Bsw module produces the associated log
or trace messages.
defaultTrace DltDefaultTraceState 0..1 attr This attributes defines the default trace status.
State Enum
dltMessage DltMessage * ref Reference to DltMessages that can be transported over
the DltLogChannel in the DltPdu.
logChannelId String 0..1 attr This attribute identifies the Channel for usage within the
Log And Trace protocol.
logTraceDefault LogTraceDefaultLog 0..1 attr This attribute allows to set a log level Threshold for Log
LogThreshold LevelEnum Level filtering.
nonVerbose Boolean 0..1 attr This attribute defines whether this channel supports
Mode non-Verbose Dlt messages. If disabled only verbose
mode messages shall be used.
5

577 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class DltLogChannel
rxPduTriggering PduTriggering 0..1 ref Reference to DltPdu that is received by the DltLog
Channel
txPduTriggering PduTriggering 0..1 ref Reference to DltPdu that is transmitted by the DltLog
Channel.

Table 6.282: DltLogChannel

Enumeration DltDefaultTraceStateEnum
Package M2::AUTOSARTemplates::SystemTemplate::Dlt
Note This enumeration defines the supported values for the Dlt default trace state.
Literal Description
DefaultTraceState The default trace state is disabled
Disabled
Tags:atp.EnumerationLiteralIndex=1
DefaultTraceState The default trace state is enabled
Enabled
Tags:atp.EnumerationLiteralIndex=0

Table 6.283: DltDefaultTraceStateEnum

Enumeration LogTraceDefaultLogLevelEnum
Package M2::AUTOSARTemplates::SystemTemplate::Dlt
Note This enum defines available log&trace log levels that may be used to define the severity level of a log
message.
Literal Description
debug Detailed information for programmers
Tags:atp.EnumerationLiteralIndex=4
error Error with impact to correct functionality
Tags:atp.EnumerationLiteralIndex=1
fatal Fatal error
Tags:atp.EnumerationLiteralIndex=0
info High level information
Tags:atp.EnumerationLiteralIndex=3
off logging is turned off
Tags:atp.EnumerationLiteralIndex=6
verbose Verbose debug message
Tags:atp.EnumerationLiteralIndex=5
warn Warning if correct behavior cannot be ensured
Tags:atp.EnumerationLiteralIndex=2

Table 6.284: LogTraceDefaultLogLevelEnum

[constr_5097] DltLogChannel.txPduTriggering and DltLogChannel.rxP-

duTriggering shall point to GeneralPurposeIPdus of category DLT dDlt-
LogChannel shall only reference PduTriggerings that are pointing to Gener-
alPurposeIPdus of category DLT in the roles txPduTriggering and rxPduTrig-
gering.c()

578 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_5306] Restriction of DltLogChannel.logChannelId attribute value dThe

DltLogChannel.logChannelId attribute value shall be composed of maximum four
ASCII characters.c()
[constr_5307] Existence of DltLogChannel.logChannelId dFor each Dlt-
LogChannel, the attribute logChannelId shall exist when the Base ECU Config-
uration is defined.c()
[constr_5308] Existence of DltLogChannel.nonVerboseMode dFor each Dlt-
LogChannel, the attribute nonVerboseMode shall exist when the Base ECU Con-
figuration is defined.c()
[constr_5309] Existence of DltConfig.sessionIdSupport dFor each DltCon-
fig, the attribute sessionIdSupport shall exist when the Base ECU Configuration
is defined.c()
[constr_5310] Existence of DltConfig.timestampSupport dFor each DltCon-
fig, the attribute timestampSupport shall exist when the Base ECU Configuration
is defined.c()
[constr_5311] Existence of DltLogChannel.logTraceDefaultLogThreshold
dFor each DltLogChannel, the attribute logTraceDefaultLogThreshold shall
exist when the Base ECU Configuration is defined.c()
[constr_5312] Existence of DltLogChannel.defaultTraceState dFor each
DltLogChannel, the attribute defaultTraceState shall exist when the Base ECU
Configuration is defined.c()
[constr_5313] Existence of DltLogChannel.txPduTriggering dFor each Dlt-
LogChannel, the reference to PduTriggering in the role txPduTriggering shall
exist when the Base ECU Configuration is defined.c()
[constr_5314] DltLogChannel txPduTriggering and rxPduTriggering shall
be on the same network dThe PduTriggerings that are referenced by a Dlt-
LogChannel in the role txPduTriggering and rxPduTriggering shall be aggre-
gated by the same PhysicalChannel.c()

6.14 Support of Complex Drivers

The System Template allows the integration of custom communication means into
AUTOSAR EcuInstances.
[TPS_SYST_01115] CDD communication support dThe elements UserDefined-
Pdu and UserDefinedIPdu shall be used to describe the Pdu-based communication
via Complex Drivers.c(RS_SYST_00043)
The UserDefinedPdu and UserDefinedIPdu elements are described in chapter
6.3 in more detail.

579 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

The UserDefinedIPdu can be used to describe the communication if a new BSW

module was added above the PduR, e.g a Diagnostic Service.

CDD

UserDefinedIPdu

PDU Router

UserDefinedIPdu
UserDefinedIPdu

Bus Tp

N-PDU

Communication
HW
Bus Interface Abstraction

L-PDU

Communication Drivers

Bus Driver

Figure 6.98: CDD over PduR

The UserDefinedPdu can be used to describe the communication if a new BSW

module was added above an Interface, e.g. a new Nm module or XCP.

CDD

UserDefinedPdu

Communication
HW
Bus Interface Abstraction

L-PDU

Communication Drivers

Bus Driver

Figure 6.99: CDD over Bus Interface

6.15 MetaData in SenderReceiverInterface

As described in [5], there is the ability for the application software to unlock access
to Pdu meta-data by using the aggregation SenderReceiverInterface.meta-
DataItemSet.

580 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

This modeling allows for the arbitrary definition of meta-data semantics that - of course
- has to be supported by the Pdu where a specific dataElement is finally mapped to.
This consistency is ensured by deriving the Pdu meta-data from the modeling
in SenderReceiverInterfaces. However, this approach can only work if all
dataElements mapped to the given Pdu define the same meta-data structure or do
not define the usage of meta-data at all.
[constr_5100] Compatibility of two MetaDataItemSets dUnder the condition that
sender and receiver typed by a SenderReceiverInterface use meta-data and
are mapped to the same EcuInstance the following condition applies: two Meta-
DataItemSets are compatible if all of the following conditions are fulfilled:
• They aggregate the same number of MetaDataItems.
• The value of MetaDataItem.length of corresponding MetaDataItems is
identical.
• The value of MetaDataItem.metaDataItemType of corresponding Meta-
DataItems is identical.
c()
[constr_5101] Consistent Definition of meta-data dIf the dataElement referenced
by a SenderReceiverToSignalMapping is also referenced by a MetaDataItem-
Set in the role dataElement and the mapping via SystemSignal, ISignal, and
ISignalToIPduMapping down to an ISignalIPdu exists then all other dataEle-
ments that are also mapped to the same ISignalIPdu shall either
• not be referenced by a MetaDataItemSet in the role dataElement (i.e. does
not make use of meta-data) or
• the definition of meta-data in the context of the affected SenderReceiverIn-
terfaces is compatible (according to the definition of compatible specification
of meta-data described in [constr_5100]).
c()

6.16 Signal Service Translation

AUTOSAR Adaptive Platform restricts communication paradigm to Service-oriented
communication. A major part of the vehicle however still uses Signal-based communi-
cation means, therefore a translation of these two approaches has to be performed.
One major goal of AUTOSAR is that it covers both
• high-performance microprocessor Machines (connected via high payload and
high bandwidth Ethernet networks)
• highly embedded microcontroller ECUs (connected via ethernet, but also via low
payload and low bandwidth CAN and LIN networks).

581 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

A seamless development of a vehicle shall be supported with one AUTOSAR method-

ology. Therefore a translation
ECU Topology Example is required which closes the gap between
GW Translation
• Signal-based communication on Classic platform
• Service-oriented communication on Adaptive platform.

Adaptive Machine Classic ECU

Adaptive Application Classic SWC

Service oriented communication Signal based communication

Ethernet CAN

Gateway ECU
(Classic AUTOSAR)

SOME/IP Serialized Bytes

Signal / Service PDU a c d b
SOME/IP
Header
Translation
a b c d

Figure 6.100: Signal/Service Translation in Classic platform gateway ECU

- AUTOSAR Confidential -
The goal
6
of thisSetchapter
date in Insert ->
is to standardize a translation between the two communication
Set footer in Insert -> Header & Footer

transport configurations
Header & Footer
on an AUTOSAR Classic platform ECU. A similar approach is
also provided in the Manifest specification for the Adaptive platform [33]. It is up to the
vehicle architecture design to choose whether the signal/service translation
shall be implemented on a Classic platform ECU or on an Adaptive platform Machine.

6.16.1 Architectural setup

The implementation of the signal/service translation on the Classic platform

is done in an Application Software Component above the RTE. This applies for events
and field notifiers. Methods are handled separately (see section 6.16.1.1).

582 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
Classic AUTOSAR Transformer chain AUTOSAR CP R21-11

Gateway ECU

Translation Application SWC

Signal
Service
Mapping

COM Based
Serializer
Transformer
RTE

E2E Transformer E2E Transformer

COM-Stack

SOME/IP Serialized Bytes Com Pdu

SOME/IP
Header a b c d a d c b

Figure 6.101: Signal/Service Translation Application Software Component

- AUTOSAR Confidential -
For the signal-based part the full functionality of the Classic platform COM-Stack is
8 Signal Service
available andTranslation
may be configured such that the signal-based ISignalIPdus may orig-
inate from a variety of sources (Can, Lin, FlexRay) and the ISignalIPdus may be
safety and security protected.
For the service-oriented part it has to be guaranteed that the defined SOME/IP Service
actually is compatible to the Adaptive platform. This applies for the payload part (e.g.
the SOME/IP serializer has to be used) as well as for the control path using BswM and
ServiceDiscovery.
The behavioral part of the Translation Software Component itself defines how the data
from signal-based side is transported to the service-oriented side, and vice versa (see
section 6.16.4).
The following terminology is used in the context of signal/service translation:
Signal/service translation defines the feature this chapter is concerned with. It does
not prescribe a specific translation direction.
Signal-service-translation defines the translation direction from a signal-based to a ser-
vice oriented representation.
Service-signal-translation defines the translation direction from a service oriented to a
signal-based representation.

583 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.16.1.1 Method handling

The handling of methods (or getter/setter calls of fields) has to be serialized using the
SOME/IP transformer. And this is only supported on Ethernet networks (see [con-
str_5117]).
Therefore there is no need to perform a translation because the methods are already
usable on the adaptive platform.

6.16.2 Mapping description

Signal/service translation is used to alter the serialization representation of data to

be compatible with the respective transport network. I.e. on an Ethernet network a
SOME/IP serialized data representation is mostly suitable, while on a CAN network the
packed signal-based data representation often required due to the low payload data
size available.
As indicated in section 6.16.1 the implementation of the translation shall be done in
an Application Software Component above the RTE. For the definition of the intended
mapping and behavior however the CompositionSwComponentType is used. This
allows to represent the requirements on the translation and still allow some freedom
with respect to the actual implementation later on.
The element which defines the behavioral aspects of the signal/service trans-
lation is the meta-class SignalServiceTranslationProps. The references
to the VariableDataPrototype in the role translationTarget define to which
events the SignalServiceTranslationProps apply. For this reference a Vari-
ableDataPrototypeInSystemInstanceRef is used (see also chapter B.8).
• In case of signal-service-translation the SignalServiceTransla-
tionProps.translationTarget collect all resulting events which belong to
one provided service instance.
• In case of service-signal-translation the SignalServiceTransla-
tionProps.translationTarget collect all resulting signals which are trans-
lated from one service instance.

584 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

ARElement FibexElement
SignalServiceTranslationPropsSet ISignalIPduGroup

+dynamicPncMappingPduGroup 0..* +pncGroup 0..*

+signalServiceTranslationProps 0..*

Identifiable Referrable Describable

+controlPnc
SignalServiceTranslationProps PncMappingIdent +ident PncMapping
0..*
+ serviceControl: 0..1 + pncIdentifier: PositiveInteger
SignalServiceTranslationControlEnum + pncWakeupEnable: Boolean [0..1]
+ shortLabel: Identifier [0..1]

«enumeration» AbstractServiceInstance
SignalServiceTranslationControlEnum
ConsumedServiceInstance
translationStart
partialNetwork
serviceDiscovery
«atpVariation»
+consumedEventGroup 0..*

+controlConsumedEventGroup Identifiable
ConsumedEventGroup
0..*

+controlProvidedEventGroup Identifiable
EventHandler
0..*

+eventHandler 0..*
«atpVariation»
+signalServiceTranslationEventProps 0..*

Identifiable AutosarDataPrototype AbstractServiceInstance

SignalServiceTranslationEventProps +translationTarget VariableDataPrototype
ProvidedServiceInstance
+ safeTranslation: Boolean «instanceRef» 0..1
+ secureTranslation: Boolean

Figure 6.102: Signal/Service Translation properties

Class SignalServiceTranslationPropsSet
Package M2::AUTOSARTemplates::CommonStructure::SignalServiceTranslation
Note Collection of SignalServiceTranslationProps.
Tags:atp.recommendedPackage=SignalServiceTranslationProps
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
signalService SignalService * aggr Collection of SignalServiceTranslationProps.
Translation TranslationProps
Props

Table 6.285: SignalServiceTranslationPropsSet

Class SignalServiceTranslationProps
Package M2::AUTOSARTemplates::CommonStructure::SignalServiceTranslation
Note This element allows to define the properties which are applicable for the signal/service translation
service.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
control ConsumedEventGroup * ref Reference to the EventGroup which encapsulates the
Consumed signal-based payload.
EventGroup
controlPnc PncMappingIdent * ref Reference to the PNCs which control the offer/subscribe
behavior of the translated service instance.
controlProvided EventHandler * ref Reference to the provided event group (aka Event
EventGroup Handler) which is automatically available when service
Control equals translationStart.
5

585 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class SignalServiceTranslationProps
serviceControl SignalService 1 attr Defines how the service instance control shall behave.
TranslationControlEnum
signalService SignalService * aggr Defines properties for a single translated event.
Translation TranslationEventProps
EventProps

Table 6.286: SignalServiceTranslationProps

Class SignalServiceTranslationEventProps
Package M2::AUTOSARTemplates::CommonStructure::SignalServiceTranslation
Note This element allows to define the properties which are applicable for the signal/service translation event.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
elementProps SignalService * aggr Defines properties for a single translated element.
TranslationElement
Props
safeTranslation Boolean 1 attr Defined whether the translation shall happen in a safe
way.
secure Boolean 1 attr Defined whether the translation shall happen in a secure
Translation way.
translation VariableDataPrototype 0..1 iref Reference to a VariableDataPrototype representing the
Target target of signal/service translation.
InstanceRef implemented by:VariableDataPrototypeIn
SystemInstanceRef

Table 6.287: SignalServiceTranslationEventProps

A simple signal/service translation setup is to have a one-to-one correspon-

dence between the signal-based data definition and the service-oriented data defini-
tion. This is illustrated in figure 6.103.
Here the setup allows for a simple PassThroughSwConnector because the involved
PortInterfaces are identical.
Please consult with [constr_1248] in the Software Component Template [5] for details
on the compatibility of connected PortInterfaces.
Note that the translated P1.dataX and P2.dataB may be configured in the COM-Stack
to be events that belong to one service instance or to belong to two different ser-
vice instances. The setup in the example of figure 6.103 uses two SignalSer-
viceTranslationProps elements and those use SignalServiceTranslation-
EventProps, indicating that P1.dataX belongs to a different service instance than
P2.dataB.

586 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

PassThroughConnector – simple 1:1
System Template
AUTOSAR CP R21-11

S/R Interface ifX

- dataX {A,C}

SignalServiceTranslationProps X

PassThroughConnector ptc1 SignalServiceTranslationEventProps X

• requiredOuterPort: R1
• providedOuterPort: P1

Signal Service Translation

R1 P1
SignalServiceTranslationProps B

R2 P2 SignalServiceTranslationEventProps B

S/R Interface ifB

- dataB PassThroughConnector ptc2 S/R Interface ifB
• requiredOuterPort: R2 - dataB
• providedOuterPort: P2

Figure 6.103: Mapping description using only PassThroughSwConnectors

The usage of the PassThroughSwConnector and (optionally) the accompanying

PassThroughConnector and
PortInterfaceMapping already suffice
InterfaceMapping
- AUTOSAR to describe
Confidential - the intended mapping from a
10 SignalServiceTranslation_PassThroughConnector.pdf
structural point of view:
Set date in Insert -> Set footer in Insert -> Header & Footer
Header & Footer

VariableAndParameterInterfaceMapping vpim1
• DataPrototypeMapping mapping1
• firstDataPrototype=dataX
• secondDataPrototype=dataZ1
• subElementMapping
PassThroughConnector ptc1 • firstElement=ifX.dataX.A
• requiredOuterPort: R1 • secondElement=ifZ.dataZ1.A
• providedOuterPort: P1 • subElementMapping
• firstElement=ifX.dataX.C
• secondElement=ifZ.dataZ1.C
S/R Interface ifX
- dataX {A,C}

Signal Service Translation

SignalServiceTranslationProps Z
R1 P1
SignalServiceTranslationEventProps Z1
SignalServiceTranslationEventProps Z2
R2 S/R Interface ifZ
- dataZ1 {A,C}
- dataZ2 {B}
S/R Interface ifY
- dataY {B}

PassThroughConnector ptc2 VariableAndParameterInterfaceMapping vpim2

• requiredOuterPort: R2 • DataPrototypeMapping mapping1
• providedOuterPort: P1 • firstDataPrototype=dataY
• secondDataPrototype=dataZ2
• subElementMapping
• firstElement=ifY.dataY.B
• secondElement=ifZ.dataZ2.B

- AUTOSAR
Figure 6.104: Mapping description using Confidential -
PassThroughSwConnectors and PortInter-
faceMappings
13 Set date in Insert ->
Header & Footer
Set footer in Insert -> Header & Footer

587 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

In figure 6.104 the additional usage of PortInterfaceMappings is required because

the connected PortInterfaces are not identical (in this example have different
shortNames).
In this example there is only one SignalServiceTranslationProps element de-
fined which uses two SignalServiceTranslationEventProps to refer to both
the data elements dataZ1 and dataZ2. Thus the translated events belong to the same
service instance.
Although the figure 6.104 indicates that the output Port P1 data dataZ1 and dataZ2 are
composed of input from several sources, this is not true for the individual data elements.
P1.dataZ1 is solely composed out of R1.dataX, while P1.dataZ2 is composed out of
R2.dataY. Thus the example shown is still a mapping from one source.
The usage of PortInterfaceMapping (specifically VariableAndParameterIn-
terfaceMapping with a DataPrototypeMapping) brings along a restriction on the
applicability of the PassThroughSwConnector usage. Specifically the mapped ele-
ments have to be both either
• typed by an ApplicationPrimitiveDataType or
• typed by an ApplicationCompositeDataType.
The mixed case (where one AutosarDataPrototype is typed by an Applica-
tionPrimitiveDataType and the other is typed by an ApplicationComposite-
DataType) is not supported by the DataPrototypeMapping. This is illustrated in
figure 6.105: The interface ifX has two VariableDataPrototypes typed by Ap-
plicationPrimitiveDataTypes, while the ifZ has a VariableDataPrototype
typed by a ApplicationCompositeDataType (having the members A, C).

588 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

PassThroughConnector and InterfaceMapping – NOT SUPPORTED
SignalServiceTranslation_PassThroughConnectorNotSupported.pdf
System Template
AUTOSAR CP R21-11

VariableAndParameterInterfaceMapping vpim1
• DataPrototypeMapping mapping1
PassThroughConnector ptc1 • firstDataPrototype=dataA
• requiredOuterPort: R1 • secondDataPrototype=dataZ1
• providedOuterPort: P1 • subElementMapping
• firstElement=???.dataA
• secondElement=ifZ.dataZ1.A

S/R Interface ifX

- dataA
- dataC
Signal Service Translation
R1 P1

R2 S/R Interface ifZ

- dataZ1 {A,C}
- dataZ2 {B}
S/R Interface ifY
- dataY {B}

PassThroughConnector ptc2 VariableAndParameterInterfaceMapping vpim2

- AUTOSAR
Figure 6.105: Not supported mapping description using Confidential -
PassThroughSwConnectors
and14PortInterfaceMappings
Set date in Insert -> Set footer in Insert -> Header & Footer
Header & Footer

6.16.2.1 Filters and Transmission Triggers

The filters and transmissionTriggers can be used to define behavioral as-

pects of the signal/service translation. They are defined in the SignalSer-
viceTranslationElementProps, which is aggregated by the SignalService-
TranslationEventProps.

589 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Identifiable
SignalServiceTranslationProps

+ serviceControl: SignalServiceTranslationControlEnum

+signalServiceTranslationEventProps 0..*

Identifiable AutosarDataPrototype
+translationTarget
SignalServiceTranslationEventProps VariableDataPrototype
«instanceRef» 0..1
+ safeTranslation: Boolean «enumeration»
+ secureTranslation: Boolean DataFilterTypeEnum

always
maskedNewEqualsX
maskedNewDiffersMaskedOld
+elementProps 0..* maskedNewDiffersX
never
Identifiable +element newIsWithin
DataPrototypeReference
SignalServiceTranslationElementProps newIsOutside
0..1 + tagId: PositiveInteger [0..1] oneEveryN
+ transmissionTrigger: Boolean [0..1]

+filter 0..1

DataFilter ImplementationDataTypeElementInPortInterfaceRef DataPrototypeInPortInterfaceRef

+ dataFilterType: DataFilterTypeEnum [0..1]
+ mask: UnlimitedInteger [0..1]
+ max: UnlimitedInteger [0..1] +dataPrototypeInSenderReceiverInterface 0..1
+ min: UnlimitedInteger [0..1]
DataPrototypeInPortInterfaceInstanceRef
+ offset: PositiveInteger [0..1]
+ period: PositiveInteger [0..1] DataPrototypeInSenderReceiverInterfaceInstanceRef
+ x: UnlimitedInteger [0..1]

+dataPrototypeInClientServerInterface 0..1

DataPrototypeInPortInterfaceInstanceRef
DataPrototypeInClientServerInterfaceInstanceRef

Figure 6.106: Signal/Service Translation element properties

Class SignalServiceTranslationElementProps
Package M2::AUTOSARTemplates::CommonStructure::SignalServiceTranslation
Note Defined translation properties for individual mapped elements.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
element DataPrototype 0..1 aggr Reference to the leaf element the SignalService
Reference TranslationElementProps apply to.
filter DataFilter 0..1 aggr Defines an optional filter to be applied during translation.
transmission Boolean 0..1 attr Defines whether the source element (which is mapped to
Trigger the referenced element) triggers the sending of the
respective payload.

Table 6.288: SignalServiceTranslationElementProps

To which data the filter and/or transmissionTrigger applies is defined by the

combination of SignalServiceTranslationEventProps.translationTarget
and SignalServiceTranslationElementProps.element references.
In case the filter and/or transmissionTrigger shall apply to the transla-
tionTarget as a whole the reference SignalServiceTranslationElement-
Props.element shall not be defined. This is specifically true if SignalService-
TranslationEventProps.translationTarget refers to a VariableDataPro-
totype that is typed by a primitive AutosarDataType:

590 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_3651] No element in case translationTarget is primitive dIf Sig-

nalServiceTranslationEventProps.translationTarget refers to a Vari-
ableDataPrototype that is typed by a primitive AutosarDataType then the refer-
ence SignalServiceTranslationElementProps.element shall not be defined.c
()
Since the reference DataPrototypeReference is used in several scenarios
(see [TPS_SYST_02195]) it needs to be constrained for the usage in scope of
the signal/service translation (i.e., for SignalServiceTranslationEle-
mentProps.element): The DataPrototypeReference used to define the Sig-
nalServiceTranslationElementProps.element is restricted to either Dat-
aPrototypeInSenderReceiverInterfaceInstanceRef or Implementation-
DataTypeElementInPortInterfaceRef.
[constr_3652] Allowed sub-classes of DataPrototypeReference in the context
of signal/service translation dIf a DataPrototypeReference in the role
SignalServiceTranslationElementProps.element is used then following sub-
classes are supported:
• if the reference target is typed by an ApplicationDataType then the Dat-
aPrototypeInSenderReceiverInterfaceInstanceRef shall be used and
shall target an ApplicationCompositeElementDataPrototype.
• if the reference target is typed by an ImplementationDataType then the Im-
plementationDataTypeElementInPortInterfaceRef shall be used.
c()
It is important that the SignalServiceTranslationEventProps.translation-
Target reference and the SignalServiceTranslationElementProps.element
in the context of one SignalServiceTranslationEventProps are consistent.
Consistent usage of either ApplicationDataType or ImplementationDataType
and consistent translationTarget target and element root:
[constr_3653] Consistent translationTarget and element in case Appli-
cationDataType is used dIf the SignalServiceTranslationEventProps.
translationTarget refers to a VariableDataPrototype that is typed by
an ApplicationDataType (targetDataPrototype of the VariableDataPro-
totypeInSystemInstanceRef) then every SignalServiceTranslationEle-
mentProps.element reference that is defined in the context of the SignalSer-
viceTranslationEventProps shall have that VariableDataPrototype as the
rootDataPrototypeInSr of the DataPrototypeInSenderReceiverInter-
faceInstanceRef.c()
[constr_3654] Consistent translationTarget and element in case Imple-
mentationDataType is used dIf the SignalServiceTranslationEventProps.
translationTarget refers to a VariableDataPrototype that is typed by an

591 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

ImplementationDataType (targetDataPrototype of the VariableDataPro-

totypeInSystemInstanceRef) then every SignalServiceTranslationEle-
mentProps.element reference that is defined in the context of the SignalSer-
viceTranslationEventProps shall have that VariableDataPrototype as the
rootDataPrototype of the ImplementationDataTypeElementInPortInter-
faceRef.c()
[TPS_SYST_03062] Definition of a primitive target for SignalServiceTrans-
lationElementProps dThe target of a SignalServiceTranslationElement-
Props is considered primitive if either:
• SignalServiceTranslationEventProps.translationTarget refers to a
VariableDataPrototype that is typed by a primitive AutosarDataType or
• SignalServiceTranslationEventProps.translationTarget refers to a
VariableDataPrototype that is typed by a composite AutosarDataType
and SignalServiceTranslationElementProps.element refers to an Au-
tosarDataPrototype that is typed by a primitive AutosarDataType.
c(RS_SYST_00059)
[TPS_SYST_03063] Definition of a composite target for SignalServiceTrans-
lationElementProps dThe target of a SignalServiceTranslationElement-
Props is considered composite if either:
• SignalServiceTranslationEventProps.translationTarget refers to a
VariableDataPrototype that is typed by a composite AutosarDataType
and no reference for SignalServiceTranslationElementProps.element
is given or
• SignalServiceTranslationEventProps.translationTarget refers to a
VariableDataPrototype that is typed by a composite AutosarDataType
and SignalServiceTranslationElementProps.element refers to an Au-
tosarDataPrototype that is typed by a composite AutosarDataType.
c(RS_SYST_00059)
The filter can be used to define a guard on the translated data. If the input data
does no pass the filter then the impacted data is not translated. It depends on the kind
of the translated data and the filter intention which filter types are supported:
[constr_3655] Supported filter types for primitive SignalServiceTransla-
tionElementProps dIf the target for SignalServiceTranslationElement-
Props is defined as primitive according to [TPS_SYST_03062] then the following val-
ues for dataFilterType are supported:
• always
• maskedNewDiffersMaskedOld
• maskedNewDiffersX

592 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• maskedNewEqualsX
• never
• newIsOutside
• newIsWithin
• oneEveryN.
c()
[constr_3656] Supported filter types for composite SignalServiceTransla-
tionElementProps dIf the target for SignalServiceTranslationElement-
Props is defined as composite according to [TPS_SYST_03062] then the following
values for dataFilterType are supported:
• always
• never
• oneEveryN.
c()
The SignalServiceTranslationElementProps.transmissionTrigger de-
fines whether translated data actually triggers the sending of the SignalService-
TranslationEventProps.translationTarget.
One aspect is when the translationTarget is composed out of several sources
(see [TPS_SYST_03040]). In this section the discussion is about whether trans-
missionTrigger is also applicable for the case where the translationTarget is
created out of one source.
If the Translation Application Software Component is implemented to perform the
signal/service translation in a periodic way (see [TPS_SYST_03042] and
[TPS_SYST_03043]) the transmissionTrigger can be used to define whether the
signal/service translation of that specific data actually triggers the sending or
whether the sending is deferred to the periodic invocation of the Translation Application
Software Component.
If the signal/service translation is configured to be done in a periodic way,
then
• if the transmissionTrigger is set to true at least once then the transla-
tionTarget will be produced based on the periodicity AND additionally every
time the input data arrives where transmissionTrigger is set to true
• if the transmissionTrigger is set to false for all members of the trans-
lationTarget then the translationTarget will be produced based on the
periodicity ONLY.
If the signal/service translation is configured to be done in a NON periodic
way (event driven only), then

593 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• if the transmissionTrigger is set to true at least once then the transla-

tionTarget will be produced every time the input data arrives where trans-
missionTrigger is set to true
• if the transmissionTrigger is set to false for all members of the transla-
tionTarget then the translationTarget will NOT be sent at all (as there is
no triggering defined, neither periodic nor via transmissionTrigger).

6.16.2.2 Mapping description from several sources

The mapping setup in figure 6.107 shows an example of a true multi-source mapping
definition: The content of dataZ3 is composed out of several sources: dataX and
PassThroughConnector and InterfaceMapping and collection from different sources
dataY.
VariableAndParameterInterfaceMapping vpim1
• DataPrototypeMapping mapping1
• firstDataPrototype=dataX
• secondDataPrototype=dataZ3
• subElementMapping
PassThroughConnector ptc1 • firstElement=ifX.dataX.A
• requiredOuterPort: R1 • secondElement=ifZ.dataZ3.A
• providedOuterPort: P1 • subElementMapping
• firstElement=ifX.dataX.C
• secondElement=ifZ.dataZ3.C
S/R Interface ifX
- dataX {A,C}

Signal Service Translation

S/R Interface ifZ

- dataZ3 {A,B,C}
S/R Interface ifY
- dataY {B}
VariableAndParameterInterfaceMapping vpim2
• DataPrototypeMapping mapping1
PassThroughConnector ptc2 • firstDataPrototype=dataY
• requiredOuterPort: R2 • secondDataPrototype=dataZ3
• providedOuterPort: P1 • subElementMapping
• firstElement=ifY.dataY.B
• secondElement=ifZ.dataZ3.B

Figure 6.107: Mapping description using PassThroughSwConnectors and PortInter-

- AUTOSAR Confidential -
faceMappings from several sources
12 Set date in Insert -> Set footer in Insert -> Header & Footer
Header & Footer

The configuration of target data elements which are composed from several sources
into the target data element is always defined from the perspective of the target data
element.

594 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

The root of the target data element is defined by the reference SignalService-
TranslationEventProps.translationTarget. With this reference the SwCom-
ponentPrototype hosting the signal/service translation is defined, as well
as the PPortPrototype, and the translationTarget VariableDataProto-
type.
In case of signal/service translation from several sources the transla-
tionTarget VariableDataPrototype is composed out of several sources. But
the definition of element translation attributes happens on the target data elements:
SignalServiceTranslationElementProps is used to define transmission-
Trigger and filter attributes for one leaf member of the translationTar-
get data element. In order to find the source data element to be translated
the PassThroughSwConnectors and potential VariableAndParameterInter-
faceMappings have to be considered as well.
Since the translationTarget may be composed from several sources a restriction
applies to the swImplPolicy of the involved source data.
A setup where several source data elements have the attribute swImplPolicy set to
queued leads to runtime issues, as - at the point in time when the translation-
Target shall be composed - all the source data elements need to be gathered. But
in case of a source data element where swImplPolicy is set to queued a source
data element queue might be empty. An empty queue might have a variety of reasons,
e.g. the rate at which the queue is filled is slower than the rate the signal/service
translation consumes the data.
Thus it would be very unlikely that all the source data element queues have at least
one element to be read and consumed at the point in time when the signal/service
translation tries to read them.
[TPS_SYST_03059] At most one queued source input in case of signal/ser-
vice translation from several sources dIf the SignalServiceTranslation-
EventProps.translationTarget is composed out of several sources then at most
one of these sources shall have the attribute swImplPolicy set to queued.c(RS_-
SYST_00059)
[TPS_SYST_03060] Source input with queued semantics shall have transmis-
sionTrigger set to true dIf a source data element has the attribute swImplPolicy
set to queued then the corresponding target SignalServiceTranslationEle-
mentProps shall have the attribute transmissionTrigger set to true.
This shall be the only SignalServiceTranslationElementProps which has
transmissionTrigger set to true in the scope of the SignalServiceTransla-
tionEventProps.c(RS_SYST_00059)
Note: [TPS_SYST_03060] implies that only one source can be queued and that source
shall be the only source which has the transmissionTrigger set to true.
The queued reception of a source data element might cause an issue (e.g., unclear
behavior in case of empty queues or queue overruns) with the periodic reception

595 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

(see [TPS_SYST_03042]) or sending (see [TPS_SYST_03043]). Thus this combina-

tion is not supported by the signal/service translation.
[TPS_SYST_03061] No support for queued reception semantics in combination
with periodic communication dIf in the scope of a SignalServiceTranslation-
EventProps.translationTarget the translationTarget has a periodic send-
ing defined according to [TPS_SYST_03043] and/or at least one source data element
has a periodic reception defined according to [TPS_SYST_03042] then none of the
source data elements shall have a queued reception semantics.c(RS_SYST_00059)
[TPS_SYST_03038] Definition of transmission triggers for translations with
different sources dThe attribute SignalServiceTranslationElementProps.
transmissionTrigger defines which translation elements (SignalService-
TranslationElementProps.element) contribute to the transmission triggering for
the mapped payload.c(RS_SYST_00059)
[TPS_SYST_03039] Full translation before transmission triggering dIn case there
has been a transmission trigger caused by a source signal the signal/service
translation shall process all other mapped source signals from the triggering
source context (signal group or IPdu) before actually sending out the target.c(RS_-
SYST_00059)
This basically means that for example if in the scenario depicted in figure 6.107
dataZ3.B were configured to trigger a transmission of dataZ3, then upon the reception
event of dataY both dataX and dataY shall be received (by calling the corresponding
RTE APIs), dataZ3 shall be assembled out of the received dataX and dataY in order
to fill dataZ3.A, dataZ3.B, and dataZ3.C with up-to-date information, and finally dataZ3
shall be sent (by calling the corresponding RTE API).
[TPS_SYST_03040] Transmission trigger for translations with different sources
dIf the attribute SignalServiceTranslationElementProps.transmission-
Trigger equals true then
the reception of the respective source signal does cause the sending of the tar-
get (after all mapped sources from the same source context have been translated,
see [TPS_SYST_03039]).c(RS_SYST_00059)
[TPS_SYST_03041] No transmission trigger for translations with different
sources dIf the attribute SignalServiceTranslationElementProps.trans-
missionTrigger is not defined or has the value false then
the reception of the respective source signal does not cause the sending of the target.c
(RS_SYST_00059)

6.16.2.3 Mapping description and data conversion

As the mapping for signal/service translation is implemented on Application

level also the data conversion possibilities of the RTE may be used directly. [TPS_-
SWCT_01560] and [TPS_SWCT_01561] in the Software Component Template [5] de-
fine for which categorys of CompuMethods data conversion is supported.

596 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.16.2.4 Implementation of PassThroughSwConnectors

The definition of SignalServiceTranslationProps, PassThroughSwConnec-

tors and potential VariableAndParameterInterfaceMappings specify the re-
quirements what the signal/service translation shall do. The actual imple-
mentation needs to be done by code executed in the scope of a SwComponentPro-
totype typed by an AtomicSwComponentType.
Whether the SwComponentPrototype implementing the signal/service
translation (typed by an AtomicSwComponentType) is put inside the Compo-
sitionSwComponentType which used to define the PassThroughSwConnectors
or whether the SwComponentPrototype implementing the signal/service
translation replaces the CompositionSwComponentType is left to the imple-
mentation.
The goal of this approach is that the model and the code of the signal/-
service translation AtomicSwComponentType can be automatically de-
rived / generated from the requirements stated in the SignalServiceTransla-
tionProps, PassThroughSwConnectors, and VariableAndParameterInter-
faceMappings. This may include the definition of one or more
• ApplicationSwComponentType
• SwcInternalBehavior
• RunnableEntity
• VariableAccess
Figure 6.108 shows an example where the upper part illustrates the Composition-
SwComponentType with PassThroughSwConnectors and VariableAndParam-
eterInterfaceMappings. The lower part of the figure sketches an Atomic-
SwComponentType actually hosting the code which implements the signal/ser-
vice translation.

597 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
PassThroughConnector and InterfaceMapping AUTOSAR CP R21-11
SignalServiceTranslation_PassThroughConnector.pdf

VariableAndParameterInterfaceMapping vpim1
• DataPrototypeMapping mapping1
• firstDataPrototype=dataX
• secondDataPrototype=dataZ1
• subElementMapping
PassThroughConnector ptc1 • firstElement=ifX.dataX.A
• requiredOuterPort: R1 • secondElement=ifZ.dataZ1.L
• providedOuterPort: P1 • subElementMapping
• firstElement=ifX.dataX.C
• secondElement=ifZ.dataZ1.K
S/R Interface ifX
- dataX {A,C}

Signal Service Translation

R1 P1

S/R Interface ifZ

- dataZ1 {K,L}

AtomicSoftwareComponent

P1.dataZ1.K = R1.dataX.C;
R1 P1.dataZ1.L = R1.dataX.A; P1

Figure 6.108: Implementation of PassThroughSwConnectors and PortInterfaceMappings

- AUTOSAR Confidential -

12
6.16.3 Service discovery control
Set date in Insert -> Set footer in Insert -> Header & Footer
Header & Footer

The service discovery module [27] handles the offering/finding of service instances as
well as the subscription to event groups. The behavior for each service instance may
be controlled by Application software components via the BswM.
In scope of the signal/service translation the Translation Software Compo-
nent needs to take control of the offering and subscribing to service instances. The
general setup is illustrated in figure 6.109.

598 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

SD Control

System Template
AUTOSAR CP R21-11

Service available
PDU A C R
data
PDU B R P Serializer
Transformer
SOME/IP
S/R Interface ifZ Header A C
- dataZ1 {A,C}
- dataZ2 {B} LdCom BswM
offer
enableRouting
PduR SD

SoAd

Message SOME/IP Message SOME/IP

Length Header A C Length Header SD

Figure 6.109: Interaction between translation SWC can Service Discovery

At which point in time a specific service instance (originating from signal/service

translation) is actually offered / subscribed at the service discovery can be defined
- AUTOSAR Confidential -
per service instance:
14 Set date in Insert -> Set footer in Insert -> Header & Footer
Header & Footer
Possible approaches for service availability/subscription are:
• translationStart - start of ECU (see section 6.16.3.1)
• partialNetwork - availability of involved partial networks (see section 6.16.3.2)
• serviceDiscovery - availability of related service instance (see section
6.16.3.3)
The attribute SignalServiceTranslationProps.serviceControl defines the
service instance control behavior.
Enumeration SignalServiceTranslationControlEnum
Package M2::AUTOSARTemplates::CommonStructure::SignalServiceTranslation
Note This enumeration allows to define how the service instance offer/subscribe control shall behave.
Literal Description
partialNetwork Defines the start of service control when specific partial networks are active.
Tags:atp.EnumerationLiteralIndex=1
serviceDiscovery Defines the start of service control when other service is available.
Tags:atp.EnumerationLiteralIndex=2
translationStart Defines the start of service control at translation start.
Tags:atp.EnumerationLiteralIndex=0

Table 6.289: SignalServiceTranslationControlEnum

599 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.16.3.1 Service control at ECU start

The approach of service control at ECU start is to utilize the AutoAvailable / AutoRe-
quire feature of the service discovery module where the service instance is automat-
ically offered at startup of the ECU. In this case the translation software component
does not need to interact with the BswM to control the service state of each individual
service instance.
It is configurable per translated service event whether that event shall be automatically
controlled at ECU start.
[TPS_SYST_03022] autoAvailable setting for provided service instance with
translationStart dFor a provided translated service instance, if the Sig-
nalServiceTranslationProps.serviceControl equals translationStart,
then the ProvidedServiceInstance owning the EventHandler referenced by
SignalServiceTranslationProps.controlProvidedEventGroup shall have
its autoAvailable attribute set to true.c(RS_SYST_00059)
[TPS_SYST_03023] autoRequire setting for required service instance with
translationStart dFor a required translated service instance, if the SignalSer-
viceTranslationProps.serviceControl equals translationStart, then the
ConsumedServiceInstance owning the ConsumedEventGroup referenced by
SignalServiceTranslationProps.controlConsumedEventGroup shall have
its autoRequire attribute set to true.c(RS_SYST_00059)
[TPS_SYST_03024] autoRequire setting for required event groups of required
service instance with translationStart dFor a required translated service
instance, if the SignalServiceTranslationProps.serviceControl equals
translationStart, then the ConsumedEventGroup referenced by SignalSer-
viceTranslationProps.controlConsumedEventGroup shall have its autoRe-
quire attribute set to true.c(RS_SYST_00059)

6.16.3.2 Service control due to availability of partial networks

If the availability of the signal-based PDUs is controlled using Partial Networking then
the respective translated services offers/subscriptions can only be activated if the spe-
cific partial networks are active. This relationship is used to control the availability of
specific service instances.
[constr_3545] Mandatory reference to a Pnc in case of partialNetwork dIf the
SignalServiceTranslationProps.serviceControl equals partialNetwork
then the reference SignalServiceTranslationProps.controlPnc shall point to
at least one PncMappingIdent.c()
[TPS_SYST_03025] Control of service instance in case of partialNetwork dIf
the SignalServiceTranslationProps.serviceControl equals partialNet-
work then the respective service instance shall be configured to be controlled using
the BswM/SD configuration.c(RS_SYST_00059)

600 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

The ComM states relevant for the activation are defined in the SWS document [34].
Requested Partial Network: respective PNC is in ComM status
COMM_PNC_REQUESTED or COMM_PNC_READY_SLEEP.
Released Partial Network: respective PNC is in ComM status
COMM_PNC_PREPARE_SLEEP or COMM_PNC_NO_COMMUNICATION.
[TPS_SYST_03026] Monitoring of the requested partial networks status in case
of partialNetwork for provided service instance dFor a provided translated ser-
vice instance, if the SignalServiceTranslationProps.serviceControl equals
partialNetwork then the translation software component shall monitor the status
of the referenced partial networks (referenced via SignalServiceTranslation-
Props.controlPnc).
If at least one of the referenced partial networks is in the state requested then the
translation software component shall offer the respective translated service instance.c
(RS_SYST_00059)
[TPS_SYST_03027] Monitoring of the requested partial networks status in case
of partialNetwork for required service instance dFor a required translated ser-
vice instance, if the SignalServiceTranslationProps.serviceControl equals
partialNetwork then the translation software component shall monitor the status
of the referenced partial networks (referenced via SignalServiceTranslation-
Props.controlPnc).
If at least one of the referenced partial networks is in the state requested then the
translation software component shall find the respective translated service instance
and subscribe to its event groups.c(RS_SYST_00059)
[TPS_SYST_03056] Monitoring of the released partial networks status in case
of partialNetwork for required service instance dFor a required translated ser-
vice instance, if the SignalServiceTranslationProps.serviceControl equals
partialNetwork then the translation software component shall monitor the status
of the referenced partial networks (referenced via SignalServiceTranslation-
Props.controlPnc).
If all of the referenced partial networks are in the state released then the translation
software component shall unsubscribe from its event groups.c(RS_SYST_00059)
[TPS_SYST_03057] Monitoring of the released partial networks status in case
of partialNetwork for provided service instance dFor a provided translated ser-
vice instance, if the SignalServiceTranslationProps.serviceControl equals
partialNetwork then the translation software component shall monitor the status
of the referenced partial networks (referenced via SignalServiceTranslation-
Props.controlPnc).
If all of the referenced partial networks are in the state released then the translation
software component shall stop offer ing the respective translated service instance.c
(RS_SYST_00059)

601 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.16.3.3 Service control due to availability of related service instance

There are scenarios where the transmission of signal-based PDUs is controlled by

means of SOME/IP service discovery, i.e., the signal-based PDUs are effectively of-
fered as events of a service and are only transmitted in case there are active subscrip-
tions present. Since the payload of the signal-based PDUs is not serialized according
to the SOME/IP transformer rules, even in such scenarios signal/service trans-
lation is required for the payload.
In this setup, however, the availability of the translated/target service instance depends
on the availability of the corresponding source service instance(s). Note, that this de-
pendency is irrespective of the actual direction of the translation:
• In case of signal to service translation the availability of the translated/target
service instance (which exhibits a SOME/IP serialized payload) depends on the
availability of the source service instance (which exhibits a signal-based payload).
• In case of service to signal translation the availability of the translated/target ser-
vice instance (which exhibits a signal-based payload) depends on the availability
of the source service instance (which exhibits a SOME/IP serialized payload).
Figure 6.110 illustrates an example setup showing exactly the above mentioned de-
pendency in both directions as well as the approach to handle this dependency:
Service to signal translation (case a): A SOME/IP serialized source service in-
stance shall be translated into a signal-based target service instance. Here
the signal-based target service instance shall only be offered when the corre-
sponding SOME/IP serialized source service instance is actually successfully
subscribed to. Thus the approach is to initially issue a find service for the
SOME/IP serialized source service instance. Upon the reception of an offer
service a subscribe event group is sent and, finally, upon the reception of a
subscribe event group acknowledge (i.e., upon the successful subscription) the
signal-based translated target service instance is offered. For this setup the
ConsumedEventGroup representing the SOME/IP serialized source service in-
stance of Ra is used as controlConsumedEventGroup.
Signal to service translation (case b): A signal-based source service instance shall
be translated into a SOME/IP serialized target service instance. Here the
SOME/IP serialized target service instance shall only be offered when the cor-
responding signal-based source service instance is actually successfully sub-
scribed to. The approach is analoguous to case a with source/target roles re-
versed. For this setup the ConsumedEventGroup representing the signal-based
source service instance of Rb is used as controlConsumedEventGroup.

602 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

Availability due to Service Discovery

System Template
AUTOSAR CP R21-11

a1. SOME/IP
Serialized service is
initially requested a3. if subscription is
a2. if service is found: a:service to signal acknowledged:
subscribe to event offer translated Signal Based
groups service
Signal Service Translation

Ra Pa

Pb Rb

b3. if subscription is b1. Signal Based

acknowledged: b:signal to service service is initially
offer translated SOME/IP requested
Serialized service
b2. if service is found:
subscribe to event groups

Figure 6.110: Translation based on service availability

[constr_3546] Mandatory reference to a ConsumedEventGroup in case of ser-

viceControl dFor a provided- AUTOSAR
translated Confidential
service - instance, if the SignalService-
18 TranslationProps.serviceControl
Set date in Insert -> equals
Set footer in Insert -> Header & FooterserviceDiscovery then the refer-
Header & Footer
ence SignalServiceTranslationProps.controlConsumedEventGroup shall
point to at least one ConsumedEventGroup.c()
In case SignalServiceTranslationProps.serviceControl is set to ser-
viceDiscovery then the ConsumedEventGroups referenced in role controlCon-
sumedEventGroup as well as the owning ConsumedServiceInstances are re-
quired for the availability of the provided translated service instance and thus have
to be found and subscribed to by means of find service and subscribe event group.
This finding and subscription is automatically (i.e., without the need of any SWC inter-
vention) achieved by having the ConsumedServiceInstance and the ConsumedE-
ventGroup autoRequire their instances.
[TPS_SYST_03028] Auto require for controlConsumedEventGroup in case of
service instance with serviceControl dFor a provided translated service in-
stance, if the SignalServiceTranslationProps.serviceControl equals ser-
viceDiscovery then every ConsumedEventGroup referenced in SignalSer-
viceTranslationProps.controlConsumedEventGroup shall have the autoRe-
quire attribute set to true.c(RS_SYST_00059)
[TPS_SYST_03058] Auto require for ConsumedServiceInstance in case of ser-
vice instance with serviceControl dFor a provided translated service instance, if
the SignalServiceTranslationProps.serviceControl equals serviceDis-
covery then the every ConsumedServiceInstance owning at least one of the
controlConsumedEventGroups shall have the autoRequire attribute set to true.c
(RS_SYST_00059)

603 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_03029] Offer for a provided translated service instance with ser-

viceControl dFor a provided translated service instance, if the SignalService-
TranslationProps.serviceControl equals serviceDiscovery and the sub-
scribe to all referenced controlConsumedEventGroups was successful, then the
respective translated target service instance shall be offer ed. This applies for both,
signal-service-translation as well as service-signal-translation.c
(RS_SYST_00059)
[TPS_SYST_03030] Stop offer for a provided service instance with service-
Control dFor a provided translated service instance, if the SignalServiceTrans-
lationProps.serviceControl equals serviceDiscovery and the subscription
of at least one controlConsumedEventGroup is not available, then a stop of-
fer of the respective translated target service instance shall be issued. This applies
for both, signal-service-translation as well as service-signal-trans-
lation.c(RS_SYST_00059)

6.16.4 Translation behavior

There are two possible ways to define behavioral aspects for the signal/service
translation use-case:
• COM-Stack
• Translation Application Software Component

6.16.4.1 COM-Stack translation behavior

The Classic platform COM-Stack can be configured to have an own periodic behavior
for periodic sending and reception/time-out monitoring. In this case the existing COM-
Stack definition of behavior is used.
Example features are:
• TransmissionModeTiming.cyclicTiming
• TransmissionModeTiming.eventControlledTiming
• IPduTiming.minimumDelay
• ISignalPort.timeout
Thus it is possible to register the Translation Application Software Component to be
notified when data arrives and then perform the translation operation solely driven by
the notifications from the COM-Stack.
There are use-cases where the COM-Stack can not be used to perform the specific
behavioral aspects because the Transformers are required to have access to the raw

604 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

received and sent data. In these cases the usage of the Translation Application Soft-
ware Component behavior is required.

6.16.4.2 Translation Application Software Component translation behavior

If the Translation Application Software Component shall implement specific behavioral

aspect these have to be defined at the definition of the CompositionSwComponent-
Type which has the signal/service translation input and output PortPro-
totypes as well as the PassThroughSwConnectors.
For the periodic behavior the definition of SenderComSpec.transmissionProps.
dataUpdatePeriod and ReceiverComSpec.receptionProps.dataUpdatePe-
riod define the expected periods for data update and check.
[TPS_SYST_03042] Periodic call in case of ReceiverComSpec.ReceiverCom-
Spec.receptionProps.dataUpdatePeriod dIf the signal/service transla-
tion CompositionSwComponentType has a RPortPrototype defined with a Re-
ceiverComSpec.receptionProps.dataUpdatePeriod defined then
the signal/service translation software component implementation shall pe-
riodically call the respective Rte reception API with the defined period.c(RS_SYST_-
00059)
[TPS_SYST_03043] Periodic call in case of SenderComSpec.transmission-
Props.dataUpdatePeriod dIf the signal/service translation Composi-
tionSwComponentType has a PPortPrototype defined with a SenderComSpec.
transmissionProps.dataUpdatePeriod defined then
the signal/service translation software component implementation shall pe-
riodically call the respective Rte sending API with the defined period.c(RS_SYST_-
00059)
Data filtering:
If there is a filter defined at the NonqueuedReceiverComSpec then the evaluation
of this DataFilter is performed in the COM-Stack. Thus the COM-Stack filtering
usually can not be applied when there are transformers involved because the state
machines of E2E transformers need to receive every message.
If a data filtering shall be applied after the data transformation inside the signal/-
service translation software component then there is the possibility to define a
DataFilter at the SignalServiceTranslationElementProps in the role fil-
ter.
[TPS_SYST_03051] Data filter inside the signal/service translation soft-
ware component dIf there is a SignalServiceTranslationElementProps.fil-
ter defined this filtering shall be implemented inside the signal/service trans-
lation software component.c(RS_SYST_00059)

605 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

6.16.5 End-to-End considerations

In case there is an E2E header attached and/or a secure communication defined the
translation needs to break the transport chain and re-calculate the E2E measures (CR-
C/MAC). The CRC/MAC is calculated over the uint8 array representation of the payload
data. Since the signal/service translation changes the data layout, also the
uint8 array representation of the payload data changes resulting in a different CRC/-
MAC value.

6.16.5.1 Safety

Due to the architectural approach of the signal/service translation the safety

aspects can be configured using existing mechanisms. Thus it is possible to define
dedicated safety end-to-end profiles for both the signal-based part, and the service-
Classic using
based Signal-based
part. communication
The translation software component then links the two parts together and
e.g. on CAN
handles the behavioral aspects of the translation.

Service Interface S/R Interface

- Events - Data Elements

Adaptive Application Classic SWC

Service oriented communication Signal based communication

Communication
SOME/IP COM-Based Matrix
Transformer Transformer

SOME/IP Serialized Bytes PDU

E2E E2E
Transformer Transformer

E2E SOME/IP Serialized Bytes E2E PDU

Ethernet CAN
Gateway ECU
(Classic AUTOSAR)

Figure 6.111: -Signal/Service

AUTOSAR Confidential -
Translation and Safety
13 Set date in Insert -> Set footer in Insert -> Header & Footer
Header & Footer

The attribute SignalServiceTranslationEventProps.safeTranslation is

used to explicitly require that both ends of the translation shall be configured in a safe
transport way and that the translation software component shall handle the translation
activity in a end-to-end preserving way.

606 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_03044] Handling of safe signal/service translation in one

software component dIt is required that the signal/service translation (and
vice versa) of one Service/SignalGroup pair which are mapped to each other, shall
be handled in one software component to also cover a closed mapping from one E2E
profile to another, if necessary. The signal/service translation of different (in-
dependent) Services/SignalGroups may be handled by different software component.c
(RS_SYST_00059)
[TPS_SYST_03036] PortAPIOption for safeTranslation RPortPrototype dIf
SignalServiceTranslationEventProps.safeTranslation is set to true then
a PortAPIOption referring to the RPortPrototype shall exist and the PortAPI-
Option.errorHandling attribute shall be set to transformerErrorHandling.c
(RS_SYST_00059)
[TPS_SYST_03037] PortAPIOption for safeTranslation PPortPrototype dIf
SignalServiceTranslationEventProps.safeTranslation is set to true then
a PortAPIOption referring to the PPortPrototype shall exist and the PortAPI-
Option.transformerStatusForwarding attribute shall be set to transformer-
StatusForwarding.c(RS_SYST_00059)
[TPS_SYST_03045] Support for safe signal/service translation dThe trans-
lation of E2E protected data shall be supported in both directions, signal-service-
-translation and service-signal-translation.c(RS_SYST_00059)
[TPS_SYST_03046] Support for safe signal/service translation with same
or different E2E profiles dThe translation of E2E protected data shall support the
occurrence of
• the same E2E profile on both sides of the communication and
• different E2E profiles on each side of the communication.
c(RS_SYST_00059)
[TPS_SYST_03047] 1:n mapping for E2E protected data dIt shall be possible to
map the same E2E protected source data to several E2E protected target data (1:n).c
(RS_SYST_00059)
[TPS_SYST_03048] E2E protected target out of E2E protected sources dThe con-
tent of one E2E protected target shall only be composed out of data from E2E protected
sources.c(RS_SYST_00059)
The rationale for [TPS_SYST_03048] is to support the use-case where target data
shall be E2E protected and is composed from several sources.
[TPS_SYST_03049] No translation of not OK E2E protected composed data dIf a
E2E protected source data is mapped into a composed E2E protected target data and
if the E2E-Check for the source data returns any E2E error (not E_OK ) then
this source data shall not be forwarded to the respective target data and (if applicable)
shall not trigger the transmission of the target.c(RS_SYST_00059)

607 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

If source data is not verified as E_OK it is not translated into a composed target. If the
translated E2E protected data comes from several sources there may occur correlation
and synchronicity issues during translation.
[TPS_SYST_03031] Sufficient ASIL level of translation software component
dIf the SignalServiceTranslationEventProps.safeTranslation equals true
then the implementation of the translation software component shall fulfill a sufficient
ASIL.c(RS_SYST_00059)
[constr_3548] EndToEnd profile for both ends of safeTranslation dIf the Sig-
nalServiceTranslationEventProps.safeTranslation equals true then both,
the signal-based payload as well as the service-oriented payload shall have an End-
ToEnd profile defined.c()
[TPS_SYST_03032] Data transmission in case of E_OK safe signal reception d
Signal/service translation shall check the end-to-end status of every received payload.
If the safety transformer returns E_OK for the received payload then the data shall
be forwarded to the respective sending of the translation software component.c(RS_-
SYST_00059)
Error handling:
[TPS_SYST_03033] No data transmission in case of reception timeout dIf no mes-
sage is received within the specified message cycle time (timeout is detected), then no
data shall be translated to the respective sending of the translation software compo-
nent.c(RS_SYST_00059)
[TPS_SYST_03034] Handling safe signal reception dThe behavior of transformer
status forwarding is defined in table 6.290.c(RS_SYST_00059)

608 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Source error Forwarding status Comment

E_OK E_OK –
E_SAFETY_VALID_REP E_SAFETY_INVALID_REP –
E_SAFETY_VALID_SEQ E_SAFETY_INVALID_SEQ –
E_SAFETY_VALID_ERR E_SAFETY_INVALID_CRC –
E_SAFETY_VALID_NND NO TRANSLATION No data received, thus no translation
E_SAFETY_NODATA_OK E_OK Statemachine is in state No Data, but
received data is ok
E_SAFETY_NODATA_REP E_SAFETY_INVALID_REP Statemachine is in state No Data, but
received data has repeated counter
E_SAFETY_NODATA_SEQ E_SAFETY_INVALID_SEQ Statemachine is in state No Data, but
received data has wrong sequence
counter
E_SAFETY_NODATA_ERR E_SAFETY_INVALID_CRC Statemachine is in state No Data, but
received data has CRC Error
E_SAFETY_NODATA_NND NO TRANSLATION –
E_SAFETY_INIT_OK E_OK –
E_SAFETY_INIT_REP E_SAFETY_INVALID_REP –
E_SAFETY_INIT_SEQ E_SAFETY_INVALID_SEQ –
E_SAFETY_INIT_ERR E_SAFETY_INVALID_CRC –
E_SAFETY_INIT_NND NO TRANSLATION No data received, thus no translation
E_SAFETY_INVALID_OK E_OK Statemachine is in status invalid, but
data itself is valid, thus no error
replication
E_SAFETY_INVALID_REP E_SAFETY_INVALID_REP –
E_SAFETY_INVALID_SEQ E_SAFETY_INVALID_SEQ –
E_SAFETY_INVALID_ERR E_SAFETY_INVALID_CRC –
E_SAFETY_INVALID_NND NO TRANSLATION No data received, thus no translation
E_SAFETY_SOFT_RUNTIMEERROR NO TRANSLATION –
E_SAFETY_HARD_RUNTIMEERROR NO TRANSLATION –

Table 6.290: Error to Forwarding status mapping

6.16.5.2 Security

The security aspects are handled in the communication stack of Classic platform.
There are two technologies for secure communication available:
• Secure Onboard Communication (SecOC) [35]
• Transport Layer Security (TLS) [36]
Which security technology is used for a translated service instance is up to the com-
munication design. The security settings have to match between the providers and the
consumers on the network.
As on Classic platform the translation happens on the application software component
level it is possible to have equal, similar, or different security technologies configured
on signal and service level (which is part of the COM-Stack configuration).

609 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

It is for instance well possible to have signals coming from a CanFD network secured
with SecOC and translated into a service which is secured using TLS on Ethernet. But
also using SecOC on Ethernet is possible.
In any case, if secure communication is involved together with signal/service
translation the translation needs to break the transport chain and re-secure the
payload (e.g. re-calculate the MAC for the newly serialized payload).
The attribute SignalServiceTranslationEventProps.secureTranslation is
used to explicitly require that both ends of the translation shall be configured in a secure
transport way and that the translation software component shall handle the translation
activity in a security-preserving way.
[constr_3549] Secure payload for both ends in case of secureTranslation dIf
the SignalServiceTranslationEventProps.secureTranslation equals true
then both, the signal-based payload as well as the service-oriented payload shall have
a secure communication defined.c()

610 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

7 Data Transformation

7.1 Outline
The transmission of data over a communication bus requires some effort to convey the
information about the nature of the transmitted data from the sender to the receiver.
Both sides need to agree on this part or else the communication will fail.
This aspect is complicated by the fact that in most cases it is uncommon to transmit
information in an atomic manner piece by piece. For the sake of properly utilizing
the available communication resources, pieces of data that may or may not have any
semantic relationship with each other are packed into a single transmission unit.
In this case, the receiver does not only have to be informed about the nature of the
individual pieces of information but also about the packing of these pieces into the
transmission unit.
There are different approaches of how this goal can be achieved, these are described
in the following sub-chapters.

7.1.1 Configuration of the Communication Layout

Use a configurable software package on both the sender and the receiver side that
can adapt to virtually any possible packing of data. In this case the packing shall be
described in machine-readable form on a very detailed level in order to allow for the
communication software to adapt to it.
For the sake of this argument, it doesn’t really matter whether the adaption to the con-
figuration is done at run-time or whether the configuration ends up in dedicated source
code. The point is that the very detailed machine-readable configuration description is
required to exist.
This approach used to be one of the pillars of the AUTOSAR standard as it entitled the
players in the business with a maximum amount of flexibility and especially the OEMs
are able to develop specific patterns for the design of their communication matrices
that can, despite the diversity, be expressed with this approach.
This approach also facilitates the monitoring of transmission during development and
deployment of the automotive software because monitoring tools can use the same
configuration information to set themselves up for the task. This aspect is very impor-
tant for debugging and quality assurance.
The downside, however, is that the act of laying out pieces of information in a limited
number of transmission units becomes cumbersome and time-consuming. This ef-
fect becomes even more prominent with the advent of more advanced communication
technologies that allow for a much bigger payload in single transmission units.

611 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

7.1.2 Data Transformation by Software

Don’t care about the individual layout of information on the bus and let a piece of
software take care of marshaling data onto the communication bus on the sender side
and the reverse process on the receiver side.
This approach gains attractiveness in an environment where large and complicated
pieces of information need to be transmitted.
Of course, in order to make this approach work it is necessary to standardize the
behavior of the marshaling software to the necessary extent such that sender and
receiver agree on how data needs to be processed.
With this approach, the amount of configuration can be reduced dramatically at the
potential expense of efficiency and code size.
But this is not the end of the story as the idea of letting software take care of data
"manipulation" can following pretty much the same pattern be utilized for further
use cases:
End-to-end Protection Data is wrapped into a harness of meta-data that allows for
checking data integrity at the receiver side.
Data Security Data is cryptographically processed such that it shall become impossi-
ble for unauthorized parties to intercept the communication process.
In other words, the approach is not limited to marshaling of data but can in the same
way also be used for an array of other useful data transformations. This is why the
terminology in this regard is not limited to the marshaling but to data transformation in
general, hence the term Data Transformer is coined.
Data Transformers can be chained such that, on the sender side, one Data
Transformer picks up the result of the transformation of another Data Trans-
former and applies a specific transformation to the already processed data.
The receiver then is required to apply the Data Transformers in reverse order in
order to finally yield the actual data and provide it to the consumer (e.g. an Applica-
tionSwComponentType).
A basic principle of the Data Transformer approach, however, is that the Data
Transformer is only responsible for the actual data transformation but not concerned
about the communication of data. This can be taken care of by other software modules.
In total, the second approach provides a sufficient level of utility that it becomes part
of the AUTOSAR standard. This chapter lays out the details of how Data Trans-
formers can be used in the context of this document.
Further information can also be found in the SWS RTE [37].

612 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

7.2 Use Cases

This chapter describes Transformer use cases that are supported by AUTOSAR.

7.2.1 Transmission of large composite data types over networks with large
PDUs (e.g Ethernet)

With a serializing transformer, it is not necessary any more to map the atomic sub-
elements of composite data types to individual signals in the RTE. The sending appli-
cation SWC sends the composite data element using Sender/Receiver communication
and hands the data over to the RTE. Then the complex data get transformed to a linear
byte array and handed over to Com which sends the data to the receiving ECU. There,
the Com stack receives the serialized data and notifies the RTE. The Rte reads the
data and calls the deserializing transformer. The deserializing transformer transforms
them back into the composite data element and gives the result to the RTE. The re-
ceiving SWC can now read the data and access it in the same form the sending SWC
has sent them.

ECU 1 Sending Application ECU 2 Receiving Application

SWC SWC
1. SWC sends data 11. SWC reads data

2. RTE hands data over 10. Deserialized data are handed over
to transfromer to the RTE as a composite data type
3. Data are 9. Data are
serialized deserialized

Serializing RTE Deserializing RTE

Transformer Transformer
4. Serialized data are given back to 8. RTE starts deserialization of
RTE received data

5. RTE send data to Com 7. Com gives data to RTE

Com Com

6. Data are transferred to the receiving ECU

Figure 7.1: Transformer Use Case: Transmission of large composite data types over
networks with large PDUs (e.g Ethernet)

613 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

7.2.2 Support of transmission from one sender to multiple receivers with Signal
Fan-out

If a signal fan-out is configured in the System Description, the RTE has to hand over
the data which should be transmitted multiple times to the Com stack. This is the case
if multiple ISignals reference the same SystemSignal in the System Description.
For each ISignal the following steps have to be performed individually:
• transform the data
• hand it over to COM
Every receiver has to deserialize the ISignal in its transformer independently.

ECU 1 Sending
ECU 2 Receiving ECU 3 Receiving
Application Application Application
SWC SWC 1 SWC 2

Transformer RTE Transformer RTE Transformer RTE

Com Com Com

Figure 7.2: Transformer Use Case: RTE Fanout

7.2.3 Support of transmission from one sender to multiple receivers with PDU
Fan-out

The transformation of inter-ECU Sender/Receiver communication should also work

together with configurations that include Pdu fan-outs inside the COM stack (PduR
fan-out). This is the case if multiple PduTriggerings reference the same Pdu in
the System Description. In that scenario the data are sent by the sending application
SWC to the RTE and transformed by the data transformer which is called by the RTE.
Then the RTE hands the data over the Com. This happens only once. Due to the Pdu
fan-out, the PduR sends the data multiple times to the Bus Interfaces using different
Pdus.

614 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

ECU 1 Sending
ECU 2 Receiving ECU 3 Receiving
Application Application Application
SWC SWC 1 SWC 2

Transformer RTE Transformer RTE Transformer RTE

Com
Com Com
PduR

Figure 7.3: Transformer Use Case: PduR Fanout

7.2.4 Transformer Chaining

It is possible to chain multiple transformers. The output of one transformer then will
be the input of the next transformer in the chain. Transformer for serialization data,
for encrypting, digitally signing or compressing data can be implemented and used to-
gether. Such architecture could be used to assemble a system, where you can flexibly
add functionality like compression or encryption to a serialized stream. In AUTOSAR
the E2E-protection is implemented by an additional serializer which is appended to the
chain.

615 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11
UC5

ECU 1 Sending Application ECU 2 Receiving Application

SWC SWC

Transformer 1
Transformer 1

Transformer 2 RTE
RTE

Transformer 3 Transformer 3

Com Com

Figure 7.4: Transformer Use Case: Transformer Chain

7.2.5 Signal Group Based interaction of the transformer with the Com module

An initial transformer (serializer) performs the serialization according to the ISignal-

ToIPduMapping from the system description. For each application data element the
corresponding mapping to an ISignalIPdu position is respected. After the transfor-
mation chain is processed the serialized data is provided to the Com module. The Com
module can have a signal based transmission mode selection defined and determines
the respective transmission mode to be applied.

7.3 Transformer configuration

As a transformer provides well defined function signatures per each communication
relation (ISignal based), which is marked for transformation, the function signature
is NOT dependent from the transformation technology used, but only from the trans-
mitted data elements (Client/Server operation signature or Sender/Receiver interface
signature). The output of a transformer will be always a linear byte array.
Configuration of data transformation consists of three parts:
1. definition of the transformer chains with their transformers
2. configuration which communication is subject to transformation

616 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

3. configuration of the transformer properties for the transformed communication

The configuration of single transformers and whole transformer chains is shown in
figure 7.5.
ARElement
DataPrototypeMapping
DataTransformationSet

«atpVariation,atpSplitable»
0..* +dataTransformation +secondToFirstDataTransformation 0..1 +firstToSecondDataTransformation 0..1
«atpVariation,atpSplitable» Identifiable
DataTransformation

+ dataTransformationKind: DataTransformationKindEnum [0..1]

+ executeDespiteDataUnavailability: Boolean
0..1 +dataTransformation +comBasedSignalGroupTransformation 0..1

«atpVariation,atpSplitable» «atpVariation,atpSplitable»

FibexElement FibexElement
«enumeration» ISignal +iSignal ISignalGroup
DataTransformationKindEnum
+ dataTypePolicy: DataTypePolicyEnum 0..*
symmetric + iSignalType: ISignalTypeEnum [0..1]
asymmetricFromByteArray + length: UnlimitedInteger
asymmetricToByteArray

+transformationISignalProps 0..* +transformationISignalProps 0..*

Describable
«atpVariation»
TransformationISignalProps

+ csErrorReaction: CSTransformerErrorReactionEnum [0..1]

1..* +transformer
0..* +transformationTechnology {ordered} +transformerChain 1

Identifiable «enumeration»
TransformationTechnology TransformerClassEnum

+ hasInternalState: Boolean [0..1] serializer

+ needsOriginalData: Boolean [0..1] safety
+ protocol: String security
+ transformerClass: TransformerClassEnum custom
+ version: String

+bufferProperties 1
«atpVariation»

CompuScale BufferProperties
0..1 +transformationDescription
+ mask: PositiveInteger [0..1] + headerLength: Integer
Describable + shortLabel: Identifier [0..1] + inPlace: Boolean
TransformationDescription + symbol: CIdentifier [0..1]
«atpVariation»
+ lowerLimit: Limit [0..1]
+ upperLimit: Limit [0..1]

Figure 7.5: Configuration of transformers and transformer chains

The DataTransformationSet acts as a central container for the configuration of

data transformation.
Class DataTransformationSet
Package M2::AUTOSARTemplates::SystemTemplate::Transformer
Note This element is the system wide container of DataTransformations which represent transformer chains.
Tags:atp.recommendedPackage=DataTransformationSets
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
5

617 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class DataTransformationSet
data DataTransformation * aggr This container consists of all transformer chains which
Transformation can be used for transformation of data communication.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=dataTransformation.shortName, data
Transformation.variationPoint.shortLabel
vh.latestBindingTime=codeGenerationTime
transformation Transformation * aggr Transformer that is used in a transformer chain for
Technology Technology transformation of data communication.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=transformationTechnology.shortName,
transformationTechnology.variationPoint.shortLabel
vh.latestBindingTime=codeGenerationTime

Table 7.1: DataTransformationSet

Class DataTransformation
Package M2::AUTOSARTemplates::SystemTemplate::Transformer
Note A DataTransformation represents a transformer chain. It is an ordered list of transformers.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
data DataTransformationKind 0..1 attr This attribute controls the kind of DataTransformation to
Transformation Enum be applied.
Kind
executeDespite Boolean 1 attr Specifies whether the transformer chain is executed even
Data if no input data are available.
Unavailability
transformer Transformation 1..* ref This attribute represents the definition of a chain of
Chain (ordered) Technology transformers that are supposed to be executed according
to the order of being referenced from DataTransformation.

Table 7.2: DataTransformation

[TPS_SYST_02030] The DataTransformationSet contains all transformer

chains dThe DataTransformationSet contains transformer chains represented by
DataTransformation elements.c(RS_SYST_00050)
For each transformer chain it can be decided via the attribute executeDespite-
DataUnavailability whether the RTE should try to execute the transformers of
the transformer chain, even when no data are available as input. e.g. the queue is
empty or there was an error in the COM stack. This is needed when no data are avail-
able but a transformer has to be executed anyway because it maintains an internal
state which has to be updated to consider that data was expected but not available.
This might be used in transformers which maintain an internal state. Of course the
specifications and implementations of all transformers in the chain have to be able to
cope with execution without valid input data.
[constr_3208] executeDespiteDataUnavailability usage restriction dIn the
set of more than one ISignal which reference the same SystemSignal in the role
systemSignal, there shall be no ISignal which references a DataTransforma-
tion where executeDespiteDataUnavailability is set to true.c()

618 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

In other words: There shall be no transformer chain which "belong" to the same
SystemSignal due to signal fan-in where the attribute executeDespiteDataU-
navailability is set to true.
[TPS_SYST_02031] A transformer is represented by a TransformationTech-
nology dA transformer is represented by a TransformationTechnology.c(RS_-
SYST_00050)
Class TransformationTechnology
Package M2::AUTOSARTemplates::SystemTemplate::Transformer
Note A TransformationTechnology is a transformer inside a transformer chain.
Tags:xml.namePlural=TRANSFORMATION-TECHNOLOGIES
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
bufferProperties BufferProperties 1 aggr Aggregation of the mandatory BufferProperties.
hasInternal Boolean 0..1 attr This attribute defines whether the Transformer has an
State internal state or not.
needsOriginal Boolean 0..1 attr Specifies whether this transformer gets access to the
Data SWC’s original data.
protocol String 1 attr Specifies the protocol that is implemented by this
transformer.
transformation Transformation 0..1 aggr A transformer can be configured with transformer specific
Description Description parameters which are represented by the Transformer
Description.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
transformer TransformerClassEnum 1 attr Specifies to which transformer class this transformer
Class belongs.
version String 1 attr Version of the implemented protocol.

Table 7.3: TransformationTechnology

Enumeration TransformerClassEnum
Package M2::AUTOSARTemplates::SystemTemplate::Transformer
Note Specifies the transformer class of a transformer.
Literal Description
custom The transformer is a custom transformer.
Tags:atp.EnumerationLiteralIndex=0
safety The transformer is a safety transformer.
Tags:atp.EnumerationLiteralIndex=1
security The transformer is a security transformer.
Tags:atp.EnumerationLiteralIndex=2
serializer The transformer is a serializing transformer.
Tags:atp.EnumerationLiteralIndex=3

Table 7.4: TransformerClassEnum

[constr_3265] TransformationTechnology.hasInternalState setting for an

E2E transformer dThe value of hasInternalState shall be set to true for a Trans-
formationTechnology with transformerClass set to safety.c()

619 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_3266] TransformationTechnology.hasInternalState setting for a

SOME/IP Transformer dThe value of hasInternalState shall be set to true for
a SOME/IP Transformer if SOMEIPTransformationISignalProps.sessionHan-
dlingSR for the ISignal is set to active.c()
[TPS_SYST_02032] Transformer chains are ordered list of transformers dA trans-
former chain consists of an ordered list of TransformationTechnologys (trans-
formers).c(RS_SYST_00050)
[constr_3121] The length of transformer chains is limited to 255 transformers
dThe maximum number of DataTransformation.transformerChain references
in the context of one DataTransformation shall be limited to 255.c()
[constr_3122] At most one transformer of each transformer class inside a trans-
former chain dIf the value of a transformerClass of a TransformationTech-
nology referenced by a DataTransformation does not equal custom, it shall be
different from all other transformerClass values of TransformationTechnol-
ogys referenced by the same DataTransformation.c()
Only for custom transformers it is possible to specify more than one transformer of
the same class in the same transformer chain. For all other transformer classes, at
most one transformer of a transformer class is allowed to exist in the same transformer
chain.
[constr_3123] Serializer transformer shall be the first in a chain dA serializer trans-
former (TransformationTechnology with attribute transformerClass set to
serializer) shall be the first transformer in a transformer chain.c()
[TPS_SYST_02033] Order of the transformerChain references in the configu-
ration represents the order on the sending side dThe order of DataTransforma-
tion.transformerChain references in the context of one DataTransformation
represents the transformation order on the sending side.c(RS_SYST_00050)
[TPS_SYST_02034] Order of the transformers on the receiving side is the reverse
of the sending side dThe order of the transformers on the receiving side of the data
shall be the inverse order of the order of the sending side.c(RS_SYST_00050)
[TPS_SYST_02035] protocol contains the human readable protocol identifier
dThe attribute protocol of a TransformationTechnology contains the protocol
name as a String which this transformer implements.c(RS_SYST_00050) This attribute
is used to distinguish transformers in a human readable way.
[TPS_SYST_02036] version contains the version of the protocol dThe attribute
version of a TransformationTechnology contains the version of the protocol as
a String implemented by this transformer.c(RS_SYST_00050) This attribute is used to
distinguish transformers.
[TPS_SYST_02037] The attribute needsOriginalData configures a trans-
former’s access to the original data dThe attribute needsOriginalData of a
TransformationTechnology specifies whether transformer needs access to the
original data.c(RS_SYST_00050)

620 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

If it is set to true, the transformer will gain access to the original data. If it is set to false,
the transformer will not gain access to the original data.
[constr_3124] Applicability of needsOriginalData dThe attribute needsOrig-
inalData of a TransformationTechnology shall only be used for the non-first
transformers in the transformer chain.c()
This will only influence the signatures of the transformer on the sender or client side,
not on the receiver or server side of a communication.
[TPS_SYST_02038] Specification of transformer class dThe transformer class to
which this transformer belongs to is specified in the attribute transformerClass of
a TransformationTechnologyc(RS_SYST_00050)
[TPS_SYST_02039] Specification of transformer specific properties dFurther
transformer specific properties can be stated inside the TransformationDescrip-
tion in the role transformationDescription of a TransformationTechnol-
ogyc(RS_SYST_00050)
Note:
This is an abstract class without any specified content. If AUTOSAR specifies a trans-
former and this transformer need configuration possibilities, this class can be inherited
to hold those as some kind of container.
[TPS_SYST_02040] Specification of transformer buffer handling dThe Buffer-
Properties in the role bufferProperties of a TransformationTechnology
specify the buffer handling which shall be executed by the RTE for this transformer.c
(RS_SYST_00050)
Class BufferProperties
Package M2::AUTOSARTemplates::SystemTemplate::Transformer
Note Configuration of the buffer properties the transformer needs to work.
Base ARObject
Attribute Type Mult. Kind Note
headerLength Integer 1 attr Defines the length of the header (in bits) this transformer
will add in front of the data.
inPlace Boolean 1 attr If set, the transformer uses the input buffer as output
buffer.
Table 7.5: BufferProperties

[TPS_SYST_02041] In-place buffer handling of transformers dThe attribute in-

Place of BufferProperties specifies whether the transformation happens in-
place.c(RS_SYST_00050)
[constr_3125] Value of attribute inPlace for the first transformer in a chain dThe
attribute inPlace shall be set to false if the TransformationTechnology of the
BufferProperties is referenced as first reference in the ordered list of references
transformerChain from a DataTransformation.c()

621 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_02042] Header length to be considered by transformers dThe attribute

headerLength of BufferProperties specifies the length of the header (in bits)
which the transformer adds.c(RS_SYST_00050)
[constr_3364] headerLength shall be a multiple of 8 dThe header length in bits
specified by headerLength shall be a multiple of 8.c()
[TPS_SYST_02044] Buffer computation of transformer dThe buffer in the RTE that
is needed:
• for the SOME/IP transformation will be calculated from the length of the ISig-
nal that is referencing a transformer chain that includes the SOME/IP Trans-
former.
• for the ComBased transformation will be calculated from the length of the Pdu
that contains the ISignalGroup that is referencing a transformer chain that
includes the ComBased Transformer.
c(RS_SYST_00050)
More details can be found in the RTE specification [37]. Please note that the buffer
computation for custom transformers is not formalized.
The following examples are showing the calculation of the length of an ISignal that
transports a VariableDataPrototype of ImplementationDataType of category
STRUCTURE via a SOME/IP Transformer.
The example struct consists of five members:
Member1: UINT16
Member2: Struct with a UINT16 length field and a one-dimensional variableSize Array
with UINT8 elements and arraySize = 8
Member3: UINT32
Member4: UINT64
Member5: Struct with a UINT16 length field and a one-dimensional variableSize Array
with UINT8 elements and arraySize = 8
The SOME/IP Transformer takes the InputData and adds additional 8 bytes as header.
In case of SOME/IP the signal based SOMEIPTransformationISignalProps and
the DataPrototype based SOMEIPTransformationProps need to be considered
as well for the calculation of the ISignal.length (see chapter 7.3.2.2 for more de-
tails). In our example the following SOMEIPTransformationProps settings are valid
for the variableSize Array:
• SOMEIPTransformationProps.alignment = 64
All these settings lead to the ISignal.length of 368 bits as shown in figure Figure
7.6. A padding element is inserted after the first variable size array as described in

622 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

Example 1: Alignment = 64 Bit
Example: Structure with 5 Members
- Member1: UINT16 System Template
- Member2: One dimensional variableSize Array with uint8 elements AUTOSAR CP R21-11
- Member3: UINT32
- Member4: UINT64
[PRS_SOMEIP_00611]. The second variable size array is the last element in the seri-
alized data stream and therefore
- Member5: One dimensional variableSizeno padding element is inserted
Array with uint8afterwards.
elements The auto-
matic padding in SOME/IP after variable size data is described in more detail in [19].

SOME/IP Header
Lengthfield
UINT16 uint8 uint8 uint8 uint8
(16Bit)
uint8 uint8 uint8 uint8 Padding

UINT32 UINT64
Lengthfield
UINT64 uint8 uint8
(16Bit)
uint8 uint8 uint8 uint8 uint8 uint8
Example 2: Alignment = 64 Bit
Example: Structure with 5 Members
64 Bit
- Member1: UINT16 - AUTOSAR Confidential
Figure 7.6: Example for calculation of -the ISignal.length
1
- Member2: One
Set date in View ->
dimensional variableSize Array with uint8 elements
Set footer in View -> Header and Footer
- Member3:
PleaseUINT32
Head and Footer
note that the padding in the SOME/IP data stream depends on the actual num-
- Member4:
ber of UINT64
elements that are transmitted in the variable data. Figure Figure 7.7 shows an
example
- Member5: One where only three elements
dimensional are transmitted
variableSize Arrayinwith the first
uint8variable size array and
elements
therefore the padding is restricted to 1 byte.

SOME/IP Header
Lengthfield
UINT16 uint8 uint8 uint8 Padding
(16Bit)
UINT32 UINT64
Lengthfield
UINT64 uint8 uint8
(16Bit)
uint8 uint8 uint8 uint8 uint8 uint8

64 Bit
Figure 7.7: SOME/IP Padding Example
- AUTOSAR Confidential -

3 Set date in View -> Set footer in View -> Header and Footer
Head and Footer

623 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Transformer specific configuration can be done in the TransformationDescrip-

tion.
[constr_5231] Allowed values for SOMEIPTransformationProps.alignment
and SOMEIPTransformationDescription.alignment dThe valid values for
SOMEIPTransformationProps.alignment and SOMEIPTransformationDe-
scription.alignment shall be 8, 16, 32, 64, 128 or 256.c()
Identifiable
TransformationTechnology

«atpVariation»

+transformationDescription 0..1

Describable
TransformationDescription

UserDefinedTransformationDescription SOMEIPTransformationDescription

+ alignment: PositiveInteger
+ byteOrder: ByteOrderEnum
+ interfaceVersion: PositiveInteger

«enumeration» EndToEndTransformationDescription «enumeration»

DataIdModeEnum ByteOrderEnum
+ clearFromValidToInvalid: Boolean [0..1]
all16Bit + counterOffset: PositiveInteger [0..1] Attributes
alternating8Bit + crcOffset: PositiveInteger [0..1] + mostSignificantByteFirst
lower8Bit + dataIdMode: DataIdModeEnum [0..1] + mostSignificantByteLast
lower12Bit + dataIdNibbleOffset: PositiveInteger [0..1] + opaque
+ maxDeltaCounter: PositiveInteger [0..1]
+ maxErrorStateInit: PositiveInteger [0..1]
+ maxErrorStateInvalid: PositiveInteger [0..1]
+ maxErrorStateValid: PositiveInteger [0..1]
+ maxNoNewOrRepeatedData: PositiveInteger [0..1]
+ minOkStateInit: PositiveInteger [0..1]
+ minOkStateInvalid: PositiveInteger [0..1]
+ minOkStateValid: PositiveInteger [0..1]
+ offset: PositiveInteger [0..1]
+ profileBehavior: EndToEndProfileBehaviorEnum [0..1]
+ profileName: NameToken
+ syncCounterInit: PositiveInteger [0..1]
+ upperHeaderBitsToShift: PositiveInteger [0..1]
+ windowSizeInit: PositiveInteger [0..1]
+ windowSizeInvalid: PositiveInteger [0..1]
+ windowSizeValid: PositiveInteger [0..1]

Figure 7.8: Configuration of transformers using TransformationDescription

Class TransformationDescription (abstract)

Package M2::AUTOSARTemplates::SystemTemplate::Transformer
Note The TransformationDescription is the abstract class that can be used by specific transformers to add
transformer specific properties.
Base ARObject, Describable
Subclasses EndToEndTransformationDescription, SOMEIPTransformationDescription, UserDefinedTransformation
Description
Attribute Type Mult. Kind Note
– – – – –
Table 7.6: TransformationDescription

624 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class UserDefinedTransformationDescription
Package M2::AUTOSARTemplates::SystemTemplate::Transformer
Note The UserDefinedTransformationDescription is used to specify details and documentation for custom
transformers.
Base ARObject, Describable, TransformationDescription
Attribute Type Mult. Kind Note
– – – – –
Table 7.7: UserDefinedTransformationDescription

[TPS_SYST_02045] SOME/IP Transformer configuration dSOME/IP Transformer

shall be configured using SOMEIPTransformationDescription.c(RS_SYST_-
00050)
[TPS_SYST_02046] E2E Transformer configuration dE2E Transformer shall be con-
figured using EndToEndTransformationDescription.c(RS_SYST_00050)
For details how to configure those transformers please see chapter 7.3.2 and chapter
7.3.4.
[TPS_SYST_02047] Custom transformer configuration dFor custom transformers
the specific configuration options shall be placed inside UserDefinedTransforma-
tionDescription.c(RS_SYST_00050)
To place the custom data in UserDefinedTransformationDescription the Ad-
minData could be used for example.
The configuration in TransformationDescription is valid for the transformer (
TransformationTechnology) and all associated ISignals. If ISignal specific
configuration shall be realized which is only valid for the transformation of a specific
ISignal, the TransformationISignalProps shall be used.

625 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

FibexElement FibexElement Identifiable

ISignal +iSignal ISignalGroup TransformationTechnology

+ dataTypePolicy: DataTypePolicyEnum
0..*
+ iSignalType: ISignalTypeEnum [0..1]
+ length: UnlimitedInteger

+transformer 1

+transformationISignalProps 0..* +transformationISignalProps 0..*

Describable
«atpVariation»
TransformationISignalProps

+ csErrorReaction: CSTransformerErrorReactionEnum [0..1]

UserDefinedTransformationISignalProps SOMEIPTransformationISignalProps

+ implementsLegacyStringSerialization: Boolean [0..1]

+ interfaceVersion: PositiveInteger [0..1]
+ isDynamicLengthFieldSize: Boolean [0..1]
+ messageType: SOMEIPMessageTypeEnum [0..1]
+ sessionHandlingSR: SOMEIPTransformerSessionHandlingEnum [0..1]
+ sizeOfArrayLengthFields: PositiveInteger [0..1]
+ sizeOfStringLengthFields: PositiveInteger [0..1]
+ sizeOfStructLengthFields: PositiveInteger [0..1]
+ sizeOfUnionLengthFields: PositiveInteger [0..1]

EndToEndTransformationISignalProps «enumeration»
CSTransformerErrorReactionEnum
+ dataId: PositiveInteger [0..*] {ordered}
+ dataLength: PositiveInteger [0..1] autonomous
+ maxDataLength: PositiveInteger [0..1] applicationOnly
+ minDataLength: PositiveInteger [0..1]
+ sourceId: PositiveInteger [0..1]
«enumeration»
SOMEIPTransformerSessionHandlingEnum

sessionHandlingActive
sessionHandlingInactive

Figure 7.9: Configuration of transformers using TransformationISignalProps

Class <<atpVariation>> TransformationISignalProps (abstract)

Package M2::AUTOSARTemplates::SystemTemplate::Transformer
Note TransformationISignalProps holds all the attributes for the different TransformationTechnologies that are
ISignal specific.
Tags:vh.latestBindingTime=postBuild
Base ARObject, Describable
Subclasses EndToEndTransformationISignalProps, SOMEIPTransformationISignalProps, UserDefinedTransformation
ISignalProps
Attribute Type Mult. Kind Note
csErrorReaction CSTransformerError 0..1 attr Defines whether the transformer chain of client/server
ReactionEnum communication coordinates an autonomous error reaction
together with the RTE or whether any error reaction is the
responsibility of the application.
dataPrototype DataPrototype * aggr Fine granular modeling of TransfromationProps on the
Transformation TransformationProps level of DataPrototypes.
Props
transformer Transformation 1 ref Reference to the TransformationTechnology description
Technology that contains transformer specific and ISignal
independent configuration properties.

Table 7.8: TransformationISignalProps

626 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Enumeration CSTransformerErrorReactionEnum
Package M2::AUTOSARTemplates::SystemTemplate::Transformer
Note Possible kinds of error reaction in case of a hard transformer error.
Literal Description
applicationOnly The application is responsible for any error reaction. No autonomous error reaction of RTE and
transformer.
Tags:atp.EnumerationLiteralIndex=0
autonomous RTE and Transformer coordinate an autonomous error reaction on their own.
Tags:atp.EnumerationLiteralIndex=1

Table 7.9: CSTransformerErrorReactionEnum

[TPS_SYST_02048] ISignal specific transformation configuration dIf an ISig-

nal references a TransformationTechnology in the role dataTransformation
and this transformation shall be configured ISignal specific, the ISignal shall ag-
gregate a TransformationISignalProps element.c(RS_SYST_00050)
[TPS_SYST_02049] Transformer specific TransformationISignalProps dThe
attribute transformer of TransformationISignalProps shall reference the
TransformationTechnology in the transformer chain (DataTransformation)
for which the ISignal specific configuration shall be given.c(RS_SYST_00050)
[constr_3213] TransformationISignalProps.csErrorReaction setting in
case that the serializer transformerClass and Client/Server communica-
tion is used dIn TransformationISignalProps the attribute csErrorReaction
shall be set if the TransformationISignalProps specifies the details for a Trans-
formationTechnology with transformerClass equal to serializer and the
ISignal that aggregates the TransformationISignalProps transports a clien-
t/server communication.c()
[constr_3214] TransformationISignalProps.csErrorReaction setting in
case that a transformerClass different from serializer is used or the Clien-
t/Server communication is not used dIn TransformationISignalProps the at-
tribute csErrorReaction shall not be used if the TransformationISignalProps
specifies the details for a TransformationTechnology with transformerClass
not equal to serializer or the ISignal that aggregates the Transformation-
ISignalProps does not transport a client/server communication.c()
[TPS_SYST_02074] Precedence of transformer configuration settings dThe same
transformer configuration settings may exist in the TransformationDescription,
TransformationISignalProps and TransformationComSpecProps elements.
The following precedence is valid for such settings:
• TransformationDescription: configuration valid for several ISignals (in
case the SOME/IP Transformer or Custom Transformer is used) or ISignal-
Groups (in case the ComBasedTransformer is used).

627 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• TransformationISignalProps: defines the configuration options valid for a

specific referenced ISignal or ISignalGroup. This settings override possible
settings in the TransformationDescription.
• TransformationComSpecProps: defines the configuration settings valid for
the port to which the ReceiverComSpec belongs (for more details see [5]). This
settings override possible settings in the TransformationDescription and
TransformationISignalProps.
c(RS_SYST_00050)
[TPS_SYST_02075] Mandatory attributes in transformer configuration elements
dIf a transformer configuration attribute is mandatory due to a particular constraint
it means that it shall be defined in at least one of the three possible locations:
TransformationDescription, TransformationISignalProps or Transfor-
mationComSpecProps.c(RS_SYST_00050)
Please note that it is not required to define the complete attribute set on each of those
locations. It means that it is allowed to overwrite single attributes in elements according
to the precedence defined in [TPS_SYST_02074].
[TPS_SYST_02050] ISignal specific configuration of the SOME/IP Transformer
dThe ISignal specific configuration of the SOME/IP Transformer shall be configured
using SOMEIPTransformationISignalProps.c(RS_SYST_00050)
[TPS_SYST_02051] ISignal specific configuration of the E2E Transformer dThe
ISignal specific configuration of the E2E Transformer shall be configured using End-
ToEndTransformationISignalProps.c(RS_SYST_00050)
For details how to configure those transformers ISignal specific please see chapter
7.3.2 and chapter 7.3.4.
[TPS_SYST_02052] ISignal specific configuration of custom transformers dThe
ISignal specific configuration of custom transformers shall be configured using
UserDefinedTransformationISignalProps.c(RS_SYST_00050)
To place the custom data in UserDefinedTransformationDescription the Ad-
minData could be used for example.
To configure which communication shall be subject to transformation is done via
references from ISignals and ISignalGroups to DataTransformations. An
overview is shown in figure 7.10.

628 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

FibexElement Identifiable
+dataTransformation
ISignal DataTransformation
«atpVariation,atpSplitable»
+ dataTypePolicy: DataTypePolicyEnum 0..1
+ iSignalType: ISignalTypeEnum [0..1]
+ length: UnlimitedInteger
0..1 +comBasedSignalGroupTransformation
0..*
+iSignal

«atpVariation,atpSplitable»
+networkRepresentationProps 0..1

«atpVariation» FibexElement
SwDataDefProps ISignalGroup

+physicalProps 0..1

+systemSignalGroup 1
ARElement +systemSignal ARElement
+systemSignal SystemSignal SystemSignalGroup
*
1 + dynamicLength: Boolean
+transformingSystemSignal

0..1

Figure 7.10: Configuration which communication shall be transformed

The DataTransformation element (which represents a transformer chain) is

• either referenced by the ISignal in the role dataTransformation which
holds the transformed representation of the data
• referenced by the ISignalGroup in the role comBasedSignalGroupTrans-
formation which holds the custom mapping of the data to the transformed rep-
resentation or
• referenced by a DataPrototypeMapping in the role firstToSecondData-
Transformation,
as defined in [constr_1400] in [5].
A VariableDataPrototype can either become a part of a DataPrototypeMap-
ping based data transformation or of an ISignal-based data transformation as de-
fined in [constr_1401] in [5].
[constr_1387] Transmission of Variable-Size Array Data Types by means
of a Transformer dIf a Transformer is used for the transmission of a Variable-Size
Array Data Types then the Variable-Size Array Data Type shall be a “new-
world” variable-size array data type according to [TPS_SWCT_01644] and [TPS_-
SWCT_01645]. “Old-world” dynamic-size array data types according to [TPS_SWCT_-
01642] and [TPS_SWCT_01643] are not supported.c()

7.3.1 Generic Transformer

[TPS_SYST_02053] A reference from ISignal to DataTransformation in the

role dataTransformation enables data transformation dTo enable the transfor-
mation of data, the ISignal which shall hold the transformed data shall reference a
DataTransformation in the role dataTransformation.c(RS_SYST_00050)

629 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_02054] Definition of data which shall be transformed dIf

1. an ISignal references a DataTransformation and
2. this ISignal references a SystemSignal and
3. the referenced SystemSignal is referenced by a SenderReceiverToSig-
nalMapping in the role systemSignal or referenced by a ClientServer-
ToSignalMapping in the role returnSignal and in the role callSignal
then the VariableDataPrototype referenced by the SenderReceiverToSig-
nalMapping or the ClientServerOperation referenced by the ClientServer-
ToSignalMapping shall be transformed.c(RS_SYST_00050)
Using this configuration the result of the transformation will be put into the ISignal
even if the data type is a composite type.
Furthermore, another SystemSignal can be added to a SystemSignalGroup in
the role transformingSystemSignal to support the configuration where a complex
data element is transferred via Sender/Receiver communication both using transforma-
tion and traditional mapping of RTE and COM.
The ISignal which references the SystemSignal which is referenced by a Sys-
temSignalGroup in the role transformingSystemSignal shall reference a
DataTransformation to transport the transformed data.
In parallel, the traditional mapping of RTE and COM maps all other SystemSignals
of the SystemSignalGroup which are referenced in the role systemSignal.
[constr_3127] Certain ISignals always need a reference to DataTransforma-
tion dAn ISignal which references a SystemSignal which is referenced by a
SystemSignalGroup in the role transformingSystemSignal shall always refer-
ence a DataTransformation.c()

7.3.2 SOME/IP Transformer

The specific configuration for SOME/IP transformers takes place in SOMEIPTrans-

formationDescription and SOMEIPTransformationISignalProps shown in
Figure 7.11.

630 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Identifiable
TransformationTechnology

+ hasInternalState: Boolean [0..1]

+ needsOriginalData: Boolean [0..1]
+ protocol: String
+ transformerClass: TransformerClassEnum
+ version: String

+transformer 1

FibexElement «atpVariation»
ISignal
+transformationDescription 0..1
+ dataTypePolicy: DataTypePolicyEnum
+ iSignalType: ISignalTypeEnum [0..1] Describable
+ length: UnlimitedInteger TransformationDescription

+transformationISignalProps 0..*

Describable
«atpVariation»
TransformationISignalProps SOMEIPTransformationDescription

+ csErrorReaction: CSTransformerErrorReactionEnum [0..1] + alignment: PositiveInteger

+ byteOrder: ByteOrderEnum
+ interfaceVersion: PositiveInteger

SOMEIPTransformationISignalProps
«enumeration»
+ implementsLegacyStringSerialization: Boolean [0..1] CSTransformerErrorReactionEnum
+ interfaceVersion: PositiveInteger [0..1]
+ isDynamicLengthFieldSize: Boolean [0..1] autonomous
+ messageType: SOMEIPMessageTypeEnum [0..1] applicationOnly
+ sessionHandlingSR: SOMEIPTransformerSessionHandlingEnum [0..1]
+ sizeOfArrayLengthFields: PositiveInteger [0..1]
+ sizeOfStringLengthFields: PositiveInteger [0..1]
+ sizeOfStructLengthFields: PositiveInteger [0..1]
+ sizeOfUnionLengthFields: PositiveInteger [0..1]

«enumeration»
SOMEIPTransformerSessionHandlingEnum
«enumeration»
«enumeration» sessionHandlingActive
SOMEIPMessageTypeEnum
ByteOrderEnum sessionHandlingInactive
Attributes
Attributes
+ request
+ mostSignificantByteFirst
+ requestNoReturn
+ mostSignificantByteLast
+ notification
+ opaque
+ response

Figure 7.11: SOME/IP specific configuration

Class SOMEIPTransformationDescription
Package M2::AUTOSARTemplates::SystemTemplate::Transformer
Note The SOMEIPTransformationDescription is used to specify SOME/IP transformer specific attributes.
Base ARObject, Describable, TransformationDescription
Attribute Type Mult. Kind Note
alignment PositiveInteger 1 attr Defines the padding for alignment purposes that will be
added by the SOME/IP transformer after the serialized
data of the variable data length data element. The
alignment shall be specified in Bits.
byteOrder ByteOrderEnum 1 attr Defines which byte order shall be serialized by the
SOME/IP transformer
interfaceVersion PositiveInteger 1 attr The interface version the SOME/IP transformer shall use.

Table 7.10: SOMEIPTransformationDescription

631 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class <<atpVariation>> SOMEIPTransformationISignalProps

Package M2::AUTOSARTemplates::SystemTemplate::Transformer
Note The class SOMEIPTransformationISignalProps specifies ISignal specific configuration properties for
SOME/IP transformer attributes.
Base ARObject, Describable, TransformationISignalProps
Attribute Type Mult. Kind Note
implements Boolean 0..1 attr This attribute indicates that Strings in the SOME/IP
LegacyString message shall NOT be serialized according to the SOME/
Serialization IP specification for Strings.
If this attribute is set to true, BOM and null-termination
shall NOT be added in the serialization for Strings in the
payload. If this attribute is set to false (or not set) BOM
and null-termination shall be added in the serialization for
Strings in the payload according to the SOME/IP
specification for Strings.
NOTE! This attribute is not future safe, and will be
removed in an upcoming AUTOSAR release!"
interfaceVersion PositiveInteger 0..1 attr The interface version the SOME/IP transformer shall use.
isDynamic Boolean 0..1 attr This attribute shall be used to determine the wire type in
LengthFieldSize the context of using the TLV encoding.
messageType SOMEIPMessageType 0..1 attr The Message Type which shall be placed into the SOME/
Enum IP header.
session SOMEIPTransformer 0..1 attr Defines whether the SOME/IP transformer shall use
HandlingSR SessionHandlingEnum session handling for Sender/Receiver communication.
sizeOfArray PositiveInteger 0..1 attr The size of all length fields (in Bytes) of fixed-size arrays
LengthFields or dynamic size arrays in the SOME/IP message. This
attribute is valid for all available occurrences of fixed-size
arrays or dynamic size arrays in the SOME/IP message.
sizeOfString PositiveInteger 0..1 attr The size of all length fields (in Bytes) of dynamic length
LengthFields strings in the SOME/IP message. This attribute is valid for
all available occurrences of strings in the SOME/IP
message.
sizeOfStruct PositiveInteger 0..1 attr The size of all length fields (in Bytes) of structs in the
LengthFields SOME/IP message. This attribute is valid for all available
occurrences of structures in the SOME/IP message. For
a more fine granular modeling on the level of Data
Prototypes the DataPrototypeTransformationProps shall
be used.
sizeOfUnion PositiveInteger 0..1 attr The size of all length fields (in Bytes) of unions in the
LengthFields SOME/IP message. This attribute is valid for all available
occurrences of Unions in the SOME/IP message. For a
more fine granular modeling on the level of Data
Prototypes the DataPrototypeTransformationProps shall
be used.
tlvDataId TlvDataIdDefinitionSet * ref This reference identifies the TlvDataIdDefinitions relevant
Definition for the enclosing SOMEIPTransformationISignalProps

Table 7.11: SOMEIPTransformationISignalProps

Enumeration ByteOrderEnum
Package M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::PrimitiveTypes
5

632 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Enumeration ByteOrderEnum
Note When more than one byte is stored in the memory the order of those bytes may differ depending on
the architecture of the processing unit. If the least significant byte is stored at the lowest address, this
architecture is called little endian and otherwise it is called big endian.
ByteOrder is very important in case of communication between different PUs or ECUs.
Literal Description
mostSignificantByte Most significant byte shall come at the lowest address (also known as BigEndian or as
First Motorola-Format)
Tags:atp.EnumerationLiteralIndex=0
mostSignificantByte Most significant byte shall come highest address (also known as LittleEndian or as Intel-Format)
Last
Tags:atp.EnumerationLiteralIndex=1
opaque For opaque data endianness conversion has to be configured to Opaque. See AUTOSAR COM
Specification for more details.
Tags:atp.EnumerationLiteralIndex=2

Table 7.12: ByteOrderEnum

Enumeration SOMEIPMessageTypeEnum
Package M2::AUTOSARTemplates::SystemTemplate::Transformer
Note Depending on the style of the communication different message types shall be set in the header of a
SOME/IP message.
Literal Description
notification A request of a notification expecting no response.
Tags:atp.EnumerationLiteralIndex=1
request A request expecting a response.
Tags:atp.EnumerationLiteralIndex=2
requestNoReturn A fire&forget request.
Tags:atp.EnumerationLiteralIndex=3
response The response message.
Tags:atp.EnumerationLiteralIndex=4

Table 7.13: SOMEIPMessageTypeEnum

Enumeration SOMEIPTransformerSessionHandlingEnum
Package M2::AUTOSARTemplates::SystemTemplate::Transformer
Note Enables or disable session handling for SOME/IP transformer
Literal Description
sessionHandling The SOME/IP Transformer shall use session handling
Active
Tags:atp.EnumerationLiteralIndex=0
sessionHandling The SOME/IP Transformer doesn’t use session handling
Inactive
Tags:atp.EnumerationLiteralIndex=1

Table 7.14: SOMEIPTransformerSessionHandlingEnum

[constr_3128] SOME/IP transformer configuration dFor each Transformation-

Description variant that is a SOMEIPTransformationDescription
• attribute protocol of TransformationTechnology shall be set to SOMEIP

633 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• attribute version of TransformationTechnology shall be set to 1.0.0

• attribute transformerClass of TransformationTechnology shall be set to
serializer
• attribute headerLength of BufferProperties shall be set to 64 (bits).
c()
The SOMEIPTransformationDescription contains the configuration for the trans-
former which shall be applied to all transformations. ISignal specific transformer
configuration (which "override" the general ones) shall be done in SOMEIPTransfor-
mationISignalProps.
[TPS_SYST_02055] Alignment of SOME/IP dThe attribute alignment defines the
alignment used in the SOME/IP transformer in Bits.c(RS_SYST_00050)
[TPS_SYST_02056] Byte Order of SOME/IP dThe attribute byteOrder defines the
byte order used in the SOME/IP transformer for creating the on wire format.c(RS_-
SYST_00050)
[constr_3129] Byte Order of SOME/IP transformer dThe attribute byteOrder of
SOMEIPTransformationDescription shall be different from opaque.c()
[TPS_SYST_02057] Interface Version of SOME/IP dThe attribute interfaceVer-
sion of SOMEIPTransformationDescription as well as interfaceVersion of
SOMEIPTransformationISignalProps defines the interface version used by the
SOME/IP transformer.c(RS_SYST_00050)
[constr_3130] Range of Interface Version dThe value of the attribute interfaceV-
ersion shall be in the range [0; 255]c()
[TPS_SYST_02092] Size of Array Length Fields dThe attribute sizeOfAr-
rayLengthFields of SOMEIPTransformationISignalProps defines the size of
an length field generated by the SOME/IP transformer in front of all available fixed-size
arrays or dynamic size arrays in the ISignal. See also [constr_3282].c(RS_SYST_-
00050)
[constr_5244] Value of attribute SOMEIPTransformationISignalProps.size-
OfArrayLengthFields dIf attribute SOMEIPTransformationISignalProps.
sizeOfArrayLengthFields is configured, then the value of attribute SOMEIP-
TransformationISignalProps.sizeOfArrayLengthFields shall be at least as
high as the number of bytes required to fit the maximum result of the individual length
field computation of all variable-size arrays that are transported in the SOME/IP mes-
sage.
In other words, for each variable-size array contained in the SOME/IP message, the
numerical value of maximum number of elements * sizeof(data type of array element)
shall be computed which yields the maximum number of bytes required to store the
individual variable-size array.

634 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

The size of the attribute SOMEIPTransformationISignalProps.sizeOfAr-

rayLengthFields shall be set such that the highest value (or bigger) obtained
from the individual computations for the contained variable-size arrays can fit into the
length field. The unit of attribute SOMEIPTransformationISignalProps.sizeO-
fArrayLengthFields is bytes.c()
[TPS_SYST_02093] Size of Structure Length Fields dThe attribute sizeOf-
StructLengthFields of SOMEIPTransformationISignalProps defines the
size of an length field generated by the SOME/IP transformer in front of all available
structures in the ISignal. See also [constr_3283].c(RS_SYST_00050)
[TPS_SYST_02359] Size of String Length Fields dThe attribute sizeOf-
StringLengthFields of SOMEIPTransformationISignalProps defines the
size of an length field generated by the SOME/IP transformer in front of all available
strings in the ISignal. See also [constr_5246].c(RS_SYST_00050)
[constr_5245] Value of attribute SOMEIPTransformationISignalProps.size-
OfStringLengthFields dIf attribute SOMEIPTransformationISignalProps.
sizeOfStringLengthFields is configured, then the value of attribute SOMEIP-
TransformationISignalProps.sizeOfStringLengthFields shall be at least
as high as the number of bytes required to fit the maximum result of the individual
length field computation of all strings that are transported in the SOME/IP message.
In other words, for each string contained in the SOME/IP message, the numerical value
of maximum number of characters in the string * maximum number of code units per
character (of the used character encoding) * maximum number of bytes per code unit
(of the used character encoding) shall be computed which yields the maximum number
of bytes required to store the individual string.
The size of the attribute SOMEIPTransformationISignalProps.sizeOf-
StringLengthFields shall be set such that the highest value (or bigger) ob-
tained from the individual computations for the contained strings can fit into the
length field. The unit of attribute SOMEIPTransformationISignalProps.size-
OfStringLengthFields is bytes.c()
[constr_1441] In AUTOSAR, the transmission of union data types over the net-
work is only supported by the SOME/IP Transformer dIf an Implementation-
DataType according to [TPS_SWCT_01700], i.e. of category STRUCT that encloses
an ImplementationDataTypeElement of category UNION, is used to directly or
(via a DataTypeMap) indirectly type an AutosarDataPrototype and the latter is
mapped to a SystemSignal then the ISignal that references that SystemSignal
shall aggregate SOMEIPTransformationISignalProps in the role transforma-
tionISignalProps.c()
[TPS_SYST_02094] Size of Union Length Fields dThe attribute sizeOfUnion-
LengthFields of SOMEIPTransformationISignalProps defines the size of an
length field generated by the SOME/IP transformer in front of all available unions in the
ISignal. See also [constr_3284].c(RS_SYST_00050)

635 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

In principle there is no need to define a size of the length indicator because the size
can be computed from the data structure itself. However there is a use case to extend
on the sender side while keeping the receiver side as it is. This means that there is the
need to express the size of the length indicator because the extended data structure
may reach a length that exceeds the capacity of the original computed size indicator.
[constr_3218] Range of Size of Array Length Fields dThe value of attribute sizeO-
fArrayLengthFields of SOMEIPTransformationISignalProps shall be either
0, 1, 2 or 4.c()
[constr_3220] Range of Size of Structure Length Fields dThe value of attribute
sizeOfStructLengthFields of SOMEIPTransformationISignalProps shall
be either 0, 1, 2 or 4.c()
[constr_3221] Range of Size of Union Length Fields dThe value of attribute sizeO-
fUnionLengthFields of SOMEIPTransformationISignalProps shall be either
0, 1, 2 or 4.c()
[TPS_SYST_02080] Message type of SOME/IP dThe attribute messageType of
SOMEIPTransformationISignalProps defines the message type used by the
SOME/IP transformer for the serialized ISignal.c(RS_SYST_00050)
[constr_3216] Usage of SOMEIPTransformationISignalProps.sessionHan-
dlingSR dThe attribute sessionHandlingSR of SOMEIPTransformationISig-
nalProps shall only be used for ISignals which reference SystemSignals which
are mapped via a SenderReceiverToSignalMapping.c()
Note: This means that sessionHandlingSR shall only be used for transformed
Sender/Receiver communication.

7.3.2.1 Handling of Strings

Prior to AUTOSAR Release 4.3 the SOME/IP Transformer did not specify any special
handling for how String data types shall be serialized. This leads to the situation that
no BOM is introduced. The SOME/IP standard however does expect a BOM for String
data type, this is also how AUTOSAR Release 4.3 defines the serialization of Strings.
The attribute SOMEIPTransformationISignalProps.implementsLegacyS-
tringSerialization enables the compatibility of string handling between
AUTOSAR pre Release 4.3 and standard SOME/IP serializers. An AUTOSAR ECU
according to Release 4.2 would not define any String specific behavior, thus it is
possible to enforce this for later Release implementations as well by setting the
attribute to true.

636 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

7.3.2.2 SOME/IP Transformation Properties on the level of DataPrototypes

The serialization of SOME/IP is based on the interface specification. For certain

datatypes like structures, unions and arrays SOME/IP supports the configuration of
length fields that will be put in front of the serialized data. AUTOSAR supports the
configuration of such SOME/IP settings on two different levels:
• modeling on ISignal level that is valid for all available occurrences of a datatype
in the SOME/IP message (see [TPS_SYST_02092], [TPS_SYST_02093] and
[TPS_SYST_02094])
• fine granular modeling on the level of DataPrototypes (see
[TPS_SYST_02121])
To allow such a fine granular modeling SOMEIPTransformationProps are defined
and collected in TransformationPropsSets.
Class TransformationPropsSet
Package M2::AUTOSARTemplates::SystemTemplate::Transformer
Note Collection of TransformationProps.
Tags:atp.recommendedPackage=TransformationPropsSets
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
transformation TransformationProps * aggr Transformer specific configuration properties.
Props

Table 7.15: TransformationPropsSet

Class TransformationProps (abstract)

Package M2::AUTOSARTemplates::SystemTemplate::Transformer
Note This meta-class represents a abstract base class for transformation settings.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Subclasses SOMEIPTransformationProps, UserDefinedTransformationProps
Attribute Type Mult. Kind Note
– – – – –
Table 7.16: TransformationProps

Class SOMEIPTransformationProps
Package M2::AUTOSARTemplates::SystemTemplate::Transformer
Note The class SOMEIPTransformationProps specifies SOME/IP specific configuration properties.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable, TransformationProps
Attribute Type Mult. Kind Note
alignment PositiveInteger 0..1 attr Defines the padding for alignment purposes that will be
added by the SOME/IP transformer after the serialized
data of the variable data length data element. The
alignment shall be specified in Bits.
5

637 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class SOMEIPTransformationProps
sizeOfArray PositiveInteger 0..1 attr This attribute describes the size of the length field (in
LengthField Bytes) that will be put in front of the referenced Array in
the SOME/IP message.
sizeOfString PositiveInteger 0..1 attr This attribute describes the size of the length field (in
LengthField Bytes) that will be put in front of the referenced String in
the SOME/IP message.
sizeOfStruct PositiveInteger 0..1 attr This attribute describes the size of the length field (in
LengthField Bytes) that will be put in front of a Structure in the SOME/
IP message.
sizeOfUnion PositiveInteger 0..1 attr This attribute describes the size of the length field (in
LengthField Bytes) that will be put in front of a Union in the SOME/IP
message.

Table 7.17: SOMEIPTransformationProps

The relation between SOMEIPTransformationProps and a DataPrototype is cre-

ated with DataPrototypeTransformationProps in the context of an ISignal.
[TPS_SYST_02127] Usage of DataPrototypeTransformationProps in case
of a VariableDataPrototype dIf a VariableDataPrototype is transported in
the ISignal the DataPrototypeTransformationProps can be used to assign
SOMEIPTransformationProps to a DataPrototype that is or is part of the Vari-
ableDataPrototype.c(RS_SYST_00050)
[TPS_SYST_02128] Usage of DataPrototypeTransformationProps in case
of a ClientServerOperation dIf a ClientServerOperation is transported in
the ISignal (callSignal or returnSignal) the DataPrototypeTransforma-
tionProps can be used to assign SOMEIPTransformationProps to a DataPro-
totype that is or is part of an ArgumentDataPrototype of the ClientServerOp-
eration.c(RS_SYST_00050)
[TPS_SYST_02129] Assignment of SOMEIPTransformationProps to a root Au-
tosarDataPrototype in a SenderReceiverInterface typed by an Appli-
cationDataType dTo assign the SOMEIPTransformationProps to a root Au-
tosarDataPrototype in a SenderReceiverInterface that is typed by an
ApplicationDataType the DataPrototypeInSenderReceiverInterfaceIn-
stanceRef shall reference the DataPrototype with the targetDataPrototype-
InSr reference. The rootDataPrototypeInSr and contextDataPrototype-
InSr references shall not be used.c(RS_SYST_00050)
[TPS_SYST_02212] Assignment of SOMEIPTransformationProps to a root Au-
tosarDataPrototype in a ClientServerInterface typed by an Applica-
tionDataType dTo assign the SOMEIPTransformationProps to a root Autosar-
DataPrototype in a ClientServerInterface that is typed by an Applica-
tionDataType the DataPrototypeInClientServerInterfaceInstanceRef
shall reference the DataPrototype with the targetDataPrototypeInCs refer-
ence. The rootDataPrototypeInCs and contextDataPrototypeInCs refer-
ences shall not be used.c(RS_SYST_00050)

638 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_02130] Assignment of SOMEIPTransformationProps to a subEle-

ment of a root AutosarDataPrototype in a SenderReceiverInterface typed
by an ApplicationDataType dTo assign the SOMEIPTransformationProps to
a subElement of a root AutosarDataPrototype in a SenderReceiverInter-
face that is typed by an ApplicationDataType the DataPrototypeInSender-
ReceiverInterfaceInstanceRef shall reference the subElement with the tar-
getDataPrototypeInSr reference. In addition the rootDataPrototypeInSr
shall be set to define the context. Optionally it may be necessary to use context-
DataPrototypeInSr references because the target subElement may be arbitrarily
nested within the root AutosarDataPrototype.c(RS_SYST_00050)
[TPS_SYST_02213] Assignment of SOMEIPTransformationProps to a subEle-
ment of a root AutosarDataPrototype in a ClientServerInterface typed
by an ApplicationDataType dTo assign the SOMEIPTransformationProps to a
subElement of a root AutosarDataPrototype in a ClientServerInterface that
is typed by an ApplicationDataType the DataPrototypeInClientServerIn-
terfaceInstanceRef shall reference the subElement with the targetDataPro-
totypeInCs reference. In addition the rootDataPrototypeInCs shall be set to
define the context. Optionally it may be necessary to use contextDataPrototype-
InCs references because the target subElement may be arbitrarily nested within the
root AutosarDataPrototype.c(RS_SYST_00050)
[TPS_SYST_02131] Assignment of SOMEIPTransformationProps to a root Au-
tosarDataPrototype in a SenderReceiverInterface typed by an Imple-
mentationDataType dTo assign the SOMEIPTransformationProps to a root Au-
tosarDataPrototype in a SenderReceiverInterface that is typed by an Im-
plementationDataType the DataPrototypeInSenderReceiverInterface-
InstanceRef shall reference the AutosarDataPrototype with the targetDat-
aPrototypeInSr reference. The rootDataPrototypeInSr and contextDat-
aPrototypeInSr references in the DataPrototypeInSenderReceiverInter-
faceInstanceRef shall not be used.c(RS_SYST_00050)
[TPS_SYST_02214] Assignment of SOMEIPTransformationProps to a root Au-
tosarDataPrototype in a ClientServerInterface typed by an Implementa-
tionDataType dTo assign the SOMEIPTransformationProps to a root Autosar-
DataPrototype in a ClientServerInterface that is typed by an Implementa-
tionDataType the DataPrototypeInClientServerInterfaceInstanceRef
shall reference the AutosarDataPrototype with the targetDataPrototypeInCs
reference. The rootDataPrototypeInCs and contextDataPrototypeInCs ref-
erences in the DataPrototypeInClientServerInterfaceInstanceRef shall
not be used.c(RS_SYST_00050)
[TPS_SYST_02132] Assignment of SOMEIPTransformationProps to a subEle-
ment of a root AutosarDataPrototype typed by an ImplementationDataType

639 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

dTo assign the SOMEIPTransformationProps to a subElement of a root Au-

tosarDataPrototype in a ClientServerInterface or SenderReceiverIn-
terface that is typed by an ImplementationDataType the Implementation-
DataTypeElementInPortInterfaceRef shall reference the targetImplemen-
tationDataTypeElement. In addition the rootDataPrototype shall be set to de-
fine the context. Optionally it may be necessary to use contextImplementation-
DataElement references because the target subElement may be arbitrarily nested
within the root AutosarDataPrototype.c(RS_SYST_00050)
[TPS_SYST_02195] Applicable use cases for DataPrototypeReference dTable
7.18 contains a comprehensive list of use cases for the usage of DataPrototypeR-
eference.c(RS_SYST_00050)

Use case Role

DataPrototypeInSender-
AutosarDataPrototype in a SenderReceiverIn- ReceiverInterfaceIn-
terface typed by an ApplicationDataType stanceRef.targetDataProto-
typeInSr
DataPrototypeIn-
AutosarDataPrototype in a ClientServerInter- ClientServerInterfaceIn-
face typed by an ApplicationDataType stanceRef.targetDataProto-
typeInCs
DataPrototypeInSender-
DataPrototype in AutosarDataPrototype in a
ReceiverInterfaceIn-
SenderReceiverInterface typed by an Applica-
stanceRef.targetDataProto-
tionCompositeDataType
typeInSr
DataPrototypeIn-
DataPrototype in AutosarDataPrototype in a
ClientServerInterfaceIn-
ClientServerInterface typed by an Application-
stanceRef.targetDataProto-
CompositeDataType
typeInCs
DataPrototypeInSender-
AutosarDataPrototype in a SenderReceiverIn- ReceiverInterfaceIn-
terface typed by an ImplementationDataType stanceRef.targetDataProto-
typeInSr
DataPrototypeIn-
AutosarDataPrototype in a ClientServerInter- ClientServerInterfaceIn-
face typed by an ImplementationDataType stanceRef.targetDataProto-
typeInCs
ImplementationDataTypeEle-
DataPrototype in AutosarDataPrototype typed by mentInPortInterfaceRef.tar-
an ImplementationDataType getImplementationDataType-
Element
Table 7.18: Possible use cases for the usage of DataPrototypeReference

640 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

SOMEIPTransformationISignalProps

+ implementsLegacyStringSerialization: Boolean [0..1]

Describable ARElement
«atpVariation» TransformationPropsSet
TransformationISignalProps

+ csErrorReaction: CSTransformerErrorReactionEnum [0..1]

+dataPrototypeTransformationProps 0..* +transformationProps 0..*

Identifiable
DataPrototypeTransformationProps
+transformationProps TransformationProps

0..1

+dataPrototypeInPortInterfaceRef 0..1
SOMEIPTransformationProps
DataPrototypeReference
+ alignment: PositiveInteger [0..1]
+ tagId: PositiveInteger [0..1] + sizeOfArrayLengthField: PositiveInteger [0..1]
+ sizeOfStringLengthField: PositiveInteger [0..1]
+ sizeOfStructLengthField: PositiveInteger [0..1]
+ sizeOfUnionLengthField: PositiveInteger [0..1]

ImplementationDataTypeElementInPortInterfaceRef

DataPrototypeInPortInterfaceRef

+dataPrototypeInSenderReceiverInterface 0..1 +dataPrototypeInClientServerInterface 0..1

DataPrototypeInPortInterfaceInstanceRef DataPrototypeInPortInterfaceInstanceRef
DataPrototypeInSenderReceiverInterfaceInstanceRef DataPrototypeInClientServerInterfaceInstanceRef

Figure 7.12: Transformation Properties on the level of DataPrototypes

Class DataPrototypeTransformationProps
Package M2::AUTOSARTemplates::SystemTemplate::Transformer
Note DataPrototypeTransformationProps allows to set the attributes for the different Transformation
Technologies that are DataPrototype specific.
Base ARObject
Attribute Type Mult. Kind Note
dataPrototypeIn DataPrototype 0..1 aggr Reference to a DataPrototype that is transported in the
PortInterface Reference serialized ISignal.
Ref
network SwDataDefProps 0..1 aggr Specification of the actual network representation for the
Representation referenced primitive DataPrototype. If a network
Props representation is provided then the baseType shall be
used by the Transformer as input for the serialization/
deserilaization.
transformation TransformationProps 0..1 ref Collection of AutosarDataPrototype related configuration
Props settings for a transformer.

Table 7.19: DataPrototypeTransformationProps

641 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class DataPrototypeReference (abstract)

Package M2::AUTOSARTemplates::SystemTemplate::Transformer
Note This meta-class provides the ability to reference a DataPrototype.
Base ARObject
Subclasses DataPrototypeInPortInterfaceRef, ImplementationDataTypeElementInPortInterfaceRef
Attribute Type Mult. Kind Note
tagId PositiveInteger 0..1 attr This attribute represents the ability to specify a tag-id for
the serialization of a specific DataPrototype in the context
of a (potentially deeply-nested) composite data structure.

Table 7.20: DataPrototypeReference

Class DataPrototypeInPortInterfaceRef
Package M2::AUTOSARTemplates::SystemTemplate::Transformer
Note This class represents a RootDataPrototype that is typed by an ApplicationDataType or Implementation
DataType or a DataTypeElement that is aggregated within a composite application data type (record or
array).
Base ARObject, DataPrototypeReference
Attribute Type Mult. Kind Note
dataPrototypeIn DataPrototype 0..1 iref This element defines a reference to a DataPrototype in
ClientServer the context of a ClientServerInterface.
Interface
InstanceRef implemented by:DataPrototypeInClient
ServerInterfaceInstanceRef
dataPrototypeIn DataPrototype 0..1 iref This element defines a reference to a DataPrototype in
SenderReceiver the context of a SenderReceiverInterface.
Interface
InstanceRef implemented by:DataPrototypeInSender
ReceiverInterfaceInstanceRef
Table 7.21: DataPrototypeInPortInterfaceRef

Class DataPrototypeInSenderReceiverInterfaceInstanceRef
Package M2::AUTOSARTemplates::SystemTemplate::Transformer::InstanceRef
Note
Base ARObject, AtpInstanceRef , DataPrototypeInPortInterfaceInstanceRef
Attribute Type Mult. Kind Note
base SenderReceiver 0..1 ref Stereotypes: atpDerived
Interface
contextData ApplicationComposite * ref Tags:xml.sequenceOffset=20
PrototypeInSr ElementDataPrototype
(ordered)
rootData AutosarDataPrototype 0..1 ref Tags:xml.sequenceOffset=10
PrototypeInSr
targetData DataPrototype 1 ref Tags:xml.sequenceOffset=30
PrototypeInSr

Table 7.22: DataPrototypeInSenderReceiverInterfaceInstanceRef

642 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class DataPrototypeInClientServerInterfaceInstanceRef
Package M2::AUTOSARTemplates::SystemTemplate::Transformer::InstanceRef
Note
Base ARObject, AtpInstanceRef , DataPrototypeInPortInterfaceInstanceRef
Attribute Type Mult. Kind Note
base ClientServerInterface 0..1 ref Stereotypes: atpDerived
contextData ApplicationComposite * ref Tags:xml.sequenceOffset=20
PrototypeInCs ElementDataPrototype
(ordered)
rootData AutosarDataPrototype 0..1 ref Tags:xml.sequenceOffset=10
PrototypeInCs
targetData DataPrototype 1 ref Tags:xml.sequenceOffset=30
PrototypeInCs

Table 7.23: DataPrototypeInClientServerInterfaceInstanceRef

Class ImplementationDataTypeElementInPortInterfaceRef
Package M2::AUTOSARTemplates::SystemTemplate::Transformer::InstanceRef
Note This meta-class represents the ability to refer to the internal structure of an AutosarDataPrototype which
is typed by an ImplementationDatatype in the context of a PortInterface.
In other words, this meta-class shall not be used to model a reference to the AutosarDataPrototype as a
target itself, even if the AutosarDataPrototype is typed by an ImplementationDataType and even if that
ImplementationDataType represents a composite data type.
Base ARObject, DataPrototypeReference
Attribute Type Mult. Kind Note
context AbstractImplementation * ref This is a context in case there are subelements with
Implementation DataTypeElement explicit types. The reference has to be ordered to
DataElement properly reflect the nested structure.
(ordered)
Tags:xml.sequenceOffset=20
rootData AutosarDataPrototype 0..1 ref This refers to the AutosarDataPrototype which is typed by
Prototype the ImplementationDatatype. The targetDataPrototype
and all defined contextDataPrototypes can be found
within this rootDataPrototype.
Tags:xml.sequenceOffset=10
target AbstractImplementation 0..1 ref This is a target ImplementationDataTypeElement in case
Implementation DataTypeElement that the rootDataPrototype is composite and the target is
DataType a subElement of the rootDataPrototype.
Element
Tags:xml.sequenceOffset=30

Table 7.24: ImplementationDataTypeElementInPortInterfaceRef

[TPS_SYST_02121] Scope of DataPrototypeTransformationProps dDat-

aPrototypeTransformationProps is defined either
• for the root DataPrototype that is transmitted in the serialized ISignal
• for each of the composite subElements of the composite root DataPrototype
c(RS_SYST_00050)
[TPS_SYST_02123] Size of a length field for a chosen array dThe attribute size-
OfArrayLengthField of SOMEIPTransformationProps defines the size of a

643 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

length field generated by the SOME/IP transformer in front of the fixed-size or dy-
namic size array for which the DataPrototypeTransformationProps is defined
according to [TPS_SYST_02121].c(RS_SYST_00050)
[constr_5247] Value of attribute DataPrototypeTransformationProps.
transformationProps.sizeOfArrayLengthField dIf the configuration of length
field is done using DataPrototypeTransformationProps.transformation-
Props.sizeOfArrayLengthField then the value of attribute DataPrototype-
TransformationProps.transformationProps.sizeOfArrayLengthField
shall be at least as high as the number of bytes required to fit the result of the
expression maximum number of elements * sizeof(data type of array element).c()
[TPS_SYST_02124] Size of a length field for a chosen structure dThe attribute
sizeOfStructLengthField of SOMEIPTransformationProps defines the size
of a length field generated by the SOME/IP transformer in front of the struc-
ture for which the DataPrototypeTransformationProps is defined according to
[TPS_SYST_02121].c(RS_SYST_00050)
[TPS_SYST_02125] Size of a length field for a chosen union dThe attribute
sizeOfUnionLengthField of SOMEIPTransformationProps defines the size
of a length field generated by the SOME/IP transformer in front of the union
for which the DataPrototypeTransformationProps is defined according to
[TPS_SYST_02121].c(RS_SYST_00050)
[TPS_SYST_02360] Size of a length field for a chosen string dThe attribute
sizeOfStringLengthField of SOMEIPTransformationProps defines the size
of a length field generated by the SOME/IP transformer in front of the string
for which the DataPrototypeTransformationProps is defined according to
[TPS_SYST_02121].c(RS_SYST_00050)
[constr_5248] Value of attribute DataPrototypeTransformationProps.
transformationProps.sizeOfStringLengthField dIf the configuration of
length field is done using DataPrototypeTransformationProps.trans-
formationProps.sizeOfStringLengthField then the value of attribute
DataPrototypeTransformationProps.transformationProps.sizeOf-
StringLengthField shall be at least as high as the number of bytes required to fit
the result of the expression maximum number of characters in the string * maximum
number of code units per character (of the used character encoding) * maximum
number of bytes per code unit (of the used character encoding).c()
[TPS_SYST_02126] Alignment of a dynamic DataPrototype dThe attribute align-
ment of SOMEIPTransformationProps defines the padding for alignment purposes
that will be added by the SOME/IP transformer after the serialized data of the variable
data length data element for which the DataPrototypeTransformationProps is
defined according to [TPS_SYST_02121].c(RS_SYST_00050)

644 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_3278] Usage of SOMEIPTransformationProps.sizeOfArrayLength-

Field dThe attribute sizeOfArrayLengthField of SOMEIPTransformation-
Props shall only be defined if the DataPrototypeTransformationProps is de-
fined for a static size array according to [TPS_SYST_02121].c()
[constr_3279] Usage of SOMEIPTransformationProps.sizeOfStructLength-
Field dThe attribute sizeOfStructLengthField of SOMEIPTransformation-
Props shall only be defined if the DataPrototypeTransformationProps is de-
fined for a structure according to [TPS_SYST_02121].c()
[constr_3280] Usage of SOMEIPTransformationProps.sizeOfUnionLength-
Field dThe attribute sizeOfUnionLengthField of SOMEIPTransformation-
Props shall only be defined if the DataPrototypeTransformationProps is de-
fined for a union according to [TPS_SYST_02121].c()
[constr_3281] Usage of SOMEIPTransformationProps.alignment dThe at-
tribute alignment of SOMEIPTransformationProps shall only be defined if the
DataPrototypeTransformationProps is defined for a variable data length data
element according to [TPS_SYST_02121].c()
[constr_3282] SOME/IP Transformation settings for arrays in the context of an
ISignal dIn the context of an ISignal the usage of DataPrototypeTransforma-
tionProps.transformationProps.sizeOfArrayLengthField is only allowed if
the SOMEIPTransformationISignalProps.sizeOfArrayLengthFields is not
defined.c()
[constr_3283] SOME/IP Transformation settings for structures in the context of
an ISignal dIn the context of an ISignal the usage of DataPrototypeTrans-
formationProps.transformationProps.sizeOfStructLengthField is only
allowed if the SOMEIPTransformationISignalProps.sizeOfStructLength-
Fields is not defined.c()
[constr_3284] SOME/IP Transformation settings for unions in the context of an
ISignal dIn the context of an ISignal the usage of DataPrototypeTransforma-
tionProps.transformationProps.sizeOfUnionLengthField is only allowed if
the SOMEIPTransformationISignalProps.sizeOfUnionLengthFields is not
defined.c()
[constr_5246] SOME/IP Transformation settings for strings in the context of an
ISignal dIn the context of an ISignal the usage of DataPrototypeTransforma-
tionProps.transformationProps.sizeOfStringLengthField is only allowed
if the SOMEIPTransformationISignalProps.sizeOfStringLengthFields is
not defined.c()
[constr_3285] Alignment of variable data length data elements in the context
of an ISignal dThe definition of DataPrototypeTransformationProps.trans-
formationProps.alignment is only allowed if the SOMEIPTransformationDe-
scription.alignment is not defined.c()

645 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

7.3.2.3 Network Representation

In order to assure that the serialization of the transported data on the sender side and
its deserialization on the receiver side(s) is done correctly, system designers need to
assure that the same datatypes (i.e., SwBaseTypes) are used for the serialization/de-
serialization on both sides. However, this agreement does not imply the use or equality
of the SwBaseTypes defined by the ImplementationDataType used by the ap-
plication software on the sender and (possibly multiple) receiver sides. This means
that each EcuInstance, regardless if it belongs to a sender or receiver, can use one
datatype for the serialization/deserialization (e.g., UInt16 in the actual SOME/IP trans-
former code) and another datatype in the application software (e.g., Float32 in the
actual application software component code).
In order to define the commonly agreed datatypes for the serialization/deserialization of
the transported data by the sender and possibly multiple receivers, AUTOSAR defines
the following two approaches:
• serialization based on the network representation ([TPS_SYST_02136])
• serialization based on the ImplementationDataTypes ([TPS_SYST_02137])
[TPS_SYST_02136] Serialization based on the network representation dIf
a network representation that defines a SwBaseType is provided for each
DataPrototype typed by a primitive data type that is part of the se-
rialized ISignal (ISignal.transformationISignalProps.dataPrototype-
TransformationProps.networkRepresentationProps), these SwBaseTypes
shall be used for the serialization/deserialization.c()
[TPS_SYST_02137] Serialization based on the ImplementationDataTypes dFor
primitive DataPrototypes that are part of the serialized ISignal where no network
representation is provided (ISignal.transformationISignalProps.dataPro-
totypeTransformationProps.networkRepresentationProps), SwBaseType
shall be provided by the ImplementationDataTypes that either types the corre-
sponding PortPrototypes on the top level Software Composition that represents
the communicating EcuInstances, or it is mapped to the ApplicationDataType
that types it.c()
[constr_3317] Assuring the same data interpretation on the sender and receiver
sides in case of serialization based on the ImplementationDataTypes dIn order
to assure the same interpretation of the serialized data by the SOME/IP transformers
on the sender and receiver sides in case of serialization based on either a primitive or
a composite ImplementationDataType, the same SwBaseType shall be defined
• for this primitive DataPrototype or
• for each primitive DataPrototype of the leaf elements of the composite Dat-
aPrototype starting from the first element until and including the last element
that is requested by the receiver,

646 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

by the ImplementationDataTypes that either types the corresponding PortPro-

totypes on the top level Software Composition of the communicating EcuInstances,
or it is mapped to the ApplicationDataType that types it.c()
If the serialization is based on the ImplementationDataTypes, the same data has
to be transmitted on all buses, i.e., it is not possible to transmit different precision
(i.e., number of bits) on different buses, as with the serialization based on the network
representation on the ISignal level.
ImplementationDataTypes used by the actual application for the transported data
shall be defined by the corresponding PortPrototypes on the AtomicSwCom-
ponentTypes of the communicating EcuInstances. The RTE is responsible for
the possible type conversion and scaling in case of different Implementation-
DataTypes used for the serialization/deserialization and in the application.
[TPS_SYST_02138] Definition of the network representation dThe network repre-
sentation for each DataPrototype typed by a primitive data type in the serialized
data shall be defined by the SwDataDefProps that is aggregated by the DataPro-
totypeTransformationProps in the role networkRepresentationProps.c()
In other words: If a DataPrototype is transported in the ISignal the DataPro-
totypeTransformationProps can be used to assign a network representation to
each primitive DataPrototype that is part of the enclosing DataPrototype.
Attributes of SwDataDefProps networkRepresentationProps
additionalNativeTypeQualifier NA
annotation NA
baseType D
compuMethod D
dataConstr D
displayFormat D
displayPresentation NA
implementationDataType NA
invalidValue NA
swAddrMethod NA
swAlignment NA
swBitRepresentation NA
swCalibrationAccess NA
swCalprmAxisSet NA
swCalprmAxisSet. swCalprmAxis NA
/SwAxisGrouped. swCalprmRef
swCalprmAxisSet. swCalprmAxis NA
/SwAxisIndividual. swVariableRef
swCalprmAxisSet. swCalprmAxis NA
/SwAxisGrouped. sharedAxisType
swCalprmAxisSet. swCalprmAxis NA
/SwAxisIndividual. inputVariableType
swCalprmAxisSet/ AxisIndividual/ NA
Unit
swCalprmAxisSet/ BaseType NA
swComparisonVariable NA
swDataDependency NA
swHostVariable NA
swImplPolicy NA

647 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Attributes of SwDataDefProps networkRepresentationProps

swIntendedResolution NA
swInterpolationMethod NA
swIsVirtual NA
swPointerTargetProps NA
swRecordLayout NA
swRefreshTiming NA
swTextProps NA
swValueBlockSize NA
unit D
valueAxisDataType NA

Table 7.25: Allowed SwDataDefProps Attributes on DataPrototypeTransformationProps

The following settings apply in table 7.25:

D Attribute can be defined in the scope of this element.
NA Attribute is not applicable for usage in the scope of this element.
[TPS_SYST_02139] Applicability of the SwDataDefProps attributes for the net-
work representation of the serialized data dUsage of DataPrototypeTransfor-
mationProps.networkRepresentationProps shall follow the restrictions given in
table Table 7.25.c()
[constr_3318] Allowed use of ISignal.networkRepresentationProps dIf a ref-
erence from ISignal to DataTransformation in the role dataTransformation
exists, this ISignal SHALL NOT aggregate SwDataDefProps in the role net-
workRepresentationProps.c()
This means that aggregating SwDataDefProps by an ISignal is applicable only if
this ISignal is not transformed.
[constr_3319] Existence of DataPrototypeTransformationProps.net-
workRepresentationProps dISignal.transformationISignalProps.
dataPrototypeTransformationProps.networkRepresentationProps shall
either
• not exist at all or
• shall be defined for all leaf elements of the root DataPrototype transmitted in
the ISignal
c()
This means that either all leaf elements of the transformed ISignal shall have a
network representation, or none.

648 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

FibexElement
ISignal

+ dataTypePolicy: DataTypePolicyEnum
+ iSignalType: ISignalTypeEnum [0..1]
+ length: UnlimitedInteger

+transformationISignalProps 0..*

Describable
SOMEIPTransformationISignalProps
«atpVariation»
TransformationISignalProps + implementsLegacyStringSerialization: Boolean [0..1]
+ interfaceVersion: PositiveInteger [0..1]
+ csErrorReaction: CSTransformerErrorReactionEnum [0..1]
+ isDynamicLengthFieldSize: Boolean [0..1]
+ messageType: SOMEIPMessageTypeEnum [0..1]
+ sessionHandlingSR: SOMEIPTransformerSessionHandlingEnum [0..1]
+ sizeOfArrayLengthFields: PositiveInteger [0..1]
+ sizeOfStringLengthFields: PositiveInteger [0..1]
+ sizeOfStructLengthFields: PositiveInteger [0..1]
+ sizeOfUnionLengthFields: PositiveInteger [0..1]

+dataPrototypeTransformationProps 0..*
+networkRepresentationProps 0..1
DataPrototypeTransformationProps «atpVariation»
+networkRepresentationProps SwDataDefProps

0..1

+swDataDefProps 0..1
+dataPrototypeInPortInterfaceRef

+tlvDataIdDefinition 0..*

ARElement
TlvDataIdDefinition
TlvDataIdDefinitionSet +tlvDataIdDefinition

«atpSplitable» 0..* «atpIdentityContr...

+ id: PositiveInteger

0..1 AbstractImplementationDataTypeElement
ImplementationDataTypeElement
DataPrototypeReference
+ arrayImplPolicy: ArrayImplPolicyEnum [0..1]
+ tagId: PositiveInteger [0..1] + arraySizeHandling: ArraySizeHandlingEnum [0..1]
+ arraySizeSemantics: ArraySizeSemanticsEnum [0..1]
+ isOptional: Boolean [0..1]
«atpVariation»
+ arraySize: PositiveInteger [0..1]

ImplementationDataTypeElementInPortInterfaceRef

DataPrototypeInPortInterfaceRef

+dataPrototypeInSenderReceiverInterface 0..1 +dataPrototypeInClientServerInterface 0..1

DataPrototypeInPortInterfaceInstanceRef DataPrototypeInPortInterfaceInstanceRef
DataPrototypeInSenderReceiverInterfaceInstanceRef DataPrototypeInClientServerInterfaceInstanceRef

Figure 7.13: Transformer Network Representation

7.3.2.3.1 Example - Serialization based on the network representation

An example with concrete methodological steps in a common OEM-Tier 1 develop-

ment process for the serialization based on the network representation is presented in
Figure 7.14. The steps are as follows:
1. OEM decides on a common SwBaseType and CompuMethod for each bus, as
part of the network representation, used for serialization/deserialization of one
concrete complex data type.

649 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

2. OEM provides an ImplementationDataType, with SwBaseType and optional

CompuMethod, on the PortPrototypes on the RootSwCompositions of the
communicating EcuInstances (sender and possibly multiple receivers). The
step is optional and PortPrototypes can also be typed by an Application-
DataType that has a mapping to an ImplementationDataType.
3. Tier 1s are free to define arbitrary ImplementationDataType (with SwBase-
Type and optional CompuMethod) in the application software components. If
this SwBaseType is different than the one used for the serialization/deserializa-
tion, RTE is responsible for the type conversion together with possible scaling
defined by the CompuMethods, as part of the network representation and Port-
Prototypes on the RootSwComposition and SwComponentPrototype that
is typed by ApplicationSwComponentType. Please note that on the re-
ceiver side it is possible that the SwComponentPrototype that is typed by
ApplicationSwComponentType receives only a subset of data defined on the
RootSwComposition. In this case, this needs be described by the PortIn-
UPDATE AR-106490
terfaceMapping.
Example - Serialization based on the network representation (2)
Bus_A
CompuMethod: identical, identical

CompuMethod: identical, identical

DataConstr: 0-2000, -
RootComposition_ECU_B

CompuMethod: y = x / 10, identical SWC_B

Struct {
Struct {
UInt8
1 Struct { Float32 3
RootComposition_ECU_A UInt8 UInt16 UInt8
} 2 UInt8 }
}
SWC_A
Struct {
Float32 2 RootComposition_ECU_C
3 UInt8
Struct {
UInt16
} UInt8
}
Struct { SWC_C
UInt16

}
UInt8 1
Struct {
CompuMethod: identical, identical
2 Struct {
UInt16 3
UInt16
}
}
CompuMethod: identical, identical
DataConstr: 0-2000, - CompuMethod: identical
DataConstr: 0-2000
CompuMethod: identical, identical
DataConstr: 0.0-2000.0, - CompuMethod: identical

Bus_B
Figure 7.14: Serialization based on the network representation
9 Set Date in Insert -> Set footer in Insert -> Header & Footer
Header & Footer

The actual steps that need to be performed at runtime are presented in Figure 7.15
and they are as follows:
1. Application of the sending software component provides the data to be transmit-
ted to the RTE and stores it in SWC internal buffer.
2. If SwBaseType defined by the ImplementationDataType on the PortPro-
totype of the ApplicationSwComponentType is different then the one op-
tionally defined by the ImplementationDataType on the PortPrototype of

650 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

the RootSwComposition, the RTE performs type conversion, and scaling if

CompuMethods are also defined on these PortPrototypes, and stores the
values internally in the RTE.
3. If network representation defines a SwBaseType that is different from the one
optionally defined by the ImplementationDataType on the PortPrototype
on the RootSwComposition, the RTE performs another type conversion, and
scaling if CompuMethod is also defined as part of the network representation,
and stores the value internally in the RTE. This internal value is used for the
serialization.
4. On the receiver side, the RTE stores the serialized data in the RTE internal buffer.
When the receiver SWC wants to read the data, the RTE first de-serializes the
values received from the bus whose type is specified by the SwBaseType that is
part of the network representation. If the SwBaseType is different then the one
optionally defined by the ImplementationDataType on the PortPrototype
of the RootSwComposition, the RTE performs type conversion, and scaling
if CompuMethods are also defined on the PortPrototype and in the network
representation, and stores the values internally in the RTE.
5. If SwBaseType defined by the ImplementationDataType on the Port-
Prototype of the SwComponentPrototype that is typed by Application-
SwComponentType is different then the one defined by the Implementation-
DataType on the PortPrototype of the RootSwComposition, the RTE per-
forms another type conversion, and scaling if CompuMethods are also defined
on these PortPrototype, and stores the final values internally in the buffer of
the application. The RTE is also able to deliver only a subset of data to the
SwComponentPrototype that is typed by ApplicationSwComponentType,
if that is required by the description of the PortInterfaceMapping.
Example - Serialization based on the network representation (4)
Bus_A

4 Struct { Struct { 5
1000 1000.0
100 0 1 1 0 0 1 0 0 10 10 RootComposition_ECU_B
} }
10 0 0 0 0 1 0 1 0
SWC_B
Struct { 3 Struct {
UInt8 Struct { Float32
RootComposition_ECU_A UInt8 UInt16 UInt8
} UInt8 }
}
SWC_A
Struct {
Float32 Struct { RootComposition_ECU_C
UInt8 UInt16
} UInt8
Struct { SWC_C
}
UInt16
UInt8
} 3 Struct {
Struct {
UInt16
UInt16
Struct { Struct { 0 0 0 0 0 0 1 1 }
}
1000.0 1000 1000
10 10 1 1 1 0 1 0 0 0
} Struct {
} 1 2 10 0 0 0 0 1 0 1 0 Struct {
1000
4 1000
} 5
}

Bus_B

Figure 7.15: Serialization based on the network representation

10 Set Date in Insert -> Set footer in Insert -> Header & Footer
Header & Footer

651 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

7.3.2.3.1.1 Necessity of data conversion based on CompuMethods

CompuMethods are used to define how the information processed by AUTOSAR (the
internal view) is to be interpreted in the physical domain. As an example the Battery-
Voltage may be processed by AUTOSAR in a 1/10th scaling, thus an Integer value of
485 represents 48,5 Volt.
It is important to recognize that the value 48,5V is never handled by the AUTOSAR
platform software. AUTOSAR only handles the internal representation (485).
Of course there are use-cases where the physical representation is required, e.g. mon-
itoring tools show the measured values in the physical domain, thus have to perform
a conversion. Another use-case is the dashboard where the BatteryVoltage might be
displayed. But in this case it is the task of the displaying application software to perform
the conversion into the physical domain, or rather into the visualization.
The AUTOSAR infrastructure (respectively the RTE) may still be required to perform a
conversion of data. This is required if two CompuMethods - applying to the same data
path - are not equal.

Figure 7.16: Data conversion based on CompuMethods

In the example figure 7.16 there are several CompuMethods defined for various oc-
currences of data: A value is produced in SWC_A with a BaseType Float32 and an
“identical” CompuMethod (y = x). The value is then delegated to the RootComposi-
tion_ECU_A, where the BaseType is an uint16 and the CompuMethod is again “identi-
cal”. For the network transport the CompuMethod is defined as y = x/10. As the two

652 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

CompuMethods are not equal the RTE will have to convert the “identical” representa-
tion to the y = x/10 representation. On the reception side there is again an “identical”
CompuMethod defined, thus another conversion by the receiving RTE is required.

7.3.2.3.2 Example - Serialization based on the ImplementationDataTypes

An example with concrete methodological steps in a common OEM-Tier 1 development

process for the serialization based on the ImplementationDataTypes is presented
in Figure 7.17. The steps are as follows:
1. OEM provides the same ImplementationDataType, with SwBaseType and
optional CompuMethod, on the PortPrototypes on the RootSwComposi-
tions of the communicating EcuInstances (sender and possibly multiple re-
ceivers). The PortPrototypes can also be typed by an Application-
DataType that has a mapping to an ImplementationDataType.
2. Tier 1s are free to define arbitrary ImplementationDataType (with SwBase-
Type and optional CompuMethod) in the application software components. If this
SwBaseType is different than the one used for the serialization/deserialization,
RTE is responsible for the type conversion together with possible scaling defined
by the CompuMethods, as part of PortPrototypes on the RootSwComposi-
tion and AtomicSwComponentTypes. Please note that on the receiver side it
is possible that the SwComponentPrototype that is typed by Application-
SwComponentTypereceives only a subset of data defined on the RootSwCom-
position. In this case, this needs be described by the PortInterfaceMap-
ping.
Example - Serialization based on the ImplementationDataTypes (2)
Bus_A
CompuMethod: identical, identical

CompuMethod: identical, identical

DataConstr: 0-2000, -
RootComposition_ECU_B

SWC_B
Struct {
Struct {
RootComposition_ECU_A UInt16
Float32 2
UInt8
1 UInt8 }
}
SWC_A
Struct {
Float32 Struct { 1 RootComposition_ECU_C
2 UInt8 UInt16
} UInt8
} SWC_C

Struct {
1 Struct {
UInt16 2
UInt16
}
UInt8
CompuMethod: identical, identical }
DataConstr: 0-2000, - CompuMethod: identical, identical
DataConstr: 0-2000, -
CompuMethod: identical, identical
DataConstr: 0.0-2000.0, - CompuMethod: identical

Bus_B
Figure 7.17: Serialization based on the ImplementationDataTypes
12 Set Date in Insert -> Set footer in Insert -> Header & Footer
Header & Footer

653 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

The actual steps that need to be performed at runtime are presented in Figure 7.18
and they are as follows:
1. Application of the sending software component provides the data to be transmit-
ted to the RTE and stores it in SWC internal buffer.
2. If SwBaseType defined by the ImplementationDataType on the Port-
Prototype of the SwComponentPrototype that is typed by Application-
SwComponentType is different then the one defined by the Implementation-
DataType on the PortPrototype of the RootSwComposition, the RTE per-
forms type conversion, and scaling if CompuMethods are also defined on these
PortPrototypes, and stores the values internally in the RTE.
3. As no network representation is provided, the internal value from step 2 is used
for the serialization and transmission on the bus.
4. On the receiver side, the RTE stores the serialized data received from the bus
in the RTE internal buffer. When the receiver SWC wants to read the data, the
RTE de-serializes these values as defined by the ImplementationDataType
on the PortPrototype of the RootSwComposition.
5. If SwBaseType defined by the ImplementationDataType on the Port-
Prototype of the SwComponentPrototype that is typed by Application-
SwComponentType is different then the one defined by the Implementation-
DataType on the PortPrototype of the RootSwComposition, the RTE per-
forms another type conversion, and scaling if CompuMethods are also defined
on these PortPrototype, and stores the final values internally in the buffer of
the application. The RTE is also able to deliver only a subset of data to the
SwComponentPrototype that is typed by ApplicationSwComponentType,
if that is required by the description of the PortInterfaceMapping.

654 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11
Example - Serialization based on the ImplementationDataTypes (4)
Bus_A

0 0 0 0 0 0 1 1 4 Struct { Struct { 5
1000 1000 1000.0
1 1 1 0 1 0 0 0 10 10 RootComposition_ECU_B
} }
10 0 0 0 0 1 0 1 0
SWC_B
Struct {
3 Struct { Float32
RootComposition_ECU_A UInt16 UInt8
UInt8 }
}
SWC_A
Struct {
Float32 Struct { RootComposition_ECU_C
UInt8 UInt16
} UInt8
} SWC_C
3
Struct {
Struct {
UInt16
0 0 0 0 0 0 1 1 UInt16
}
1000 UInt8
Struct { Struct { 1 1 1 0 1 0 0 0 }
Struct {
1000.0 1000
1000 Struct {
10 10 10 0 0 0 0 1 0 1 0 10 1000
} 1 } 2 } 4 } 5

Bus_B
Figure 7.18: Serialization based on the ImplementationDataTypes
14 Set Date in Insert -> Set footer in Insert -> Header & Footer
Header & Footer

7.3.3 COM Based Transformer

In order to support the signal group based interaction of the transformer with the COM
module as defined in the COM Based Transformer specification [18] a further modeling
is supported:
In case the array based signal group API of Com shall be used the ISignalGroup
has a reference to the DataTransformation element in the role comBasedSig-
nalGroupTransformation. This defines that the RTE shall use the array based
signal group API of Com [22] in order to transport the transformed data.
[TPS_SYST_02058] Usage of COM Based Transformer dIf
1. an ISignalGroup references a DataTransformation in the role com-
BasedSignalGroupTransformation and
2. this ISignalGroup references a SystemSignalGroup and
3. the referenced SystemSignalGroup is referenced by a SenderReceiver-
ToSignalGroupMapping in the role signalGroup
then the VariableDataPrototype referenced by the SenderReceiverToSig-
nalGroupMapping shall be transformed using the COM Based Transformer [18].c
(RS_SYST_00051)

655 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_5050] VariableDataPrototype of COM Based Transformer dThe Vari-

ableDataPrototype of [TPS_SYST_02058] shall be typed by an Application-
RecordDataType or an ImplementationDataType of category STRUCTURE.c
()
Please note that according to [SWS_Rte_03867] the RTE calculates the Input-
BufferLength that is used for the output buffer calculation for Sender/Receiver com-
munication needed for the VariableDataPrototype of the dataElement of the
SenderReceiverInterface that shall be transformed.
[constr_3132] Required COM Based Transformation for comBasedSignal-
GroupTransformation dIf a ISignalGroup has a reference to the DataTrans-
formation element in the role comBasedSignalGroupTransformation then this
DataTransformation shall be the handled by the COM Based Transformer [18].c()
Note that the SystemSignalGroup (and the corresponding ISignalGroup) in this
case not only contains the application data element signals mapped by the Sender-
ReceiverToSignalGroupMapping but also the data which has been added by the
transformers (e.g. crc, sequence counter, ...). This is also shown in the example in
Figure 7.20.
FibexElement Identifiable
+dataTransformation
ISignal DataTransformation
«atpVariation,atpSplitable»
+ dataTypePolicy: DataTypePolicyEnum 0..1
+ iSignalType: ISignalTypeEnum [0..1]
+ length: UnlimitedInteger
+comBasedSignalGroupTransformation 0..1
0..*
+iSignal
«atpVariation,atpSplitable»

FibexElement
ISignalGroup

+systemSignalGroup 1
+systemSignal ARElement +systemSignal ARElement
SystemSignal SystemSignalGroup
1 *
+ dynamicLength: Boolean
+transformingSystemSignal

0..1
+systemSignal 1 +signalGroup 1

DataMapping

SenderReceiverToSignalMapping SenderReceiverToSignalGroupMapping

Figure 7.19: Transformer Data Mapping

[constr_3183] ISignalGroup with transformationISignalProps dAn ISig-

nalGroup that aggregates transformationISignalProps shall reference the
DataTransformation in the role comBasedSignalGroupTransformation.c()

656 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_02068] Transformer header field representation in an ISignal-

Group dIn case ISignalGroup has a reference to a DataTransformation in
the role comBasedSignalGroupTransformation and the DataTransformation
has further TransformationTechnologys defined in the role transformerChain
then space for the individual headers shall be allocated by defining one ISignal per
header part that is member of the ISignalGroup.c(RS_SYST_00056)
[constr_3152] BufferProperties.headerLength settings for any transformer
used in combination with a COM Based transformer dA transformer used in a
transformer chain with a COM Based transformer shall be configured with the following
values:
• BufferProperties.headerLength = 0
c()
This is because the space for the transformer headers (e.g. CRC and Sequence-
Counter for E2E) needs to be allocated by a proper ISignalGroup layout according
to [TPS_SYST_02068].
length of the uint8-array representation

Signal
Signal Group X Signal B Signal IPdu
A

start position of the uint8-array representation

Signal M CRC SC D D D D Signal IPdu showing

Signal B group signals
A 1 2 3 4

Further Transformer
M CRC SC D D D D
fills header data
1 2 3 4

Array representation
M CRC SC D D D D
enhanced by
1 2 3 4 E2E Transformer

Array representation
M CRC SC D D D D
result of
1 2 3 4 COM Based Transformer

Start of RTE buffer for all transformers of this Signal Group

Figure 7.20: Example of COM Based Transformer buffer layout

- AUTOSAR Confidential -
As shown in figure 7.20 the example illustrates that for the E2E header (’CRC’ and ’SC’)
and the ’M’ header three further ISignals are defined within the ISignalGroup in
order to compensate the space required by the additional transformers.

657 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

7.3.4 E2E Transformer

This section specifies the configuration of the E2E protection that is invoked "out-of-
box" by RTE and realized by E2E Transformer [38], E2E Library [23] and CRC Li-
brary [39].
The specific configuration for an E2E transformer takes place in EndToEndTrans-
formationDescription and EndToEndTransformationISignalProps shown
in Figure 7.21 and in EndToEndTransformationComSpecProps (see more details
in [5])
[TPS_SYST_02275] Relation between EndToEndTransformationDescription
and EndToEndTransformationComSpecProps dIt is possible to overwrite the
ISignal specific E2E settings that are defined in EndToEndTransformation-
Description with settings available in the EndToEndTransformationCom-
SpecProps defined at the PortPrototype of a SwComponentType. With this ap-
proach it is possible to define Port-Prototype specific configuration options for the E2E
data transformer.c(RS_SYST_00056)
Identifiable
TransformationTechnology

«enumeration»
EndToEndProfileBehaviorEnum

PRE_R4_2
R4_2 +transformer 1

«atpVariation»

+transformationDescription 0..1
FibexElement Describable
ISignal FibexElement
+iSignal TransformationDescription
ISignalGroup
+ dataTypePolicy: DataTypePolicyEnum 0..*
+ iSignalType: ISignalTypeEnum [0..1]
+ length: UnlimitedInteger

+transformationISignalProps 0..* +transformationISignalProps 0..*

Describable EndToEndTransformationDescription

«atpVariation» + clearFromValidToInvalid: Boolean [0..1]

TransformationISignalProps + counterOffset: PositiveInteger [0..1]
+ crcOffset: PositiveInteger [0..1]
+ csErrorReaction: CSTransformerErrorReactionEnum [0..1] + dataIdMode: DataIdModeEnum [0..1]
+ dataIdNibbleOffset: PositiveInteger [0..1]
+ maxDeltaCounter: PositiveInteger [0..1]
+ maxErrorStateInit: PositiveInteger [0..1]
+ maxErrorStateInvalid: PositiveInteger [0..1]
+ maxErrorStateValid: PositiveInteger [0..1]
+ maxNoNewOrRepeatedData: PositiveInteger [0..1]
«enumeration» + minOkStateInit: PositiveInteger [0..1]
EndToEndTransformationISignalProps
DataIdModeEnum + minOkStateInvalid: PositiveInteger [0..1]
+ dataId: PositiveInteger [0..*] {ordered} + minOkStateValid: PositiveInteger [0..1]
all16Bit
+ dataLength: PositiveInteger [0..1] + offset: PositiveInteger [0..1]
alternating8Bit
+ maxDataLength: PositiveInteger [0..1] + profileBehavior: EndToEndProfileBehaviorEnum [0..1]
lower8Bit
+ minDataLength: PositiveInteger [0..1] + profileName: NameToken
lower12Bit
+ sourceId: PositiveInteger [0..1] + syncCounterInit: PositiveInteger [0..1]
+ upperHeaderBitsToShift: PositiveInteger [0..1]
+ windowSizeInit: PositiveInteger [0..1]
+ windowSizeInvalid: PositiveInteger [0..1]
+ windowSizeValid: PositiveInteger [0..1]

+e2eProfileCompatibilityProps 0..1

ARElement
E2EProfileCompatibilityProps

+ transitToInvalidExtended: Boolean [0..1]

Figure 7.21: E2E Transformer Configuration

658 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class EndToEndTransformationDescription
Package M2::AUTOSARTemplates::SystemTemplate::Transformer
Note EndToEndTransformationDescription holds these attributes which are profile specific and have the same
value for all E2E transformers.
Base ARObject, Describable, TransformationDescription
Attribute Type Mult. Kind Note
clearFromValid Boolean 0..1 attr Clear monitoring window on transition from state Valid to
ToInvalid state Invalid.
counterOffset PositiveInteger 0..1 attr Offset of the counter in the Data[] array in bits.
crcOffset PositiveInteger 0..1 attr Offset of the CRC in the Data[] array in bits.
dataIdMode DataIdModeEnum 0..1 attr This attribute describes the inclusion mode that is used to
include the implicit two-byte Data ID in the one-byte CRC.
dataIdNibble PositiveInteger 0..1 attr Offset of the Data ID nibble in the Data[] array in bits.
Offset
e2eProfile E2EProfileCompatibility 0..1 ref Reference to additional settings for the E2E state
Compatibility Props machine.
Props
maxDelta PositiveInteger 0..1 attr Maximum allowed difference between two counter values
Counter of two consecutively received valid messages. For
example, if the receiver gets data with counter 1 and Max
DeltaCounter is 3, then at the next reception the receiver
can accept Counters with values 2, 3 or 4.
maxErrorState PositiveInteger 0..1 attr Maximal number of checks in which ProfileStatus equal to
Init E2E_P_ERROR was determined, within the last Window
Size checks, for the state E2E_SM_INIT.
maxErrorState PositiveInteger 0..1 attr Maximal number of checks in which ProfileStatus equal to
Invalid E2E_P_ERROR was determined, within the last Window
Size checks, for the state E2E_SM_INVALID.
maxErrorState PositiveInteger 0..1 attr Maximal number of checks in which ProfileStatus equal to
Valid E2E_P_ERROR was determined, within the last Window
Size checks, for the state E2E_SM_VALID.
maxNoNewOr PositiveInteger 0..1 attr The maximum allowed amount of consecutive failed
RepeatedData counter checks.
minOkStateInit PositiveInteger 0..1 attr Minimal number of checks in which ProfileStatus equal to
E2E_P_OK was determined, within the last WindowSize
checks, for the state E2E_SM_INIT.
minOkState PositiveInteger 0..1 attr Minimal number of checks in which ProfileStatus equal to
Invalid E2E_P_OK was determined, within the last WindowSize
checks, for the state E2E_SM_INVALID.
minOkState PositiveInteger 0..1 attr Minimal number of checks in which ProfileStatus equal to
Valid E2E_P_OK was determined, within the last WindowSize
checks, for the state E2E_SM_VALID.
offset PositiveInteger 0..1 attr Offset of the E2E header in the Data[] array in bits.
profileBehavior EndToEndProfile 0..1 attr Behavior of the check functionality
BehaviorEnum
profileName NameToken 1 attr Definition of the E2E profile.
syncCounterInit PositiveInteger 0..1 attr Number of checks required for validating the consistency
of the counter that shall be received with a valid counter
(i.e. counter within the allowed lock-in range) after the
detection of an unexpected behavior of a received
counter.
upperHeader PositiveInteger 0..1 attr This attribute describes the number of upper-header bits
BitsToShift to be shifted.
value = 0 or not present: shift of upper header is NOT
performed.
5

659 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class EndToEndTransformationDescription
4
value > 0: the E2E Transformer on the protect-side, takes
the first upperHeaderBitsToShift bits from the upper buffer
(e.g. SOME/IP header part generated by SOME/IP
transformer) and shifts them towards the lower bytes and
bits within the Data[] for the length of the E2E header
(e.g. 12 bytes in case of E2E Profile 4). This means the
shift distance is fixed - it depends on the E2E header size
- what is configured here is the number of bits that are to
be shifted. This option is defined because the Some/IP
header generated by SOME/IP transformer shall be, due
to compatibility between non-protected and
E2E-protected communication, at the same position,
which is before E2E header.
windowSizeInit PositiveInteger 0..1 attr Size of the monitoring window of state Init for the E2E
state machine.
windowSize PositiveInteger 0..1 attr Size of the monitoring window of state Invalid for the E2E
Invalid state machine.
windowSize PositiveInteger 0..1 attr Size of the monitoring window of state Valid for the E2E
Valid state machine.
Table 7.26: EndToEndTransformationDescription

Enumeration DataIdModeEnum
Package M2::AUTOSARTemplates::SystemTemplate::Transformer
Note Supported inclusion modes to include the implicit two-byte Data ID in the one-byte CRC.
Literal Description
all16Bit Two bytes are included in the CRC (double ID configuration).
Tags:atp.EnumerationLiteralIndex=0
alternating8Bit One of the two bytes byte is included, alternating high and low byte, depending on parity of the
counter (alternating ID configuration). For even counter low byte is included; For odd counters the
high byte is included.
Tags:atp.EnumerationLiteralIndex=1
lower12Bit The low byte is included in the implicit CRC calculation, the low nibble of the high byte is transmitted
along with the data (i.e. it is explicitly included), the high nibble of the high byte is not used. This is
applicable for the IDs up to 12 bits.
Tags:atp.EnumerationLiteralIndex=2
lower8Bit Only low byte is included, high byte is never used. This is applicable if the IDs in a particular system
are 8 bits.
Tags:atp.EnumerationLiteralIndex=3

Table 7.27: DataIdModeEnum

Class E2EProfileCompatibilityProps
Package M2::AUTOSARTemplates::SystemTemplate::Transformer
Note This meta-class collects settings for configuration of the E2E state machine.
Tags:atp.recommendedPackage=E2EProfileCompatibilityPropsCollection
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
5

660 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class E2EProfileCompatibilityProps
transitToInvalid Boolean 0..1 attr E2E State machine behavior concerning transition from
Extended NODATA/INIT to INVALID
value=0 (false): no direct transition from NODATA to
INVALID, no transition from INIT to INVALID due to
counter-related faults (Autosar R19-11 or former
behavior)
value=1 (true): direct transition from NODATA to INVALID
covered, transition from INIT to INVALID due to
counter-related faults covered (state machine extended)

Table 7.28: E2EProfileCompatibilityProps

Enumeration EndToEndProfileBehaviorEnum
Package M2::AUTOSARTemplates::SystemTemplate::Transformer
Note Behavior of the check functionality
Literal Description
PRE_R4_2 Check has the legacy behavior, before AUTOSAR Release 4.2.
Tags:atp.EnumerationLiteralIndex=0
R4_2 Check behaves like new P4/P5/P6 profiles introduced in AUTOSAR Release 4.2.
Tags:atp.EnumerationLiteralIndex=1

Table 7.29: EndToEndProfileBehaviorEnum

Class <<atpVariation>> EndToEndTransformationISignalProps

Package M2::AUTOSARTemplates::SystemTemplate::Transformer
Note Holds all the ISignal specific attributes for the EndToEndTransformer.
Base ARObject, Describable, TransformationISignalProps
Attribute Type Mult. Kind Note
dataId (ordered) PositiveInteger * attr This represents a unique numerical identifier.
Note: ID is used for protection against masquerading.
The details concerning the maximum number of values
(this information is specific for each E2E profile)
applicable for this attribute are controlled by a semantic
constraint that depends on the category of the EndToEnd
Protection.
dataLength PositiveInteger 0..1 attr Length of payload and E2E header in bits.
maxDataLength PositiveInteger 0..1 attr Maximum length of payload and E2E header in bits.
minDataLength PositiveInteger 0..1 attr Minimum length of payload and E2E header in bits.
sourceId PositiveInteger 0..1 attr This attribute represents a unique numerical identifier
identifying the source of a certain transmission. In case of
C/S communication, this ID uniquely identifies the client.
Note: ID is used for protection against masquerading.
The details concerning the maximum number of values
(this information is specific for each E2E profile)
applicable for this attribute are controlled by a semantic
constraint that depends on the category of the EndToEnd
Protection.
Table 7.30: EndToEndTransformationISignalProps

661 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_5229] Existence of attribute E2EProfileCompatibilityProps.

transitToInvalidExtended is mandatory for each EndToEndTrans-
formationDescription dFor each EndToEndTransformationDe-
scription, a reference to E2EProfileCompatibilityProps in the
role e2eProfileCompatibilityProps shall exist and the referenced
E2EProfileCompatibilityProps shall define a value for the attribute transit-
ToInvalidExtended.c()
[constr_3313] E2E transformer configuration dFor each TransformationDe-
scription variant that is a EndToEndTransformationDescription
• attribute protocol of TransformationTechnology shall be set to E2E
• attribute version of TransformationTechnology shall be set to 1.0.0
• attribute transformerClass of TransformationTechnology shall be set to
safety
c()
[TPS_SYST_02067] E2E profile dThe E2E profile is defined by EndToEndTrans-
formationDescription.profileName.c(RS_SYST_00056)
[TPS_SYST_02073] EndToEndTransformationDescription.profileName d
EndToEndTransformationDescription.profileName can have the following
values: PROFILE_01, PROFILE_02, PROFILE_04, PROFILE_05, PROFILE_06,
PROFILE_07, PROFILE_08, PROFILE_08m, PROFILE_11, PROFILE_22, PRO-
FILE_04m, PROFILE_07m, PROFILE_44, and PROFILE_44m.c(RS_SYST_00056)
[TPS_SYST_02072] profileName of EndToEndTransformationDescription
dThe values for the profileName of EndToEndTransformationDescription
mentioned in [TPS_SYST_02073] are standardized and reserved for being used in
the way the AUTOSAR standard foresees. In addition, it is positively possible to use
other than the standardized values for the profileName.c(RS_SYST_00056)
The setting of the EndToEndTransformationDescription.profileName has an
influence on the upper- and lower multiplicities of certain attributes of EndToEnd-
TransformationDescription and EndToEndTransformationISignalProps.
[constr_3185] Multiplicity of EndToEndTransformationDescription.dataId-
Mode in PROFILE_01 and PROFILE_11 dIf the EndToEndTransformationDe-
scription.profileName attribute is set to PROFILE_01 or PROFILE_11 then the
multiplicity of the EndToEndTransformationDescription.dataIdMode attribute
shall be 1.c()
[constr_3186] Multiplicity of EndToEndTransformationDescription.dataId-
Mode in PROFILE_02, PROFILE_04, PROFILE_05, PROFILE_06, PROFILE_07,
PROFILE_08, PROFILE_22, PROFILE_04m, PROFILE_07m, PROFILE_08m, PRO-
FILE_44 and PROFILE_44m dIf the EndToEndTransformationDescription.
profileName attribute is set to a value of PROFILE_02, PROFILE_04, PRO-
FILE_05, PROFILE_06, PROFILE_07, PROFILE_08, PROFILE_22, PROFILE_04m,

662 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

PROFILE_07m, PROFILE_08m, PROFILE_44, or PROFILE_44m then the multiplicity

of the EndToEndTransformationDescription.dataIdMode attribute shall be 0.c
()
[constr_3326] Allowed values for EndToEndTransformationDescription.
dataIdMode in PROFILE_11 dIf the EndToEndTransformationDescription.
profileName attribute has a value of PROFILE_11 then the value of the EndToEnd-
TransformationDescription.dataIdMode attribute shall be set to all16Bit or
lower12Bit.c()
[constr_3187] Multiplicity of EndToEndTransformationDescription.coun-
terOffset in PROFILE_01 and PROFILE_11 dIf the EndToEndTransformation-
Description.profileName attribute is set to PROFILE_01 or PROFILE_11 then
the multiplicity of the EndToEndTransformationDescription.counterOffset
attribute shall be 1.c()
[constr_3188] Multiplicity of EndToEndTransformationDescription.coun-
terOffset in PROFILE_02, PROFILE_04, PROFILE_05, PROFILE_06, PRO-
FILE_07, PROFILE_08, PROFILE_22, PROFILE_04m, PROFILE_07m, PRO-
FILE_08m, PROFILE_44, and PROFILE_44m dIf the EndToEndTransformation-
Description.profileName attribute is set to a value of PROFILE_02, PRO-
FILE_04, PROFILE_05, PROFILE_06, PROFILE_07, PROFILE_08, PROFILE_22,
PROFILE_04m, PROFILE_07m, PROFILE_08m, PROFILE_44, or PROFILE_44m
then the multiplicity of the EndToEndTransformationDescription.counterOff-
set attribute shall be 0.c()
[constr_3189] Multiplicity of EndToEndTransformationDescription.crcOff-
set in PROFILE_01 and PROFILE_11 dIf the EndToEndTransformationDe-
scription.profileName attribute is set to PROFILE_01 or PROFILE_11 then the
multiplicity of the EndToEndTransformationDescription.crcOffset attribute
shall be 1.c()
[constr_3190] Multiplicity of EndToEndTransformationDescription.crcOff-
set in PROFILE_02, PROFILE_04, PROFILE_05, PROFILE_06, PROFILE_07,
PROFILE_08, PROFILE_22, PROFILE_04m, PROFILE_07m, PROFILE_08m, PRO-
FILE_44 and PROFILE_44m dIf the EndToEndTransformationDescription.
profileName attribute is set to a value of PROFILE_02, PROFILE_04, PRO-
FILE_05, PROFILE_06, PROFILE_07, PROFILE_08, PROFILE_22, PROFILE_04m,
PROFILE_07m, PROFILE_08m, PROFILE_44, or PROFILE_44m then the multiplicity
of the EndToEndTransformationDescription.crcOffset attribute shall be 0.c()
[constr_3193] Multiplicity of EndToEndTransformationDescription.offset
in PROFILE_01 and PROFILE_11 dIf the EndToEndTransformationDescrip-
tion.profileName attribute is set to PROFILE_01 or PROFILE_11 then the mul-
tiplicity of the EndToEndTransformationDescription.offset attribute shall be
0.c()

663 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_3194] Multiplicity of EndToEndTransformationDescription.offset

in PROFILE_02, PROFILE_04, PROFILE_05, PROFILE_06, PROFILE_07, PRO-
FILE_08, PROFILE_22, PROFILE_04m, PROFILE_07m, PROFILE_08m, PRO-
FILE_44 and PROFILE_44m dIf the EndToEndTransformationDescription.
profileName attribute is set to a value PROFILE_02, PROFILE_04, PROFILE_05,
PROFILE_06, PROFILE_07, PROFILE_08, PROFILE_22, PROFILE_04m, PRO-
FILE_07m, PROFILE_08m, PROFILE_44 or PROFILE_44m then the multiplicity of the
EndToEndTransformationDescription.offset attribute shall be 1.c()
[constr_3191] Multiplicity of EndToEndTransformationDescription.dataId-
NibbleOffset in PROFILE_01, PROFILE_11 and dataIdMode equal to
lower12Bit dIf the EndToEndTransformationDescription.profileName at-
tribute is set to PROFILE_01 or PROFILE_11 and the value of the EndToEnd-
TransformationDescription.dataIdMode attribute is set to lower12Bit then
the multiplicity of the EndToEndTransformationDescription.dataIdNibble-
Offset attribute shall be 1.c()
[constr_3192] Multiplicity of EndToEndTransformationDescription.dataId-
NibbleOffset in PROFILE_02, PROFILE_04, PROFILE_05, PROFILE_06, PRO-
FILE_07, PROFILE_08, PROFILE_22, PROFILE_04m, PROFILE_07m, PRO-
FILE_08m, PROFILE_44, and PROFILE_44m or dataIdMode different from
lower12Bit dIf the EndToEndTransformationDescription.profileName at-
tribute is set to a value of PROFILE_02, PROFILE_04, PROFILE_05, PROFILE_06,
PROFILE_07, PROFILE_08, PROFILE_22, PROFILE_04m, PROFILE_07m, PRO-
FILE_08m, PROFILE_44, or PROFILE_44m or the EndToEndTransformationDe-
scription.dataIdMode attribute is set to value different from lower12Bit then
the multiplicity of the EndToEndTransformationDescription.dataIdNibble-
Offset attribute shall be 0.c()
[constr_3148] executeDespiteDataUnavailability setting in case an E2E
Transformer is used dA transformer chain using E2E shall be configured with Data-
Transformation.executeDespiteDataUnavailability = TRUE.c()
[constr_3149] TransformationTechnology.needsOriginalData settings for
E2E Transformer dThe TransformationTechnology.needsOriginalData at-
tribute of a TransformationTechnology element of an E2E transformer shall be
set to FALSE.c()
[constr_3151] BufferProperties.headerLength settings for an E2E trans-
former used in combination with a SOME/IP transformer dThe BufferProper-
ties.headerLength for an E2E transformer located in a transformer chain with a
SOME/IP transformer shall be configured with the following values depending on the
value of the EndToEndTransformationDescription.profileName attribute:
1. PROFILE_01: BufferProperties.headerLength = 16 bits
2. PROFILE_02: BufferProperties.headerLength = 16 bits
3. PROFILE_04: BufferProperties.headerLength = 96 bits

664 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4. PROFILE_05: BufferProperties.headerLength = 24 bits

5. PROFILE_06: BufferProperties.headerLength = 40 bits
6. PROFILE_07: BufferProperties.headerLength = 160 bits
7. PROFILE_08: BufferProperties.headerLength = 128 bits
8. PROFILE_11: BufferProperties.headerLength = 16 bits
9. PROFILE_22: BufferProperties.headerLength = 16 bits
10. PROFILE_04m: BufferProperties.headerLength = 128 bits
11. PROFILE_07m: BufferProperties.headerLength = 192 bits
12. PROFILE_08m: BufferProperties.headerLength = 160 bits
13. PROFILE_44: BufferProperties.headerLength = 96 bits
14. PROFILE_44m: BufferProperties.headerLength = 128 bits
c()
This means that the E2E header in profiles 1 and 2 use 2 bytes when using SOME/IP
transformer. This yields four unused bits in case of some recommended configuration
settings of Profile 1 and 2. Those unused bits are set to 0xF by the E2E transformer
on the sender side.
[constr_3153] E2E header field reservation required by COM Based transformer
dA COM Based transformer that is used in a transformer chain with an E2E transformer
requires that the following amount of space is allocated for the E2E header fields using
a proper ISignalGroup layout according to [TPS_SYST_02068]:
PROFILE_01: if dataIdMode == lower12Bit: 16 bits
PROFILE_01: if dataIdMode != lower12Bit: 12 bits
PROFILE_02: 16 bits
PROFILE_04: 96 bits
PROFILE_05: 24 bits
PROFILE_06: 40 bits
PROFILE_07: 160 bits
PROFILE_08: 128 bits
PROFILE_11: if dataIdMode == lower12Bit: 16 bits
PROFILE_11: if dataIdMode == all16Bit: 12 bits
PROFILE_22: 16 bits
PROFILE_04m: 128 bits

665 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

PROFILE_07m: 192 bits

PROFILE_08m: 160 bits
PROFILE_44: 96 bits
PROFILE_44m: 128 bits
c()
[constr_3184] Only one EndToEndTransformationISignalProps.dataId ele-
ment in PROFILE_01 and PROFILE_11 dIf the EndToEndTransformationDe-
scription.profileName attribute has a value of PROFILE_01 or PROFILE_11 then
the multiplicity of the EndToEndTransformationISignalProps.dataId attribute
shall be 1.c()
[constr_3156] Allowed values for EndToEndTransformationISignalProps.
dataId in PROFILE_01 and PROFILE_11 dIf the EndToEndTransformationDe-
scription.profileName attribute has a value of PROFILE_01 or PROFILE_11 then
the value of the EndToEndTransformationISignalProps.dataId attribute shall
be in the range of 0-65535.c()
[constr_3157] Allowed values for EndToEndTransformationISignalProps.
dataId in PROFILE_01 and PROFILE_11 in case dataIdMode is set to
lower12Bit dIf the EndToEndTransformationDescription.profileName at-
tribute has a value of PROFILE_01 or PROFILE_11 and the value of EndToEnd-
TransformationDescription.dataIdMode attribute has a value of lower12Bit
then the value of the EndToEndTransformationISignalProps.dataId attribute
shall be in the range of 256-65535.c()
[constr_3158] Allowed values for EndToEndTransformationDescription.
maxDeltaCounter in PROFILE_01 and PROFILE_11 dIf the EndToEndTransfor-
mationDescription.profileName attribute has a value of PROFILE_01 or PRO-
FILE_11 then the attribute maxDeltaCounter shall be in the range 1-14.c()
[constr_3195] Allowed values for EndToEndTransformationDescription.
maxDeltaCounter in PROFILE_02 and PROFILE_22 dIf the EndToEndTransfor-
mationDescription.profileName attribute has a value of PROFILE_02 or PRO-
FILE_22 then the attribute maxDeltaCounter shall be in the range 1-15.c()
[constr_3159] Allowed values for EndToEndTransformationDescription.
maxDeltaCounter in PROFILE_04, PROFILE_04m PROFILE_44 and PRO-
FILE_44m dIf the EndToEndTransformationDescription.profileName at-
tribute has a value of PROFILE_04, PROFILE_04m, PROFILE_44, or PROFILE_44m
the value of maxDeltaCounter attribute shall be in the range 1-65535.c()
[constr_3196] Allowed values for EndToEndTransformationDescription.
maxDeltaCounter in PROFILE_05 dIf the EndToEndTransformationDescrip-
tion.profileName attribute has a value of PROFILE_05 then the attribute
maxDeltaCounter shall be in the range 1-255.c()

666 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_3197] Allowed values for EndToEndTransformationDescription.

maxDeltaCounter in PROFILE_06 dIf the EndToEndTransformationDescrip-
tion.profileName attribute has a value of PROFILE_06 then the attribute
maxDeltaCounter shall be in the range 1-255.c()
[constr_3316] Allowed values for EndToEndTransformationDescription.
maxDeltaCounter in PROFILE_07, PROFILE_08, PROFILE_07m and PRO-
FILE_08m dIf the EndToEndTransformationDescription.profileName at-
tribute has a value of PROFILE_07, PROFILE_08, PROFILE_07m, or PROFILE_08m
the value of maxDeltaCounter attribute shall be in the range 1-4‘294‘967‘295.c()
[constr_3160] EndToEndTransformationISignalProps.dataId in PRO-
FILE_02 and PROFILE_22 dIf the EndToEndTransformationDescription.
profileName attribute has a value of PROFILE_02 or PROFILE_22 then the multi-
plicity of the dataId attribute shall be 16 and the value of each instance shall be in
the range 0..255.c()
[constr_5220] Multiplicity of EndToEndTransformationISignalProps.sour-
ceId in PROFILE_04m, PROFILE_07m, PROFILE_08m and PROFILE_44m dIf the
EndToEndTransformationDescription.profileName attribute is set to PRO-
FILE_04m, PROFILE_07m, PROFILE_08m, or PROFILE_44m then the multiplicity of
the EndToEndTransformationISignalProps.sourceId attribute shall be 1.c()
[constr_5221] Multiplicity of EndToEndTransformationISignalProps.sour-
ceId in PROFILE_01, PROFILE_02, PROFILE_04, PROFILE_05, PROFILE_06,
PROFILE_07, PROFILE_11, and PROFILE_22 dIf the EndToEndTransformation-
Description.profileName attribute is set to PROFILE_01, PROFILE_02, PRO-
FILE_04, PROFILE_05, PROFILE_06, PROFILE_07, PROFILE_11, or PROFILE_22
then the multiplicity of the EndToEndTransformationISignalProps.sourceId
attribute shall be 0.c()
[constr_3161] EndToEndTransformationISignalProps.dataLength in PRO-
FILE_01, PROFILE_02, PROFILE_05, PROFILE_11, PROFILE_22 dIf the End-
ToEndTransformationDescription.profileName attribute has a value of PRO-
FILE_01, PROFILE_02, PROFILE_05, PROFILE_11, or PROFILE_22 then the mul-
tiplicity of the EndToEndTransformationISignalProps.dataLength attribute
shall be 1.c()
[constr_3162] EndToEndTransformationISignalProps.minDataLength and
EndToEndTransformationISignalProps.maxDataLength in PROFILE_01,
PROFILE_02, PROFILE_05, PROFILE_11, PROFILE_22 dIf the EndToEndTrans-
formationDescription.profileName attribute has a value of PROFILE_01,
PROFILE_02, PROFILE_05, PROFILE_11, or PROFILE_22 then the multiplicity of
the attributes EndToEndTransformationISignalProps.minDataLength and
EndToEndTransformationISignalProps.maxDataLength shall be 0.c()
[constr_3163] EndToEndTransformationISignalProps.minDataLength and
EndToEndTransformationISignalProps.maxDataLength in PROFILE_04,
PROFILE_06, PROFILE_07, PROFILE_08, PROFILE_04m, PROFILE_07m,

667 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

PROFILE_08m, PROFILE_44, and PROFILE_44m dIf the EndToEndTrans-

formationDescription.profileName attribute has a value of PROFILE_04,
PROFILE_06, PROFILE_07, PROFILE_08, PROFILE_04m, PROFILE_07m, PRO-
FILE_08m, PROFILE_44, or PROFILE_44m then the multiplicity of the attributes
EndToEndTransformationISignalProps.minDataLength and EndToEnd-
TransformationISignalProps.maxDataLength shall be 1.c()
[constr_3164] EndToEndTransformationISignalProps.dataLength in PRO-
FILE_04, PROFILE_06, PROFILE_07, PROFILE_08, PROFILE_04m, PRO-
FILE_07m, PROFILE_08m, PROFILE_44 and PROFILE_44m dIf the EndToEnd-
TransformationDescription.profileName attribute has a value of PRO-
FILE_04, PROFILE_06, PROFILE_07, PROFILE_08, PROFILE_04m, PROFILE_07m,
PROFILE_08m, PROFILE_44, or PROFILE_44m then the multiplicity of the attribute
EndToEndTransformationISignalProps.dataLength shall be 0.c()
[constr_3533] EndToEndTransformationISignalProps.dataLength shall be
a multiple of 8 dThe value of EndToEndTransformationISignalProps.dataL-
ength, EndToEndTransformationISignalProps.maxDataLength, and End-
ToEndTransformationISignalProps.minDataLength shall be a multiple of 8.c
()
[constr_3155] Allowed values for EndToEndTransformationDescription.up-
perHeaderBitsToShift dThe value of of the EndToEndTransformationDe-
scription.upperHeaderBitsToShift attribute depends on the used serializing
transformer:
COM based transformer: 0 (no bits are shifted)
SOME/IP transformer: 64 (to support the header shift of SOME/IP).
Custom transformer: no restriction (depends on header length and placement of cus-
tom transformer)
c()
[constr_3165] Effect of EndToEndTransformationDescription.upper-
HeaderBitsToShift value in PROFILE_01, PROFILE_11 dIf the EndToEnd-
TransformationDescription.profileName attribute has a value of PRO-
FILE_01 or PROFILE_11 and the serializing transformer is different than the
ComBasedTransformer then:
1. EndToEndTransformationDescription.crcOffset shall be set to the
same value of upperHeaderBitsToShift.
2. EndToEndTransformationDescription.counterOffset shall be set to
the value of upperHeaderBitsToShift + 8.
3. (if used) EndToEndTransformationDescription.dataIdNibbleOffset
shall be set to the value of upperHeaderBitsToShift + 12.
c()

668 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_3327] Effect of EndToEndTransformationDescription.upper-

HeaderBitsToShift value in PROFILE_22 dIf the EndToEndTransforma-
tionDescription.profileName attribute has a value of PROFILE_22 and the
serializing transformer is different than the ComBasedTransformer, then End-
ToEndTransformationDescription.offset shall be set to the same value of
upperHeaderBitsToShift.c()
This means that the E2E header of profile 1 and profile 11, when used with SOME/IP
Transformer or a Custom Transformer, is not spread across application data, but is
a consecutive block of bytes. The layout flexibility available with these E2E protection
profiles is therefore only supported if the ComBasedTransformer is used in combination
with the E2E Transformer.
[constr_3166] EndToEndTransformationDescription.upperHeaderBit-
sToShift in PROFILE_02 dIf the EndToEndTransformationDescription.
profileName attribute has a value of PROFILE_02 then the value of the upper-
HeaderBitsToShift attribute shall be 0.c()
[constr_3169] EndToEndTransformationDescription.offset value in PRO-
FILE_02 and PROFILE_22 dIf the EndToEndTransformationDescription.pro-
fileName attribute has a value of PROFILE_02 or PROFILE_22 then the value of the
EndToEndTransformationDescription.offset attribute shall be 0.c()
[constr_3167] Effect of EndToEndTransformationDescription.upper-
HeaderBitsToShift value in PROFILE_04, PROFILE_05, PROFILE_06, PRO-
FILE_07, PROFILE_08, PROFILE_04m, PROFILE_07m, PROFILE_08m, PRO-
FILE_44, and PROFILE_44m dIf the EndToEndTransformationDescription.
profileName attribute has a value of PROFILE_04, PROFILE_05, PROFILE_06,
PROFILE_07, PROFILE_08, PROFILE_04m, PROFILE_07m, PROFILE_08m,
PROFILE_44, or PROFILE_44m the value of the EndToEndTransformationDe-
scription.offset attribute shall be equal to the value of the EndToEndTrans-
formationDescription.upperHeaderBitsToShift attribute.c()
[TPS_SYST_02194] Identification of E2E protected data in case of PROFILE_04,
PROFILE_05, PROFILE_06, PROFILE_07, PROFILE_08, PROFILE_04m, PRO-
FILE_07m, PROFILE_08m, PROFILE_44, and PROFILE_44m dIf the EndToEnd-
TransformationDescription.profileName attribute has a value of PPRO-
FILE_04, PROFILE_05, PROFILE_06, PROFILE_07, PROFILE_08, PROFILE_04m,
PROFILE_07m, PROFILE_08m, PROFILE_44m or PROFILE_44 the E2E protected
data is identified by a EndToEndTransformationISignalProps.dataId.c()
In other words if a SystemSignal defines the E2E protected data and a fanout is
described by several ISignals that point to this SystemSignal, the dataId in each
of those ISignals may have the same value.
[constr_3172] Effect of EndToEndTransformationDescription.profileBe-
havior value in PROFILE_01 dIf the EndToEndTransformationDescription.
profileName attribute has a value of PROFILE_01 and the value of the profile-
Behavior attribute is R4_2 then:

669 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• the value of the EndToEndTransformationDescription.maxNoNewOrRe-

peatedData attribute shall be 14.
• the value of the EndToEndTransformationDescription.syncCoun-
terInit attribute shall be 1.
c()
[constr_3173] Effect of EndToEndTransformationDescription.profileBe-
havior value in PROFILE_02 dIf the EndToEndTransformationDescription.
profileName attribute has a value of PROFILE_02 and the value of the profile-
Behavior attribute is R4_2 then:
• the value of the EndToEndTransformationDescription.maxNoNewOrRe-
peatedData attribute shall be 15.
• the value of the EndToEndTransformationDescription.syncCoun-
terInit attribute shall be 1.
c()
[constr_3174] EndToEndTransformationDescription settings not allowed
in PROFILE_04, PROFILE_05, PROFILE_06, PROFILE_07, PROFILE_08, PRO-
FILE_11, PROFILE_22, PROFILE_04m, PROFILE_07m, PROFILE_08m, PRO-
FILE_44 and PROFILE_44m dIf the EndToEndTransformationDescription.
profileName attribute has a value of PROFILE_04, PROFILE_05, PROFILE_06,
PROFILE_07, PROFILE_08, PROFILE_11, PROFILE_22, PROFILE_04m, PRO-
FILE_07m, PROFILE_08m, PROFILE_44 or PROFILE_44m then:
1. the multiplicity of the EndToEndTransformationDescription.
maxNoNewOrRepeatedData attribute shall be 0.
2. the multiplicity of the EndToEndTransformationDescription.syncCoun-
terInit attribute shall be 0.
3. the multiplicity of the EndToEndTransformationDescription.profileBe-
havior attribute shall be 0.
c()
The EndToEndTransformationDescription may be differently chosen for a given
ISignal or ISignalGroup depending on selected variant, with the following excep-
tions:
[constr_3182] Restriction on TransformationTechnology.transformation-
Description VariationPoint dThe EndToEndTransformationDescription.
profileName attribute shall not be subject to variability for a given ISignal / ISig-
nalGroup, i.e., the value of the EndToEndTransformationDescription.pro-
fileName attribute shall be the same in all different variants.c()
In other words, it is not possible that in one variant PROFILE_04 is used, and in another
variant PROFILE_05 is used for the same ISignal or ISignalGroup.

670 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

7.3.4.1 E2E state machine settings

E2E state machine settings are set in EndToEndTransformationDescription

and a subset of them can be overridden in EndToEndTransformationCom-
SpecProps. The E2E state machine is described in more detail in the E2E Protocol
specification [40].
Please note that the configuration of the E2E state machines with the configuration at-
tributes available in EndToEndTransformationDescription is restricted by [con-
str_3176], [constr_3177], [constr_3178], [constr_3179], [constr_3180], [constr_3181]
defined in [40].

7.3.4.2 E2E recommended configuration settings

This chapter provides different configuration settings for particular E2E Profiles. Please
note that in future additional recommended configuration settings might be added.

7.3.4.2.1 E2E Profile 1 configuration setting C

Caveat: The E2E wrapper approach involves technologies that are not subjected to
the AUTOSAR standard and is superseded by the superior E2E transformer approach
(which is fully standardized by AUTOSAR). Hence, new projects (without legacy con-
straints due to carry-over parts) shall use the fully standardized E2E transformer ap-
proach.
The E2E Profile 1 configuration setting C is foreseen for CAN/FlexRay messages
that are serialized by the COM based transformer and should be used with RTE
event-based communication, i.e. queued communication with queue size = 1, using
Rte_Send / Rte_Receive.
[TPS_SYST_02069] Recommended configuration settings for E2E Profile 1 con-
figuration setting C dThe recommended configuration settings for E2E Profile 1 con-
figuration setting C are defined in Table 7.31.c(RS_SYST_00056)

Attribute Allowed value Comment

EndToEndTransformationDescription.profileName PROFILE_01 Profile 1
EndToEndTransformationDescription.crcOffset 0 CRC offset
EndToEndTransformationDescription.counterOffset 8 Counter offset
EndToEndTransformationDescription.dataIdNibble- 12 Data Id high nibble offset
Offset
EndToEndTransformationDescription.maxDelta- 2 Maximum jump considered to be OK is
Counter 2, i.e. one lost message.
EndToEndTransformationDescription.minOk- 1 At least one OK message
StateInit
EndToEndTransformationDescription.maxEr- 1 One error allowed
rorStateInit
EndToEndTransformationDescription.windowSize- 3 Last 3 messages are considered
Valid

671 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Attribute Allowed value Comment

EndToEndTransformationDescription.windowSizeIn- 3 Last 3 messages are considered
valid
EndToEndTransformationDescription.window- 2 Last 2 messages are considered
SizeInit
EndToEndTransformationDescription.minOkState- 1 At least one OK message
Valid
EndToEndTransformationDescription.maxErrorStat- 1 One error allowed
eValid
EndToEndTransformationDescription.minOkStateIn- 2 At least two OK messages
valid
EndToEndTransformationDescription.maxEr- 1 One error allowed
rorStateInvalid
EndToEndTransformationDescription.upperHeader- 0 no bits are shifted
BitsToShift
BufferProperties.headerLength 16 16 bits is the length of E2E profile 1C
header.
EndToEndTransformationDescription.profileBehav- R4_2 Behavior of Profile P1 adjusted for the
ior state machine.
EndToEndTransformationDescription.maxNoNewOrRe- 14 Behavior of Profile P1 adjusted for the
peatedData state machine.
EndToEndTransformationDescription.syncCoun- 1 Behavior of Profile P1 adjusted for the
terInit state machine.

Table 7.31: Configuration of E2E Profile 1 configuration setting C

7.3.4.2.2 E2E Profile 4 configuration setting A

The E2E Profile 4 configuration setting A is foreseen for long messages that are seri-
alized by the SOME/IP transformer. The configuration setting 4A should be used with
RTE event-based communication, i.e. queued communication with queue size = 1,
using Rte_Send / Rte_Receive.
This configuration setting is quite strict as it does not allow any errors, i.e.:
1. Repetitions
2. Counter jumps bigger than 1.
3. Errors not related to counters (e.g. CRC, data ID, length)
As soon as any error is detected, there is a transition to invalid state.
[TPS_SYST_02070] Recommended configuration settings for E2E Profile 4 con-
figuration setting A dThe recommended configuration settings for E2E Profile 4 con-
figuration setting A are defined in Table 7.32.c(RS_SYST_00056)

Attribute Allowed value Comment

EndToEndTransformationDescription.profileName PROFILE_04 Profile 4
EndToEndTransformationDescription.offset 64 To support the fixed location of Some/IP
header
EndToEndTransformationDescription.maxDelta- 1 Maximum jump considered to be OK is
Counter 1
EndToEndTransformationDescription.minOk- 1 received message shall be OK.
StateInit

672 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Attribute Allowed value Comment

EndToEndTransformationDescription.maxEr- 0 No errors allowed
rorStateInit
EndToEndTransformationDescription.windowSize- 1 Only the last message is considered
Valid
EndToEndTransformationDescription.windowSizeIn- 1 Only the last message is considered
valid
EndToEndTransformationDescription.window- 2 The two last messages are considered
SizeInit
EndToEndTransformationDescription.minOkState- 1 received message shall be OK.
Valid
EndToEndTransformationDescription.maxErrorStat- 0 No errors allowed
eValid
EndToEndTransformationDescription.minOkStateIn- 1 received message shall be OK.
valid
EndToEndTransformationDescription.maxEr- 0 No errors allowed
rorStateInvalid
EndToEndTransformationDescription.upperHeader- 64 64 bits from Some/IP header to be
BitsToShift shifted
BufferProperties.headerLength 96 96 bits is the length of E2E profile 4
header.

Table 7.32: Configuration of E2E configuration setting 4A

7.3.4.2.3 E2E Profile 4 configuration setting B

The E2E Profile 4 configuration setting B is foreseen for long messages that are seri-
alized by the SOME/IP transformer. The configuration setting 4B should be used with
RTE event-based communication, i.e. queued communication with queue size = 1,
using Rte_Send / Rte_Receive.
This configuration setting requires having within the monitoring window the following
properties:
1. At least one OK message
2. At most one error not related to counters (e.g. CRC, data ID, length)
3. the remaining data in the monitoring window may be
• repetitions or
• jumps above 1.
As soon as any error is detected, there is a transition to invalid state.
[TPS_SYST_02071] Recommended configuration settings for E2E Profile 4 con-
figuration setting B dThe recommended configuration settings for E2E Profile 4 con-
figuration setting B are defined in Table 7.33.c(RS_SYST_00056)

Attribute Allowed value Comment

EndToEndTransformationDescription.profileName PROFILE_04 Profile 4
EndToEndTransformationDescription.offset 64 To support the fixed location of Some/IP
header

673 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Attribute Allowed value Comment

EndToEndTransformationDescription.maxDelta- 2 Maximum jump considered to be OK is
Counter 2, i.e. one lost message
EndToEndTransformationDescription.minOk- 1 At least one OK message
StateInit
EndToEndTransformationDescription.maxEr- 1 One error allowed
rorStateInit
EndToEndTransformationDescription.windowSize- 3 Last 3 messages are considered
Valid
EndToEndTransformationDescription.windowSizeIn- 3 Last 3 messages are considered
valid
EndToEndTransformationDescription.window- 2 Last 2 messages are considered
SizeInit
EndToEndTransformationDescription.minOkState- 1 At least one OK message
Valid
EndToEndTransformationDescription.maxErrorStat- 1 One error allowed
eValid
EndToEndTransformationDescription.minOkStateIn- 2 At least two OK messages
valid
EndToEndTransformationDescription.maxEr- 1 One error allowed
rorStateInvalid
EndToEndTransformationDescription.upperHeader- 64 64 bits from Some/IP header to be
BitsToShift shifted
BufferProperties.headerLength 96 96 bits is the length of E2E profile 4
header.

Table 7.33: Configuration of E2E Profile 4 configuration setting B

7.3.4.2.4 E2E Profile 7 configuration setting A

The E2E Profile 7 configuration setting A is foreseen for long messages (up to 4 MB)
that are serialized by the SOME/IP transformer.
This configuration setting is quite strict as it does not allow any errors, i.e.:
1. Repetitions
2. Counter jumps bigger than 1.
3. Errors not related to counters (e.g. CRC, data ID, length)
As soon as any error is detected, there is a transition to invalid state.
[TPS_SYST_02134] Recommended configuration settings for E2E Profile 7 con-
figuration setting A dThe recommended configuration settings for E2E Profile 7 con-
figuration setting A are defined in Table 7.34.c(RS_SYST_00056)

Attribute Allowed value Comment

EndToEndTransformationDescription.profileName PROFILE_07 Profile 7
EndToEndTransformationDescription.offset 64 To support the fixed location of Some/IP
header
EndToEndTransformationDescription.maxDelta- 1 Maximum jump considered to be OK is
Counter 1
EndToEndTransformationDescription.minOk- 1 received message shall be OK.
StateInit

674 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Attribute Allowed value Comment

EndToEndTransformationDescription.maxEr- 0 No errors allowed
rorStateInit
EndToEndTransformationDescription.windowSize- 1 Only the last message is considered
Valid
EndToEndTransformationDescription.windowSizeIn- 1 Only the last message is considered
valid
EndToEndTransformationDescription.window- 2 Only the last two messages are
SizeInit considered
EndToEndTransformationDescription.minOkState- 1 received message shall be OK.
Valid
EndToEndTransformationDescription.maxErrorStat- 0 No errors allowed
eValid
EndToEndTransformationDescription.minOkStateIn- 1 received message shall be OK.
valid
EndToEndTransformationDescription.maxEr- 0 No errors allowed
rorStateInvalid
EndToEndTransformationDescription.upperHeader- 64 64 bits from Some/IP header to be
BitsToShift shifted
BufferProperties.headerLength 160 160 bits is the length of E2E profile 7
header.

Table 7.34: Configuration of E2E Profile 7 configuration setting A

7.3.4.2.5 E2E Profile 7 configuration setting B

The E2E Profile 7 configuration setting B is foreseen for long messages (up to 4 MB)
that are serialized by the SOME/IP transformer.
This configuration setting requires having within the monitoring window the following
properties:
1. At least one OK message
2. At most one error not related to counters (e.g. CRC, data ID, length)
3. the remaining data in the monitoring window may be
• repetitions or
• jumps above 1.
As soon as any error is detected, there is a transition to invalid state.
[TPS_SYST_02135] Recommended configuration settings for E2E Profile 7 con-
figuration setting B dThe recommended configuration settings for E2E Profile 7 con-
figuration setting B are defined in Table 7.35.c(RS_SYST_00056)

Attribute Allowed value Comment

EndToEndTransformationDescription.profileName PROFILE_07 Profile 7
EndToEndTransformationDescription.offset 64 To support the fixed location of Some/IP
header
EndToEndTransformationDescription.maxDelta- 2 Maximum jump considered to be OK is
Counter 2, i.e. one lost message
EndToEndTransformationDescription.minOk- 1 At least one OK message
StateInit

675 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Attribute Allowed value Comment

EndToEndTransformationDescription.maxEr- 1 One error allowed
rorStateInit
EndToEndTransformationDescription.windowSize- 3 Last 3 messages are considered
Valid
EndToEndTransformationDescription.windowSizeIn- 3 Last 3 messages are considered
valid
EndToEndTransformationDescription.window- 2 Last 2 messages are considered
SizeInit
EndToEndTransformationDescription.minOkState- 1 At least one OK message
Valid
EndToEndTransformationDescription.maxErrorStat- 1 One error allowed
eValid
EndToEndTransformationDescription.minOkStateIn- 2 At least two OK messages
valid
EndToEndTransformationDescription.maxEr- 1 One error allowed
rorStateInvalid
EndToEndTransformationDescription.upperHeader- 64 64 bits from Some/IP header to be
BitsToShift shifted
BufferProperties.headerLength 160 160 bits is the length of E2E profile 7
header.

Table 7.35: Configuration of E2E Profile 7 configuration setting B

7.3.4.2.6 E2E Profile 11 configuration setting C

The E2E Profile 11 configuration setting C is foreseen for CAN/FlexRay messages

that are serialized by the COM based transformer and should be used with RTE
event-based communication, i.e. queued communication with queue size = 1, using
Rte_Send / Rte_Receive.
[TPS_SYST_02155] Recommended configuration settings for E2E Profile 11 con-
figuration setting C dThe recommended configuration settings for E2E Profile 11 con-
figuration setting C are defined in Table 7.36.c(RS_SYST_00056)

Attribute Allowed value Comment

EndToEndTransformationDescription.profileName PROFILE_11 Profile 11
EndToEndTransformationDescription.crcOffset 0 CRC offset
EndToEndTransformationDescription.counterOffset 8 Counter offset
EndToEndTransformationDescription.dataIdNibble- 12 Data Id high nibble offset
Offset
EndToEndTransformationDescription.maxDelta- 2 Maximum jump considered to be OK is
Counter 2, i.e. one lost message.
EndToEndTransformationDescription.minOk- 1 At least one OK message
StateInit
EndToEndTransformationDescription.maxEr- 1 One error allowed
rorStateInit
EndToEndTransformationDescription.windowSize- 3 Last 3 messages are considered
Valid
EndToEndTransformationDescription.windowSizeIn- 3 Last 3 messages are considered
valid
EndToEndTransformationDescription.window- 2 Last 2 messages are considered
SizeInit
EndToEndTransformationDescription.minOkState- 1 At least one OK message
Valid

676 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Attribute Allowed value Comment

EndToEndTransformationDescription.maxErrorStat- 1 One error allowed
eValid
EndToEndTransformationDescription.minOkStateIn- 2 At least two OK messages
valid
EndToEndTransformationDescription.maxEr- 1 One error allowed
rorStateInvalid
EndToEndTransformationDescription.upperHeader- 0 no bits are shifted
BitsToShift
BufferProperties.headerLength 16 16 bits is the length of E2E profile 1C
header.

Table 7.36: Configuration of E2E Profile 11 configuration setting C

7.3.4.2.7 E2E Profile 4m configuration setting A

The E2E Profile 4m configuration setting A is foreseen for long messages that are
serialized by e.g. the SOME/IP transformer.
This configuration setting is quite strict as it does not allow any errors, i.e.:
1. Repetitions
2. Counter jumps bigger than 1 at the source side
3. Errors not related to counters (e.g. CRC, data ID, length)
As soon as any error is detected, there is a transition to invalid state.
[TPS_SYST_02349] Recommended configuration settings for E2E Profile 4m
configuration setting A dThe recommended configuration settings for E2E Profile
4m configuration setting A are defined in Table 7.37.c(RS_SYST_00056)

Attribute Allowed value Comment

EndToEndTransformationDescription.profileName PROFILE_04m Profile 4m
EndToEndTransformationDescription.offset 0 Header added by the serializing
transformer (e.g., SOME/IP
transformer) is not included in CRC
calculation
EndToEndTransformationDescription.maxDelta- 1 Maximum jump considered to be OK is
Counter - source (client) 1 for the source side
EndToEndTransformationDescription.maxDelta- 216 − 1 No counter-based checks on the sink
Counter - sink (server) side
EndToEndTransformationDescription.minOk- 1 received message shall be OK.
StateInit
EndToEndTransformationDescription.maxEr- 0 No errors allowed
rorStateInit
EndToEndTransformationDescription.windowSize- 1 Only the last message is considered
Valid
EndToEndTransformationDescription.windowSizeIn- 1 Only the last message is considered
valid
EndToEndTransformationDescription.window- 2 The two last messages are considered
SizeInit
EndToEndTransformationDescription.minOkState- 1 received message shall be OK.
Valid
EndToEndTransformationDescription.maxErrorStat- 0 No errors allowed
eValid

677 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Attribute Allowed value Comment

EndToEndTransformationDescription.minOkStateIn- 1 received message shall be OK.
valid
EndToEndTransformationDescription.maxEr- 0 No errors allowed
rorStateInvalid
EndToEndTransformationDescription.upperHeader- x depends on the length of the header
BitsToShift added by the serializing transformer
(e.g., 64 in case of the SOME/IP
transformer)
BufferProperties.headerLength 128 128 bits is the length of E2E profile 4m
header.

Table 7.37: Configuration of E2E Profile 4m configuration setting A

Please note that the ISignal that represents the ClientServerOperation re-
quest shall refer an EndToEndTransformationDescription that defines the
maxDeltaCounter for the sink. The ISignal that represents the ClientServer-
Operation response shall refer an EndToEndTransformationDescription that
defines the maxDeltaCounter for the source.

7.3.4.2.8 E2E Profile 7m configuration setting A

The E2E Profile 7m configuration setting A is foreseen for long messages (up to 4 MB)
that are serialized by e.g. the SOME/IP transformer.
This configuration setting is quite strict as it does not allow any errors, i.e.:
1. Repetitions
2. Counter jumps bigger than 1 at the source side
3. Errors not related to counters (e.g. CRC, data ID, length)
As soon as any error is detected, there is a transition to invalid state.
[TPS_SYST_02350] Recommended configuration settings for E2E Profile 7m
configuration setting A dThe recommended configuration settings for E2E Profile
7m configuration setting A are defined in Table 7.38.c(RS_SYST_00056)

Attribute Allowed value Comment

EndToEndTransformationDescription.profileName PROFILE_07m Profile 7m
EndToEndTransformationDescription.offset 0 Header added by the serializing
transformer (e.g., SOME/IP
transformer) is not included in CRC
calculation
EndToEndTransformationDescription.maxDelta- 1 Maximum jump considered to be OK is
Counter - source (client) 1 for the source side
EndToEndTransformationDescription.maxDelta- 232 − 1 No counter-based checks on the sink
Counter - sink (server) side
EndToEndTransformationDescription.minOk- 1 received message shall be OK.
StateInit
EndToEndTransformationDescription.maxEr- 0 No errors allowed
rorStateInit
EndToEndTransformationDescription.windowSize- 1 Only the last message is considered
Valid

678 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Attribute Allowed value Comment

EndToEndTransformationDescription.windowSizeIn- 1 Only the last message is considered
valid
EndToEndTransformationDescription.window- 2 Only the last two messages are
SizeInit considered
EndToEndTransformationDescription.minOkState- 1 received message shall be OK.
Valid
EndToEndTransformationDescription.maxErrorStat- 0 No errors allowed
eValid
EndToEndTransformationDescription.minOkStateIn- 1 received message shall be OK.
valid
EndToEndTransformationDescription.maxEr- 0 No errors allowed
rorStateInvalid
EndToEndTransformationDescription.upperHeader- x depends on the length of the header
BitsToShift added by the serializing transformer
(e.g., 64 in case of the SOME/IP
transformer)
BufferProperties.headerLength 192 192 bits is the length of E2E profile 7m
header.

Table 7.38: Configuration of E2E Profile 7m configuration setting A

679 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

7.3.5 UserDefined Transformer

Autosar allows to describe custom Transformers that are not standardized by

AUTOSAR. This is done by the usage of the following elements:
• UserDefinedTransformationDescription
• UserDefinedTransformationISignalProps
• UserDefinedTransformationProps
Identifiable
TransformationTechnology

+ hasInternalState: Boolean [0..1]

+ needsOriginalData: Boolean [0..1]
+ protocol: String
+ transformerClass: TransformerClassEnum
+ version: String

+transformer 1

«atpVariation»
FibexElement
+transformationDescription 0..1
ISignal
Describable
+ dataTypePolicy: DataTypePolicyEnum
TransformationDescription
+ iSignalType: ISignalTypeEnum [0..1]
+ length: UnlimitedInteger

+transformationISignalProps 0..*

Describable
UserDefinedTransformationDescription
«atpVariation»
TransformationISignalProps

+ csErrorReaction: CSTransformerErrorReactionEnum [0..1]

UserDefinedTransformationProps

+dataPrototypeTransformationProps 0..*
Identifiable
UserDefinedTransformationISignalProps DataPrototypeTransformationProps +transformationProps
TransformationProps
0..1

Figure 7.22: User Defined Transformation configuration

Please note that all these UserDefined classes are Identifiable or Describable
and therefore are able to describe special data (sdg) which is not represented by the
standard model.
Class <<atpVariation>> UserDefinedTransformationISignalProps
Package M2::AUTOSARTemplates::SystemTemplate::Transformer
Note The UserDefinedTransformationISignalProps is used to specify ISignal specific configuration properties
for custom transformers.
Base ARObject, Describable, TransformationISignalProps
Attribute Type Mult. Kind Note
– – – – –
Table 7.39: UserDefinedTransformationISignalProps

680 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class UserDefinedTransformationProps
Package M2::AUTOSARTemplates::SystemTemplate::Transformer
Note The class UserDefinedTransformationProps specifies specific configuration properties of a user defined
serializer.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable, TransformationProps
Attribute Type Mult. Kind Note
– – – – –
Table 7.40: UserDefinedTransformationProps

7.3.6 Support for TLV Encoding

AUTOSAR supports the usage of the so-called Tag-Length-Value (TLV) encoding. The
following sub-sections explain the details and the extent of the support for TLV encod-
ing.

7.3.6.1 Assignment of TLV Data Ids

[TPS_SYST_05016] Assignment of TLV data ids dThe assignment of TLV data ids
is done in the context of the specification of SOMEIPTransformationISignal-
Props, namely by means of the attribute SOMEIPTransformationISignalProps.
tlvDataIdDefinition.tlvDataIdDefinition.id.c(RS_SYST_00058)
This approach takes benefit from the fact that the TlvDataIdDefinition is able to
create references to relevant model elements.
The assignment of the TLV data id is therefore done by creating such a reference and
assigning a TLV data id to it by means of the attribute TlvDataIdDefinition.id.
Please note that the assignment of TLV data ids is compulsory for an entire data struc-
ture that has at least one optional member. In a nutshell, this conclusion (that is also
backed by [PRS_SOMEIP_00230], see [19]) is the motivation for the existence of [con-
str_1641] and [constr_1642].
Please note further that the assignment of TLV data ids is not restricted to data struc-
tures with optional members. There is also a use case to support sending the elements
of a specific data structure in arbitrary order even if none of the elements is considered
optional.
Moreover, TLV data ids can also be assigned to arguments of a ClientServerOp-
eration. Using TLV data ids for arguments supports that arguments can be sent in
arbitrary order and that new arguments can be added at arbitrary positions during the
evolution of the interface. Note that optional arguments are not supported.
[TPS_SYST_02378] Optional method arguments dAUTOSAR Classic platform does
not support the existence of optional method arguments.c()

681 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

The reason for the restriction in [TPS_SYST_02378] is that the RTE does not have an
API to handle optional method arguments.
TransformationISignalProps ARElement
SOMEIPTransformationISignalProps +tlvDataIdDefinition TlvDataIdDefinitionSet

+ implementsLegacyStringSerialization: Boolean [0..1] 0..*

0..* +tlvDataIdDefinition
AutosarDataPrototype
TlvDataIdDefinition
ArgumentDataPrototype +tlvArgument

0..1 «atpIdentityContributor»
+ direction: ArgumentDirectionEnum [0..1]
+ id: PositiveInteger
+ serverArgumentImplPolicy: ServerArgumentImplPolicyEnum [0..1]

ApplicationCompositeElementDataPrototype
+tlvRecordElement
ApplicationRecordElement
0..1
+ isOptional: Boolean [0..1]

AtpStructureElement
Identifiable +tlvImplementationDataTypeElement
AbstractImplementationDataTypeElement
0..1

Figure 7.23: Definition of data ids for the TLV encoding inside a SOME/IP message

To sum it up: the usage of TLV data ids and optional members are two different fea-
tures. Optional members require the usage of TLV data ids, but TLV data ids can also
be used without having optional members.
Class TlvDataIdDefinitionSet
Package M2::AUTOSARTemplates::SystemTemplate::Transformer
Note This meta-class acts as a container of TlvDataIdDefinitions to be used in a given context
Tags:atp.recommendedPackage=TlvDataDefinitionSets
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
tlvDataId TlvDataIdDefinition * aggr This aggregation represents the collection of TlVDataTid
Definition Definitions aggregated by the TlvDataIdDefinitionSet
Stereotypes: atpSplitable
Tags:atp.Splitkey=tlvDataIdDefinition.id

Table 7.41: TlvDataIdDefinitionSet

Class TlvDataIdDefinition
Package M2::AUTOSARTemplates::SystemTemplate::Transformer
Note This meta-class represents the ability to define the tlvDataId.
Base ARObject
Attribute Type Mult. Kind Note
id PositiveInteger 1 attr This attribute represents the definition of the value of the
TlvDataId
Stereotypes: atpIdentityContributor
5

682 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class TlvDataIdDefinition
tlvArgument ArgumentDataPrototype 0..1 ref This reference assigns a tlvDataId to a given argument of
a ClientServerOperation.
tlv AbstractImplementation 0..1 ref This reference associates the definition of a TLV data id
Implementation DataTypeElement with a given AbstractImplementationDataTypeElement.
DataType
Element
tlvRecord ApplicationRecord 0..1 ref This reference associates the definition of a TLV data id
Element Element with a given ApplicationRecordElement.

Table 7.42: TlvDataIdDefinition

[TPS_SYST_02211] Reference from SOMEIPTransformationISignalProps to

TlvDataIdDefinitionSet dThe reference from SOMEIPTransformationISig-
nalProps to TlvDataIdDefinitionSet means that it is in the hand of the creator
of a model to decide whether a global scope should be assumed or whether the defi-
nition needs to be customized for a specific case.c(RS_SYST_00058)
[constr_1641] Consistent assignment of TLV data ids to ApplicationRecord-
DataType dFor every ApplicationRecordDataType where direct members set the
attribute ApplicationRecordElement.isOptional to the value True references
to all direct members of this ApplicationRecordDataType shall be created on the
basis of the definition of TlvDataIdDefinition.c()
[constr_1642] Consistent assignment of TLV data ids to Implementation-
DataType or ImplementationDataTypeElement dFor every Implementa-
tionDataType or ImplementationDataTypeElement of category STRUCTURE
where direct members set the attribute ImplementationDataTypeElement.isOp-
tional to the value True references to all direct members of this Implementation-
DataType resp ImplementationDataTypeElement shall be created on the basis
of the definition of TlvDataIdDefinition.c()
The definition of a TlvDataIdDefinition that refers to an eligible model element
is not limited to scenarios where optional elements are defined. It is also possible to
define TlvDataIdDefinition for arbitrary methods or data structures.
A typical use case could be to prepare the argument list or sub-elements for future
extensions. However, if one argument or sub-element is referenced then it is necessary
to define references from TlvDataIdDefinitions to all other arguments or sub-
elements as well.
[constr_5111] Existence of references TlvDataIdDefinition.tlvArgument,
TlvDataIdDefinition.tlvRecordElement, and TlvDataIdDefinition.
tlvImplementationDataTypeElement dFor each TlvDataIdDefinition, only
one out of the following references shall exist:
• reference to ArgumentDataPrototype in the role tlvArgument
• reference to ApplicationRecordElement in the role tlvRecordElement

683 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• reference to ImplementationDataTypeElement in the role tlvImplemen-

tationDataTypeElement.
c()
[constr_1643] Completeness of the existence of a set of TlvDataIdDefinition.
tlvArguments dIf the reference TlvDataIdDefinition.tlvArguments exists for
one argument of a given ClientServerOperation then further TlvDataIdDef-
inition.tlvArguments shall exist for all arguments of the given ClientServer-
Operation and all affected TlvDataIdDefinitions shall be referenced by the
same SOMEIPTransformationISignalProps via TlvDataIdDefinitionSet.c
()
[constr_1644] Completeness of the existence of a set of TlvDataIdDefinition.
tlvRecordElements dIf the reference TlvDataIdDefinition.tlvRecordEle-
ment exists for one element of a given ApplicationRecordDataType then further
TlvDataIdDefinition.tlvRecordElement shall exist for all elements of the given
ApplicationRecordDataType and all affected TlvDataIdDefinitions shall be
referenced by the same SOMEIPTransformationISignalProps via TlvDataId-
DefinitionSet.c()
[constr_1645] Completeness of the existence of a set of TlvDataIdDefinition.
tlvImplementationDataTypeElements dCompleteness of the existence of a set
of TlvDataIdDefinition.tlvImplementationDataTypeElements If the refer-
ence TlvDataIdDefinition.tlvImplementationDataTypeElement exists for
one subElement of a given ImplementationDataType or Implementation-
DataTypeElement then further TlvDataIdDefinition.tlvImplementation-
DataTypeElement shall exist for all subElements of the given Implementation-
DataType or ImplementationDataTypeElement and all affected TlvDataId-
Definitions shall be referenced by the same SOMEIPTransformationISignal-
Props via TlvDataIdDefinitionSet.c()
The definition of a TlvDataIdDefinition.id has the purpose to provide means to
unambiguously identify the argument or sub-element. For this purpose, the value of
the id needs to be unique in the respective context.
[constr_1646] Scope of the uniqueness of the value of TlvDataIdDefinition.
id for references to ArgumentDataPrototype dFor all TlvDataIdDefinition
that are referencing ArgumentDataPrototypes of a given ClientServerOpera-
tion in the role tlvArgument the attribute TlvDataIdDefinition.id shall exist
and have a unique value in the context of respective arguments of the enclosing
ClientServerOperation where attribute direction is set to the value in/inout
or out/inout.
Note: an argument where attribute direction is set to the value in may have the
same data id as an argument where attribute direction is set to the value out
since the two are transferred in separate messages.c()

684 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_1647] Scope of the uniqueness of the value of TlvDataIdDefinition.

id for references to ApplicationRecordElement dFor all TlvDataIdDefini-
tion that are referencing ApplicationRecordElements of a given Applica-
tionDataType in the role tlvRecordElement the attribute TlvDataIdDefini-
tion.id shall exist and have a unique value in the context of respective enclosing
ApplicationRecordDataType.c()
[constr_1648] Scope of the uniqueness of the value of TlvDataIdDefini-
tion.id for references to ImplementationDataTypeElement dFor all Tlv-
DataIdDefinition that are referencing ImplementationDataTypeElements of
a given ImplementationDataType/ImplementationDataTypeElement in the
role tlvImplementationDataTypeElement the attribute TlvDataIdDefini-
tion.id shall exist and have a unique value in the context of respective enclosing
ImplementationDataType or ImplementationDataTypeElement.c()
Obviously, it is necessary to avoid ambiguity with respect to the definition of TLV data
ids. Each model element that can be assigned such an id shall only be assigned one
id.
[constr_1649] TlvDataIdDefinition referencing ArgumentDataPrototype
dEach ArgumentDataPrototype shall be referenced at most once in the role tl-
vArgument in the context of the same SOMEIPTransformationISignalProps.c
()
[constr_1650] TlvDataIdDefinition referencing ApplicationRecordEle-
ment dEach ApplicationRecordElement shall be referenced at most once in
the role tlvRecordElement in the context of the same SOMEIPTransformation-
ISignalProps.c()
[constr_1651] TlvDataIdDefinition referencing ImplementationDataType-
Element dEach ImplementationDataTypeElement shall be referenced at most
once in the role tlvImplementationDataTypeElement in the context of the same
SOMEIPTransformationISignalProps.c()
As depicted in Figure 7.23, the meta-model supports the TlvDataIdDefinition to
refer both to an ApplicationRecordElement as well as an Implementation-
DataTypeElement.
In a typical case either the one or the other reference will be used and there is inten-
tionally no constraint to explicitly use both references in a concrete model.
It would mean a significant markup in real-world AUTOSAR models to explicitly require
that TlvDataIdDefinitions shall exist that assign concrete ids to both a given Ap-
plicationRecordDataType as well as the mapped ImplementationDataType.
However, scenarios are conceivable that the assignment of TLV data ids may be done
based on ApplicationDataType plus networkRepresentationProps on one
end of the communication and based on ImplementationDataType on the other
end.

685 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

In this case, a constraint to keep TLV data ids in sync between Application-
DataType and ImplementationDataType would not even be helpful because ei-
ther side might not know about the actual data type used as the basis of the creation
of the Transformer at the other end.
Nevertheless, if both an ApplicationDataType and the mapped Implementa-
tionDataType are annotated with TLV data Ids within the same model then the as-
sociated values shall obviously be identical for corresponding sub-elements.

7.3.6.2 Assignment of TLV Wire Type

The TLV encoding supports the definition of a so-called wire type that controls how
the information about the length of length fields shall be interpreted. The meaning of
specific settings of the wire type is defined in [19].
[TPS_SYST_05017] Definition of the applicable wire type attribute SOMEIP-
TransformationISignalProps.isDynamicLengthFieldSize shall be used to
define the applicable wire type dIf the value of attribute SOMEIPTransformation-
ISignalProps.isDynamicLengthFieldSize is set to True then wire type 5-7
shall be used.
If the value of attribute SOMEIPTransformationISignalProps.isDynami-
cLengthFieldSize does not exist or is set to False then wire type 4 shall be used.c
(RS_SYST_00058)
[constr_1652] Definition of static length fields sizes in case of TLV usage
dIf TlvDataIdDefinitions are defined for a SOMEIPTransformationISig-
nalProps, the attributes sizeOfArrayLengthFields, sizeOfStructLength-
Fields, sizeOfStringLengthFields and sizeOfUnionLengthFields shall
be greater than 0.c()
Rationale for the existence of [constr_1652]: The TLV serialization requires the usage
of length fields. If wire type 4 is used the length field size shall be statically configured.
If wire types 5-7 (dynamic length field size) are used the static configuration of the
length field size shall also be present since not all length fields are preceded by a tag,
e.g. structures contained in an array or the top-level struct contained in a SOME/IP
event. Not using length fields here would result in ambiguities.
[constr_1653] Identical values for length fields sizes in case of TLV usage
dIf TlvDataIdDefinitions are defined for a SOMEIPTransformationISig-
nalProps, the attributes sizeOfArrayLengthFields, sizeOfStructLength-
Fields, sizeOfStringLengthFields and sizeOfUnionLengthFields shall
have an identical value.c()
Rationale for the existence of [constr_1653]: if an unknown member or argument is
encountered the deserializer cannot determine the actual datatype of the member/ar-
gument when wire type 4 is used.

686 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_1654] No definition of length field sizes on DataPrototype level in

case of TLV usage dIf TlvDataIdDefinitions are defined for a SOMEIPTrans-
formationISignalProps, the attributes sizeOfArrayLengthFields, sizeOf-
StructLengthFields and sizeOfUnionLengthFields shall not be defined on
DataPrototype level but only on ISignal level.c()
Rationale for the existence of [constr_1654]: if an unknown member or argument is
encountered the deserializer needs to know the size of the length field when wire type
4 is used. The easiest way is that the size of the length field is then only defined at the
top-level element.

687 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

8 Gateways
A gateway is a function within an EcuInstance that performs as a FrameMap-
ping, IPduMapping or ISignalMapping function between two or more Commu-
nicationClusters.
PackageableElement
FibexElement

EcuInstance Gateway
+ecu

«atpVariation»
«atpVariation» «atpVariation»

0..* +frameMapping +iPduMapping 0..* +signalMapping 0..*

FrameMapping IPduMapping ISignalMapping

+ pduMaxLength: PositiveInteger [0..1]

+ pdurTpChunkSize: PositiveInteger [0..1]

+targetIPdu 1

TargetIPduRef +sourceSignal 1 +targetSignal 1

+sourceFrame 1 +targetFrame 1
Identifiable
Identifiable
ISignalTriggering
FrameTriggering

+sourceIPdu 1 +targetIPdu 1

Identifiable
PduTriggering

PduMappingDefaultValue +defaultValue

0..1

+defaultValueElement 1..*

DefaultValueElement

+ elementByteValue: Integer
+ elementPosition: Integer

Figure 8.1: Communication Overview (Fibex4Multiplatform: Gateway)

688 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Figure 8.1 shows the meta-model for the Gateway description in the System Template.
Class Gateway
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Multiplatform
Note A gateway is an ECU that is connected to two or more clusters (channels, but not redundant), and
performs a frame, Pdu or signal mapping between them.
Tags:atp.recommendedPackage=Gateways
Base ARObject, CollectableElement, FibexElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
ecu EcuInstance 1 ref Reference to one ECU instance that implements the
gateway.
frameMapping FrameMapping * aggr Frame Gateway: The entire source frame is mapped as it
is onto the target frame (what in general is only possible
inside of a common platform). In this case source and
target frame should be the identical object.
atpVariation: If frames are variable in clusters, the
gateway frame mapping needs to be variable, too.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
iPduMapping IPduMapping * aggr IPdu Gateway: Arranges those IPdus that are transferred
by the gateway from one channel to the other in pairs and
defines the mapping between them.
atpVariation: If PDUs are variable in clusters, the gateway
PDU mapping needs to be variable, too.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
signalMapping ISignalMapping * aggr Signal Gateway: Arranges those signals that are
transferred by the gateway from one channel to the other
in pairs and defines the mapping between them.
atpVariation: If signals are variable in clusters, the
gateway signal mapping needs to be variable, too.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild

Table 8.1: Gateway

689 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

8.1 Frame Mapping

The FrameMapping arranges those FrameTriggerings that are transferred by the
Gateway from one PhysicalChannel to the other in pairs and defines the mapping
between them. Each pair consists of a sourceFrame and a targetFrame referenc-
ing to a FrameTriggering.
[TPS_SYST_01116] Frame Mapping is not supported by the AUTOSAR BSW dThe
FrameMapping is not supported by the AUTOSAR BSW.c()
The existence is optional and has been incorporated into the System Template mainly
for compatibility in order to allow interchange between FIBEX and AUTOSAR descrip-
tions.
FrameMapping +introduction «atpMixed»
DocumentationBlock
0..1

+targetFrame 1 +sourceFrame 1

Identifiable
FrameTriggering

Figure 8.2: Frame Mapping (Fibex4Multiplatform: FrameMapping)

Class FrameMapping
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Multiplatform
Note The entire source frame is mapped as it is onto the target frame (what in general is only possible inside of
a common platform). In this case source and target frame should be the identical object.
Each pair consists in a SOURCE and a TARGET referencing to a FrameTriggering.
The Frame Mapping is not supported by the Autosar BSW. The existence is optional and has been
incorporated into the System Template mainly for compatibility in order to allow interchange between
FIBEX and AUTOSAR descriptions.
Base ARObject
Attribute Type Mult. Kind Note
introduction DocumentationBlock 0..1 aggr This represents introductory documentation about the
frame mapping.
sourceFrame FrameTriggering 1 ref Source destination of the referencing mapping.
targetFrame FrameTriggering 1 ref Target destination of the referencing mapping.

Table 8.2: FrameMapping

690 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

8.2 IPdu Mapping

[TPS_SYST_01117] Pdu Gateway support dThe IPduMapping arranges those
IPdus that are transferred by the Gateway from one PhysicalChannel to the other
(or the same) PhysicalChannel in pairs and defines the mapping between them.
Each pair consist of a sourceIPdu and a targetIPdu referencing to a PduTrig-
gering.c()
For FlexRay: If a Pdu is gatewayed to more than one PhysicalChannel of the same
CommunicationCluster, all of this gateway relationships shall be specified. There-
fore, all affected PduTriggerings shall be referenced in the gateway mappings.
[TPS_SYST_01118] Support of Multicast Pdu routing dThe 1:n multicast routing is
supported with the definition of several IPduMappings where the sourceIPdu refers
to the same PduTriggering.c()
[TPS_SYST_02143] Support of Multisource Pdu routing dThe n:1 routing is sup-
ported with the definition of several IPduMappings where the targetIPdu refers to
the same PduTriggering.c()
Please note that in case of n:1 routing by a local module (e.g. COM, Dcm) it shall
be enforced at run-time that at most one routing path is active (i.e., enabled via
PduR_EnableRouting()). In case of n:1 routing by a pure gateway routing (either TP or
IF) all routing paths can be active at run time.
[TPS_SYST_02207] Routing on the fly dIf routing on the fly is not possible in case:
• there is more than one destination routing path or
• the routing path uses the Interface (IF) API instead of Transport Protocol (TP) API
then IPduMapping.pdurTpChunkSize will be ignored in the Ecu configuration.c()

691 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

IPduMapping «atpMixed»
+introduction DocumentationBlock
+ pduMaxLength: PositiveInteger [0..1]
+ pdurTpChunkSize: PositiveInteger [0..1] 0..1

+targetIPdu 1

TargetIPduRef

+sourceIPdu 1 +targetIPdu 1

Identifiable
PduTriggering

PduMappingDefaultValue
+defaultValue

0..1

+defaultValueElement 1..*

DefaultValueElement

+ elementByteValue: Integer
+ elementPosition: Integer

Figure 8.3: I-Pdu Mapping (Fibex4Multiplatform: IPduMapping)

Class IPduMapping
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Multiplatform
Note Arranges those IPdus that are transferred by the gateway from one channel to the other in pairs and
defines the mapping between them.
Base ARObject
Attribute Type Mult. Kind Note
introduction DocumentationBlock 0..1 aggr This represents introductory documentation about the
IPdu mapping.
pduMaxLength PositiveInteger 0..1 attr Define the maximum length in bytes which limits the
length of the Pdu during gateway operation if the runtime
length of the received Pdu exceeds this limit.
pdurTpChunk PositiveInteger 0..1 attr Optionally defines the to be configured Pdu Router Tp
Size ChunkSize for this routing relation.
sourceIPdu PduTriggering 1 ref Source destination of the referencing mapping.
targetIPdu TargetIPduRef 1 aggr Target destination of the referencing mapping.

Table 8.3: IPduMapping

Class TargetIPduRef
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Multiplatform
Note Target destination of the referencing mapping.
Base ARObject
Attribute Type Mult. Kind Note
5

692 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class TargetIPduRef
defaultValue PduMappingDefault 0..1 aggr If no I-Pdu has been received a default value will be
Value distributed.
targetIPdu PduTriggering 1 ref IPdu Reference

Table 8.4: TargetIPduRef

Class PduMappingDefaultValue
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Multiplatform
Note Default Value which will be distributed if no I-Pdu has been received since last sending.
Base ARObject
Attribute Type Mult. Kind Note
defaultValue DefaultValueElement 1..* aggr The default value consists of a number of elements. Each
Element default value element is represented by the element and
the position in an array.

Table 8.5: PduMappingDefaultValue

Class DefaultValueElement
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Multiplatform
Note The default value consists of a number of elements. Each element is one byte long and the number of
elements is specified by SduLength.
Base ARObject
Attribute Type Mult. Kind Note
elementByte Integer 1 attr The integer value of a freely defined data byte.
Value
elementPosition Integer 1 attr This attribute specifies the byte position of the element
within the default value
Table 8.6: DefaultValueElement

8.2.1 Usage of IPduMapping.pduMaxLength

The Pdu gateway can be configured to use IPduMapping.pduMaxLength as a spe-

cific value per gateway operation. This value (if defined) will be used for the length
configuration of the involved Pdus in the Ecu Configuration of the COM-Stack. There is
no direct 1:1 correspondence of IPduMapping.pduMaxLength in EcuC, it is reflected
in the value of EcuC PduLength only.
The rational for the existence of IPduMapping.pduMaxLength is that in the system
template the length of a Pdu is defined at the Pdu.length attribute. The Pdu can be
used in the definition of several PduTriggerings. The use-case is to have the pos-
sibility to define different ECU Configuration PduLengths for each routing operation (
IPduMapping).
[TPS_SYST_02310] Pdu routing with IPduMapping.pduMaxLength dThe attribute
IPduMapping.pduMaxLength defines a maximum length which shall be forwarded

693 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

to the destination module by the PduR, if the runtime length of the actually received
Pdu exceeds IPduMapping.pduMaxLength.c()
If the attribute IPduMapping.pduMaxLength is defined the value will be derived into
the EcuC PduLength configuration parameter.
• If the runtime length of the received Pdu does not exceed PduLength (now con-
figured to the value of IPduMapping.pduMaxLength) then the PduR will for-
ward the runtime length of the received Pdu to the corresponding targetIPdu.
• If the runtime length of the received Pdu does exceed PduLength (now config-
ured to the value of IPduMapping.pduMaxLength) then the PduR will forward
the PduLength of the received Pdu to the corresponding targetIPdu.
If the attribute IPduMapping.pduMaxLength is not defined then the Pdu.length
is used to derive the PduLength configuration parameter. This corresponds to the
normal routing operation.
[constr_5166] Existence of IPduMapping.pduMaxLength dIf several IPduMap-
pings refer to the same PduTriggering in IPduMapping.sourceIPdu, then all of
these IPduMappings shall provide either no IPduMapping.pduMaxLength value,
or the same IPduMapping.pduMaxLength value.c()
[TPS_SYST_02311] IPduMapping.pduMaxLength relying on the environment
length configuration dIPduMapping.pduMaxLength shall not exceed the available
amount of free payload bytes in the surrounding Pdus or frames of routedPdu, where
routedPdu is the sourceIPdu or the targetIPdu, e.g. if routedPdu is contained
in a ContainerIPdu with (ContainerIPdu.headerType = shortHeader), then
IPduMapping.pduMaxLength shall not exceed (ContainerIPdu.length - 4) (4
being the byte length of the short HeaderId/Length field)c()
Example: Pdu_A is transmitted on CAN_1 network in a CAN-FD frame and forwarded
by a gateway as part of a ContainerIPdu to CAN_2 network.
Pdu_A in the transmitting ECU_A (CAN_1) has the following configuration:
Pdu.length = 9 bytes.
The routing path to route Pdu_A as Contained IPdu to CAN_2 has the following con-
figuration:
• IPduMapping.pduMaxLength = 60 byte
• IPduMapping.sourceIPdu = PduTriggering referring to PDU_A
• IPduMapping.targetIPdu = refers to PduTriggering referring to PDU_B
(PDU_B as part of a ContainerIPdu)
The length information in the system description are:
• sourceIPdu.length = 9 byte
• targetIPdu.length = 60 byte (due to pduMaxLength = 60 byte).

694 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

The gateway has no data length check configured.

Because this is an IPduMapping with pduMaxLength defined, the specific upstream
mapping for the EcuC PduLength applies:
In case IPduMapping is used:
1:1 (sourceIPdu:targetIPdu) routing: When the SysTPduToPduTriggeringRef
PduTriggering is referenced by an IPduMapping in the role sourceIPdu or tar-
getIPdu, respectively, and that IPduMapping has a pduMaxLength defined then
IPduMapping.pduMaxLength shall be used as PduLength for the derived PduRSr-
cPdu and PduRDestPdu, respectively.
The PduLength in Ecu Configuraton of the received and sent Pdu is configured to 60
byte.
Thus both, the receiving and the sending path in the gateway Ecu Configuration are
prepared to handle a Pdu with 60 byte.
• ECU_A transmits PDU_A within a CAN-FD frame with a length of actually 12 byte
(9 byte payload + 3 byte padding).
• ECU_B (gateway) receives the CAN-L-PDU and CanIf forwards 12 byte to the
upper layer as received length.
• PduR forwards 12 byte (as the received length is smaller than IPduMapping.
pduMaxLength of 60 byte)
• IpduM packs the received 12 byte payload in the container.
Update scenario: Communication matrix of ECU_A is updated and payload of PDU_A
is extended to 60 Byte. ECU_B (gateway) is not updated.
• ECU_A transmits the extended PDU_A within a CAN-L-PDU with a length of 64
byte (60 byte payload + 4 byte padding).
• ECU_B (gateway) receives the CAN-L-PDU, CanIf forwards 64 byte to PduR.
• PduR forwards 60 byte (as the received length is bigger than IPduMapping.
pduMaxLength of 60 byte) as received length to the IpduM.
• IPduM packs the shortened 60 byte Pdu to the configured ContainerIPdu.
[constr_5235] Maximum Frame.frameLength of the used bus protocol shall not
be exceeded dThe Pdu.length used for an IPdu and the IPduMapping.pdu-
MaxLength used for a targetIPdu shall not exceed the limitation of the maximum
Frame.frameLength of the used bus protocol (e.g. CAN2.0 max. Frame.frame-
Length == 8Byte, CAN-FD Frame.frameLength == 64byte).c()
[constr_5236] Restriction of IPduMapping.pduMaxLength dIPduMapping.pdu-
MaxLength shall be equal or greater than the maximum Pdu.length of sourceIPdu
and targetIPdu. For a N:1 routing and 1:N routing, respectively, the maximum Pdu.
length of all involved Pdus shall be used to evaluate a proper IPduMapping.pdu-
MaxLength.c()

695 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

8.2.2 Routing and processing of Diagnostics Pdus

An EcuInstance routes a source DcmIPdu to a destination DcmIPdu if there is an

IPduMapping in place that is configured according to [TPS_SYST_01117]. The
EcuInstance also processes the DcmIPdu locally if the source DcmIPdu is assigned
a functional destination address.

696 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

8.3 Signal Mapping

[TPS_SYST_01119] Signal Gateway support dThe ISignalMapping defines the
mapping between ISignals and ISignalGroups that are transferred by the Gate-
way from one PhysicalChannel to the other (or the same) PhysicalChannel.
Each mapping pair consists of a sourceSignal and a targetSignal referencing
an ISignalTriggering. Each ISignalTriggering points to either an ISignal
or an ISignalGroup. The ISignal refers to the to be routed SystemSignal, the
ISignalGroup refers to the to be routed SystemSignalGroup.c()
[constr_3051] Restriction of ISignalMapping references dIf the sourceSignal
references an ISignal then the targetSignal shall also reference an ISignal.c()
[TPS_SYST_01155] Routing of ISignalGroups dIf the sourceSignal references
an ISignalGroup then the targetSignal can reference either an ISignalGroup
or an ISignal.c()
[constr_3052] Complete ISignalMapping of ISignalGroup signals dIf an ISig-
nalMapping to an ISignal that is a member of a ISignalGroup exists then (see
[TPS_SYST_01120]) an ISignalMapping to the enclosing ISignalGroup shall ex-
ist as well.c()
[TPS_SYST_02162] Routing of ISignals of ISignalGroups dWhen performing
a signal group routing two approaches are supported for the pairing of the included
ISignals:
• implicit mapping: the ISignalMapping points in the sourceSignal role to
an ISignalTriggering of an ISignalGroup and no ISignalMappings are
defined for the included ISignals. Identical shortNames of ISignal elements
identify correlating ISignals between the source and the target in the scope of
the ISignalMapping.
• explicit mapping: the ISignalMapping points in the sourceSignal role to an
ISignalTriggering of an ISignalGroup and in addition explicitly specified
ISignalMappings define which ISignals correlate to each other.
c()
Please note that SWS_COM [22] does not support the “implicit mapping” of
[TPS_SYST_02162]. Thus it is required in the upstream mapping to derive individ-
ual ISignalMappings for all the members of a to be routed ISignalGroup.
[TPS_SYST_01120] Precedence of ISignalMappings dIf a dedicated ISig-
nalMapping for at least one ISignal within an ISignalGroup exists the implicit
mapping on the basis of shortNames is no longer applicable for any ISignal within
that ISignalGroup.c()
[TPS_SYST_01121] Support of Mulicast signal routing dThe 1:n multicast routing is
supported with the definition of several ISignalMappings. See also the COM Signal
Gateway fan-out description in [TPS_SYST_01110].c()

697 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

ISignalMapping «atpMixed»
+introduction DocumentationBlock

0..1

+sourceSignal 1 +targetSignal 1

Identifiable
ISignalTriggering

+iSignal 0..1 +iSignalGroup 0..1

FibexElement FibexElement
ISignal ISignalGroup
+iSignal
+ dataTypePolicy: DataTypePolicyEnum
0..*
+ iSignalType: ISignalTypeEnum [0..1]
+ length: UnlimitedInteger

+systemSignal 1 +systemSignalGroup 1
+transformingSystemSignal
ARElement ARElement
SystemSignal 0..1 SystemSignalGroup

+ dynamicLength: Boolean +systemSignal

Figure 8.4: Signal Mapping (Fibex4Multiplatform: Signal Mapping)

Class ISignalMapping
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Multiplatform
Note Arranges those signals (or SignalGroups) that are transferred by the gateway from one channel to the
other in pairs and defines the mapping between them. Each pair consists in a source and a target
referencing to a ISignalTriggering.
Base ARObject
Attribute Type Mult. Kind Note
introduction DocumentationBlock 0..1 aggr This represents introductory documentation about the
ISignal mapping.
sourceSignal ISignalTriggering 1 ref Source destination of the referencing mapping.
targetSignal ISignalTriggering 1 ref Target destination of the referencing mapping.

Table 8.7: ISignalMapping

8.3.1 Partial Signal Group Mapping

[TPS_SYST_01122] partial routing between ISignalGroups dThe ISignalMap-

ping supports partial routing between ISignalGroups which have not identical set
of ISignals within an ISignalGroup.c()
[constr_3053] Complete ISignalMapping of target ISignalGroup dIf an ISig-
nalGroup is referenced by a targetSignal then [TPS_SYST_02162] applies for
each of the contained ISignal of that ISignalGroup.c()
Figure 8.5 shows an example for a partial signal group mapping with explicit mappings
for the GroupSignals.

698 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

SignalGateway: ISignalMapping

:ISignalMapping :ISignalMapping :ISignalMapping

+sourceSignal +targetSignal +sourceSignal +targetSignal +sourceSignal +targetSignal

A: ISignalTriggering B: ISignalTriggering A1: ISignalTriggering B1: ISignalTriggering A3: ISignalTriggering B2: ISignalTriggering

A: ISignalGroup B: ISignalGroup

A1: ISignal B1: ISignal

A2: ISignal B2: ISignal

A3: ISignal

Figure 8.5: Partial Signal Group Mapping Example

699 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

9 Global Time Synchronization

9.1 Introduction
This chapter describes the modeling of how a global time synchronization in an
AUTOSAR system can be achieved. There are two kinds of time bases: synchro-
nized time base and offset time base. This manifests in two possible values for the
attribute category (see [constr_3519]).
[constr_3519] Value of category of GlobalTimeDomain dThe attribute category
of GlobalTimeDomain can have the following values:
• SYNCHRONIZED: this time base does not depend on the existence of another
time base
• OFFSET: this time base depends on the existence of another time base. It deliv-
ers a value that represents an offset relative to the referenced (GlobalTimeDo-
main.offsetTimeDomain) synchronized time base.
c()
There are several use cases for implementing a system-wide global time in an vehicle:
• In case of an accident it may be necessary to post-mortem analyze whether the
vehicle ECUs performed according to specification. This implies that it shall be
possible to unambiguously determine the sequence of activities before a crash.
This sequence can only be determined if all components in the distributed system
depend on a reliable global time basis.
• It may be necessary that several ECUs in the distributed system need to act in
concert with respect to the time that a specific activity is executed. A very trivial
example for this requirement is the activation of turn indicators in a car. These
are rarely connected to a single ECU (which could take care of synchronously
flashing the turn indicators) but their synchronized execution is still very essential
for the vehicle operation.
• The distribution of several global time bases shall be possible (e.g. a vehicle local
time based on the runtime of the car and a GPS-based time).
• It shall be possible to define offset time bases which have the property that they
are based on a synchronized time base and distribute the offset time value as
difference to the synchronized time base.
It is obvious that the distribution of global time within a vehicle requires a system-wide
context and therefore, the AUTOSAR System Template defines relevant meta-classes
and their relations for this purpose.
Of course, the actual implementation of global time distribution is done in a couple
of basic-software modules that need to be configured in the context of integrating a
particular ECU. The purpose of the meta-model described in chapter 9 is to support
the configuration of these basic-software modules.

700 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

The modeling of how the distribution of global time is supposed to work can roughly be
distributed into two parts, the discussion of the big picture (see 9.2) and the description
of the details that eventually will support the configuration of the corresponding basic-
software modules. The latter can be found in chapter 9.3.

9.2 The big Picture

The central part of the formalization of global time synchronization is the existence of
a global time domain, formalized as GlobalTimeDomain.
However, the fragment global in global time domain primarily stresses the fact that it is
supposed to support the distribution of a global time rather than implying an information
about the scope or visibility of a GlobalTimeDomain1 .
In other words, there is typically more than a single GlobalTimeDomain available in
the System.
Please note that the concept of the GlobalTimeDomain roughly corresponds to the
existence of a CommunicationCluster, i.e. it takes at least one Communication-
Cluster to implement a global time domain.
[TPS_SYST_05006] Chaining of GlobalTimeDomains dIt is possible to extend the
global time domain to several CommunicationClusters that are interconnected by
means of a Gateway.
In other words, the global time base is routed from one CommunicationCluster to
another, whereas the Time Slave resp. Time Slave Port updates its local time base
by using the received global time base and takes into account, whether a time base
correction has to be considered or not.
There are certainly use-cases for implementing a GlobalTimeDomain that extends
to several CommunicationClusters, but in many (if not in the majority of) cases it
will be necessary to update the time information for the sake of precision.
In this case, however, two separate GlobalTimeDomains rather than a single Glob-
alTimeDomain exist. The GlobalTimeDomain relate to each other such that one
GlobalTimeDomain refers to the other in the role globalTimeSubDomain.c()
In order to understand the way how GlobalTimeDomains refer to each other, it is
important to understand that the concept of a global time domain has an underlying
asymmetric approach of how the time information is distributed.
That is, not all participants in the communication of global time information are able
and/or entitled to update the time information and send it around for others to consume.
[TPS_SYST_02103] Semantics of GlobalTimeDomain.domainId dGlobalTime-
Domain.domainId represents a specific time source, e.g. GPS time.c()

1
For the intents and purposes of this chapter, always make sure to read global-time domain rather
than global time-domain.

701 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

The modeling of GlobalTimeDomains and SubDomains describes the propagation

of time values of a time source through the networks. Since the specific time source
corresponds to the value of GlobalTimeDomain.domainId [constr_3251] is formu-
lated.
[constr_3251] Value of GlobalTimeDomain.domainId in globalTimeSubDo-
main chains dIn a chain of GlobalTimeDomain.globalTimeSubDomain the value
of the attribute GlobalTimeDomain.domainId shall be identical.c()
[TPS_SYST_05007] separation of roles within a GlobalTimeDomain dWithin a sin-
gle global time domain, There is a strict separation of roles into a single global time
master (formalized by the meta-class GlobalTimeMaster) and a collection of so-
called global time slaves (formalized by means of the meta-class GlobalTimeSlave).
The role of the GlobalTimeMaster is to provide the global time information and the
role of the collection of GlobalTimeSlaves is to consume the information. The chain-
ing of GlobalTimeDomains needs to be understood as the intention to implement the
following information flow:
1. from the GlobalTimeMaster of one GlobalTimeDomain to the Global-
TimeSlaves of the same GlobalTimeDomain
2. via the GlobalTimeMaster of the GlobalTimeDomain referenced in the role
globalTimeSubDomain to the GlobalTimeSlaves of the globalTimeSub-
Domain
c()

702 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Identifiable
GlobalTimeCorrectionProps
PduTriggering
+ offsetCorrectionAdaptionInterval: TimeValue [0..1]
+ offsetCorrectionJumpThreshold: TimeValue [0..1]
+ rateCorrectionMeasurementDuration: TimeValue [0..1] +pduTriggering 0..1
+ rateCorrectionsPerMeasurementDuration: PositiveInteger [0..1]

+globalTimeCorrectionProps 0..1 «atpVariation»

+offsetTimeDomain 0..1
FibexElement
GlobalTimeDomain

+ debounceTime: TimeValue [0..1]

+ domainId: PositiveInteger +globalTimeSubDomain 0..*
+ syncLossTimeout: TimeValue [0..1] «atpVariation»

+globalTimeDomainProperty
AbstractGlobalTimeDomainProps
«atpVariation» 0..1

+networkSegmentId NetworkSegmentIdentification
0..1 + networkSegmentId: PositiveInteger [0..1]

«atpVariation»
+gateway 0..*

Identifiable +host FibexElement

GlobalTimeGateway 1 EcuInstance

«atpVariation» «atpVariation»

+slave 0..* +slave 1 +master 1 +globalTimeMaster 0..1

Identifiable Identifiable
GlobalTimeSlave GlobalTimeMaster
«atpVariation»
+ followUpTimeoutValue: TimeValue [0..1] + immediateResumeTime: TimeValue [0..1]
+ timeLeapFutureThreshold: TimeValue [0..1] + isSystemWideGlobalTimeMaster: Boolean
+ timeLeapHealingCounter: PositiveInteger [0..1] + syncPeriod: TimeValue
+ timeLeapPastThreshold: TimeValue [0..1]

+communicationConnector 1 +communicationConnector 1 +connector *

Identifiable
CommunicationConnector

+ createEcuWakeupSource: Boolean [0..1]

+ dynamicPncToChannelMappingEnabled: Boolean [0..1]
+ pncFilterArrayMask: PositiveInteger [0..*] {ordered}
+ pncGatewayType: PncGatewayTypeEnum [0..1]

Figure 9.1: Big Picture of AUTOSAR global time synchronization

[TPS_SYST_05008] Semantics of a GlobalTimeGateway dIn order to achieve the

flow of information between a GlobalTimeSlave of a given GlobalTimeDomain to
the GlobalTimeMaster of another GlobalTimeDomain, it is necessary to establish
the existence of a so-called GlobalTimeGateway.
In terms of functionality, a GlobalTimeGateway complements the functionality of the
underlying Gateway such that, on top of the mere routing from one Communication-
Cluster to another, the time information is actively updated in the process of passing
it from one GlobalTimeDomain to the other.c()
[TPS_SYST_05009] GlobalTimeDomain.pduTriggering for transmitting global
time information dThe flow of global time information is unidirectional, i.e. the Glob-
alTimeSlaves consume the information without providing any form of feedback to
the corresponding GlobalTimeMaster.
Thanks to this conceptual detail, there is only the need for one dedicated Pdu for the
transmission of the actual global time information in the context of one GlobalTime-
Domain.

703 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

The characteristics of accessing the information contained in this Pdu do make any
requirements on the nature of the Pdu. Therefore, it is sufficient and applicable to use
the GeneralPurposePdu for this use case.
To make this possible, it is necessary to include the global time use case in the set of
standardized values of the attribute GeneralPurposePdu.category. In other words,
[constr_3081] applies.c()
[constr_3261] GlobalTimeDomain.pduTriggering category dThe Pdu that is
referenced by the PduTriggering that in turn is referenced by GlobalTimeDo-
main in the role pduTriggering shall be a GeneralPurposePdu of category
GLOBAL_TIME.c()
[TPS_SYST_05010] GlobalTimeDomain.pduTriggering is not required on Eth-
ernet dThe Pdu for transmitting global time information is not required on the Ethernet
bus. Here, the information is accessed directly from the Ethernet Interfaces, i.e. the
hardware already keeps track of the global time.c()
[constr_1369] CommunicationConnectors shall be attached to the same Com-
municationCluster dAll CommunicationConnectors referenced from Global-
TimeMaster and GlobalTimeSlaves aggregated in one GlobalTimeDomain shall
be referenced in the role commConnector by the same PhysicalChannel aggre-
gated by the same CommunicationCluster.c()
[constr_1370] Consistency of GlobalTimeDomain dThe GlobalTimeSlave ref-
erenced in the role GlobalTimeGateway.slave and the GlobalTimeMaster refer-
enced in the role GlobalTimeGateway.master shall not be aggregated by the same
GlobalTimeDomain.c()
The background of [constr_1370] is that the GlobalTimeGateway is supposed to
connect two GlobalTimeDomains it is hardly possible that the GlobalTimeGate-
way.slave and the GlobalTimeMaster can be aggregated by the same Global-
TimeDomain.
[TPS_SYST_05011] Ownership of GlobalTimeGateway dSince the existence of a
GlobalTimeGateway is only justified if a GlobalTimeDomain exists that is refer-
enced by a GlobalTimeDomain in the role globalTimeSubDomain it seems appro-
priate to aggregate the GlobalTimeGateway at the GlobalTimeDomain referenced
in the role globalTimeSubDomain.c()
In other words, the GlobalTimeGateway shall be aggregated at the GlobalTime-
Domain that also aggregates the master.
Please note that GlobalTimeDomain.gateway effectively has a 0..1 multiplicity since
no more than one globalTimeMaster is allowed per GlobalTimeDomain.
[constr_1371] Consistency of attribute host dWithin the context of an ag-
gregating GlobalTimeDomain, the CommunicationConnectors referenced in
the role GlobalTimeGateway.master.communicationConnector and Global-
TimeGateway.slave.communicationConnector shall be aggregated by the same
EcuInstance that is referenced in the role GlobalTimeGateway.host.c()

704 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_1372] Consistency of attribute pduTriggering dWithin the context of an

aggregating GlobalTimeDomain, the pduTriggering shall be owned by Physi-
calChannel that is also referencing the CommunicationConnectors referenced in
the roles GlobalTimeSlave.communicationConnector and GlobalTimeMas-
ter.communicationConnector.c()
[TPS_SYST_05013] Semantics of GlobalTimeMaster.isSystemWideGlobal-
TimeMaster dThe attribute GlobalTimeMaster.isSystemWideGlobalTimeMas-
ter indicates whether a given GlobalTimeMaster is considered an independent (i.e.
[constr_1373] applies) source of global time information.c()
[constr_1373] GlobalTimeMaster with attribute isSystemWideGlobal-
TimeMaster set to TRUE dGlobalTimeMaster with attribute isSystemWide-
GlobalTimeMaster set to TRUE shall not be referenced in the role Global-
TimeGateway.master.c()
[TPS_SYST_05014] GlobalTimeMaster.isSystemWideGlobalTimeMaster
dThere is no limitation regarding the number of GlobalTimeMasters that have at-
tribute isSystemWideGlobalTimeMaster set to TRUE. The attribute does not imply
that there can only be one GlobalTimeMaster within the context of a System.c()
[constr_1374] Only fan-out possible for GlobalTimeGateway dFor all Global-
TimeGateways that refer to the same EcuInstance the condition applies that no two
GlobalTimeGateways shall refer to the same GlobalTimeMaster.c()
In other words, a fan-in of time information such that time information is received from
several sources is not supported.
GlobalTime sub domains are associated with specific PhysicalChannels (via
the PduTriggerings of GeneralPurposePdus with category GLOBAL_TIME,
see [constr_3081]).
In order to identify the PhysicalChannel on a system scope, the NetworkSegmen-
tIdentification.networkSegmentId is used.
The networkSegmentId is derived into the ECU Configuration of every GlobalTime
sub domain participant and is available to the TimeSync modules.
One specific use-case is the identification of dedicated PhysicalChannels for the
Time Validation (see [41]), where a central entity receives time validation notifications
from network nodes of several GlobalTime subdomains and needs to match the re-
spective notifications according to the networkSegmentId.
[constr_3620] GlobalTimeDomain.networkSegmentId only applicable to Glob-
alTime sub domains dThe aggregation GlobalTimeDomain.networkSegmentId
shall only be defined if the GlobalTimeDomain is itself referenced in the role Glob-
alTimeDomain.globalTimeSubDomain.c()
Rational: There is a GlobalTime sub domain defined for each network the GlobalTime
is distributed to, thus only for GlobalTime sub domains a definition of a networkSeg-
mentId makes sense.

705 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Note that the GlobalTimeDomain.networkSegmentId is currently not taken to the

ECU Configuration of the EthTSyn module, as there are other means used for the
identification of EthTSyn network segments (see [42]).
[constr_3621] Value range of GlobalTimeDomain.networkSegmentId dIf de-
fined, the value of GlobalTimeDomain.networkSegmentId shall be in the range
0..255.c()
In figure 9.2 an example of a Global Time Sync setup is shown. The Global time master
ECU creates the TimeDomain and provides it to several globalTimeSubDomains.
The GlobalTimeMasters for the globalTimeSubDomains take the TimeDomain
and distribute it to their networks.
The time for the GlobalTimeMasters TM11 and TM21 is based on the TimeDomain
and therefore they have the attribute isSystemWideGlobalTimeMaster set to true.
The time for the GlobalTimeMasters TM12 and TM22 are based on a Glob-
alTimeGateway and therefore they have the attribute isSystemWideGlobal-
TimeMaster set to false.

Global time master

sub11 TM11 sub21 TM21

FR ETH

TS TS

TS sub22 TG2 TS2

TM22
sub12 CAN2
TG1 TS1 Time
TM12 Domain
TS
CAN1

TS
TS

TS: GlobalTime slave

TM: GlobalTime master
TG: GlobalTime gateway

Figure 9.2: Example Global Time Sync topology

A partial outline of the example system description structure is shown in figure 9.3.

706 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

TimeDomain:
GlobalTimeDomain

domainId = 1
category = SYNCHRONIZED

+globalTimeSubDomain
TM11: GlobalTimeFrMaster
+globalTimeMaster
sub11: GlobalTimeDomain
isSystemWideGlobalTimeMaster = true
domainId = 1
category = SYNCHRONIZED
+slave
:GlobalTimeFrSlave

+slave
:GlobalTimeFrSlave

+slave +slave
TS1:
GlobalTimeFrSlave

+globalTimeSubDomain

sub12: GlobalTimeDomain +master

+globalTimeMaster TM12: GlobalTimeCanMaster
domainId = 1
category = SYNCHRONIZED isSystemWideGlobalTimeMaster = false

+gateway
TG1:
GlobalTimeGateway

+slave
:GlobalTimeCanSlave

+globalTimeSubDomain sub21: GlobalTimeDomain +globalTimeMaster TM21: GlobalTimeEthMaster

domainId = 1 isSystemWideGlobalTimeMaster = true

category = SYNCHRONIZED

Figure 9.3: System Description of Global Time Sync example

An offset time domain is defined by an reference from a GlobalTimeDomain to

another GlobalTimeDomain in the role GlobalTimeDomain.offsetTimeDomain.
This makes the reference source the offset time domain and the reference target the
synchronized time domain.
[constr_3520] Offset time domain shall be based on a synchronized time domain
dIf a GlobalTimeDomain has a reference with the role GlobalTimeDomain.off-
setTimeDomain the reference source shall have a GlobalTimeDomain.domainId
in the range of 16-31 and the reference target shall have a GlobalTimeDomain.do-
mainId in the range of 0-15.c()
Rationale: In the [41] Specification the ranges are fixed for synchronized and offset
time domains.
Note that the same synchronized time domain can be referenced by several different
offset time domains.
[TPS_SYST_03015] Offset time domain requires synchronized time domain
dSince the calculation of the actual offset time domain time requires the presence of
the synchronized time domain as well as the offset time domain it is required that every
ECU which receives an offset time domain also receives the respective synchronized
time domain.c()

707 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

In figure 9.4, an example of a Offset Time Sync setup is shown. The example is based
on the setup shown in figure 9.2 and extends this with the definition of an offset time
domain.
The Global time master ECU creates the synchronized TimeDomain and provides it to
several globalTimeSubDomains. The figure needs to be interpreted in the way that
the OffsetTimeDomain is based on the TimeDomain and is sort of overlaid, although
drawn side by side.
The time slave TS_O receives the TimeDomain as a GlobalTimeSlave and also
provides the OffsetTimeDomain as TM51 in the role of a GlobalTimeMaster on the
same network FR.

Global time master

sub11 TM11 sub21 TM21 sub51

FR ETH FR

TS TS TS

TS_O sub22 TG2 TM51

TS2
TM22
sub12 CAN2 Offset sub52
TG1 TS1 Time Time
TG5 TS5
TM12 Domain Domain TM52
TS
CAN1 CAN1

TS
TS TS

TS: GlobalTime slave

TM: GlobalTime master
TG: GlobalTime gateway

Figure 9.4: Example Offset Time Sync topology

A partial outline of the example system description structure is shown in figure 9.5.

708 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

TimeDomain: +offsetTimeBase TimeDomainOffset:

GlobalTimeDomain GlobalTimeDomain

domainId = 1 domainId = 16
category = SYNCHRONIZED category = OFFSET

+globalTimeSubDomain +globalTimeSubDomain

sub11: GlobalTimeDomain sub51: +globalTimeMaster TM51: GlobalTimeFrMaster

GlobalTimeDomain isSystemWideGlobalTimeMaster = true
domainId = 1
category = SYNCHRONIZED domainId = 16
category = OFFSET
+offsetTimeBase +slave
:GlobalTimeFrSlave

+slave +slave
TS5:
GlobalTimeFrSlave

+globalTimeSubDomain +globalTimeSubDomain
+master
sub12: GlobalTimeDomain sub52: +globalTimeMaster TM52: GlobalTimeCanMaster
GlobalTimeDomain isSystemWideGlobalTimeMaster = false
domainId = 1
category = SYNCHRONIZED domainId = 16
category = OFFSET
+offsetTimeBase +gateway
TG5:
GlobalTimeGateway

+slave
:GlobalTimeCanSlave

+globalTimeSubDomain

sub21: GlobalTimeDomain

domainId = 1
category = SYNCHRONIZED

Figure 9.5: System Description of Offset Time Sync example

Class GlobalTimeDomain
Package M2::AUTOSARTemplates::SystemTemplate::GlobalTime
Note This represents the ability to define a global time domain.
Tags:atp.recommendedPackage=GlobalTimeDomains
Base ARObject, CollectableElement, FibexElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
debounceTime TimeValue 0..1 attr Defines the minimum amount of time between two time
sync messages are transmitted.
domainId PositiveInteger 1 attr This represents the ID of the GlobalTimeDomain used in
the network messages sent on behalf of global time
management.
gateway GlobalTimeGateway * aggr A GlobalTimeGateway may exist in the context of a
GlobalTimeDomain to actively update the global time
information as it is routed from one GlobalTimeDomain to
another.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
globalTime GlobalTimeCorrection 0..1 aggr Defintion of attributes for rate and offset correction.
CorrectionProps Props
globalTime AbstractGlobalTime 0..1 aggr Additional properties of the GlobalTimeDomain.
Domain DomainProps
Stereotypes: atpVariation
Property
Tags:vh.latestBindingTime=postBuild
5

709 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class GlobalTimeDomain
globalTime GlobalTimeMaster 0..1 aggr This represents the single master of a GlobalTime
Master Domain. A GlobalTimeDomain may have no GlobalTime
Domain.master, e.g. when it gets its time from a GPS
receiver.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
globalTimeSub GlobalTimeDomain * ref By this means it is possible to create a hierarchy of sub
Domain Domains where one global time domain can declare one
or more other global time domains as its subDomains.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
network NetworkSegment 0..1 aggr Defines the numerical identification of a GlobalTime sub
SegmentId Identification domain.
offsetTime GlobalTimeDomain 0..1 ref Reference to a synchronized time domain this offset time
Domain domain is based on. The reference source is the offset
time domain. The reference target is the synchronized
time domain.
pduTriggering PduTriggering 0..1 ref This PduTriggering will be taken to transmit the global
time information from a GlobalTimeMaster to a the
associated GlobalTimeSlaves.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
slave GlobalTimeSlave * aggr This represents the collections of slaves of the Global
TimeDomain. A GlobalTimeDomain may have no Global
TimeDomain.slaves, e.g. when it propagates its time
directly to sub domains.
Stereotypes: atpVariation
Tags:vh.latestBindingTime=postBuild
syncLoss TimeValue 0..1 attr This attribute describes the timeout for the situation that
Timeout the time synchronization gets lost in the scope of the time
domain.
Table 9.1: GlobalTimeDomain

Class AbstractGlobalTimeDomainProps (abstract)

Package M2::AUTOSARTemplates::SystemTemplate::GlobalTime
Note This abstract class enables a GlobalTimeDomain to specify additional properties.
Base ARObject
Subclasses CanGlobalTimeDomainProps, EthGlobalTimeDomainProps, FrGlobalTimeDomainProps
Attribute Type Mult. Kind Note
– – – – –
Table 9.2: AbstractGlobalTimeDomainProps

Class NetworkSegmentIdentification
Package M2::AUTOSARTemplates::SystemTemplate::GlobalTime
Note This meta-class represents the ability to identify the PhysicalChannel on a system scope in a numerical
way. One possible application of this approach is the Time Validation.
Base ARObject
Attribute Type Mult. Kind Note
5

710 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class NetworkSegmentIdentification
network PositiveInteger 0..1 attr This attribute represents the numerical identifier of a
SegmentId PhysicalChannel on system level scope.

Table 9.3: NetworkSegmentIdentification

Class GlobalTimeMaster (abstract)

Package M2::AUTOSARTemplates::SystemTemplate::GlobalTime
Note This represents the generic concept of a global time master.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Subclasses GlobalTimeCanMaster, GlobalTimeEthMaster, GlobalTimeFrMaster, UserDefinedGlobalTimeMaster
Attribute Type Mult. Kind Note
communication Communication 1 ref The GlobalTimeMaster is bound to the Communication
Connector Connector Connector.
immediate TimeValue 0..1 attr Defines the minimum time between an "immediate"
ResumeTime message and the next periodic message.
isSystemWide Boolean 1 attr If set to TRUE, the GlobalTimeMaster is supposed to act
GlobalTime as the root of global time information.
Master
syncPeriod TimeValue 1 attr This represents the period. Unit: seconds

Table 9.4: GlobalTimeMaster

Class GlobalTimeSlave (abstract)

Package M2::AUTOSARTemplates::SystemTemplate::GlobalTime
Note This represents the generic concept of a global time slave.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Subclasses GlobalTimeCanSlave, GlobalTimeEthSlave, GlobalTimeFrSlave, UserDefinedGlobalTimeSlave
Attribute Type Mult. Kind Note
communication Communication 1 ref The GlobalTimeSlave is bound to the Communication
Connector Connector Connector.
followUp TimeValue 0..1 attr Rx timeout for the follow-up message.
TimeoutValue
timeLeapFuture TimeValue 0..1 attr Defines the maximum allowed positive difference
Threshold between the current Local Time Base value and a newly
received Global Time Base value.
timeLeap PositiveInteger 0..1 attr Defines the required number of updates to the Time Base
HealingCounter where the time difference to the previous received value
has to remain within the bounds of timeLeapFuture
Threshold and timeLeapPastThreshold until that Time
Base is considered healed.
timeLeapPast TimeValue 0..1 attr Defines the maximum allowed negative difference
Threshold between the current Local Time Base value and a newly
received Global Time Base value.

Table 9.5: GlobalTimeSlave

Class GlobalTimeGateway
Package M2::AUTOSARTemplates::SystemTemplate::GlobalTime
Note This represents the ability to define a time gateway for establishing a global time domain over several
communication clusters.
5

711 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class GlobalTimeGateway
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
host EcuInstance 1 ref The GlobalTimeGateway is hosted by the referenced Ecu
Instance.
master GlobalTimeMaster 1 ref This represents the master of the global time gateway.
slave GlobalTimeSlave 1 ref This represents the slave of the GlobalTimeGateway.

Table 9.6: GlobalTimeGateway

[TPS_SYST_02115] Applicability of GlobalTimeDomain.globalTimeDomain-

Property dThe defined properties at GlobalTimeDomain.globalTimeDomain-
Property may be defined individually per GlobalTimeDomain. This allows to define
different value sets for each GlobalTimeDomain and any of the sub-domains.c()
[TPS_SYST_02163] Applicability of syncLossTimeout dGlobalTimeDomain.
syncLossTimeout shall be specified for GlobalTimeDomains that have an aggre-
gated slave and for all other cases this attribute is not applicable.c()
Class GlobalTimeCorrectionProps
Package M2::AUTOSARTemplates::SystemTemplate::GlobalTime
Note This meta-class defines the attributes for rate and offset correction.
Base ARObject
Attribute Type Mult. Kind Note
offsetCorrection TimeValue 0..1 attr Defines the interval during which the adaptive rate
AdaptionInterval correction cancels out the rate- and time deviation.
offsetCorrection TimeValue 0..1 attr Threshold for the correction method. Deviations below
JumpThreshold this value will be corrected by a linear reduction over a
defined timespan. Values equal- and greater than this
value will be corrected by immediately setting the correct
time- and rate in form of a jump.
rateCorrection TimeValue 0..1 attr Definition of the time span which is used to calculate the
Measurement rate deviation.
Duration
rateCorrections PositiveInteger 0..1 attr Defines the number of simultaneous rate measurements
Per to determine the current rate deviation.
Measurement
Duration
Table 9.7: GlobalTimeCorrectionProps

9.3 Detailed Description of Global Time Synchronization

This chapter describes how the concept of global time synchronization is applied to
various communication bus systems.
Although the characteristics of the supported bus systems differ widely in terms of their
communication behavior, the modeling is actually quite similar for all of the supported
bus systems.

712 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

9.3.1 Time Synchronization over CAN

This chapter described the detailing of how the concept of global time synchronization
is applied to the CAN bus in particular.
The implementation of global time synchronization on the CAN bus is modeled by
means of GlobalTimeCanMaster, a concrete subclass of GlobalTimeMaster. A
similar approach applies for the GlobalTimeCanSlave, which is derived from Glob-
alTimeSlave.
Identifiable
GlobalTimeMaster

+ immediateResumeTime: TimeValue [0..1]

+ isSystemWideGlobalTimeMaster: Boolean
+ syncPeriod: TimeValue

GlobalTimeCanMaster «enumeration»
GlobalTimeCrcSupportEnum
+ crcSecured: GlobalTimeCrcSupportEnum [0..1]
+ syncConfirmationTimeout: TimeValue crcSupported
crcNotSupported

Figure 9.6: Modeling of the GlobalTimeCanMaster

Identifiable
GlobalTimeSlave

+ followUpTimeoutValue: TimeValue [0..1]

+ timeLeapFutureThreshold: TimeValue [0..1]
+ timeLeapHealingCounter: PositiveInteger [0..1]
+ timeLeapPastThreshold: TimeValue [0..1]

«enumeration»
GlobalTimeCanSlave GlobalTimeCrcValidationEnum
+ crcValidated: GlobalTimeCrcValidationEnum crcValidated
+ sequenceCounterJumpWidth: PositiveInteger [0..1]
crcNotValidated
crcIgnored
crcOptional

Figure 9.7: Modeling of the GlobalTimeCanSlave

In addition to the CAN specific Master and Slave properties CAN specific CanGlob-
alTimeDomainProps can be described.

713 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

«atpVariation»

+globalTimeSubDomain 0..*

FibexElement
+offsetTimeDomain 0..1
GlobalTimeDomain

+ debounceTime: TimeValue [0..1]

+ domainId: PositiveInteger
+ syncLossTimeout: TimeValue [0..1]
+networkSegmentId NetworkSegmentIdentification
0..1 + networkSegmentId: PositiveInteger [0..1]

«atpVariation»
+globalTimeDomainProperty 0..1

AbstractGlobalTimeDomainProps

CanGlobalTimeDomainProps

+ fupDataIDList: PositiveInteger [0..16] {ordered}

+ ofnsDataIDList: PositiveInteger [0..16] {ordered}
+ ofsDataIDList: PositiveInteger [0..16] {ordered}
+ syncDataIDList: PositiveInteger [0..16] {ordered}

Figure 9.8: Modeling of the CAN specific CanGlobalTimeDomainProps

Class GlobalTimeCanMaster
Package M2::AUTOSARTemplates::SystemTemplate::GlobalTime::CAN
Note This represents the specialization of the GlobalTimeMaster for the CAN communication.
Base ARObject, GlobalTimeMaster , Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
crcSecured GlobalTimeCrcSupport 0..1 attr Definition of whether or not CRC is supported. This is
Enum only relevant for selected bus systems.
sync TimeValue 1 attr This represents the value for the confirmation timeout.
Confirmation Unit: seconds.
Timeout
Table 9.8: GlobalTimeCanMaster

Class GlobalTimeCanSlave
Package M2::AUTOSARTemplates::SystemTemplate::GlobalTime::CAN
Note This represents the specialization of the GlobalTimeSlave for the CAN communication.
Base ARObject, GlobalTimeSlave, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
crcValidated GlobalTimeCrc 1 attr Definition of whether or not validation of the CRC is
ValidationEnum supported.
sequence PositiveInteger 0..1 attr Specifies the maximum allowed gap of the sequence
CounterJump counter between two SYNC resp. two OFS messages.
Width
Table 9.9: GlobalTimeCanSlave

Class CanGlobalTimeDomainProps
Package M2::AUTOSARTemplates::SystemTemplate::GlobalTime::CAN
Note Enables the definition of Can Global Time specific properties.
Base ARObject, AbstractGlobalTimeDomainProps
5

714 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class CanGlobalTimeDomainProps
Attribute Type Mult. Kind Note
fupDataIDList PositiveInteger 0..16 attr The DataIDList for FUP messages to calculate CRC.
(ordered)
ofnsDataIDList PositiveInteger 0..16 attr The DataIDList for OFNS messages to calculate CRC.
(ordered)
ofsDataIDList PositiveInteger 0..16 attr The DataIDList for OFS messages to calculate CRC.
(ordered)
syncDataIDList PositiveInteger 0..16 attr The DataIDList for SYNC messages to calculate CRC.
(ordered)

Table 9.10: CanGlobalTimeDomainProps

9.3.2 Time Synchronization over Ethernet

This chapter described the detailing of how the concept of global time synchroniza-
tion is applied to the Ethernet bus in particular. For details concerning the functional
behavior please refer to [42].
The implementation of global time synchronization on the Ethernet bus is modeled
by means of GlobalTimeEthMaster, a concrete subclass of GlobalTimeMaster.
A similar approach applies for the GlobalTimeEthSlave, which is derived from
GlobalTimeSlave.
Identifiable
«enumeration»
GlobalTimeMaster
GlobalTimeCrcSupportEnum
+ immediateResumeTime: TimeValue [0..1]
crcSupported
+ isSystemWideGlobalTimeMaster: Boolean
crcNotSupported
+ syncPeriod: TimeValue

GlobalTimeEthMaster

+ crcSecured: GlobalTimeCrcSupportEnum [0..1]

+subTlvConfig 0..1

EthTSynSubTlvConfig

+ ofsSubTlv: Boolean [0..1]

+ statusSubTlv: Boolean [0..1]
+ timeSubTlv: Boolean [0..1]
+ userDataSubTlv: Boolean [0..1]

Figure 9.9: Modeling of the GlobalTimeEthMaster

715 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Identifiable
GlobalTimeSlave

+ followUpTimeoutValue: TimeValue [0..1]

+ timeLeapFutureThreshold: TimeValue [0..1]
+ timeLeapHealingCounter: PositiveInteger [0..1]
+ timeLeapPastThreshold: TimeValue [0..1]

GlobalTimeEthSlave «enumeration»
GlobalTimeCrcValidationEnum
+ crcValidated: GlobalTimeCrcValidationEnum [0..1]
crcValidated
crcNotValidated
crcIgnored
crcOptional

Figure 9.10: Modeling of the GlobalTimeEthSlave

«atpVariation»

+globalTimeSubDomain 0..*

FibexElement
GlobalTime::GlobalTimeDomain

+ debounceTime: TimeValue [0..1] +offsetTimeDomain 0..1

+ domainId: PositiveInteger
+ syncLossTimeout: TimeValue [0..1]

«atpVariation»
+globalTimeDomainProperty 0..1

GlobalTime::
AbstractGlobalTimeDomainProps «enumeration»
EthGlobalTimeMessageFormatEnum

IEEE802_1AS
IEEE802_1AS_AUTOSAR

EthTSynCrcFlags
EthGlobalTimeDomainProps
+ crcCorrectionField: Boolean [0..1]
+ destinationPhysicalAddress: MacAddressString [0..1] +crcFlags + crcDomainNumber: Boolean [0..1]
+ fupDataIDList: PositiveInteger [0..16] {ordered} 0..1 + crcMessageLength: Boolean [0..1]
+ messageCompliance: EthGlobalTimeMessageFormatEnum + crcPreciseOriginTimestamp: Boolean [0..1]
+ vlanPriority: PositiveInteger [0..1] + crcSequenceId: Boolean [0..1]
+ crcSourcePortIdentity: Boolean [0..1]

Figure 9.11: Modeling of the EthGlobalTimeDomainProps

Class GlobalTimeEthMaster
Package M2::AUTOSARTemplates::SystemTemplate::GlobalTime::ETH
Note This represents the specialization of the GlobalTimeMaster for Ethernet communication.
Base ARObject, GlobalTimeMaster , Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
crcSecured GlobalTimeCrcSupport 0..1 attr Definition of whether or not CRC is supported. This is
Enum only relevant for selected bus systems.
subTlvConfig EthTSynSubTlvConfig 0..1 aggr Defines the subTLV fields which shall be included in the
time sync message.

Table 9.11: GlobalTimeEthMaster

Class EthTSynSubTlvConfig
Package M2::AUTOSARTemplates::SystemTemplate::GlobalTime::ETH
Note Defines the subTLV fields which shall be included in the time sync message.
5

716 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class EthTSynSubTlvConfig
Base ARObject
Attribute Type Mult. Kind Note
ofsSubTlv Boolean 0..1 attr Defines whether an AUTOSAR Follow_Up TLV OFS
Sub-TLV is used.
statusSubTlv Boolean 0..1 attr Defines whether an AUTOSAR Follow_Up TLV Status
Sub-TLV is used.
timeSubTlv Boolean 0..1 attr Defines whether an AUTOSAR Follow_Up TLV Time
Sub-TLV is used.
userDataSubTlv Boolean 0..1 attr Defines whether an AUTOSAR Follow_Up TLV UserData
Sub-TLV is used.

Table 9.12: EthTSynSubTlvConfig

Class GlobalTimeEthSlave
Package M2::AUTOSARTemplates::SystemTemplate::GlobalTime::ETH
Note This represents the specialization of the GlobalTimeSlave for Ethernet communication.
Base ARObject, GlobalTimeSlave, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
crcValidated GlobalTimeCrc 0..1 attr Definition of whether or not validation of the CRC is
ValidationEnum supported.

Table 9.13: GlobalTimeEthSlave

Class EthGlobalTimeDomainProps
Package M2::AUTOSARTemplates::SystemTemplate::GlobalTime::ETH
Note Enables the definition of Ethernet Global Time specific properties.
Base ARObject, AbstractGlobalTimeDomainProps
Attribute Type Mult. Kind Note
crcFlags EthTSynCrcFlags 0..1 aggr Defines the fields of the message which shall be taken
into account for CRC calculation and verification.
destination MacAddressString 0..1 attr Defines the MAC multicast address the Ethernet time
Physical sync messages are communicated on.
Address
fupDataIDList PositiveInteger 0..16 attr The DataIDList for FUP messages to calculate CRC.
(ordered)
managed EthGlobalTime * aggr Collection of CouplingPorts which are managed in the
CouplingPort ManagedCouplingPort scope of this Ethernet GlobalTimeDomain.
message EthGlobalTimeMessage 1 attr Defines the compliance of the Ethernet time sync
Compliance FormatEnum messages to specific standards.
vlanPriority PositiveInteger 0..1 attr Defines which VLAN priority shall be assigned to a time
sync message in case the message is sent using a VLAN
tag.

Table 9.14: EthGlobalTimeDomainProps

Class EthTSynCrcFlags
Package M2::AUTOSARTemplates::SystemTemplate::GlobalTime::ETH
Note Defines the fields of the message which shall be taken into account for CRC calculation and verification.
5

717 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class EthTSynCrcFlags
Base ARObject
Attribute Type Mult. Kind Note
crcCorrection Boolean 0..1 attr CorrectionField from the Follow_Up Message Header
Field shall be included in CRC calculation.
crcDomain Boolean 0..1 attr DomainNumber from the Follow_Up Message Header
Number shall be included in CRC calculation.
crcMessage Boolean 0..1 attr MessageLength from the Follow_Up Message Header
Length shall be included in CRC calculation.
crcPrecise Boolean 0..1 attr PreciseOriginTimestamp from the Follow_Up Message
Origin Field shall be included in CRC calculation.
Timestamp
crcSequenceId Boolean 0..1 attr SequenceId from the Follow_Up Message Header shall
be included in CRC calculation.
crcSourcePort Boolean 0..1 attr SourcePortIdentity from the Follow_Up Message Header
Identity shall be included in CRC calculation.

Table 9.15: EthTSynCrcFlags

Enumeration EthGlobalTimeMessageFormatEnum
Package M2::AUTOSARTemplates::SystemTemplate::GlobalTime::ETH
Note Specifies which message formats are available to for the Ethernet time sync protocol.
Literal Description
IEEE802_1AS Message format according to IEEE 802.1AS standard.
Tags:
atp.EnumerationLiteralIndex=0
xml.name=IEEE802-1AS
IEEE802_1AS_ Message format according to IEEE 802.1AS standard with AUTOSAR extensions.
AUTOSAR
Tags:
atp.EnumerationLiteralIndex=1
xml.name=IEEE802-1AS-AUTOSAR

Table 9.16: EthGlobalTimeMessageFormatEnum

[constr_3312] Consistency of vlanPriority and EthernetCommunication-

Connector dA GlobalTimeEthMaster refers to an EthernetCommunication-
Connector in the role communicationConnector. If that EthernetCommuni-
cationConnector is referenced by an EthernetPhysicalChannel in the role
commConnector and the EthernetPhysicalChannel has a vLan tag defined via
the VlanConfig then the GlobalTimeDomain of the GlobalTimeEthMaster shall
aggregate EthGlobalTimeDomainProps in the role globalTimeDomainProp-
erty and the attribute EthGlobalTimeDomainProps.vlanPriority shall exist.c
()
In Ethernet networks the usage of Ethernet switches introduces another layer of de-
lay in the transportation of data. This of course also applies to the global time syn-
chronization messages and there are means to compensate these delays available in
AUTOSAR.
In order to cope with delays on global time sync of Ethernet transport technology two
use-cases are supported:

718 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• an ECU is connected to an Ethernet switch but does not manage the switch (see
section 9.3.2.2)
• an ECU is connected to an Ethernet switch and also manages this switch (see
section 9.3.2.3)
The CouplingPort is used in either use-case to describe the connection of the ECU
to the Ethernet network / switch. Thus there are some attributes related to the Cou-
plingPort which apply to both use-cases.

9.3.2.1 Time Synchronization and Ethernet propagation delay

The propagation delay measurement is applicable to the CouplingPort in scope of

the global time synchronization.
The default propagation delay time (which is used if propagation delay measurement is
disabled or is not yet measured) is defined at the GlobalTimeCouplingPortProps
with the attribute propagationDelay. The GlobalTimeCouplingPortProps are
aggregated at the CouplingPortDetails in the role globalTimeProps.
Whether an ECU shall initiate a propagation delay measurement at a certain Cou-
plingPort and on a specific GlobalTimeDomain is defined by the attribute pde-
layRequestPeriod at the EthGlobalTimeManagedCouplingPort.
[TPS_SYST_03016] Applicability of EthGlobalTimeManagedCouplingPort.
pdelayRequestPeriod dWhen EthGlobalTimeManagedCouplingPort.pde-
layRequestPeriod is not defined or has the value 0 then initiation of propagation
delay measurement is disabled for the CouplingPort referenced by couplingPort
and the GlobalTimeDomain the EthGlobalTimeManagedCouplingPort belongs
to.c()
Whether an ECU shall respond to propagation delay measurement at a certain Cou-
plingPort and on a specific GlobalTimeDomain is defined by the attribute pde-
layResponseEnabled at the EthGlobalTimeManagedCouplingPort.

9.3.2.2 Time Synchronization and Ethernet connection

In case the ECU is directly connected to the Ethernet network and does not manage
an Ethernet switch (of course there may be Ethernet switches used in the topology,
but for this use-case these switches are not visible to the description of this ECU) the
Ethernet time synchronization only needs to cope with the connection of this ECU to
the Ethernet network. Considering the example in figure 9.13 this applies to the ECUs
TS1, TS2, TS3, and TM which are just connected to the Ethernet switches but do not
manage any Ethernet switch.

719 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_03017] Reference to CouplingPort in the context of a Global-

TimeDomain dIn case a GlobalTimeDomain is communicated via a Coupling-
Port and the respective ECU does not manage an Ethernet switch then the refer-
ence EthGlobalTimeManagedCouplingPort.couplingPort shall reference a
CouplingPort which is aggregated by the EthernetCommunicationController
in the role couplingPort. The EthernetCommunicationController itself shall
be referenced by a GlobalTimeMaster or GlobalTimeEthSlave (via the Com-
municationConnector) and that GlobalTimeMaster or GlobalTimeEthSlave
shall be aggregated by the GlobalTimeDomain initially mentioned.c()
EthGlobalTimeDomainProps EthGlobalTimeManagedCouplingPort

+ destinationPhysicalAddress: MacAddressString [0..1] +managedCouplingPort + pdelayLatencyThreshold: TimeValue [0..1]

+ fupDataIDList: PositiveInteger [0..16] {ordered} 0..* + pdelayRequestPeriod: TimeValue [0..1]
+ messageCompliance: EthGlobalTimeMessageFormatEnum + pdelayRespAndRespFollowUpTimeout: TimeValue [0..1]
+ vlanPriority: PositiveInteger [0..1] + pdelayResponseEnabled: Boolean

AbstractGlobalTimeDomainProps
GlobalTimeCouplingPortProps
+globalTimeDomainProperty 0..1
«atpVariation» + propagationDelay: TimeValue
«atpVariation»
+globalTimeSubDomain 0..*
+globalTimeProps 0..1
FibexElement
GlobalTimeDomain CouplingPortDetails
+ debounceTime: TimeValue [0..1]
+ domainId: PositiveInteger +couplingPortDetails 0..1
+ syncLossTimeout: TimeValue [0..1] +couplingPort 0..1

Identifiable
CouplingPort

«atpVariation» «atpVariation»
+slave 0..* +globalTimeMaster +couplingPort 0..*
0..1
Identifiable Identifiable
FibexElement
GlobalTimeSlave GlobalTimeMaster
EcuInstance
+ followUpTimeoutValue: TimeValue [0..1] + immediateResumeTime: TimeValue [0..1]
+ timeLeapFutureThreshold: TimeValue [0..1] + isSystemWideGlobalTimeMaster: Boolean
+ timeLeapHealingCounter: PositiveInteger [0..1] + syncPeriod: TimeValue
+ timeLeapPastThreshold: TimeValue [0..1]

«atpVariation»
+communicationConnector 1
+connector *
+communicationConnector Identifiable

1 CommunicationConnector «atpVariation»

GlobalTimeEthSlave

+ crcValidated: GlobalTimeCrcValidationEnum [0..1] +commController 1 +commController 1..*

Identifiable
«atpVariation»
CommunicationController
GlobalTimeEthMaster

+ crcSecured: GlobalTimeCrcSupportEnum [0..1]

EthernetCommunicationController

Figure 9.12: Overview of the Ethernet time sync in relation with a CouplingPort of an
ECU

9.3.2.3 Time Synchronization and managed Ethernet switch

In case an ECU manages an Ethernet switch then that management ECU can basically
be the GlobalTimeEthMaster or the GlobalTimeEthSlave located (see also fig-
ure 9.13). For the description of the time delay compensation on System Template
level this does not matter.

720 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

It is essential to configure all possible time synchronization communication paths be-

tween the involved entities.
In case of ECU A in figure 9.13 the GlobalTimeEthMaster shall
• refer to the CouplingPort 0 since this is where
– all time sync messages will be sent out by the GlobalTimeEthMaster
– all adjusted follow up messages will be sent out by the GlobalTimeEth-
Master
• refer to the CouplingPort 1 because this is where the Ethernet switch is con-
nected to the management ECU A
• refer to the CouplingPorts 2, 3, and 4 since this is where the time sync mes-
sages will be forwarded by the switch
• not refer to the CouplingPort 5 because this one is not involved in that Glob-
alTimeDomains communication
In case of ECU B in figure 9.13 the GlobalTimeEthSlave shall
• refer to the CouplingPort 0 since this is where
– the time sync messages will be received by the GlobalTimeEthSlave
– all adjusted follow up messages will be sent out by the GlobalTimeEth-
Slave
• refer to the CouplingPort 1 because this is where the Ethernet switch is con-
nected to the management ECU B
• refer to the CouplingPort 3 because this is where the time sync messages will
be received from the GlobalTimeEthMaster on ECU TM
• refer to the CouplingPorts 2 and 4 since this is where the time sync messages
will be forwarded by the switch
• not refer to the CouplingPort 5 because this one is not involved in that Glob-
alTimeDomains communication
Please note that the non-involvement of the CouplingPort 5 is used for illustration
purposes. It would also be possible to involve CouplingPort 5 in that GlobalTime-
Domain definition although currently there is no ECU as an GlobalTimeEthSlave
defined. In that case the CouplingPort 5 is prepared to be connected to an ECU
with an GlobalTimeEthSlave later.

721 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Ethernet Switch Ethernet Switch

Management ECU A Management ECU B

Global time master Global time slave

0 0

1 1

Switch Switch
2 3 4 5 2 3 4 5

0 0 0 0 0 0

TS1 TS2 TS3 TS1 TM TS3

Figure 9.13: Example of a managed Ethernet Switch

722 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

EthGlobalTimeManagedCouplingPort

+ pdelayLatencyThreshold: TimeValue [0..1]

+ pdelayRequestPeriod: TimeValue [0..1]
+ pdelayRespAndRespFollowUpTimeout: TimeValue [0..1]
+ pdelayResponseEnabled: Boolean

GlobalTimeCouplingPortProps
+managedCouplingPort 0..*
+ propagationDelay: TimeValue

EthGlobalTimeDomainProps
+globalTimeProps 0..1
+ destinationPhysicalAddress: MacAddressString [0..1]
+ fupDataIDList: PositiveInteger [0..16] {ordered}
+ messageCompliance: EthGlobalTimeMessageFormatEnum CouplingPortDetails
+ vlanPriority: PositiveInteger [0..1]
+couplingPortDetails 0..1
+couplingPort 0..1
AbstractGlobalTimeDomainProps Identifiable
CouplingPort
+globalTimeDomainProperty 0..1
«atpVariation»
«atpVariation»
+globalTimeSubDomain 0..* +couplingPort 0..*

FibexElement «atpVariation,atpSplitable»

GlobalTimeDomain

+ debounceTime: TimeValue [0..1] FibexElement

+ domainId: PositiveInteger
CouplingElement
+ syncLossTimeout: TimeValue [0..1]
+ couplingType: CouplingElementEnum

«atpVariation» «atpVariation»
+ecuInstance 0..1
+slave 0..* +globalTimeMaster 0..1
FibexElement
Identifiable Identifiable
EcuInstance
GlobalTimeSlave GlobalTimeMaster

+ followUpTimeoutValue: TimeValue [0..1] + immediateResumeTime: TimeValue [0..1]

+ timeLeapFutureThreshold: TimeValue [0..1] + isSystemWideGlobalTimeMaster: Boolean
+ timeLeapHealingCounter: PositiveInteger [0..1] + syncPeriod: TimeValue
+ timeLeapPastThreshold: TimeValue [0..1]
«atpVariation»
+communicationConnector 1 +connector *
Identifiable
+communicationConnector CommunicationConnector
«atpVariation»
1
GlobalTimeEthSlave

+ crcValidated: GlobalTimeCrcValidationEnum [0..1] +commController 1 +commController 1..*

Identifiable
«atpVariation»
CommunicationController
GlobalTimeEthMaster

+ crcSecured: GlobalTimeCrcSupportEnum [0..1]

Figure 9.14: Overview of the Ethernet time sync in relation with a CouplingPort of an
Ethernet switch

Class EthGlobalTimeManagedCouplingPort
Package M2::AUTOSARTemplates::SystemTemplate::GlobalTime::ETH
Note Specifies a CouplingPort which is managed by an Ethernet Global Time Domain.
Base ARObject
Attribute Type Mult. Kind Note
couplingPort CouplingPort 0..1 ref Defines which CouplingPort is managed by this EthGlobal
TimeManagedCouplingPort.
pdelayLatency TimeValue 0..1 attr Threshold for calculated Pdelay. If a measured Pdelay
Threshold exceeds pdelayLatencyThreshold, the measured Pdelay
value is discarded.
pdelayRequest TimeValue 0..1 attr Defines the period for the pdelay request messages.
Period
5

723 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class EthGlobalTimeManagedCouplingPort
pdelayRespAnd TimeValue 0..1 attr Timeout value for Pdelay_Resp and Pdelay_Resp_
RespFollowUp Follow_Up after a Pdelay_Req has been transmitted resp.
Timeout a Pdelay_Resp has been received. A value of 0 or not
defining this attribute deactivates this timeout observation.
pdelay Boolean 1 attr Defines whether PDELAY RESPONSE and PDELAY
Response RESPONSE FOLLOW UP shall be sent on this Coupling
Enabled Port.
Table 9.17: EthGlobalTimeManagedCouplingPort

Class GlobalTimeCouplingPortProps
Package M2::AUTOSARTemplates::SystemTemplate::Fibex::Fibex4Ethernet::EthernetTopology
Note Defines properties for the usage of the CouplingPort in the scope of Global Time Sync.
Base ARObject
Attribute Type Mult. Kind Note
propagation TimeValue 1 attr If cyclic propagation delay measurement is enabled, this
Delay parameter represents the default value of the propagation
delay until the first actually measured propagation delay is
available. If cyclic propagation delay measurement is
disabled, this parameter defines a fixed value for the
propagation delay.

Table 9.18: GlobalTimeCouplingPortProps

9.3.3 Time Synchronization over FlexRay

This chapter described the detailing of how the concept of global time synchronization
is applied to the Flexray bus in particular.
The implementation of global time synchronization on the Flexray bus is modeled by
means of GlobalTimeFrMaster, a concrete subclass of GlobalTimeMaster. A
similar approach applies for the GlobalTimeFrSlave, which is derived from Glob-
alTimeSlave.
Identifiable
GlobalTimeMaster

+ immediateResumeTime: TimeValue [0..1]

+ isSystemWideGlobalTimeMaster: Boolean
+ syncPeriod: TimeValue

GlobalTimeFrMaster «enumeration»
GlobalTimeCrcSupportEnum
+ crcSecured: GlobalTimeCrcSupportEnum
crcSupported
crcNotSupported

Figure 9.15: Modeling of the GlobalTimeFrMaster

724 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Identifiable
GlobalTimeSlave

+ followUpTimeoutValue: TimeValue [0..1]

+ timeLeapFutureThreshold: TimeValue [0..1]
+ timeLeapHealingCounter: PositiveInteger [0..1]
+ timeLeapPastThreshold: TimeValue [0..1]

«enumeration»
GlobalTimeFrSlave
GlobalTimeCrcValidationEnum
+ crcValidated: GlobalTimeCrcValidationEnum
crcValidated
+ sequenceCounterJumpWidth: PositiveInteger [0..1]
crcNotValidated
crcIgnored
crcOptional

Figure 9.16: Modeling of the GlobalTimeFrSlave

In addition to the FlexRay specific Master and Slave properties FlexRay specific Fr-
GlobalTimeDomainProps can be described.
«atpVariation»

+globalTimeSubDomain 0..*

FibexElement
+offsetTimeDomain 0..1
GlobalTimeDomain

+ debounceTime: TimeValue [0..1]

+ domainId: PositiveInteger
+ syncLossTimeout: TimeValue [0..1] +networkSegmentId
NetworkSegmentIdentification
0..1
+ networkSegmentId: PositiveInteger [0..1]

«atpVariation»
+globalTimeDomainProperty 0..1

AbstractGlobalTimeDomainProps

FrGlobalTimeDomainProps

+ ofsDataIDList: PositiveInteger [0..16] {ordered}

+ syncDataIDList: PositiveInteger [0..16] {ordered}

Figure 9.17: Modeling of the FlexRay specific FrGlobalTimeDomainProps

Class GlobalTimeFrMaster
Package M2::AUTOSARTemplates::SystemTemplate::GlobalTime::FR
Note This represents the specialization of the GlobalTimeMaster for Flexray communication.
Base ARObject, GlobalTimeMaster , Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
crcSecured GlobalTimeCrcSupport 1 attr Definition of whether or not CRC is supported. This is
Enum only relevant for selected bus systems.

Table 9.19: GlobalTimeFrMaster

Class GlobalTimeFrSlave
Package M2::AUTOSARTemplates::SystemTemplate::GlobalTime::FR
Note This represents the specialization of the GlobalTimeSlave for Flexray communication.
Base ARObject, GlobalTimeSlave, Identifiable, MultilanguageReferrable, Referrable
5

725 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class GlobalTimeFrSlave
Attribute Type Mult. Kind Note
crcValidated GlobalTimeCrc 1 attr Definition of whether or not validation of the CRC is
ValidationEnum supported.
sequence PositiveInteger 0..1 attr Specifies the maximum allowed gap of the sequence
CounterJump counter between two SYNC resp. two OFS messages.
Width
Table 9.20: GlobalTimeFrSlave

Class FrGlobalTimeDomainProps
Package M2::AUTOSARTemplates::SystemTemplate::GlobalTime::FR
Note Enables the definition of Flexray GlobalTime specific properties.
Base ARObject, AbstractGlobalTimeDomainProps
Attribute Type Mult. Kind Note
ofsDataIDList PositiveInteger 0..16 attr The DataIDList for OFS messages to calculate CRC.
(ordered)
syncDataIDList PositiveInteger 0..16 attr The DataIDList for SYNC messages to calculate CRC.
(ordered)

Table 9.21: FrGlobalTimeDomainProps

9.3.4 Time Synchronization by user defined Timebase Provider

This chapter describes the details of how the concept of global time synchronization
is applied to user defined Timebase Providers. The implementation of global time
synchronization by user defined timebase providers is modeled by means of UserDe-
finedGlobalTimeMaster, a concrete subclass of GlobalTimeMaster. A similar
approach applies for the UserDefinedGlobalTimeSlave, which is derived from
GlobalTimeSlave.
GlobalTimeMaster

+ immediateResumeTime: TimeValue [0..1]

+ isSystemWideGlobalTimeMaster: Boolean
+ syncPeriod: TimeValue

UserDefinedGlobalTimeMaster

Figure 9.18: Modeling of the UserDefinedGlobalTimeMaster

726 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

GlobalTimeSlave

+ followUpTimeoutValue: TimeValue [0..1]

+ timeLeapFutureThreshold: TimeValue [0..1]
+ timeLeapHealingCounter: PositiveInteger [0..1]
+ timeLeapPastThreshold: TimeValue [0..1]

UserDefinedGlobalTimeSlave

Figure 9.19: Modeling of the UserDefinedGlobalTimeSlave

Class UserDefinedGlobalTimeMaster
Package M2::AUTOSARTemplates::SystemTemplate::GlobalTime::UserDefined
Note This represents the specialization of the GlobalTimeMaster for user defined communication.
Base ARObject, GlobalTimeMaster , Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
– – – – –
Table 9.22: UserDefinedGlobalTimeMaster

Class UserDefinedGlobalTimeSlave
Package M2::AUTOSARTemplates::SystemTemplate::GlobalTime::UserDefined
Note This represents the specialization of the GlobalTimeSlave for user defined communication.
Base ARObject, GlobalTimeSlave, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
– – – – –
Table 9.23: UserDefinedGlobalTimeSlave

9.3.5 Time Synchronization Common Properties

The purpose of this chapter is basically to provide the class tables of meta-classes
taken to implement configuration properties in the context of global time synchroniza-
tion. The specifics about how these meta-classes are used is explained in the bus-
specific chapters (i.e. chapters 9.3.1, 9.3.2, and 9.3.3).
Enumeration GlobalTimeCrcSupportEnum
Package M2::AUTOSARTemplates::SystemTemplate::GlobalTime
Note This enumeration is used to define whether and how CRC on the TX side shall be utilized.
Literal Description
crcNotSupported This indicates that CRC is not supported
Tags:atp.EnumerationLiteralIndex=0
5

727 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Enumeration GlobalTimeCrcSupportEnum
crcSupported This indicates that CRC is supported
Tags:atp.EnumerationLiteralIndex=1

Table 9.24: GlobalTimeCrcSupportEnum

Enumeration GlobalTimeCrcValidationEnum
Package M2::AUTOSARTemplates::SystemTemplate::GlobalTime
Note This enumeration provides values for the evaluation of the CRC
Literal Description
crcIgnored The CRC is supposed to be ignored
Tags:atp.EnumerationLiteralIndex=0
crcNotValidated The CRC is not supposed to be present. If CRC is present the message is ignored.
Tags:atp.EnumerationLiteralIndex=1
crcOptional Either the CRC is present and then shall be validated or the CRC is not present and no CRC check is
done.
Tags:atp.EnumerationLiteralIndex=3
crcValidated This CRC is supposed to be validated.
Tags:atp.EnumerationLiteralIndex=2

Table 9.25: GlobalTimeCrcValidationEnum

728 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

10 Description of Service Discovery Services in

Classic Platform

10.1 Representation of Service Interfaces on VFB level

ServiceInterfaces in the Adaptive Platform and in SOME/IP consist of Events,
Fields and Methods. AUTOSAR classic platform does not support ServiceIn-
terfaces but provides the possibility to communicate in a service oriented way over
SOME/IP.
To mimic a ServiceInterface in the Classic Platform any combination of
ClientServerInterfaces, SenderReceiverInterfaces or TriggerInter-
faces may be used.
[TPS_SYST_02283] Collection of ServiceInterface elements dThe collection
of PortInterfaces that represent one ServiceInterface shall be wrapped
by a Collection element with category SET and collectionSemantics
SO_SERVICE_INTERFACE.c()
An example of ServiceInterface named RadarService is shown in the following
listing.
Listing 10.1: Example for a ServiceInterface Collection
<AR-PACKAGE>
<SHORT-NAME>ServiceInterfaces</SHORT-NAME>
<ELEMENTS>

<COLLECTION>
<SHORT-NAME>RadarService</SHORT-NAME>
<CATEGORY>SET</CATEGORY>
<COLLECTION-SEMANTICS>SO_SERVICE_INTERFACE</COLLECTION-SEMANTICS>
<ELEMENT-REFS>
<ELEMENT-REF DEST="VARIABLE-DATA-PROTOTYPE">/PortInterfaces/
RadarService_BrakeEvent/BrakeEvent</ELEMENT-REF>
<ELEMENT-REF DEST="CLIENT-SERVER-OPERATION">/PortInterfaces/
RadarService_Methods/Calibrate</ELEMENT-REF>
<ELEMENT-REF DEST="CLIENT-SERVER-OPERATION">/PortInterfaces/
RadarService_Methods/Adjust</ELEMENT-REF>
<ELEMENT-REF DEST="COLLECTION">/Fields/RadarService_UpdateRate</
ELEMENT-REF>
<ELEMENT-REF DEST="COLLECTION">/FireAndForgetMethods/
RadarService_FireAndForgetMethods</ELEMENT-REF>
</ELEMENT-REFS>
</COLLECTION>
</ELEMENTS>
</AR-PACKAGE>

The RadarService in this example consist of:

• an Event named BrakeEvent,
• a Method named Calibrate,

729 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• a Method named Adjust,

• a Field named RadarService_UpdateRate,
• a Collection of Fire_And_Forget Methods.

10.1.1 Representation of Events

[TPS_SYST_02284] Event in a ServiceInterface dAn event in a Servi-

ceInterface shall be described as a VariableDataPrototype in a Sender-
ReceiverInterface.c()
Please note that in SOME/IP and other description formats like ASAM FIBEX an Event
consist of one or several Parameters. In AUTOSAR an Event with several parame-
ters needs to be described as an VariableDataPrototype that is typed by an
AutosarDataType of category STRUCTURE. Each parameter of the Event shall be
represented as a member of the STRUCTURE.

10.1.2 Representation of Methods

[TPS_SYST_02285] Method in a ServiceInterface dA method of a ServiceIn-

terface shall be described as a ClientServerOperation in a ClientServer-
Interface.c()
Each method parameter shall be described as an argument of the ClientServer-
Operation. Please note that the order of method parameters is expressed by the
order of arguments.

10.1.3 Representation of Fire and Forget Methods

A so-called “fire & forget” method in SOME/IP represents a special form of a method
dedicated to the sole purpose of conveying information from the service consumer to
the service provider. The semantics of a “fire & forget” method is comparable to the
semantics of an event, only reverse. In case that the ServiceInterface contains
a “fire & forget” method the service consumer is able to call this method without the
expectation of any response from the service provider.
[TPS_SYST_02286] “fire & forget” method with data in a ServiceInterface dA
“fire & forget” method of a ServiceInterface that contains data shall be described
as a VariableDataPrototype in a SenderReceiverInterface. The service
provider will consume the VariableDataPrototype. The service consumer will
provide the VariableDataPrototype.c()

730 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

If such a “fire & forget” method contains several parameters the VariableDataPro-
totype shall be typed by an AutosarDataType of category STRUCTURE. Each pa-
rameter of the “fire & forget” method shall be represented as a member of the STRUC-
TURE.
[TPS_SYST_02287] “Fire & forget” method without data in a ServiceInterface
dA “fire & forget” method of a ServiceInterface that does not contain any data
shall be described as a Trigger in a TriggerInterface. The service provider will
consume the Trigger. The service consumer will provide the Trigger.c()
To distinguish “fire & forget” methods with parameters from Events a sub-collection is
introduced in the ServiceInterface Collection. The sub-collection refers to all “fire &
forget” methods represented as VariableDataPrototypes and Triggers that are
defined by the ServiceInterface.
[TPS_SYST_02288] “Fire & forget” method in a ServiceInterface
dThe “fire & forget” methods of ServiceInterface shall be wrapped by
a Collection element with category SET and collectionSemantics
SO_SERVICE_FIRE_AND_FORGET_METHODS.c()
Listing 10.2: Example for a fire & forget Method Collection
<AR-PACKAGE>
<SHORT-NAME>FireAndForgetMethods</SHORT-NAME>
<ELEMENTS>

<COLLECTION>
<SHORT-NAME>RadarService_FireAndForgetMethods</SHORT-NAME>
<CATEGORY>SET</CATEGORY>
<COLLECTION-SEMANTICS>SO_SERVICE_FIRE_AND_FORGET_METHODS</COLLECTION-
SEMANTICS>
<ELEMENT-REFS>
<ELEMENT-REF DEST="VARIABLE-DATA-PROTOTYPE">/PortInterfaces/
RadarService_Reset/Reset</ELEMENT-REF>
<ELEMENT-REF DEST="TRIGGER">/PortInterfaces/
RadarService_LogCurrentState/RadarService_LogCurrentState</
ELEMENT-REF>
</ELEMENT-REFS>
</COLLECTION>
</ELEMENTS>
</AR-PACKAGE>

10.1.4 Representation of Fields

A Field represents a piece of data hosted by a server that exposes to one or more
client(s) a get accessor and/or a set mutator. Clients can optionally receive notifications
of changes of the Field’s value. In addition a Field has a concrete value at any time.
As soon as the ServiceInterface is offered a Field of this ServiceInterface
can be accessed by a client.

731 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_02289] Field in a ServiceInterface dThe elements of a Field

shall be wrapped by a Collection element with category SET and collectionSe-
mantics SO_SERVICE_FIELD.c()
[TPS_SYST_02290] Field elements dA Collection element with category
SO_SERVICE_FIELD is allowed to contain one, two or all three of the following items:
• a reference to a VariableDataPrototype representing a Field Notifier,
• a reference to a ClientServerOperation representing a Field Getter,
• a reference to a ClientServerOperation representing a Field Setter.
c()
[TPS_SYST_02291] Field Notifier dA Field Notifier is represented by a
VariableDataPrototype in a SenderReceiverInterface.c()
[TPS_SYST_02292] Field Getter dA Field Getter is represented by a
ClientServerOperation with ArgumentDataPrototypes with direction
out.c()
After the getter call the requester will receive the current value of the Field in the
response.
[TPS_SYST_02293] Field Setter dA Field Setter is represented by a
ClientServerOperation with ArgumentDataPrototypes with direction out
and in.c()
Please note that it is the decision of the Service Provider to accept the setter request
or to deny it. The current value of the Field will always be sent back to the requester as
response.
Listing 10.3: Example for a Field Collection
<AR-PACKAGE>
<SHORT-NAME>Fields</SHORT-NAME>
<ELEMENTS>

<COLLECTION>
<SHORT-NAME>RadarService_UpdateRate</SHORT-NAME>
<CATEGORY>SET</CATEGORY>
<COLLECTION-SEMANTICS>SO_SERVICE_FIELD</COLLECTION-SEMANTICS>
<ELEMENT-REFS>
<ELEMENT-REF DEST="VARIABLE-DATA-PROTOTYPE">/PortInterfaces/
RadarService_UpdateRate_Notifier/UpdateRate</ELEMENT-REF>
<ELEMENT-REF DEST="CLIENT-SERVER-OPERATION">/PortInterfaces/
RadarService_UpdateRate_GetterSetter/Getter</ELEMENT-REF>
<ELEMENT-REF DEST="CLIENT-SERVER-OPERATION">/PortInterfaces/
RadarService_UpdateRate_GetterSetter/Setter</ELEMENT-REF>
</ELEMENT-REFS>
</COLLECTION>
</ELEMENTS>
</AR-PACKAGE>

732 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

10.2 Representation of Service Interfaces on network level

Elements of ServiceInterfaces are mapped by the DataMapping to System-
Signals and later to ISignals and ISignalIPdus for transport over the network.
For the serialization as an UINT8 Array two different Transformers are supported, as
defined in [TPS_SYST_02294] and [TPS_SYST_02295].
[TPS_SYST_02294] Serialization of ServiceInterfaces using ComBased-
Transformer dIf the ComBasedTransformer is used to serialize the members of
a ServiceInterface, then
• the SenderReceiverToSignalGroupMapping is used to map the Vari-
ableDataPrototype that represents an Event or Field Notifier to a
SystemSignalGroup. Please note that the datatype of an Event is a Struc-
ture as described above. Each primitive member of this Structure is mapped by
the SenderRecRecordElementMapping to a SystemSignal in the System-
SignalGroup. The SystemSignalGroup is mapped as ISignalGroup into
an ISignalIPdu that is transported over the network.
• the serialization of Methods, Field Setters, Field Getters by the Com-
BasedTransformer is not supported.
c()
[TPS_SYST_02295] Serialization of ServiceInterfaces using SomeipTrans-
former dIf the SomeipTransformer is used to serialize the members of a Servi-
ceInterface, then
• the SenderReceiverToSignalMapping is used to map the VariableDat-
aPrototype that represents the Event or Field Notifier to a single Sys-
temSignal. The SystemSignal is mapped as an ISignal into an ISig-
nalIPdu that is transported over the network.
• the ClientServerToSignalMapping is used to map the ClientServerOp-
eration that represents the Method or Field Setter or Field Getter to
a Call-SystemSignal and to a Return-SystemSignal. Both SystemSignals
are mapped as ISignals into dedicated ISignalIPdus that are transported
over the network.
• the SenderReceiverToSignalMapping is used to map the VariableDat-
aPrototype that represents the “fire & forget” method with data to a System-
Signal. The SystemSignal is mapped as ISignal into an ISignalIPdu
that is transported over the network. The messageType in the SOMEIPTrans-
formationISignalProps that is aggregated by the ISignal shall be set to
requestNoReturn.
• the TriggerToSignalMapping is used to map the Trigger that represents
the “fire & forget” method without data to a SystemSignal. The SystemSig-
nal is mapped as ISignal into an ISignalIPdu that is transported over the

733 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

network. The messageType in the SOMEIPTransformationISignalProps

that is aggregated by the ISignal shall be set to requestNoReturn.
c()
The ServiceInterfaces itself are represented as ServiceInstances in the Sys-
tem Description. The ProvidedServiceInstance is used to describe that a specific
instance of a ServiceInterface is provided on an ApplicationEndpoint. The
ConsumedServiceInstance is used to describe that a search for a specific instance
of a ServiceInterface is executed on an ApplicationEndpoint.
The Pdus that represent the elements of the ServiceInterface are attached to the
ServiceInstances via PduActivationRoutingGroups.
Please note that the Pdus that represent the Methods, “fire & forget” methods, Field
Setter and Field Getter are assigned to the ServiceInstance in a method-
ActivationRoutingGroup since they are activated by the SD module as soon as
the Service is offered.
The Pdus that represent the Events and Field Notifiers are assigned to Even-
tHandlers on the provided side as pduActivationRoutingGroups or to Con-
sumedEventGroups on the receiver side as pduActivationRoutingGroups.
[TPS_SYST_02296] eventGroupControlType of a unicast Event dIf the Pdu rep-
resents an Event that is transmitted or received over unicast then the eventGroup-
ControlType attribute of the PduActivationRoutingGroup that refers the Pdu
shall be set to activationUnicast.c()
[TPS_SYST_02297] eventGroupControlType of a multicast Event dIf the Pdu
represents an Event that is transmitted or received over multicast then the event-
GroupControlType attribute of the PduActivationRoutingGroup that refers the
Pdu shall be set to activationMulticast.c()
[TPS_SYST_02298] eventGroupControlType of a unicast Field dIf the Pdu rep-
resents a Field Notifier that is transmitted or received over unicast then either:
• two PduActivationRoutingGroups shall be used where:
– the eventGroupControlType attribute of the PduActivationRout-
ingGroup that refers the Pdu is set to activationUnicast.
– the eventGroupControlType attribute of the PduActivationRout-
ingGroup that refers the Pdu is set to triggerUnicast.
• or one PduActivationRoutingGroup shall be used where the eventGroup-
ControlType attribute of the PduActivationRoutingGroup that refers the
Pdu shall be set to activationAndTriggerUnicast.
c()
With this approach it is ensured that the current value of the Field is sent back imme-
diately to the subscriber in an event-like notification pattern as soon as the subscription

734 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

to the field becomes effective (TriggerUnicast). Additional update notifications will be

sent to subscribers over IP Unicast whenever the value of the field gets updated (Acti-
vationUnicast). Please note that the immediate transmission of the current value to the
subscriber of the Field value is supported over IP Unicast only.
Apart of the immediate transmission (TriggerUnicast) the server may choose to transmit
further notifications over IP Multicast in case that the multicastThreshold is set to
a value >= 1. In this case a PduActivationRoutingGroup shall be used that has
the eventGroupControlType attribute set to activationMulticast.
The following listing shows an example for a ProvidedServiceInstance of the
RadarService.
Listing 10.4: Example for a ProvidedServiceInstance
<PROVIDED-SERVICE-INSTANCE>
<SHORT-NAME>RadarService_1</SHORT-NAME>
<MAJOR-VERSION>1</MAJOR-VERSION>
<METHOD-ACTIVATION-ROUTING-GROUPS>

<PDU-ACTIVATION-ROUTING-GROUP>
<SHORT-NAME>RadarService_1_methodActivationGroup</SHORT-NAME>
<I-PDU-IDENTIFIER-UDP-REFS>
<I-PDU-IDENTIFIER-UDP-REF DEST="SO-CON-I-PDU-IDENTIFIER">/
SoConIpduIdentifierSet/RadarServicePduSet/
RadarService_Calibrate_Call</I-PDU-IDENTIFIER-UDP-REF>
<I-PDU-IDENTIFIER-UDP-REF DEST="SO-CON-I-PDU-IDENTIFIER">/
SoConIpduIdentifierSet/RadarServicePduSet/
RadarService_Calibrate_Return</I-PDU-IDENTIFIER-UDP-REF>
<I-PDU-IDENTIFIER-UDP-REF DEST="SO-CON-I-PDU-IDENTIFIER">/
SoConIpduIdentifierSet/RadarServicePduSet/
RadarService_Adjust_Call</I-PDU-IDENTIFIER-UDP-REF>
<I-PDU-IDENTIFIER-UDP-REF DEST="SO-CON-I-PDU-IDENTIFIER">/
SoConIpduIdentifierSet/RadarServicePduSet/
RadarService_Adjust_Return</I-PDU-IDENTIFIER-UDP-REF>
<I-PDU-IDENTIFIER-UDP-REF DEST="SO-CON-I-PDU-IDENTIFIER">/
SoConIpduIdentifierSet/RadarServicePduSet/
RadarService_UpdateRate_Getter_Call</I-PDU-IDENTIFIER-UDP-REF>
<I-PDU-IDENTIFIER-UDP-REF DEST="SO-CON-I-PDU-IDENTIFIER">/
SoConIpduIdentifierSet/RadarServicePduSet/
RadarService_UpdateRate_Getter_Return</I-PDU-IDENTIFIER-UDP-REF>
<I-PDU-IDENTIFIER-UDP-REF DEST="SO-CON-I-PDU-IDENTIFIER">/
SoConIpduIdentifierSet/RadarServicePduSet/
RadarService_UpdateRate_Setter_Call</I-PDU-IDENTIFIER-UDP-REF>
<I-PDU-IDENTIFIER-UDP-REF DEST="SO-CON-I-PDU-IDENTIFIER">/
SoConIpduIdentifierSet/RadarServicePduSet/
RadarService_UpdateRate_Setter_Return</I-PDU-IDENTIFIER-UDP-REF>
<I-PDU-IDENTIFIER-UDP-REF DEST="SO-CON-I-PDU-IDENTIFIER">/
SoConIpduIdentifierSet/RadarServicePduSet/
RadarService_LogCurrentState</I-PDU-IDENTIFIER-UDP-REF>
<I-PDU-IDENTIFIER-UDP-REF DEST="SO-CON-I-PDU-IDENTIFIER">/
SoConIpduIdentifierSet/RadarServicePduSet/RadarService_Reset</I-
PDU-IDENTIFIER-UDP-REF>
</I-PDU-IDENTIFIER-UDP-REFS>

735 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

</PDU-ACTIVATION-ROUTING-GROUP>
</METHOD-ACTIVATION-ROUTING-GROUPS>
<EVENT-HANDLERS>

<EVENT-HANDLER>
<SHORT-NAME>EventGroup_All</SHORT-NAME>
<EVENT-GROUP-IDENTIFIER>1</EVENT-GROUP-IDENTIFIER>
<EVENT-MULTICAST-ADDRESSS>
<APPLICATION-ENDPOINT-REF-CONDITIONAL>
<APPLICATION-ENDPOINT-REF DEST="APPLICATION-ENDPOINT">/
CommunicationClusters/EthernetCluster/Vlan73/
MyEcuMulticastSocketAddress/MyEcuMulticastAep</APPLICATION-
ENDPOINT-REF>
</APPLICATION-ENDPOINT-REF-CONDITIONAL>
</EVENT-MULTICAST-ADDRESSS>
<MULTICAST-THRESHOLD>2</MULTICAST-THRESHOLD>
<PDU-ACTIVATION-ROUTING-GROUPS>

<PDU-ACTIVATION-ROUTING-GROUP>
<SHORT-NAME>RadarService_1_eventAndNotifierActivationUnicastGroup
</SHORT-NAME>
<EVENT-GROUP-CONTROL-TYPE>ACTIVATION-UNICAST</EVENT-GROUP-CONTROL
-TYPE>
<I-PDU-IDENTIFIER-UDP-REFS>
<I-PDU-IDENTIFIER-UDP-REF DEST="SO-CON-I-PDU-IDENTIFIER">/
SoConIpduIdentifierSet/RadarServicePduSet/
RadarService_BrakeEvent</I-PDU-IDENTIFIER-UDP-REF>
<I-PDU-IDENTIFIER-UDP-REF DEST="SO-CON-I-PDU-IDENTIFIER">/
SoConIpduIdentifierSet/RadarServicePduSet/
RadarService_UpdateRate_Notifier</I-PDU-IDENTIFIER-UDP-REF>
</I-PDU-IDENTIFIER-UDP-REFS>
</PDU-ACTIVATION-ROUTING-GROUP>

<PDU-ACTIVATION-ROUTING-GROUP>
<SHORT-NAME>RadarService_1_TriggerUnicastGroup</SHORT-NAME>
<EVENT-GROUP-CONTROL-TYPE>TRIGGER-UNICAST</EVENT-GROUP-CONTROL-
TYPE>
<I-PDU-IDENTIFIER-UDP-REFS>
<I-PDU-IDENTIFIER-UDP-REF DEST="SO-CON-I-PDU-IDENTIFIER">/
SoConIpduIdentifierSet/RadarServicePduSet/
RadarService_UpdateRate_Notifier</I-PDU-IDENTIFIER-UDP-REF>
</I-PDU-IDENTIFIER-UDP-REFS>
</PDU-ACTIVATION-ROUTING-GROUP>

<PDU-ACTIVATION-ROUTING-GROUP>
<SHORT-NAME>
RadarService_1_eventAndNotifierActivationMulticastGroup</SHORT
-NAME>

736 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

<EVENT-GROUP-CONTROL-TYPE>ACTIVATION-MULTICAST</EVENT-GROUP-
CONTROL-TYPE>
<I-PDU-IDENTIFIER-UDP-REFS>
<I-PDU-IDENTIFIER-UDP-REF DEST="SO-CON-I-PDU-IDENTIFIER">/
SoConIpduIdentifierSet/RadarServicePduSet/
RadarService_BrakeEvent</I-PDU-IDENTIFIER-UDP-REF>
<I-PDU-IDENTIFIER-UDP-REF DEST="SO-CON-I-PDU-IDENTIFIER">/
SoConIpduIdentifierSet/RadarServicePduSet/
RadarService_UpdateRate_Notifier</I-PDU-IDENTIFIER-UDP-REF>
</I-PDU-IDENTIFIER-UDP-REFS>
</PDU-ACTIVATION-ROUTING-GROUP>
</PDU-ACTIVATION-ROUTING-GROUPS>
</EVENT-HANDLER>
</EVENT-HANDLERS>
<INSTANCE-IDENTIFIER>1</INSTANCE-IDENTIFIER>
<LOCAL-UNICAST-ADDRESSS>
<APPLICATION-ENDPOINT-REF-CONDITIONAL>
<APPLICATION-ENDPOINT-REF DEST="APPLICATION-ENDPOINT">/
CommunicationClusters/EthernetCluster/Vlan73/
MyEcuUnicastSocketAddress/MyEcuUnicastAep</APPLICATION-ENDPOINT-
REF>
</APPLICATION-ENDPOINT-REF-CONDITIONAL>
</LOCAL-UNICAST-ADDRESSS>
<MINOR-VERSION>0</MINOR-VERSION>
<SERVICE-IDENTIFIER>27</SERVICE-IDENTIFIER>
</PROVIDED-SERVICE-INSTANCE>

737 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

11 Software Cluster

11.1 Big Picture

Among the different architecture approaches implemented in automotive software solu-
tions, the so-called domain architecture is characterized by the existence of so-called
domain controllers1 that act as a “manager” for a specific domain (e.g. powertrain,
body, chassis) in automotive software.
Domain controllers are connected to each other via a backbone communication bus
and also typically utilize various communication buses to communicate with domain-
specific controller ECUs. The concept of domain controllers is sketched in Figure
11.1.

Infotainment Body Controller Powertrain Chassis

Controller Controller Controller Controller

Figure 11.1: Sketch of an automotive domain controller architecture

A consequence of the domain controller concept is that the individual domain controller
ECUs become very complex and typically host several thousand software-components.
As far as the methodology on the AUTOSAR classic platform is concerned2 , the ECU
needs to be fully integrated before the generation of the RTE can be started.
The integration involves not only the consistent configuration of all basic software mod-
ules but also requires the creation of connections between the application software and
the service software-components that represent the service layer of the AUTOSAR ba-
sic software.
This leads to the following list of issues:
• Generation of the RTE takes a long time.

1
This term is inspired by the existence of functional domains inside a typical vehicle, not to be con-
fused with the definition of the term (“central authentication server”) in general computer science.
2
The workflow on the AUTOSAR classic platform is centered around the idea to build a complete
executable image for each ECU in one step

738 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• Single failures can block the entire integration process.

• Build times become very high.
Please note that similar problems occur in any kind of software architecture which
centralizes software functionality in specific ECUs, e.g. zone Controllers.
In response to the increase in complexity, integration time, possible mistakes, and build
time, the software on such complex ECUs can be structurally decomposed into so-
called Software Clusters of arbitrary complexity.
A Software Cluster can be developed, integrated against, and built independently
of the surrounding host system on the enclosing ECU. After completion of the develop-
ment workflow, a Software Cluster can be deployed to its host ECU independently,
i.e. the deployment of such a Software Cluster does not require the entire ECU to
be re-programmed.

Application Layer
Applic ation Applic ation Applic ation
Software Software Software
Com ponent Com ponent Com ponent
AU TOSA R AU TOSA R AU TOSA R
Inte rfa ce Inte rfa ce Inte rfa ce

Runtime Environment
L ibs Services CD Ds

Application Layer Application Layer Application Layer

Applic ation Applic ation Applic ation Applic ation Applic ation Applic ation Applic ation Applic ation
Software Software Software Software Software Software Software Software
Com ponent Com ponent Com ponent Com ponent Com ponent Com ponent Com ponent Com ponent
AU TOSA R AU TOSA R AU TOSA R AU TOSA R AU TOSA R AU TOSA R AU TOSA R AU TOSA R
Inte rfa ce Inte rfa ce Inte rfa ce Inte rfa ce Inte rfa ce Inte rfa ce Inte rfa ce Inte rfa ce

Runti me Environment Runtime Environment Runtime Environment

L ibs Services CD Ds Services

Runtime Environment

Services Layer
Com pl ex
ECU Abstr action Layer Dri vers

Microcontroller Abstraction Layer

Microcontroller

Figure 11.2: Replace an existing Software Cluster without reprogramming the entire
ECU

In other words, the rest of the software on the respective ECU can be left unchanged
and is kept binary identical if a given Software Cluster is flashed onto the respec-
tive ECU.
[TPS_SYST_02315]{DRAFT} Definition of a software cluster on the AUTOSAR
classic platform dOn the AUTOSAR classic platform, a Software Cluster is rep-
resented by meta-class CpSoftwareCluster. A CpSoftwareCluster is defined
by references to a collection of either
• CompositionSwComponentType in the role swComposition, in this case the
CpSoftwareCluster is described as a re-usable asset out of the context of a
concrete System.

739 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• SwComponentPrototype in the role swComponent, in the case the CpSoft-

wareCluster is defined in the context of a System.
c(RS_SYST_00060)
ARElement AtpPrototype
AtpStructureElement +rootSoftwareComposition Identifiable
System RootSwCompositionPrototype
«atpVariation,atpSplitable» 0..1
+ containerIPduHeaderByteOrder: ByteOrderEnum [0..1]
+ ecuExtractVersion: RevisionLabelString [0..1]
+ pncVectorLength: PositiveInteger [0..1]
+ pncVectorOffset: PositiveInteger [0..1]
+ systemVersion: RevisionLabelString

«isOfType»
«atpSplitable,atpVariation» 1
{redefines
+swCluster 0..* +softwareComposition atpType}
ARElement +swComposition SwComponentType
CpSoftwareCluster CompositionSwComponentType
«atpVariation,atpSplitable» 0..*

«atpVariation,atpSplitable»

+component 0..*
!
AtpPrototype

SwComponentPrototype

+swComponent 0..1
«atpVariation,atpSplitable»
«instanceRef»
+swComponentAssignment 0..*

SwComponentPrototypeAssignment

Figure 11.3: Modeling of the CpSoftwareCluster

[TPS_SYST_02316]{DRAFT} Semantics of meta-class SwComponentPrototy-

peAssignment dMeta-class SwComponentPrototypeAssignment as well as its
aggregation at CpSoftwareCluster in the role swComponentAssignment sup-
ports the definition of a variation point in the relation between CpSoftwareCluster
and SwComponentPrototype.c(RS_SYST_00060)
Class CpSoftwareCluster
Package M2::AUTOSARTemplates::SystemTemplate::SoftwareCluster
Note This meta class provides the ability to define a CP Software Cluster. Each CP Software Cluster can be
integrated and build individually. It defines the sub-set of hierarchical tree(s) of Software Components
belonging to this CP Software Cluster. Resources required or provided by this CP Software Cluster are
given in the according mappings.
Tags:
atp.Status=draft
atp.recommendedPackage=CpSoftwareClusters
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
5

740 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class CpSoftwareCluster
swComponent SwComponent * aggr This is the collection of SwComponentPrototype
Assignment PrototypeAssignment Assignments
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=swComponentAssignment, swComponent
Assignment.variationPoint.shortLabel
atp.Status=draft
vh.latestBindingTime=postBuild
swComposition CompositionSw * ref Software Components in the context of a CompositionSw
ComponentType ComponentType belonging to this CP Software Cluster.
This reference can be used to describe the belonging
SWCs when the CP Software Cluster is described out of
the context of a System, e.g. reusable CP Software
Cluster.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=swComposition.compositionSwComponent
Type, swComposition.variationPoint.shortLabel
atp.Status=draft
vh.latestBindingTime=systemDesignTime

Table 11.1: CpSoftwareCluster

Class SwComponentPrototypeAssignment
Package M2::AUTOSARTemplates::SystemTemplate::SoftwareCluster
Note This meta-class is only required to allow for the variant modeling of an instanceRef.
Tags:atp.Status=draft
Base ARObject
Attribute Type Mult. Kind Note
swComponent SwComponent 0..1 iref hierarchical tree(s) of Software Components belonging to
Prototype this CP Software Cluster. This reference is used to
describe the belonging SWCs if the CP Software Cluster
is described in the context of a System,
Tags:atp.Status=draft
InstanceRef implemented by:ComponentInSystem
InstanceRef
Table 11.2: SwComponentPrototypeAssignment

[TPS_SYST_02317]{DRAFT} References from CpSoftwareCluster to Compo-

sitionSwComponentType and SwComponentPrototype dThe usage of the refer-
ence CpSoftwareCluster.swComposition shall eventually be replaced by a ref-
erence in the role swComposition when the SwComponentPrototypes referenced
by the CpSoftwareCluster (via the role swComponentAssignment) are integrated
into a concrete Ecu Extract.c(RS_SYST_00060)
Class CompositionSwComponentType
Package M2::AUTOSARTemplates::SWComponentTemplate::Composition
5

741 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class CompositionSwComponentType
Note A CompositionSwComponentType aggregates SwComponentPrototypes (that in turn are typed by Sw
ComponentTypes) as well as SwConnectors for primarily connecting SwComponentPrototypes among
each others and towards the surface of the CompositionSwComponentType. By this means, hierarchical
structures of software-components can be created.
Tags:atp.recommendedPackage=SwComponentTypes
Base ARElement, ARObject, AtpBlueprint, AtpBlueprintable, AtpClassifier , AtpType, CollectableElement,
Identifiable, MultilanguageReferrable, PackageableElement, Referrable, SwComponentType
Attribute Type Mult. Kind Note
component SwComponent * aggr The instantiated components that are part of this
Prototype composition. The aggregation of SwComponentPrototype
is subject to variability with the purpose to support the
conditional existence of a SwComponentPrototype.
Please be aware: if the conditional existence of Sw
ComponentPrototypes is resolved post-build the
deselected SwComponentPrototypes are still contained in
the ECUs build but the instances are inactive in that they
are not scheduled by the RTE.
The aggregation is marked as atpSplitable in order to
allow the addition of service components to the ECU
extract during the ECU integration.
The use case for having 0 components owned by the
CompositionSwComponentType could be to deliver an
empty CompositionSwComponentType to e.g. a supplier
for filling the internal structure.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=component.shortName, component.variation
Point.shortLabel
vh.latestBindingTime=postBuild
connector SwConnector * aggr SwConnectors have the principal ability to establish a
connection among PortPrototypes. They can have many
roles in the context of a CompositionSwComponentType.
Details are refined by subclasses.
The aggregation of SwConnectors is subject to variability
with the purpose to support variant data flow.
The aggregation is marked as atpSplitable in order to
allow the extension of the ECU extract with AssemblySw
Connectors between ApplicationSwComponentTypes and
ServiceSwComponentTypes during the ECU integration.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=connector.shortName, connector.variation
Point.shortLabel
vh.latestBindingTime=postBuild
constantValue ConstantSpecification * ref Reference to the ConstantSpecificationMapping to be
Mapping MappingSet applied for initValues of PPortComSpecs and RPortCom
Spec.
Stereotypes: atpSplitable
Tags:atp.Splitkey=constantValueMapping
dataType DataTypeMappingSet * ref Reference to the DataTypeMapping to be applied for the
Mapping used ApplicationDataTypes in PortInterfaces.
Background: when developing subsystems it may happen
that ApplicationDataTypes are used on the surface of
CompositionSwComponentTypes. In this case it would be
reasonable to be able to also provide the intended
mapping to the ImplementationDataTypes. However, this
5

742 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class CompositionSwComponentType
4
mapping shall be informal and not technically binding for
the implementors mainly because the RTE generator is
not concerned about the CompositionSwComponent
Types.
Rationale: if the mapping of ApplicationDataTypes on the
delegated and inner PortPrototype matches then the
mapping to ImplementationDataTypes is not impacting
compatibility.
Stereotypes: atpSplitable
Tags:atp.Splitkey=dataTypeMapping
instantiation InstantiationRTEEvent * aggr This allows to define instantiation specific properties for
RTEEventProps Props RTE Events, in particular for instance specific scheduling.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=instantiationRTEEventProps.shortLabel,
instantiationRTEEventProps.variationPoint.shortLabel
vh.latestBindingTime=codeGenerationTime

Table 11.3: CompositionSwComponentType

Class SwComponentPrototype
Package M2::AUTOSARTemplates::SWComponentTemplate::Composition
Note Role of a software component within a composition.
Base ARObject, AtpFeature, AtpPrototype, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
type SwComponentType 0..1 tref Type of the instance.
Stereotypes: isOfType

Table 11.4: SwComponentPrototype

[TPS_SYST_02318]{DRAFT} Membership in System dThe membership of a given

CpSoftwareCluster can be formalized by means of the reference System.
swCluster.c(RS_SYST_00060)
[TPS_SYST_02319]{DRAFT} Semantics of attribute CpSoftwareCluster.cate-
gory dThe following values for attribute CpSoftwareCluster.category are stan-
dardized by AUTOSAR:
• HOST_SOFTWARE_CLUSTER: the CpSoftwareCluster that contains the major
part of the basic-software stack, especially micro-controller-dependent modules
including the operating system.
• APPLICATION_SOFTWARE_CLUSTER: the CpSoftwareCluster represents
application-level functionality conceptually located on top of the CpSoft-
wareCluster of category HOST_SOFTWARE_CLUSTER.
c(RS_SYST_00060)
[constr_5176]{DRAFT} Existence of CpSoftwareCluster of category HOST_-
SOFTWARE_CLUSTER on one EcuInstance dOn each EcuInstance, exactly one
CpSoftwareCluster of category HOST_SOFTWARE_CLUSTER shall exist.c()

743 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_5177]{DRAFT} Validity of reference CpSoftwareClusterToEcuIn-

stanceMapping.swCluster dA CpSoftwareClusterToEcuInstanceMapping
that references a given CpSoftwareCluster in the role CpSoftwareCluster-
ToEcuInstanceMapping.swCluster shall be aggregated by the same System (in
the role System.mapping.swMapping) that also refers to the referenced CpSoft-
wareCluster in the role System.swCluster.c()
The interaction of Software Clusters with the service layer of the basic soft-
ware stack requires the definition of Software Cluster Resources (see Figure
11.4). Software Clusters declare required and provided Software Cluster
Resources that can be satisfied from a central resource pool.

Figure 11.4: Example usage of Software Cluster Resources

Details regarding the Software Cluster Resource are described in section 11.2.
There are in principle two different approaches to connect Software Clusters with
each other:
Off-board In this case the connection is created by a software tool on the basis of the
binary image of the Software Cluster and modeled information that formally
describes the so-called Software Cluster Binary Manifest. The content

744 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

of the model of the Software Cluster Binary Manifest represents meta-

data of the actual connection information. The main benefit of this approach is
that the meta-data does not have to be stored on-board, i.e. on the target Ecu.
On-board In this case the connection is created by software running on the target Ecu
during the reprogramming phase on the basis of meta-data of the connection
endpoints (semantically identical to the content of the model of the respective
Software Cluster Binary Manifest). The connection data is stored in
modifiable memory. The meta-data content is stored on device, and the required
memory markup for this aspect needs to be taken into account for Ecu design.
It is important to understand that the Software Cluster and the corresponding
Software Cluster Binary Manifest are associated with different steps in the
development workflow. A Software Cluster represents a design model element
while the Software Cluster Binary Manifest is a derived information used to
support a downstream integration phase for defining an off-board connection.
This relation leads to modeling decisions, such that elements of the Software Clus-
ter Binary Manifest can only reference elements of the Software Cluster,
but can’t be aggregated by them.

Application Layer

Applic ation Applic ation Applic ation

SW Cluster
Software Software Software
Com ponent Com ponent Com ponent

AU TOSA R AU TOSA R AU TOSA R

Inte rfa ce Inte rfa ce Inte rfa ce

Runtime Environment

Inter SWCL communication

Binary Ma nifest

Figure 11.5: Software Cluster Binary Manifest of a single Software Cluster

The Software Cluster Binary Manifest is described in more detail in section

11.3.
The mapping of Software Clusters to EcuInstance and ApplicationParti-
tion is described in section 5.5.

745 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

11.2 Software Cluster Resources

A CpSoftwareCluster is able to provide CpSoftwareClusterResources that
will be accessed by other CpSoftwareClusters. At the same time a CpSoft-
wareCluster may require CpSoftwareClusterResources from other CpSoft-
wareClusters to operate the software that belongs to the CpSoftwareCluster.
Identifiable +variableDataPrototype AutosarDataPrototype
AtpStructureElement
PortElementToCommunicationResourceMapping «instanceRef» 0..1 VariableDataPrototype
Identifiable
+clientServerOperation ClientServerOperation

«instanceRef» 0..1 + diagArgIntegrity: Boolean [0..1]

+parameterDataPrototype AutosarDataPrototype

«instanceRef» ParameterDataPrototype
0..1

AtpPrototype
+modeDeclarationGroupPrototype ModeDeclarationGroupPrototype

«instanceRef» 0..1 + swCalibrationAccess: SwCalibrationAccessEnum [0..1]

AtpStructureElement
Identifiable
+trigger
Trigger
«instanceRef» 0..1
+ swImplPolicy: SwImplPolicyEnum [0..1]

+communicationResource CpSoftwareClusterCommunicationResource ARElement

CpSoftwareClusterResourcePool
0..1

+communicationResourceProps 0..1 «atpSplitable»

+resource 0..*
CpSoftwareClusterCommunicationResourceProps Identifiable
CpSoftwareClusterResource

+ globalResourceId: PositiveInteger [0..1]

+ isMandatory: Boolean [0..1]

+resource 0..1

DataComProps +dependentResource 0..*

+ sendIndication: SendIndicationEnum [0..1]
RoleBasedResourceDependency

+ role: Identifier [0..1]

+portElementToComResourceMapping Identifiable

0..* «atpVariation,atpSplitable» SystemMapping

+mapping 0..*
«atpVariation,atpSplitable»

ARElement
0..* +portElementToComResourceMapping CpSoftwareClusterServiceResource
AtpStructureElement
System
+serviceResource 0..1

«atpVariation,atpSplitable»
«atpSplitable,atpVariation»
«atpVariation,atpSplitable»
+swCluster 0..* +softwareClusterToResourceMapping 0..*

ARElement +provider Identifiable

CpSoftwareCluster CpSoftwareClusterToResourceMapping
0..1
+requester
ARElement
0..*
CpSoftwareClusterMappingSet
+softwareClusterToResourceMapping

«atpVariation,atpSplitable» 0..*

+resourceNeeds 0..*
+subContainer 0..*
EcucIndexableValue
«atpVariation,atpSpli
ARElement
Identifiable
EcucModuleConfigurationValues +container EcucContainerValue
+ ecucDefEdition: RevisionLabelString [0..1] «atpVariation,atpSplitable» 0..*
+ implementationConfigVariant: EcucConfigurationVariantEnum [0..1]
+ postBuildVariantUsed: Boolean [0..1]

Figure 11.6: Software Cluster Resources

746 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_02320]{DRAFT} Kinds of CpSoftwareClusterResources dThere

are two kinds of CpSoftwareClusterResources:
• CpSoftwareClusterCommunicationResource that relates to a port based
communication on VFB level, for instance to a sender-receiver communication,
• CpSoftwareClusterServiceResource that relates to the Basic Software, for
instance to a NvBlock.
c(RS_SYST_00060, RS_SYST_00062)
Class CpSoftwareClusterResourcePool
Package M2::AUTOSARTemplates::SystemTemplate::SoftwareCluster
Note Represents the pool of resources which can be provided or required by CP Software Clusters.
Tags:
atp.Status=draft
atp.recommendedPackage=CpSoftwareClusterResourcePools
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
ecuScope EcuInstance * ref This reference identifies the EcuInstance in which the
resource pool is defined.
Stereotypes: atpSplitable
Tags:
atp.Splitkey=ecuScope
atp.Status=draft
resource CpSoftwareCluster * aggr This aggregation represents the collection of resources in
Resource the enclosing resource pool.
Stereotypes: atpSplitable
Tags:
atp.Splitkey=resource.shortName
atp.Status=draft

Table 11.5: CpSoftwareClusterResourcePool

Class CpSoftwareClusterResource (abstract)

Package M2::AUTOSARTemplates::SystemTemplate::SoftwareCluster
Note Represents a single resource required or provided by a CP Software Cluster.
Tags:
atp.Status=draft
atp.recommendedPackage=Resources
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Subclasses CpSoftwareClusterCommunicationResource, CpSoftwareClusterServiceResource
Attribute Type Mult. Kind Note
dependent RoleBasedResource * aggr Link to a resource which depends on this resource to
Resource Dependency implement them.
Tags:atp.Status=draft
5

747 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class CpSoftwareClusterResource (abstract)
globalResource PositiveInteger 0..1 attr A unique identifiers per resource used for the connection
Id process. The identifier is required to be unique in the
scope of a single machine. If software clusters are
designed to be reused on multiple machines the
uniqueness requirements applies for all the intended
machines.
Tags:atp.Status=draft
isMandatory Boolean 0..1 attr This attribute indicates, that the resource is mandatory to
operate the Software Cluster. If the resource is not
provided on the machine the connection process of any
Software Cluster requiring this resource gets aborted.
Tags:atp.Status=draft

Table 11.6: CpSoftwareClusterResource

Class RoleBasedResourceDependency
Package M2::AUTOSARTemplates::SystemTemplate::SoftwareCluster
Note This class specifies a dependency between CpSoftwareClusterResources.
Tags:atp.Status=draft
Base ARObject
Attribute Type Mult. Kind Note
resource CpSoftwareCluster 0..1 ref Reference to resource for which the dependency is
Resource depicted.
Tags:atp.Status=draft
role Identifier 0..1 attr This is attributes characterizes the kind of dependency
Tags:atp.Status=draft

Table 11.7: RoleBasedResourceDependency

[constr_5178]{DRAFT} Existence of attribute CpSoftwareClusterResource.

globalResourceId dFor each CpSoftwareClusterResource, attribute global-
ResourceId shall exist at the time when the definition of the resource pool is
finished.c()
[constr_5179]{DRAFT} Existence of attribute CpSoftwareClusterResource.
isMandatory dFor each CpSoftwareClusterResource, attribute isMandatory
shall exist at the time when the definition of the resource pool is finished.c()
[constr_5180]{DRAFT} Allowed values for CpSoftwareClusterResource.
globalResourceId dAttribute CpSoftwareClusterResource.globalResour-
ceId shall not be set to 0.c()
For explanation of [constr_5180], the value 0 is reserved to mark an invalid ID value.
Class CpSoftwareClusterCommunicationResource
Package M2::AUTOSARTemplates::SystemTemplate::SoftwareCluster
5

748 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class CpSoftwareClusterCommunicationResource
Note Represents a single resource required or provided by a CP Software Cluster which relates to the port
based communication on VFB level.
Tags:atp.Status=draft
Base ARObject, CpSoftwareClusterResource, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
communication CpSoftwareCluster 0..1 aggr This aggregation supports the further qualification of the
ResourceProps Communication enclosing CpSoftwareClusterCommunicationRecource by
ResourceProps means of additional attributes depending on the nature of
the CpSoftwareClusterCommunicationRecource.

Table 11.8: CpSoftwareClusterCommunicationResource

Class CpSoftwareClusterCommunicationResourceProps (abstract)

Package M2::AUTOSARTemplates::SystemTemplate::SoftwareCluster
Note Communication properties for cross cluster communication.
Tags:atp.Status=draft
Base ARObject
Subclasses DataComProps
Attribute Type Mult. Kind Note
– – – – –
Table 11.9: CpSoftwareClusterCommunicationResourceProps

Class DataComProps
Package M2::AUTOSARTemplates::SystemTemplate::SoftwareCluster
Note Represents a single resource required or provided by a CP Software Cluster which relates to the port
based communication on VFB level.
Tags:atp.Status=draft
Base ARObject, CpSoftwareClusterCommunicationResourceProps
Attribute Type Mult. Kind Note
sendIndication SendIndicationEnum 0..1 attr Send indication behavior for last-is-the best data
communication.
Table 11.10: DataComProps

Enumeration SendIndicationEnum
Package M2::AUTOSARTemplates::SystemTemplate::SoftwareCluster
Note This meta-class provides a way to specify in which way redundancy shall be applied on collection
level.
Tags:atp.Status=draft
Literal Description
anySendOperation This value represents the requirement that any send operation of the Software Cluster is indicated.
Tags:
atp.EnumerationLiteralIndex=2
atp.Status=draft
5

749 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Enumeration SendIndicationEnum
none This value represents the requirement that send operations of the Software Cluster are not indicated.
Tags:
atp.EnumerationLiteralIndex=1
atp.Status=draft

Table 11.11: SendIndicationEnum

Class CpSoftwareClusterServiceResource
Package M2::AUTOSARTemplates::SystemTemplate::SoftwareCluster
Note Represents a single resource required or provided by a CP Software Cluster which relates to the BSW.
Tags:atp.Status=draft
Base ARObject, CpSoftwareClusterResource, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
resourceNeeds EcucContainerValue * ref Refernce(s) to one or multiple EcucContainerValue(s)
qualifying the characteristics of the resource.
Tags:atp.Status=draft

Table 11.12: CpSoftwareClusterServiceResource

[constr_5181]{DRAFT} Existence of attribute CpSoftwareClusterServiceRe-

source.category dFor each CpSoftwareClusterServiceResource, attribute
category shall exist at the time when the definition of the resource pool is fin-
ished.c()
The applicable values of CpSoftwareClusterServiceResource.category are
defined in the document "Software Cluster Connection".
CpSoftwareClusterResources are collected in CpSoftwareClusterResour-
cePools and are assigned to a CpSoftwareCluster in different ways as defined
by the following specification items:
[TPS_SYST_02321]{DRAFT} Assignment of CpSoftwareClusterCommunica-
tionResources to CpSoftwareClusters in the context of a SwComponentPro-
totype dIn case that a SwComponentPrototype is defined in the context of a Sys-
tem and this SwComponentPrototype is assigned to the CpSoftwareCluster with
the CpSoftwareCluster.swComponentAssignment and the SwComponentPro-
totype defines an interface of the CpSoftwareCluster then the PortElement-
ToCommunicationResourceMapping aggregated by a SystemMapping maps the
CpSoftwareClusterCommunicationResource to an element of a PortInter-
face used in the context of a PortPrototype in the SwComponentPrototype.
If the PortPrototype of the SwComponentPrototype is a PPortPrototype then
the CpSoftwareClusterCommunicationResource is provided by the CpSoft-
wareCluster.
If the PortPrototype of the SwComponentPrototype is a RPortPrototype then
the CpSoftwareClusterCommunicationResource is required by the CpSoft-
wareCluster.c(RS_SYST_00060, RS_SYST_00062)

750 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_02345]{DRAFT} Assignment of CpSoftwareClusterCommunica-

tionResources to CpSoftwareClusters in the context of a SwComponent-
Type dIn case that a CompositionSwComponentType is defined and is assigned
to the CpSoftwareCluster with the CpSoftwareCluster.swComposition and
this SwComponentType defines an interface of the CpSoftwareCluster then
the PortElementToCommunicationResourceMapping that is aggregated by a
CpSoftwareClusterMappingSet maps the CpSoftwareClusterCommunica-
tionResource to an element of a PortInterface used in the context of a Port-
Prototype of a CompositionSwComponentType.
If the PortPrototype of the CompositionSwComponentType is a PPortProto-
type then the CpSoftwareClusterCommunicationResource is provided by the
CpSoftwareCluster.
If the PortPrototype of the CompositionSwComponentType is a RPortProto-
type then the CpSoftwareClusterCommunicationResource is required by the
CpSoftwareCluster.c(RS_SYST_00060, RS_SYST_00062)
Class PortElementToCommunicationResourceMapping
Package M2::AUTOSARTemplates::SystemTemplate
Note This meta class maps a communication resource to CP Software Clusters. In this case the kind of Port
Prototype specified whether the Software Cluster has to provide or to require the resource.
Tags:atp.Status=draft
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
clientServer ClientServerOperation 0..1 iref ClientServerOperation instance qualifying the
Operation communication resource
Tags:atp.Status=draft
InstanceRef implemented by:OperationInSystem
InstanceRef
communication CpSoftwareCluster 0..1 ref Communication resource for which the mapping applies.
Resource Communication
Tags:atp.Status=draft
Resource
mode ModeDeclarationGroup 0..1 iref ModeDeclarationGroupPrototype instance qualifying the
Declaration Prototype communication resource
GroupPrototype
Tags:atp.Status=draft
InstanceRef implemented by:ModeDeclarationGroup
PrototypeInSystemInstanceRef
parameterData ParameterData 0..1 iref ParameterDataPrototype instance qualifying the
Prototype Prototype communication resource.
Tags:atp.Status=draft
InstanceRef implemented by:ParameterDataPrototype
InSystemInstanceRef
trigger Trigger 0..1 iref Trigger instance qualifying the communication resource.
Tags:atp.Status=draft
InstanceRef implemented by:TriggerInSystemInstance
Ref
variableData VariableDataPrototype 0..1 iref VariableDataPrototype instance qualifying the
Prototype communication resource
Tags:atp.Status=draft
InstanceRef implemented by:VariableDataPrototypeIn
SystemInstanceRef

Table 11.13: PortElementToCommunicationResourceMapping

751 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Please note that the assignment of CpSoftwareClusterCommunicationRe-

sources to CpSoftwareClusters in the context of a SwComponentTypes as de-
scribed by [TPS_SYST_02345] shall only be used in an early stage of the Methodol-
ogy if the System with the RootSwCompositionPrototype and all included Sys-
temMappings is not available yet.
In this case not all context references in the «instanceRef» of PortElementToCom-
municationResourceMapping can be used since the SwComponentPrototype
is not available yet.
[TPS_SYST_02322]{DRAFT} PortElementToCommunicationResourceMap-
ping aggregated by SystemMapping supersedes PortElementToCommuni-
cationResourceMapping aggregated by CpSoftwareClusterMappingSet
dIf a PortElementToCommunicationResourceMapping that is aggregated by
the SystemMapping and a PortElementToCommunicationResourceMap-
ping that is aggregated by the CpSoftwareClusterMappingSet exist at the
same time and both reference the same element in the same PortPrototype
then the PortElementToCommunicationResourceMapping that is aggregated
by the SystemMapping supersedes the PortElementToCommunicationRe-
sourceMapping that is aggregated by the CpSoftwareClusterMappingSet.c
(RS_SYST_00060, RS_SYST_00062)
[constr_5182]{DRAFT} PRPortPrototypes are excluded as CpSoftwareClus-
ter interfaces dA CpSoftwareClusterCommunicationResource is not allowed
to be mapped by a PortElementToCommunicationResourceMapping to an ele-
ment of a PortInterface in the context of a PRPortPrototype.c()
Please note that it is allowed that a PPortPrototype that is referenced by a
PortElementToCommunicationResourceMapping is allowed to be connected via
a DelegationSwConnector to a PRPortPrototype.
[constr_5183]{DRAFT} PortElementToCommunicationResourceMapping
shall reference exactly one element of a PortInterface dFor any given
PortElementToCommunicationResourceMapping, either the reference
• parameterDataPrototype or
• modeDeclarationGroupPrototype or
• trigger or
• clientServerOperation or
• variableDataPrototype
shall exist.c()
[TPS_SYST_02323]{DRAFT} Assignment of CpSoftwareClusterServiceRe-
sources to CpSoftwareClusters dA CpSoftwareClusterServiceResource
is mapped to CpSoftwareCluster with a CpSoftwareClusterToResourceMap-
ping.c(RS_SYST_00060, RS_SYST_00062)

752 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class CpSoftwareClusterToResourceMapping
Package M2::AUTOSARTemplates::SystemTemplate::SoftwareCluster
Note This meta class maps a service resource to CP Software Clusters. By this mapping it’s specified whether
the Software Cluster has to provide or to require the resource.
Tags:atp.Status=draft
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
provider CpSoftwareCluster 0..1 ref CP Software Cluster providing the resource
Tags:atp.Status=draft
requester CpSoftwareCluster * ref CP Software Cluster requesting the resource
Tags:atp.Status=draft
service CpSoftwareCluster 0..1 ref Service resource for which the mapping applies.
Resource ServiceResource
Tags:atp.Status=draft

Table 11.14: CpSoftwareClusterToResourceMapping

[TPS_SYST_02324]{DRAFT} CpSoftwareClusterServiceResource provided

by the CpSoftwareCluster dA CpSoftwareClusterResource is provided by a
CpSoftwareCluster if a CpSoftwareClusterToResourceMapping exists that
• references the CpSoftwareClusterResource in the role serviceResource
and
• references the CpSoftwareCluster in the role provider
c(RS_SYST_00060, RS_SYST_00062)
[TPS_SYST_02325]{DRAFT} CpSoftwareClusterServiceResource required
by the CpSoftwareCluster dA CpSoftwareClusterResource is required by a
CpSoftwareCluster if a CpSoftwareClusterToResourceMapping exists that
• references the CpSoftwareClusterResource in the role serviceResource
and
• references the CpSoftwareCluster in the role requester.
c(RS_SYST_00060, RS_SYST_00062)
[constr_5184]{DRAFT} CpSoftwareClusterServiceResource can be pro-
vided only once on an EcuInstance dA CpSoftwareClusterServiceResource
shall not be mapped by several CpSoftwareClusterToResourceMappings to Cp-
SoftwareClusters in the provider role if the CpSoftwareClusters are mapped
to the same EcuInstance by CpSoftwareClusterToEcuInstanceMappings.c()
[TPS_SYST_02326]{DRAFT} Aggregation possibilities of CpSoftwareCluster-
ToResourceMapping dThe CpSoftwareClusterToResourceMapping can be
aggregated by CpSoftwareClusterMappingSet and by SystemMapping.
• CpSoftwareClusterMappingSet.softwareClusterToResourceMap-
ping can be used in an early stage of the Methodology if the System with the

753 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

RootSwCompositionPrototype and all included SystemMappings is not

available yet.
• SystemMapping.softwareClusterToResourceMapping can be used in a
later stage of Methodology if the System with the RootSwCompositionPro-
totype and all included SystemMappings is available.
c(RS_SYST_00060, RS_SYST_00062)
[TPS_SYST_02346]{DRAFT} CpSoftwareClusterToResourceMapping aggre-
gated by SystemMapping supersedes CpSoftwareClusterToResourceMap-
ping aggregated by CpSoftwareClusterMappingSet dIf a CpSoftwareClus-
terToResourceMapping that is aggregated by the SystemMapping and a
CpSoftwareClusterToResourceMapping that is aggregated by the CpSoft-
wareClusterMappingSet exist at the same time and both are mapping the
same CpSoftwareClusterServiceResource to the same CpSoftwareClus-
ter then the CpSoftwareClusterToResourceMapping that is aggregated by the
SystemMapping supersedes the CpSoftwareClusterToResourceMapping that
is aggregated by the CpSoftwareClusterMappingSet.c(RS_SYST_00060, RS_-
SYST_00062)

11.3 Software Cluster Binary Manifest

[TPS_SYST_02327]{DRAFT} Role of the Software Cluster Binary Mani-
fest dThe modeling of the Software Cluster Binary Manifest allows for the
formal definition of how a given Software Cluster interacts with the environment.
This formal model is only relevant for the creation of an off-board connection be-
tween Software Clusters.
The core characteristics of the model of a Software Cluster Binary Manifest
are:
• The model of a Software Cluster Binary Manifest is created during the
Software Cluster’s build because it has to store information (e.g. data and
function addresses, ID values for the interaction with basic software services) that
only become available during build time.
• The model of a Software Cluster Binary Manifest uses guarding infor-
mation (e.g. hash values) to ensure that only compatible resources are connected
to each other.
The Software Cluster Binary Manifest is defined on integration level3 .c(RS_-
SYST_00061)

3
As opposed to design level, on which the actual CpSoftwareCluster exists

754 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Binary Manifest Binary Manifest

Executable Executable
Binary Software Binary Software
Cluster 1 ID42 ID42 Cluster 1
0x32168 Exchange of ?
0x11 ?
references at
ID17 connection ID17
? phase 0x61207

Software Cluster 1 Software Cluster 2

Figure 11.7: Two Software Cluster exchange information in their Software Cluster
Binary Manifests.

This means that, at run-time, the Software Cluster Binary Manifest consists
of data structures that are partly non-modifiable (to define e.g. meta-data or describe
the access to a resource) and partly modifiable (to store the connection information,
see Figure 11.7).

Binary Manifest Binary Manifest

Executable Executable
Binary Software Binary Software
Cluster 1 ID42 ID42 Cluster 1
0x32168 0x61000
0x11 0x00
ID17 ID17
0x32000 0x61207

Software Cluster 1 Software Cluster 2

Figure 11.8: Two Software Cluster and their fully-configured Software Cluster
Binary Manifests

The missing pieces in the Software Cluster Binary Manifest can be filled by
exchanging information at either configuration-time (off-board) or run-time (on-board),
see Figure 11.8. The algorithm used to create an off-board connection is identical to
the algorithm used to create an on-board connection.
The difference ist mainly that the creation of the on-board connection needs the infor-
mation stored in the model of a Software Cluster Binary Manifest on-board,
i.e. a significant amount of on-board storage is required for holding the connection
meta-data.
The logical structure of the Software Cluster Binary Manifest is depicted in
Figure 11.9

755 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Figure 11.9: Logical structure of the Software Cluster Binary Manifest

[TPS_SYST_02328]{DRAFT} Semantics of meta-class CpSoftwareClus-

terBinaryManifestDescriptor dThe existence of the CpSoftwareClus-
terBinaryManifestDescriptor represents the definition of the model of a
Software Cluster Binary Manifest for a given Software Cluster.
Because of this relation, it is necessary that CpSoftwareClusterBinaryMani-
festDescriptor references the corresponding CpSoftwareCluster instead of
being aggregated by it.c(RS_SYST_00061)

756 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Identifiable
CpSoftwareClusterResource

+ globalResourceId: PositiveInteger [0..1]

+ isMandatory: Boolean [0..1]

+resource 0..1

ARElement Identifiable
CpSoftwareCluster BinaryManifestResource

+ globalResourceId: PositiveInteger [0..1]

+ resourceGuardValue: String [0..1]

+cpSoftwareCluster 0..1

ARElement
BinaryManifestRequireResource
CpSoftwareClusterBinaryManifestDescriptor +requireResource
+ connectionIsMandatory: Boolean [0..1]
+ softwareClusterId: PositiveInteger [0..1] 0..*

+provideResource BinaryManifestProvideResource

* + numberOfNotifierSets: PositiveInteger [0..1]

+ supportsMultipleNotifierSets: Boolean [0..1]

+resourceDefinition 0..1

Identifiable
+resourceDefinition BinaryManifestResourceDefinition

0..*

Identifiable
BinaryManifestAddressableObject

+ address: Address [0..1]

+ symbol: SymbolString [0..1]

0..*
+itemDefinition {ordered}

BinaryManifestMetaDataField Identifiable
+metaDataField BinaryManifestItemDefinition
+ size: PositiveInteger [0..1]
0..* + value: VerbatimString [0..1] + isOptional: Boolean [0..1]
+ size: PositiveInteger [0..1]
+auxiliaryFieldDefinition
0..*

Figure 11.10: Modeling of the Software Cluster Binary Manifest

[TPS_SYST_02329]{DRAFT} Provison of a Software Cluster’s ID dThe ID of

a given Software Cluster formalized as CpSoftwareCluster cannot be defined
as an attribute of CpSoftwareCluster because the ID represents an integration-level
information. Therefore, the ID is provided by means of attribute CpSoftwareClus-
terBinaryManifestDescriptor.softwareClusterId.c(RS_SYST_00061)
[TPS_SYST_02330]{DRAFT} Possible values of attribute CpSoftwareClus-
terBinaryManifestDescriptor.category dThe following values for attribute
CpSoftwareCluster.category are standardized by AUTOSAR:
• HOST_SOFTWARE_CLUSTER: the CpSoftwareClusterBinaryManifestDe-
scriptor that contains the major part of the basic-software stack, especially
micro-controller-dependent modules including the operating system.

757 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• APPLICATION_SOFTWARE_CLUSTER: the CpSoftwareClusterBinaryMan-

ifestDescriptor represents application-level functionality conceptually lo-
cated on top of the CpSoftwareCluster of category HOST_SOFTWARE_-
CLUSTER.
• SUBSTITUTION_SOFTWARE_CLUSTER: in this case the CpSoftwareClus-
terBinaryManifestDescriptor is used for debugging or prototyping pur-
poses.
c(RS_SYST_00061)
Please note that the standardized values of attribute category for CpSoft-
wareCluster and CpSoftwareClusterBinaryManifestDescriptor differ by
the definition of value SUBSTITTION_SOFTWARE_CLUSTER.
This value is not applicable on the “System”-level, but may make sense in the local
scope of the deployment configuration of a given CpSoftwareCluster by means of
CpSoftwareClusterBinaryManifestDescriptor.
Class CpSoftwareClusterBinaryManifestDescriptor
Package M2::AUTOSARTemplates::SystemTemplate::SoftwareCluster::BinaryManifest
Note This meta-class has the ability to act as a hub for all information related to the binary manifest of a given
CP software cluster. The manifest is subject to integrator work and therefore not a part of the definition of
the CP software cluster itself.
Tags:
atp.Status=draft
atp.recommendedPackage=CpSoftwareClusterBinaryManifestDescriptors
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mult. Kind Note
cpSoftware CpSoftwareCluster 0..1 ref This reference identifies the CpSoftwareCluster to which
Cluster the enclosing CpSoftwareClusterBinaryManifest
Descriptor belongs,
The CpSoftwareClusterBinaryManifestDescriptor is
defined in an integration phase while the referenced Cp
SoftwareCluster represents a design element. Therefore,
it makes sense to use a reference rather than an
aggregation in the relation of the two meta-classes.
Tags:atp.Status=draft
metaDataField BinaryManifestMeta * aggr This aggregation identifies the collection of meta-data
DataField contained in the enclosing binary manifest.
Tags:atp.Status=draft
provide BinaryManifestProvide * aggr This aggregation represents the collection of provided
Resource Resource resources in the enclosing binary manifest.
Tags:atp.Status=draft
require BinaryManifestRequire * aggr This aggregation represents the collection of required
Resource Resource resources in the enclosing binary manifest.
Tags:atp.Status=draft
resource BinaryManifest * aggr This aggregation represents the collection of binary
Definition ResourceDefinition manifest resource definitions that belong to the enclosing
CpSoftwareClusterBinaryManifestDescriptor.
Tags:atp.Status=draft
5

758 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class CpSoftwareClusterBinaryManifestDescriptor
softwareCluster PositiveInteger 0..1 attr This attribute represents the value of the id of the
Id corresponding CP software cluster. This id is only
assigned by an integrator and can therefore not be part of
the description of the CP software cluster itself.
Tags:atp.Status=draft

Table 11.15: CpSoftwareClusterBinaryManifestDescriptor

[TPS_SYST_02331]{DRAFT} Definition of provided resource in the context of

the Software Cluster Binary Manifest dA provided resource of a Software
Cluster Binary Manifest represents an “offer” of the Software Cluster to
other Software Clusters.
For the formal point of view, this “offer” is defined by means of a BinaryMani-
festProvideResource, aggregated at CpSoftwareClusterBinaryManifest-
Descriptor in the role provideResource.
Attribute supportsMultipleNotifierSets indicates whether the resource sup-
port the call of multiple notifier call-back functions.c(RS_SYST_00061)
Class BinaryManifestProvideResource
Package M2::AUTOSARTemplates::SystemTemplate::SoftwareCluster::BinaryManifest
Note This meta-class represents a provided resource in the binary manifest.
Tags:atp.Status=draft
Base ARObject, BinaryManifestResource, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
numberOf PositiveInteger 0..1 attr This attribute provides an upper limit for the number of
NotifierSets notifiers for this resource.
Tags:atp.Status=draft
supports Boolean 0..1 attr This attribute indicates whether the enclosing Binary
MultipleNotifier ManifestResource supports multiple notifiers sets.
Sets
Tags:atp.Status=draft

Table 11.16: BinaryManifestProvideResource

[constr_5185]{DRAFT} Existence of attribute BinaryManifestProvideRe-

source.globalResourceId dFor each BinaryManifestProvideResource, at-
tribute globalResourceId shall exist at the time when the definition of binary
object meta-data is finished.c()
[constr_5186]{DRAFT} Existence of attribute BinaryManifestProvideRe-
source.resourceGuardValue dFor each BinaryManifestProvideResource,
attribute resourceGuardValue shall exist at the time when the definition of bi-
nary object meta-data is finished.c()
[constr_5187]{DRAFT} Existence of attribute BinaryManifestProvideRe-
source.supportsMultipleNotifierSets dFor each BinaryManifest-
ProvideResource, attribute supportsMultipleNotifierSets shall exist at the
time when the definition of binary object meta-data is finished.c()

759 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_5188]{DRAFT} Existence of attribute BinaryManifestProvideRe-

source.numberOfNotifierSets dFor each BinaryManifestProvideRe-
source, attribute numberOfNotifierSets shall exist at the time when the
definition of binary object meta-data is finished.c()
[constr_5189]{DRAFT} Existence of reference BinaryManifestProvideRe-
source.resourceDefinition dFor each BinaryManifestProvideResource,
the reference in the role resourceDefinition shall exist at the time when the
definition of binary object meta-data is finished.c()
[constr_5190]{DRAFT} Existence of aggregation BinaryManifestProvideRe-
source.item dFor each BinaryManifestProvideResource, the aggregation in
the role item shall exist at least once at the time when the definition of binary
object meta-data is finished.c()
[constr_5191]{DRAFT} Consequence of attribute BinaryManifestProvideRe-
source.item.category dThe following values of attribute BinaryManifest-
ProvideResource.item.category shall require the existence of aggregations:
• If category is set to PROVIDER_HANDLE and the attribute isUnused is not
set to true then the aggregation BinaryManifestProvideResource.item.
value shall exist at the time when the definition of binary object meta-data
is finished.
• If category is set to NOTIFIER_HANDLE and the attribute isUnused is not
set to true then the aggregation BinaryManifestProvideResource.item.
defaultValue shall exist at the time when the definition of binary object
meta-data is finished.
• If category is set to AUXILARY_ACTUAL_NUMBER_NOTIFIER_SETS then the
aggregation BinaryManifestProvideResource.item.defaultValue shall
exist at the time when the definition of binary object meta-data is finished.
c()
Class BinaryManifestResource (abstract)
Package M2::AUTOSARTemplates::SystemTemplate::SoftwareCluster::BinaryManifest
Note This meta-class acts as an abstract base class for specializations.
Tags:atp.Status=draft
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Subclasses BinaryManifestProvideResource, BinaryManifestRequireResource
Attribute Type Mult. Kind Note
globalResource PositiveInteger 0..1 attr A unique identifiers per resource used for the connection
Id process. The identifier is required to be unique in the
scope of a single machine. If software clusters are
designed to be reused on multiple machines the
uniqueness requirements applies for all the intended
machines.
Tags:atp.Status=draft
5

760 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class BinaryManifestResource (abstract)
item (ordered) BinaryManifestItem * aggr This aggregation represents the collection of binary
manifest handles owned by the enclosing binary manifest
resource.
Tags:atp.Status=draft
resource CpSoftwareCluster 0..1 ref This reference identifies the CpSoftwareClusterResource
Resource (on design level) that corresponds to the BinaryManifest
Resource (on integration level).
Tags:atp.Status=draft
resource BinaryManifest 0..1 ref this reference identifies the definition of the Binary
Definition ResourceDefinition ManifestResource. The definition provides configuration
information that is shared among all BinaryManifest
Resources that refer to the BinaryManifestResource
Definition.
Tags:atp.Status=draft
resourceGuard String 0..1 attr This attribute specifies the guard value of the enclosing
Value binary manifest resource.
Tags:atp.Status=draft

Table 11.17: BinaryManifestResource

[TPS_SYST_02332]{DRAFT} Definition of required resource in the context of

the Software Cluster Binary Manifest dA required resource of a Software
Cluster Binary Manifest represents an “request” of the Software Cluster
towards other Software Clusters.
For the formal point of view, this “request” is defined by means of a BinaryMani-
festRequireResource, aggregated at CpSoftwareClusterBinaryManifest-
Descriptor in the role requireResource.
Required resources could be left unconnected unless attribute connectionIs-
Mandatory is set to True.c(RS_SYST_00061)
Class BinaryManifestRequireResource
Package M2::AUTOSARTemplates::SystemTemplate::SoftwareCluster::BinaryManifest
Note This meta-class represents a required resource in the binary manifest.
Tags:atp.Status=draft
Base ARObject, BinaryManifestResource, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
connectionIs Boolean 0..1 attr This attribute indicates whether the connection of the
Mandatory enclosing BinaryManifestResource is mandatory.
Tags:atp.Status=draft

Table 11.18: BinaryManifestRequireResource

[constr_5192]{DRAFT} Existence of attribute BinaryManifestRequireRe-

source.globalResourceId dFor each BinaryManifestRequireResource, at-
tribute globalResourceId shall exist at the time when the definition of binary
object meta-data is finished.c()

761 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_5193]{DRAFT} Existence of attribute BinaryManifestRequireRe-

source.resourceGuardValue dFor each BinaryManifestRequireResource,
attribute resourceGuardValue shall exist at the time when the definition of bi-
nary object meta-data is finished.c()
[constr_5194]{DRAFT} Existence of reference BinaryManifestRequireRe-
source.resourceDefinition dFor each BinaryManifestRequireResource,
the reference in the role resourceDefinition shall exist at the time when the
definition of binary object meta-data is finished.c()
[constr_5195]{DRAFT} Existence of aggregation BinaryManifestRequireRe-
source.item dFor each BinaryManifestRequireResource, the aggregation in
the role item shall exist at least once at the time when the definition of binary
object meta-data is finished.c()
[constr_5196]{DRAFT} Consequence of attribute BinaryManifestRequireRe-
source.item.category dThe following values of attribute BinaryManifestRe-
quireResource.item.category shall require the existence of aggregations:
• If category is set to PROVIDER_HANDLE then the aggregation BinaryMan-
ifestRequireResource.item.defaultValue shall exist at the time when
the definition of binary object meta-data is finished.
• If category is set to NOTIFIER_HANDLE then the aggregation BinaryMani-
festRequireResource.item.value shall exist at the time when the defini-
tion of binary object meta-data is finished.
c()
Class BinaryManifestResourceDefinition
Package M2::AUTOSARTemplates::SystemTemplate::SoftwareCluster::BinaryManifest
Note This meta-class represents the ability to specify a resource definition that provides information that can
be shared by all resources that refer to the respective resource definition.
Tags:atp.Status=draft
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
itemDefinition BinaryManifestItem * aggr This aggregation specifies the collection of handle
(ordered) Definition definitions in the context of the enclosing binary manifest
resource definitions.
Tags:atp.Status=draft

Table 11.19: BinaryManifestResourceDefinition

[constr_5197]{DRAFT} Existence of aggregation BinaryManifestRe-

sourceDefinition.itemDefinition dFor each BinaryManifestRe-
sourceDefinition, the aggregation in the role itemDefinition shall exist
at least once at the time when the definition of binary object meta-data is
finished.c()

762 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_02333]{DRAFT} Purpose of meta-class BinaryManifestRe-

sourceDefinition dThe purpose of meta-class BinaryManifestResourceDef-
inition is to provide attributes that apply (by definition) to all BinaryManifestRe-
sources that refer to a specific BinaryManifestResourceDefinition.
In other words, the configuration modeled in a BinaryManifestResourceDefini-
tion is shared among all BinaryManifestResources that reference the Binary-
ManifestResourceDefinition.c(RS_SYST_00061)
Identifiable
CpSoftwareClusterResource

+ globalResourceId: PositiveInteger [0..1]

+ isMandatory: Boolean [0..1]

+resource 0..1

Identifiable
BinaryManifestResource

+ globalResourceId: PositiveInteger [0..1]

+ resourceGuardValue: String [0..1]

Identifiable
BinaryManifestProvideResource BinaryManifestRequireResource
BinaryManifestAddressableObject
+ numberOfNotifierSets: PositiveInteger [0..1] + connectionIsMandatory: Boolean [0..1]
+ supportsMultipleNotifierSets: Boolean [0..1] + address: Address [0..1]
+ symbol: SymbolString [0..1]

0..1 +resourceDefinition +item 0..* {ordered}

Identifiable
BinaryManifestItem
BinaryManifestResourceDefinition
+ isUnused: Boolean [0..1]

+auxiliaryField 0..*

0..*
+itemDefinition {ordered} +value 0..1 +defaultValue 0..1

Identifiable +auxiliaryFieldDefinition 0..*

BinaryManifestItemValue
BinaryManifestItemDefinition

+ isOptional: Boolean [0..1]

+ size: PositiveInteger [0..1]

BinaryManifestItemPointerValue BinaryManifestItemNumericalValue

+ address: Address [0..1] + value: Numerical [0..1]
+ symbol: SymbolString [0..1]

Figure 11.11: Modeling of the BinaryManifestResource

Please note that by referencing BinaryManifestResourceDefinition from Bi-

naryManifestResource repetition can be avoided. It is expected that in the context
of a given CpSoftwareClusterBinaryManifestDescriptor several Binary-
ManifestResources exist that share the same BinaryManifestResourceDef-
inition.
[constr_5198]{DRAFT} Allowed BinaryManifestResource.resourceDefini-
tion dAn BinaryManifestResourceDefinition shall only be referenced
from a BinaryManifestResource that is aggregated in the same CpSoft-
wareClusterBinaryManifestDescriptor as the referenced BinaryMani-
festResourceDefinition.c()

763 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_02334]{DRAFT} Semantics of meta-class BinaryManifestItem

dThe purpose of meta-class BinaryManifestItem is to define elements that specify
the detailed interface (on the level of symbols) of a BinaryManifestResource.
At run-time, the BinaryManifestItem is represented by its symbol located at the
corresponding address.c(RS_SYST_00061)
[constr_5271] Existence of attribute BinaryManifestItem.isUnused dFor each
BinaryManifestItem, the attribute isUnused shall exist at the time when the defi-
nition of binary object meta-data is finished.c()
[constr_5272] Value of attribute BinaryManifestItem.isUnused dThe attribute
BinaryManifestItem.isUnused shall only permitted to be set to true if the related
BinaryManifestItemDefinition has its attribute isOptional set to true,c()
[TPS_SYST_02335]{DRAFT} Semantics of aggregation BinaryManifestItem.
auxiliaryField dThe aggregation BinaryManifestItem.auxiliaryField can
be used to define structured BinaryManifestItem.c(RS_SYST_00061)
Class BinaryManifestItem
Package M2::AUTOSARTemplates::SystemTemplate::SoftwareCluster::BinaryManifest
Note This meta-class represents the ability to describe a specific handle or auxiliary field in the context of
binary manifest resource.
Tags:atp.Status=draft
Base ARObject, BinaryManifestAddressableObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
auxiliaryField BinaryManifestItem * aggr This aggregation is used to define structured Binary
ManifestItems.
Tags:
atp.Status=draft
xml.sequenceOffset=20
defaultValue BinaryManifestItem 0..1 aggr This aggregation represents the definition of a default
Value value for a binary manifest handle or an auxiliaryField.
This value shall be taken if no connection for this
resource is possible.
Tags:
atp.Status=draft
xml.sequenceOffset=10
isUnused Boolean 0..1 attr If true, the handle or auxiliary field in the context of binary
manifest resource relates to an optional BinaryManifest
ItemDefinition and is not used.
Tags:atp.Status=draft
value BinaryManifestItem 0..1 aggr This aggregation represents the definition of a value for a
Value binary manifest handle or an auxiliaryField.
This value shall be taken to establish a connection.
Tags:atp.Status=draft

Table 11.20: BinaryManifestItem

764 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_5199]{DRAFT} Consequence of attribute BinaryManifestItem.auxil-

iaryField.category dIf attribute BinaryManifestItem.auxiliaryField.cat-
egory is set to value AUXILARY_CONNECTED_SW_CLUSTER_ID then attribute Bina-
ryManifestItem.auxiliaryField.defaultValue shall exist at the time when
the definition of binary object meta-data is finished.c()
[TPS_SYST_02336]{DRAFT} Semantics of meta-class BinaryMani-
festItemDefinition dThe purpose of meta-class BinaryManifestItemDefi-
nition is to provide attributes that are shared among all corresponding BinaryMan-
ifestItems.c(RS_SYST_00061)
[TPS_SYST_02337]{DRAFT} Semantics of aggregation BinaryMani-
festItemDefinition.auxiliaryFieldDefinition dThe aggregation Bi-
naryManifestItemDefinition.auxiliaryFieldDefinition can be used to
define structured BinaryManifestItemDefinition.c(RS_SYST_00061)
[TPS_SYST_02338]{DRAFT} Relation between BinaryManifestItemDefini-
tion and BinaryManifestItem dThe relation between a particular BinaryMan-
ifestItemDefinition and a particular BinaryManifestItem is created by
• the ordered aggregation of meta-class BinaryManifestItemDefinition at
BinaryManifestResource in the role itemDefinition and
• the ordered aggregation of meta-class BinaryManifestItem at BinaryMan-
ifestResource in the role item.
In other words, the mentioned correspondence is created such that the nth Binary-
ManifestResourceDefinition.itemDefinition applies to the nth BinaryMan-
ifestResource.item.c(RS_SYST_00061)
Class BinaryManifestItemDefinition
Package M2::AUTOSARTemplates::SystemTemplate::SoftwareCluster::BinaryManifest
Note This meta-class provides the ability to define the handle definition or an auxiliary field of a binary manifest
resource.
Tags:atp.Status=draft
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
auxiliaryField BinaryManifestItem * aggr This aggregation is used to define structured Binary
Definition Definition ManifestItemDefinitions.
Tags:atp.Status=draft
isOptional Boolean 0..1 attr If true, the handle definition or auxiliary field of a binary
manifest resource is optional and may not be used in all
BinaryManifestResources referring to this BinaryManifest
ResourceDefinition.
Tags:atp.Status=draft
size PositiveInteger 0..1 attr This attribute provides the ability to specify the size of the
enclosing BinaryManifestResourceDefinition.
Tags:atp.Status=draft

Table 11.21: BinaryManifestItemDefinition

765 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_5200]{DRAFT} Existence of attribute BinaryManifestItemDefini-

tion.category dFor each BinaryManifestItemDefinition, attribute cate-
gory shall exist at the time when the definition of binary object meta-data is fin-
ished.c()
[constr_5201]{DRAFT} Existence of attribute BinaryManifestItemDefini-
tion.size dFor each BinaryManifestItemDefinition, attribute size shall exist
at the time when the definition of binary object meta-data is finished.c()
Class BinaryManifestAddressableObject (abstract)
Package M2::AUTOSARTemplates::SystemTemplate::SoftwareCluster::BinaryManifest
Note This meta-class acts as an abstract base class for addressable objects in the context of the binary
manifest of a CP software cluster.
Tags:atp.Status=draft
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Subclasses BinaryManifestItem, BinaryManifestMetaDataField
Attribute Type Mult. Kind Note
address Address 0..1 attr This attribute specifies the address of the enclosing
addressable object.
Tags:atp.Status=draft
symbol SymbolString 0..1 attr This attribute specifies the symbol of the addressable
object.
Tags:atp.Status=draft

Table 11.22: BinaryManifestAddressableObject

[TPS_SYST_02339]{DRAFT} Standardized values of attribute BinaryManifes-

tAddressableObject.category dThe following list of values of attribute Binary-
ManifestAddressableObject.category is standardized by AUTOSAR:
• PROVIDER_HANDLE: the BinaryManifestAddressableObject is used to
store a provider handle.
• NOTIFIER_HANDLE: the BinaryManifestAddressableObject is used to
store a notifier handle.
• IMMUTABLE_TABLES_CHECKSUM: the Immutable Tables Checksum is built over
all constants of the Software Cluster Binary Manifest which are not
changed by the Software Cluster connection step.
• SUBSCRIBED_INTERFACE_VALIDITY_MARKER: the Subscribed Interface Va-
lidity Marker indicate that all tables storing subscribed handles are written after
the Software Cluster connection step.
• AUXILARY_ACTUAL_NUMBER_NOTIFIER_SETS: the auxiliary field actual num-
ber of used notifier sets describes how many of the notifier sets are occupied by
connected resources.
• AUXILARY_CONNECTED_SW_CLUSTER_ID: the auxiliary field connected Soft-
ware Cluster Id holds the Software Cluster Id from which the handle values are
taken in case an connection is established.

766 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

c(RS_SYST_00061)
Please note that custom values of BinaryManifestAddressableObject.cate-
gory are supported as long as the custom value is created in a way that it will not
clash with standardized values that may be added in the future. Such a name clash
can be prevented by using company-specific or project-specific prefixes, suffixes, or
infixes in the value.
[TPS_SYST_02340]{DRAFT} Semantics of abstract meta-class BinaryMani-
festItemValue dSub-classes of abstract meta-class BinaryManifestItemValue
can be used to specify default values for a BinaryManifestItem.c(RS_SYST_-
00061)
Class BinaryManifestItemValue (abstract)
Package M2::AUTOSARTemplates::SystemTemplate::SoftwareCluster::BinaryManifest
Note This meta-class has the ability to act as an abstract base class for values of binary manifest item.
Tags:atp.Status=draft
Base ARObject
Subclasses BinaryManifestItemNumericalValue, BinaryManifestItemPointerValue
Attribute Type Mult. Kind Note
– – – – –
Table 11.23: BinaryManifestItemValue

Class BinaryManifestItemNumericalValue
Package M2::AUTOSARTemplates::SystemTemplate::SoftwareCluster::BinaryManifest
Note This meta-class has the ability to provide a numerical value for a binary manifest item.
Tags:atp.Status=draft
Base ARObject, BinaryManifestItemValue
Attribute Type Mult. Kind Note
value Numerical 0..1 attr This attribute specifies the actual numerical value to be
used in the binary manifest handle.
Tags:atp.Status=draft

Table 11.24: BinaryManifestItemNumericalValue

[constr_5202]{DRAFT} Existence of attribute BinaryManifestItemNumeri-

calValue.value dFor each BinaryManifestItemNumericalValue, attribute
value shall exist at the time when the definition of binary object meta-data is
finished.c()
[TPS_SYST_02341]{DRAFT} Semantics of the aggregation of meta-class Bina-
ryManifestItemPointerValue in the role defaultValue dMeta-class Binary-
ManifestItemPointerValue is used to provide a default value for a pointer.
This means that the default value consists of the address and the symbol of the
target object of the pointer.

767 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

In other words, the memory at the BinaryManifestItem.address is filled with the

default target address taken from BinaryManifestItemPointerValue.address.c
(RS_SYST_00061)
Class BinaryManifestItemPointerValue
Package M2::AUTOSARTemplates::SystemTemplate::SoftwareCluster::BinaryManifest
Note This meta-class has the ability to provide a value for a pointer in the context of a binary manifest item.
Tags:atp.Status=draft
Base ARObject, BinaryManifestItemValue
Attribute Type Mult. Kind Note
address Address 0..1 attr This attribute represents the address value of the
enclosing pointer value.
Tags:atp.Status=draft
symbol SymbolString 0..1 attr This attribute represents the symbol associated with the
binary manifest handle.
Tags:atp.Status=draft

Table 11.25: BinaryManifestItemPointerValue

[constr_5218]{DRAFT} Existence of attribute BinaryManifestItemPointer-

Value.address dFor each BinaryManifestItemPointerValue, attribute ad-
dress shall exist at the time when the definition of binary object meta-data is
finished.c()
[constr_5203]{DRAFT} Existence of attribute BinaryManifestItemPointer-
Value.symbol dFor each BinaryManifestItemPointerValue, attribute symbol
shall exist at the time when the definition of binary object meta-data is finished.c
()
[TPS_SYST_02342]{DRAFT} Semantics of meta-class BinaryManifestMeta-
DataField dMeta-class BinaryManifestMetaDataField is used to describe
meta-data of a Software Cluster Binary Manifest. This can be achieved
by means of the aggregation of BinaryManifestMetaDataField at CpSoft-
wareClusterBinaryManifestDescriptor in the role metaDataField.
As a part of the Software Cluster Binary Manifest, a BinaryManifest-
MetaDataField is represented at run-time by a symbol that is located at an ad-
dress.
On the model level, attribute category can be used to further categorize a specific
BinaryManifestMetaDataField.c(RS_SYST_00061)
Class BinaryManifestMetaDataField
Package M2::AUTOSARTemplates::SystemTemplate::SoftwareCluster::BinaryManifest
Note This meta-class provides the ability to define a meta-data field for the binary manifest descriptor.
Tags:atp.Status=draft
Base ARObject, BinaryManifestAddressableObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
5

768 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class BinaryManifestMetaDataField
size PositiveInteger 0..1 attr The value of this attribute represents the size of the
meta-data field in bytes.
Tags:atp.Status=draft
value VerbatimString 0..1 attr This attribute specifies the value of the meta-data field.
Tags:atp.Status=draft

Table 11.26: BinaryManifestMetaDataField

[constr_5204]{DRAFT} Existence of attribute BinaryManifestMetaDataField.

category dFor each BinaryManifestMetaDataField, attribute category shall
exist at the time when the definition of binary object meta-data is finished.c()
[constr_5205]{DRAFT} Existence of attribute BinaryManifestMetaDataField.
size dFor each BinaryManifestMetaDataField, attribute size shall exist at the
time when the definition of binary object meta-data is finished.c()
[constr_5217]{DRAFT} Existence of attribute BinaryManifestMetaDataField.
value dFor each BinaryManifestMetaDataField of category IMMUTABLE_-
TABLES_CHECKSUM, attribute value shall exist at the time when the definition of
binary object meta-data is finished.c()
[constr_5206]{DRAFT} Existence of attribute BinaryManifestMetaDataField.
symbol dFor each BinaryManifestMetaDataField, attribute symbol shall exist
at the time when the definition of binary object meta-data is finished.c()
[constr_5207]{DRAFT} Existence of attribute BinaryManifestMetaDataField.
address dFor each BinaryManifestMetaDataField, attribute address shall ex-
ist at the time when the definition of binary object meta-data is finished.c()
Please note that the meta-data of a Software Cluster Binary Manifest repre-
sent information that is immutable during the phase of connecting Software Clus-
ters with each other.

11.4 Software Cluster Extraction

A System with category SYSTEM_DESCRIPTION is typically used to describe the
complete vehicle with all included ECUs. Such a SYSTEM_DESCRIPTION may also
contain several CpSoftwareClusters that are assigned to different EcuInstances
by CpSoftwareClusterToEcuInstanceMappings.
To describe the content of a single CpSoftwareCluster a new System category is
introduced:
[TPS_SYST_02343]{DRAFT} System with category
SW_CLUSTER_SYSTEM_DESCRIPTION dA System with category
SW_CLUSTER_SYSTEM_DESCRIPTION describes the content of a single Cp-
SoftwareCluster.c(RS_SYST_00060)

769 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_02344]{DRAFT} SW_CLUSTER_SYSTEM_DESCRIPTION content dA

System with category SW_CLUSTER_SYSTEM_DESCRIPTION shall only contain the
CpSoftwareCluster relevant content, e.g.
• the EcuInstance to which the CpSoftwareCluster is mapped by CpSoft-
wareClusterToEcuInstanceMapping,
• the ApplicationPartitions to which the CpSoftwareCluster is mapped
by CpSoftwareClusterResourceToApplicationPartitionMapping,
• the CompositionSwComponentTypes referenced by the CpSoftwareClus-
ter in the role swComposition with all included SwComponentPrototypes
and all elements used by these SwComponentPrototypes directly or indirectly,
• the SwComponentPrototypes referenced by the CpSoftwareCluster via
SwComponentPrototypeAssignment and all elements used by these SwCom-
ponentPrototypes directly or indirectly,
• the CpSoftwareClusterToResourceMappings that references the CpSoft-
wareCluster in the role provider or requester with all CpSoftwareClus-
terServiceResources that in turn are referenced by the CpSoftwareClus-
terToResourceMappings,
• the SwConnectors that describe the communication relation between SwCom-
ponentPrototypes of the CpSoftwareCluster in focus,
• the PortInterfaceMappings that are referenced by the included SwConnec-
tors and do not lead to a conversion of the data/operation representation since
the data scaling between CpSoftwareClusters is excluded,
• the DataMappings that describe the communication relation to different Cp-
SoftwareClusters and to SwComponentPrototypes outside of the Cp-
SoftwareCluster in focus,
• the communication matrix description related content that is related to the the
included SystemSignals, e.g. ISignals, ISignalTriggerings, ISig-
nalIPdus and all the rest of them.
c(RS_SYST_00060)
Please note that in some cases the relevant DataMappings for the CpSoft-
wareCluster may be described in the SYSTEM_DESCRIPTION on the opposite side,
i.e. on different CpSoftwareClusters or on SwComponentPrototypes outside
of the CpSoftwareCluster. The reason is that in the SYSTEM_DESCRIPTION the
definition of DataMappings is sufficient on one side. But since these side will be re-
moved during the creation of the SW_CLUSTER_SYSTEM_DESCRIPTION the relevant
DataMappings shall be shifted to the CpSoftwareCluster in focus.
For the Ecu and RTE Configuration a System with category ECU_EXTRACT
is derived from the SYSTEM_DESCRIPTION, ECU_SYSTEM_DESCRIPTION or
SW_CLUSTER_SYSTEM_DESCRIPTION as described by [TPS_SYST_01139].

770 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

The derivation of an ECU_EXTRACT is a model transformation since a “flat view” of

SwComponentPrototypes running on the EcuInstance is expected by the RTE.
The SwComponentPrototypes that are included in the CompositionSwCom-
ponentType that is referenced by a CpSoftwareCluster in the role swCom-
position need to be flattened according to the rules described in chapter 14
in the ECU_EXTRACT. So in case of a SW_CLUSTER_SYSTEM_DESCRIPTION the
ECU_EXTRACT represents the “flat view” of a single CpSoftwareCluster.
Please note that during the creation of the ECU_EXTRACT the «instanceRef»s in
PortElementToCommunicationResourceMapping shall be adapted because of
the process of flattening the hierarchical Software Composition into the “flat view” rep-
resentation.
[constr_5208]{DRAFT} Existence of System.swCluster dIn a System with cat-
egory SW_CLUSTER_SYSTEM_DESCRIPTION, the reference System.swCluster
shall exist at least once at the time when the software cluster extraction is fin-
ished.c()
[constr_5209]{DRAFT} Existence of reference CpSoftwareCluster.
swComponentAssignmentswComponent dIn a System with category
SW_CLUSTER_SYSTEM_DESCRIPTION, the reference System.swCluster.swCom-
ponentAssignmentswComponent shall exist at the time when the software
cluster extraction is finished.c()
[constr_5210]{DRAFT} Existence of reference SystemMapping.
portElementToComResourceMapping dIn a System with category
SW_CLUSTER_SYSTEM_DESCRIPTION, the reference System.mapping.portEle-
mentToComResourceMapping shall exist at least once at the time when the
software cluster extraction is finished.c()
[constr_5211]{DRAFT} Existence of reference PortElementToCommunica-
tionResourceMapping.communicationResource dIn a System with category
SW_CLUSTER_SYSTEM_DESCRIPTION, the reference System.mapping.portEle-
mentToComResourceMapping.communicationResource shall exist at least once
at the time when the software cluster extraction is finished.c()
[constr_5212]{DRAFT} Existence of reference SystemMapping.re-
sourceToApplicationPartitionMapping dIn a System with category
SW_CLUSTER_SYSTEM_DESCRIPTION, the reference System.mapping.resource-
ToApplicationPartitionMapping shall exist at the time when the software
cluster extraction is finished.c()
[constr_5213]{DRAFT} Existence of reference CpSoftwareClusterResource-
ToApplicationPartitionMapping.applicationPartition dIn a System with
category SW_CLUSTER_SYSTEM_DESCRIPTION, the reference System.mapping.
resourceToApplicationPartitionMapping.applicationPartition shall
exist at the time when the software cluster extraction is finished.c()

771 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_5214]{DRAFT} Existence of reference CpSoftwareClusterResource-

ToApplicationPartitionMapping.resource dIn a System with category
SW_CLUSTER_SYSTEM_DESCRIPTION, the reference System.mapping.resource-
ToApplicationPartitionMapping.resource shall exist at the time when the
software cluster extraction is finished.c()
[constr_5215]{DRAFT} Existence of reference CpSoftwareCluster-
ToResourceMapping.serviceResource dIn a System with category
SW_CLUSTER_SYSTEM_DESCRIPTION, the reference System.mapping.soft-
wareClusterToResourceMapping.serviceResource shall exist at the time
when the software cluster extraction is finished.c()
[constr_5216]{DRAFT} Existence of reference CpSoftwareClusterToRe-
sourceMapping.requester and/or provider dIn a System with category
SW_CLUSTER_SYSTEM_DESCRIPTION, at least one of the references System.map-
ping.softwareClusterToResourceMapping.requester or System.mapping.
softwareClusterToResourceMapping.provider shall exist at the time when
the software cluster extraction is finished.c()

11.4.1 Software Cluster Extraction and DataMappings

The creation of the SW_CLUSTER_SYSTEM_DESCRIPTION for the HOST_SOFT-

WARE_CLUSTER takes a special role. The DataMappings and CpSoftwareClus-
terToResourceMappings of all CpSoftwareClusters that are mapped to the
same EcuInstance as the HOST_SOFTWARE_CLUSTER shall be made available in
the SW_CLUSTER_SYSTEM_DESCRIPTION of the HOST_SOFTWARE_CLUSTER.
This is shown in the example in Figure 11.12, where the Mappings of
the outerPort that is connected to “Composition1” are available in the
SW_CLUSTER_SYSTEM_DESCRIPTION for “SWCL11” where the “Composition1”
is located and the “HOST” CpSoftwareCluster.

772 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

SW Cluster
CpSoftwareCluster
CommunicationResource

PortElementToCommunication
ResourceMapping
SWCL11
CpSoftwareCluster
Extract
Composition 1
CommunicationResource
Comp 1.1
DataMapping
PortElementToCommunication Comp 1.2
ResourceMapping
SYSTEM SystemSignal
Composition 1 Composition 2
Comp 1.1 Comp 2.1
Comp 2.2 DataMapping
Comp 1.2 SW Cluster
CpSoftwareCluster
CommunicationResource
SystemSignal
PortElementToCommunication
Composition 3 (Host)
DataMapping ResourceMapping
Comp 3.1
Comp 3.2 HOST DataMapping
Extract
SystemSignal Composition 3 (Host) SystemSignal
Comp 3.1
Comp 3.2 DataMapping

SystemSignal

Figure 11.12: Handling of DataMapping during creation of

SW_CLUSTER_SYSTEM_DESCRIPTION

The DataMappings on the HOST_SOFTWARE_CLUSTER are necessary for the gen-

eration of the AUTOSAR COM Stack. ISignals that are referencing the System-
Signals are mapped into ISignalIPdus and these ISignalIPdus are instantiated
on the PhysicalChannels via PduTriggerings. This information is necessary to
derive the COM Pdus. The ISignalIPdus are then mapped into Frames for commu-
nication over CAN or FlexRay or are assigned to ProvidedServiceInstances or
ConsumedServiceInstances for communication over SOME/IP. All information that
is necessary to configure the COM Stack shall be available in the HOST_SOFTWARE_-
CLUSTER.
The outerPorts of the APPLICATION_SOFTWARE_CLUSTERs and the available
DataMappings and CpSoftwareClusterToResourceMappings in these Cp-
SoftwareClusters are used to configure the RTE and the Transformers.

773 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

12 Usage of the System Template

As introduced in [TPS_SYST_01003] the System Template is used to describe a
System with category SYSTEM_CONSTRAINT_DESCRIPTION, a System with cat-
egory ABSTRACT_SYSTEM_DESCRIPTION and a System with category SYS-
TEM_DESCRIPTION. System with category SYSTEM_EXTRACT is described in more
detail in chapter 13. System with category ECU_EXTRACT is described in more detail
in chapter 14.
Certain elements of the System Template may have a different meaning at the different
stages of the AUTOSAR Methodology. The following sections describe the differences.

774 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

12.1 System Constraint Description

Meta-classes, Chapters Usage to describe the System Con- Usage to describe the System Configura-
straints tion
CommunicationCluster, The Topology is completely described in the The Topology description will be unchanged
EcuInstance (chapter 3) System Constraint Description. copied to the System Configuration descrip-
tion. The Topology may only be changed
during another iteration development step of
the whole system.
FrameTriggering, The System with category SYS- In contrary to the System with category
PduTriggering, ISignal- TEM_CONSTRAINT_DESCRIPTION de- SYSTEM_CONSTRAINT_DESCRIPTION
Triggering (chapter 6) scribes all FrameTriggerings that are the final System with category
predefined on all CommunicationClus- SYSTEM_DESCRIPTION contains all
ters of a vehicle. The predefinition of the FrameTriggerings, PduTriggerings,
communication matrix forces the system ISignalTriggerings that will be sent by
generator to use the given FrameTrigger- any EcuInstance in the car. No matter if
ings. Constraints for the system generator they were predefined (system constraint) or
arise here e.g. from the used bus bandwidth, if they were generated by the system gener-
used identifiers as well as from the timing ator. The available information, in addition
and at which position in a Frame a Pdu is to the information, which is inserted by the
transmitted on a PhysicalChannel on a AUTOSAR Ecu configuration generator step,
CommunicationCluster. will be used as input to configure the Basic
SW for the communication.
Such a manual definition of the communica-
tion can be made for any reason where it is
necessary to restrict the system generator.
One example is the usage of legacy EcuIn-
stances in an AUTOSAR System. The
FrameTriggerings that are transmitted or
received by these legacy EcuInstances
are constraints for the system generator be-
cause they cannot be changed, if the com-
patibility is supposed to be achieved without
any changes at the legacy EcuInstances.
Gateway (chapter 8) The System with category SYS- In contrary to the System with category
TEM_CONSTRAINT_DESCRIPTION de- SYSTEM_CONSTRAINT_DESCRIPTION
scribes all Gateways in the system including the final System with category SYS-
their IPduMappings and ISignalMap- TEM_DESCRIPTION describes all Gate-
pings that are predefined. The reasons for ways with all their IPduMappings and
such predefinitions are quite the same as for ISignalMappings. No matter if they were
the predefinitions of the FrameTrigger- predefined (System Constraint) or if they
ings. were generated by the System Generator.
SwcToEcuMapping (subsec- The mapping of Software Components to In a complete System with category SYS-
tion 5.1.1) EcuInstances may be predefined. The TEM_DESCRIPTION, all Software Compo-
predefinition will force the system generator nents are mapped to EcuInstances.
to use the specified mapping. Thus, with the
SwcToEcuMapping element it is possible to
describe that one or more Software Compo-
nents shall be mapped to a specific EcuIn-
stance.
MappingConstraint There may be system constraints that limit After the mapping has been com-
(subsection 5.1.4) the system generators freedom to map pleted, the System with category SYS-
Software Components to arbitrary EcuIn- TEM_DESCRIPTION will contain mapping
ComponentClustering stances. These system constraints can be descriptions for all elements, and the map-
(subsubsection 5.1.4.1) necessary e.g. for optimization and safety ping constraints are obsolete. But that does
reasons to make additional guidelines for the not mean that mapping constraints have to
ComponentSeparation ( System Generator. be deleted after the system generation step.
subsubsection 5.1.4.2) By deleting the mapping constraints you
would lose the information why a mapping of
a Software Component to an EcuInstance
is chosen.
5

775 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Meta-classes, Chapters Usage to describe the System Con- Usage to describe the System Configura-
straints tion
DataMapping (section 5.2) The System with category SYS- In contrary to the System with category
TEM_CONSTRAINT_DESCRIPTION may de- SYSTEM_CONSTRAINT_DESCRIPTION
SenderReceiver- scribe the predefined mapping of Software the final System with category SYS-
ToSignalMapping ( Components to certain EcuInstances (see TEM_DESCRIPTION shall contain all
subsubsection 5.2.1.1) chapter 5.1.1). Only if such a mapping ex- DataMapping definitions. No matter if
ists, it is reasonable to define the DataMap- they were predefined (system constraint)
SenderReceiverToSig- ping of the data exchanged between the or if they were generated by the System-
nalGroupMapping ( Software Components. Generator.
subsubsection 5.2.1.2)

ClientServerToSig-
nalMapping (subsubsection
5.2.1.3)
SignalPathConstraint It can be necessary e.g. for optimization SignalPathConstraints are not an
(subsection 5.2.2) and safety reasons to make additional guide- obligatory part of the System with
lines for the System Generator, which spe- category SYSTEM_DESCRIPTION. In
CommonSignalPath ( cific way a VariableDataPrototype or the final System with category SYS-
subsubsection 5.2.2.1) ClientServerOperation should take in TEM_DESCRIPTION every ISignal is as-
the network without defining in which Pdu signed to a Pdu and every Pdu is assigned to
ForbiddenSignalPath and Frame it is transmitted. a Frame. Thereby the paths of Variable-
(subsubsection 5.2.2.2) DataPrototypes or ClientServerOp-
erations on the network are implicitly
PermissibleSignal- described. But that does not mean that
Path (subsubsection 5.2.2.3) the SignalPathConstraints have to be
deleted after the system generation step.
SeparateSignalPath (sub- By deleting the SignalPathConstraints
subsection 5.2.2.4) you would lose the information why you have
chosen e.g. a specific mapping of an ISig-
nal into a Pdu. If you extend or change
the system at a later stage the missing
SignalPathConstraints could lead to
not wanted signal mappings by the System
Generator.

Table 12.1: Usage of the System Template

12.2 Abstract System Description

[TPS_SYST_01134] Abstract System Description dDue to the fact that the functional
view on vehicle system can differ from the actual technical definition of the software-
architectures of individual EcuInstances the System Template optionally allows to
define a System with category ABSTRACT_SYSTEM_DESCRIPTION.c()
[TPS_SYST_01135] Refactoring of an Abstract System Description into a project
specific technical view of the software architecture dThe System with category
ABSTRACT_SYSTEM_DESCRIPTION concentrates on the functional aspects of the sys-
tem design and provides an own abstract VFB. During the further activities this abstract
view shall be refactored into a more project specific technical view of the software ar-
chitecture.
It is important to note that during the refactoring of the System with cate-
gory ABSTRACT_SYSTEM_DESCRIPTION into the System with category SYS-
TEM_DESCRIPTION no restrictions to the allowed actions apply (This is in contrast
to the activity of deriving the System with category SYSTEM_EXTRACT from the
System with category SYSTEM_DESCRIPTION, see [TPS_SYST_01123].c()

776 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[TPS_SYST_01136] ViewMapSet and ViewMap are used to trace the transforma-

tions between different models dThe ViewMapSet and ViewMap elements are used
to trace the transformations between different models within the AUTOSAR environ-
ment.c()
System Template
Abstract
These classesSystem
are described more
Descriptionin System Description
detail in the Generic Structure Template [2].
AbstractSoftwareComposition

Abstract Empty Composition

System
Description

SoftwareComposition
System
Description Empty Composition

Figure 12.1: Abstract System Description refactoring to a System Description

- AUTOSAR Confidential -
18 5 July 2012

777 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

13 System Extract of the System Configuration

Description
This chapter describes contents and creation of the AUTOSAR work product System
with category SYSTEM_EXTRACT, based on Meta Model elements contained in the
System Template and Software Component Template.
The System with category SYSTEM_EXTRACT is introduced to allow a collabora-
tion between an OEM and a Supplier.1 The OEM/Supplier Collaboration scenario is
described in more detail in chapter 13.1.
The OEM is often only interested in the required functionality and the integration of
the functionality into the System. Thus the OEM provides a basis for designing a
subsystem, which is developed by the supplier. One difference to the System with
category ECU_EXTRACT is that the System with category SYSTEM_EXTRACT is
not fully decomposed and still needs to be refined before it forms the basis for the ECU
configuration. Another difference is that a System with category SYSTEM_EXTRACT
is not fixed to an EcuInstance.
[TPS_SYST_01123] System Extract may cover one or many EcuInstances dThe
System with category SYSTEM_EXTRACT may cover one or many EcuInstances.c
()
The System with category SYSTEM_EXTRACT is using the same meta model el-
ements as the System with category SYSTEM_DESCRIPTION. The System with
category SYSTEM_DESCRIPTION is a special case of a System with category
SYSTEM_EXTRACT. From the technical point of view there is no difference. The dis-
tinction is only made for the sake of Methodology [4].
In the System with category SYSTEM_EXTRACT the OEM strips all information from
the System with category SYSTEM_DESCRIPTION that is not needed for the def-
inition of the subsystem. There is one exception to this simple ”remove” rule: the
communication mapping may need to be extended, which will be described in more
detail in chapter 13.2.
[TPS_SYST_03000] Co-existing System with category SYSTEM_DESCRIPTION
and System with category SYSTEM_EXTRACT dIn order to be able to handle one
System with category SYSTEM_DESCRIPTION and one or several Systems with
category SYSTEM_EXTRACT within the same workspace it shall be possible to pro-
vide different full qualified names to the elements of System with category SYS-
TEM_EXTRACT.c(RS_SYST_00045)
When different Systems with various categories co-exist it is possible to define
ViewMap and ViewMapSet between their elements according to [TPS_SYST_01136].

1
Collaboration scenarios between different departments of an OEM are also supported by the
System with category SYSTEM_EXTRACT. For the sake of simplicity such scenarios are not addressed
here.

778 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

In contrast to the System with category ECU_EXTRACT the System with category
SYSTEM_EXTRACT may contain CompositionSwComponentTypes. Empty Compo-
sitionSwComponentTypes in the System with category SYSTEM_EXTRACT rep-
resent subsystems that need to be refined by a Supplier. Figure 13.1 shows an ex-
ample where a System with category SYSTEM_DESCRIPTION is stripped down to a
subsystem.
System Extract example

SoftwareComposition

System
Configuration
Description

SoftwareComposition
System
Extract (all
elements
that are not
relevant for
ECU A are
removed
Port used only in ECU internal communication SWC mapped to ECU A
Port used in ECU external communication SWC mapped to ECU B
- AUTOSAR Confidential -
Figure
5 13.1:05.02.2008
System Extract creation: irrelevant
ECU Extract elements are removed from the System
- Specification Improvement

Description

13.1 OEM/Supplier Collaboration Scenario

In an important collaboration scenario, an OEM commissions a supplier to provide im-
plementations of one or more functionalities to be integrated into an AUTOSAR system
in the form of Application Components. The OEM is primarily interested in the required
functionality and the interfaces defining the integration of the Software Component into
the System VFB rather than the internal structure of such a component. On the other
hand, the supplier, delivering both the component implementation in combination with
the ECU it is destined to run on, may claim the internal structure of such a higher-
level component contains substantial intellectual property, and hence may not want to
disclose its internal works to the OEM.
Effectively, the use case can be described in the following manner:
• The OEM generates a System with category SYSTEM_EXTRACT from the Sys-
tem with category SYSTEM_DESCRIPTION. From the System with category
SYSTEM_DESCRIPTION all elements are removed that are not relevant for the
design of the subsystem, such as SW components or topology elements.

779 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• The OEM can deliver a sub-structure of Software Compositions or even Atomic

Software Components in the System with category SYSTEM_EXTRACT. But
the System with category SYSTEM_EXTRACT can also contain empty Software
Compositions. The OEM shall have the possibility to define only the outer shell
of a Software Composition that is to implement a certain functionality. Such an
empty CompositionSwComponentType does contain all the provided and re-
quired ports with the included ReceiverComSpecs and SenderComSpecs de-
scribing the requested component’s outside communication needs. But it does
not need to contain SwComponentPrototypes or SwConnectors at this stage.
• Such empty components are added to a System’s VFB, the outside ports are
connected with other components in the VFB. However, at this stage the inner
structure of such CompositionSwComponentType can still be left empty.
• The System with category SYSTEM_EXTRACT contains the mapping of com-
ponents to the target EcuInstances, including the empty compositions. Signal
mappings affecting the empty compositions are targeting the Composition-
SwComponentType’s ports.
• The OEM delivers the System with category SYSTEM_EXTRACT to the Sup-
plier.
• The Supplier adds the substructure to the empty CompositionSwComponent-
Types by adding SwComponentPrototypes and SwConnectors. This once
more leads to a hierarchical VFB, effectively the Supplier creates a local System
Description for his subsystem.
• The Supplier adjusts the Signal mappings to the actual ports of the inner Atom-
icSwComponentType prototype.
• The Supplier generates the System with category ECU_EXTRACT from
his ECU-local system description. The resulting System with category
ECU_EXTRACT does not include prototypes of type CompositionSwCompo-
nentType any longer.
• Based on this System with category ECU_EXTRACT the actual ECU configura-
tion is done.
When the supplier receives the System with category SYSTEM_EXTRACT from the
OEM he has basically two choices how to proceed:
1. The Supplier takes the System with category SYSTEM_EXTRACT of the OEM
as the structural basis for the ECU development. In this case the following steps
may follow:
• The Supplier adds the substructure to the empty CompositionSwCom-
ponentTypes by adding SwComponentPrototypes and SwConnectors.
This once more leads to a hierarchical VFB, effectively the Supplier cre-
ates a local System Description for his subsystem (System with category
ECU_SYSTEM_DESCRIPTION).

780 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• The Supplier adjusts the Signal mappings to the actual ports of the inner
AtomicSwComponentType prototype.
2. The Supplier creates an own structure to base the ECU development on System
with category ECU_SYSTEM_DESCRIPTION and perform a view mapping be-
tween the OEM’s System with category SYSTEM_EXTRACT and the System
with category ECU_SYSTEM_DESCRIPTION. In this case the following steps
may follow:
• The Supplier develops an own structure how the ECU shall be designed
but needs to respect the required outer boundary of the OEM’s required
communication behavior (ReceiverComSpecs and SenderComSpecs).
• The Supplier adjusts the Signal mappings to the actual ports of the inner
AtomicSwComponentType prototype.
When the design of the System with category ECU_SYSTEM_DESCRIPTION is com-
plete the following steps follow:
• The Supplier generates the System with category ECU_EXTRACT from his
System with category ECU_SYSTEM_DESCRIPTION. The resulting System
with category ECU_EXTRACT does not include prototypes of type Composi-
tionSwComponentType any longer.
• Based on this System with category ECU_EXTRACT the actual ECU configura-
tion is done.

13.2 Data Mapping in the System Extract

As mentioned before, there is a slight complication to the simple ”remove” rule. This
can be shown best with an example.
Example: Assume a simple topology with two EcuInstances A and B and three Pdus
X (sent from A to B), Y (sent from B to A) and Z (sent from B to A) as shown in Figure
13.2.
PDU_X

ECU A PDU_Y ECU B

PDU_Z

Figure 13.2: Example topology with two EcuInstances and three Pdus exchanged be-
tween them

Furthermore assume a composition of software-components realized by the meta-

class CompositionSwComponentType as shown in Figure 13.3. It consists of
six SwComponentPrototypes ‘A1’ to ‘A3’ (aggregated in composition ‘SwCompA’),

781 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

‘B1’ / ‘B2’ (aggregated in composition ‘SWCompB’), ‘C1’ (aggregated in composition

‘SWCompAplusBplusC’) and an empty composition ‘SWCompC’.
The overall composition ‘SWCompAplusBplusC’ aggregates ‘SwCompA’, ‘SWCompB’,
the empty ‘SWCompC‘ and the SwComponentPrototype ‘C1’.

SWCompAplusBplusC

SWCompA Mapped to Mapped to SWCompB Mapped to

PDU_X,
PDU_X, PDU_Y,
SignalX2
SignalX1 SW-C SignalY1
R
A2 SW-C SW-C
R R P R
B1 B2
SW-C P
A1 Mapped to
SW-C
R P P PDU_Z,
A3
SWCompC SignalZ1

R Empty Composition P R SW-C

SWCompC C1

SW Component mapped to ECU A

SW Component mapped to ECU B

Figure 13.3: Example SW composition with mapping information

The atomic SwComponentPrototypes ‘A1’, ‘A2’, ‘B1’ and ‘C1’ are mapped to ‘ECU
A’. The atomic SwComponentPrototypes ‘A3’, ‘B2’ and the empty composition
‘SWCompC‘ are mapped to ‘ECU B’. The data sent from
• ‘A1’ to ‘A3’ is mapped to ‘PDU_X’, ‘SignalX1’,
• ‘B1’ to ‘B2’ is mapped to ‘PDU_X’, ‘SignalX2’ and
• ‘A3’ to ‘B1’ and ‘A3’ to ‘SWCompC‘ is mapped to ‘PDU_Y’, ‘SignalY1’
• ‘SWCompC‘ to ‘C1’ is mapped to ‘PDU_Z’, ‘SignalZ1’
As usual, the data mapping rules refer to the VariableDataPrototype in the
PPortPrototype of the sending SW component. Note that DataMappings can be
performed on compositions and on atomic SwComponentPrototypes as described
in chapter 5.2.1. 2
Figure 13.4 shows how the System extract for ECU A and for ECU B of this SW com-
position would look like: Only those elements are included that are relevant for the
subsystem.

2
Data mapping is allowed on empty compositions and on compositions that contain atomic SwCom-
ponentPrototypes.

782 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

SWCompAplusBplusC

SWCompA Mapped to SWCompB

PDU_X, Mapped to
SignalX1 PDU_X,
SW-C Mapped to SignalX2
R
A2 PDU_Y, SW-C
R P
SignalY1 B1
SW-C P
A1 Mapped to
PDU_Z,
SignalZ1
R
SW-C
C1

SWCompAplusBplusC

SWCompA Mapped to SWCompB Mapped to

PDU_Y, PDU_X,
SignalY1 SignalX2
Mapped to SW-C
PDU_X, R R
B2
SignalX1

SW-C Mapped to
R P P PDU_Z,
A3
SWCompC SignalZ1

R Empty Composition P
SWCompC

SW Component mapped to ECU A

SW Component mapped to ECU B

Figure 13.4: Example System extract for ECU A (upper figure) and ECU B (lower figure)
of above introduced composition

In both figures all SwComponentPrototypes and compositions that are mapped onto
the EcuInstance are included. The SwConnector between these SwComponent-
Prototypes are also included. Furthermore, the relevant topology information and
communication matrix have to be included, but they are out of scope of this example.
SwConnectors that were used to connect to SW components that are not included in
the System Extract are not included. Instead, the mapping to an ISignal in a Pdu is
used to identify the source/destination of that data.
The problem that new mapping rules have to be added arises for example in the Sys-
tem Extract for ‘ECU A’ with the mapping to ‘PDU Y’, ‘SignalY1’: Since SW component
‘A3’, which was referenced in the original mapping, is no longer included, the data
mapping needs a new data element in a port to reference to. In the example, it is the
required port of ‘B1’, so that the Supplier has the information that B1 receives the data
via ‘PDU Y’.

783 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

13.3 SW component inclusion and top level data mapping

In section 13.2 the approach is to provide the DataMapping on the PortPrototypes
of the SwComponentPrototypes which are mapped to one EcuInstance. Since
the granularity of mapping SwComponentPrototypes to EcuInstances is possible
for individual atomic SwComponentPrototypes this approach may result in many
DataMappings from different software component PortPrototypes to the same
SystemSignal (depending where in the hierarchical structure they are located).
An alternative approach is to provide the complete communication information of the
whole System Extract on the RootSwCompositionPrototype and perform the
DataMapping on the PortPrototypes of the RootSwCompositionPrototype
only. This approach is illustrated in figure 13.5.
PortPrototypes are created on the RootSwCompositionPrototype represent-
ing the external communication of this EcuInstance. DelegationSwConnectors
are created to establish the communication of the external software components with
the software components inside the local EcuInstance.
In figure 13.5 the software components X, Y and Z are mapped to remote EcuIn-
stances. Their communication needs are collected in PortPrototypes on the
RootSwCompositionPrototype and the communication is delegated via SwCon-
nectors inside the hierarchical software component structure.
In this example the approach for X and Y is trivial since there are only some Delega-
tionSwConnectors required to connect the PortPrototypes of the RootSwCom-
positionPrototype with the PortPrototypes of the respective SwComponent-
Prototypes.
But for SwComponentPrototype Z the approach needs to be extended, because
the communication on system level is designed to happen inside the composition V.
In this case the communication needs to be delegated out of the composition (cre-
ation of DelegationSwConnectors inside the composition V) to be visible in the
RootSwCompositionPrototype. Then again the approach of connection to the
RootSwCompositionPrototype can be applied.

784 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11
System Extract example

SoftwareComposition

Empty Composition
V Y

X
Z

SoftwareComposition – ECU Extract Mapped to

FrameY,
Empty Composition SignalY1
V
Mapped to
FrameX,
SignalX1
Mapped to
FrameY,
SignalY2

SWC mapped to ECU A

SWC mapped to ECU B
- AUTOSAR Confidential -
3
Figure
05.02.2008
13.5: Example with ECU
software components mapped to two ECUs
Extract - Specification Improvement

785 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

13.4 Port-Interface Mapping in the System Extract

A similar problem as the one with DataMappings described in chapter 13.2 and chap-
ter 13.3 exists for the PortInterfaceMappings as well. To illustrate this Figure 13.6
depicts an example with software components mapped to two different ECUs.

SwCompAplusB PortInterfaceMapping

SwCompA SwCompB
SW-C
R
A2
SW-C SW-C SW-C
P P R R P R
A1 B1 B3
SW-C
R P
A3

SW Component mapped to ECU A Port typed by Interface X

SW Component mapped to ECU B Port typed by Interface Y

Figure 13.6: Example with software components mapped to two ECUs

Hereby the PPortPrototype typed with PortInterface X of SWCompA is con-

nected with the RPortPrototype typed with PortInterface Y of SWCompB by
- AUTOSAR Confidential -
means of an AssemblySwConnector. This AssemblySwConnector has an at-
8 05.02.2008 ECU Extract - Specification Improvement

tached PortInterfaceMapping to perform a mapping between the elements (see

chapter 4.3.1.5 of [5]) of the two otherwise incompatible PortInterfaces X and Y.
A System Extract for ECU A is now created by applying the approach described
in chapter 13.3, i.e., by providing the complete communication information of the
whole System Extract on the RootSwCompositionPrototype and performing the
DataMapping on the PortPrototypes of the RootSwCompositionPrototype
only.
When doing this however the following two additional things have to be considered:
• The PortInterfaceMapping shall be preserved during this process
• The information about the PortInterfaces referenced by the PortProto-
types connected by the AssemblySwConnector referencing the PortInter-
faceMapping shall be preserved during this process
Just as in the approach described in chapter 13.3 PortPrototypes are created
on the RootSwCompositionPrototype representing the external communication
of this EcuInstance. The RPortPrototypes however are not typed by the Port-
Interface X of the RPortPrototypes of the SwComponentPrototypes inside
ECU A (SWCompB in the example) but by the PortInterface Y of the PPortPro-
totype which was connected to the RPortPrototypes by means of the Assem-
blySwConnector. Afterwards the just like in the approach described in chapter 13.3

786 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

DelegationSwConnectors are created to connect the PortPrototypes of the

RootSwCompositionPrototype with the corresponding RPortPrototypes of the
SwComponentPrototypes inside ECU A.
This however yields a DelegationSwConnector between RPortPrototype typed
by PortInterface Y (which has been created on the RootSwCompositionPro-
totype) and the RPortPrototype typed by PortInterface X of SWCompB. In
order to perform a mapping between the elements of these otherwise incompatible
interfaces, the PortInterfaceMapping which has initially been referred to by the
AssemblySwConnector needs to be referenced by the DelegationSwConnector.
The final result of this process in depicted in Figure 13.7

SwCompAplusB PortInterfaceMapping
SwCompA SwCompB
SW-C
R
A2
SW-C SW-C
P P R R P P P
A1 B1

P R
SW Component mapped to ECU A Port typed by Interface X

SW Component mapped to ECU B Port typed by Interface Y

Figure 13.7: Example with software components mapped to two ECUs

- AUTOSAR Confidential -

14 9
ECU Extract of the System Configuration
05.02.2008 ECU Extract - Specification Improvement

Description
This chapter describes contents and creation of the AUTOSAR System with cate-
gory ECU_EXTRACT, based on Meta Model elements contained in the System Tem-
plate and Software Component Template.
The System with category ECU_EXTRACT represents the view of one specific
EcuInstance onto the overall System with category SYSTEM_DESCRIPTION. The
System with category ECU_EXTRACT forms the basis for configuring that particular
EcuInstance in focus.
For instance, RTE configuration fundamentally depends on the number and types of
SwComponentPrototypes deployed onto the EcuInstance; Services are config-
ured according to those Software Components’ ServiceNeeds; the COM-stack BSW

787 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

modules will be configured considering the EcuInstance’s participation in the overall

System Network Topology and Communication.
[TPS_SYST_01139] Ecu Extract derived from System Description or Sys-
tem Extract covers exactly one EcuInstance dThe System with category
ECU_EXTRACT shall only contain the subset of information derived from the Sys-
tem with category SYSTEM_DESCRIPTION or System with category SYS-
TEM_EXTRACT relevant for configuring the targeted EcuInstance.c()
In order to keep ECU configuration focused and manageable despite the complexity
of a full System Configuration, all other information shall be stripped from the System
with category SYSTEM_DESCRIPTION or from the System with category SYS-
TEM_EXTRACT when creating the System with category ECU_EXTRACT.
AUTOSAR VFB Descriptions naturally form hierarchies of CompositionSwCompo-
nentTypes. Consequently, in the System Configuration the SWC-related information
for different EcuInstances is not separated but in general is intermingled. In contrast,
for the task of ECU configuration (RTE configuration, Service Configuration, Measure-
ment and Calibration) a hierarchically “flat view” on the SwComponentPrototypes
running on the EcuInstances is preferable over a hierarchical view, which is more fa-
vored by application-software development. Thus, deriving an System with category
ECU_EXTRACT actually is a model transformation, following a set of rules described in
the following sections.
[TPS_SYST_02313] Ecu Extract derived from ECU_SYSTEM_DESCRIPTION cov-
ers an EcuInstance dThe System with category ECU_SYSTEM_DESCRIPTION
defines the content of a single EcuInstance and the same is true for the derived
ECU_EXTRACT. The derived ECU_EXTRACT is flattened and does not contain any hier-
archies of CompositionSwComponentTypes.c()
[TPS_SYST_02314] Ecu Extract derived from SW_CLUSTER_SYSTEM_DESCRIPTION
covers a subset of an EcuInstance dThe System with category
SW_CLUSTER_SYSTEM_DESCRIPTION defines the content of a single CpSoft-
wareCluster and the same is true for the derived ECU_EXTRACT. The derived
ECU_EXTRACT is flattened and does not contain any hierarchies of Composition-
SwComponentTypes.c()
As System- and ECU development typically happens in iterations, the use case of
repeatedly extracting the information from an incrementally changing System Config-
uration needs to be considered. In particular, it shall be possible to detect changes
between consecutively generated ECU extracts in order to selectively update the exist-
ing ECU configuration (14.5).
AUTOSAR supports the definition and consequently the handling of Variability in the
System Configuration. According to the specified binding time associated with a partic-
ular VariationPoint, typically some of these variants will already be resolved at the
time of a System with category ECU_EXTRACT. If however the binding time occurs in
a later stage of the AUTOSAR methodology, i.e. during ECU Configuration or later, the
variability needs to be carried over to the System with category ECU_EXTRACT. This

788 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

also holds true for Variation points that ultimately are resolved at system configuration
time but affect post-build configuration parameters. (14.6)
The System with category ECU_EXTRACT logically forms one entity. Therefore, for
ease of readability the rest of the chapter assumes just one file, “the XML file”. How-
ever, it explicitly is allowed to split the System with category ECU_EXTRACT over
several files.

14.1 Topology
Only those Topology elements relevant for the EcuInstance in scope are taken over
from the System with category SYSTEM_DESCRIPTION into the System with cat-
egory ECU_EXTRACT.
• The System with category ECU_EXTRACT is always associated with exactly
one EcuInstance. Therefore exactly one EcuInstance is included along with
all classes included in EcuInstance by composition: CommunicationCon-
trollers and CommunicationConnectors with all their CommConnector-
Ports.
• A CommunicationCluster is included along with all its PhysicalChannels if
at least one PhysicalChannel is used by the EcuInstance. In other words, if
at least one of the included CommunicationConnectors is referenced by any
of a CommunicationCluster’s PhysicalChannels, the whole Communica-
tionCluster and all its PhysicalChannels are included.
• From the used PhysicalChannels, only those FrameTriggerings,
PduTriggerings, ISignalTriggerings shall be included that are used
by the EcuInstance, e.g. they are associated with a FramePort, IPdu-
Port, ISignalPort belonging to one of the EcuInstance’s Communica-
tionConnectors. Note: Including just a subset of a PhysicalChannel’s
FrameTriggerings, PduTriggerings, ISignalTriggerings is possible
without changing the PhysicalChannel itself because of the splitable
stereotype applied on the PhysicalChannel / FrameTriggering, PduTrig-
gering, ISignalTriggering composition.
As the Topology elements are not modified when taken over into the System with
category ECU_EXTRACT, their package structure and short names are not touched
(see section 14.4.1).

14.2 Top-level Software Composition

In the System with category SYSTEM_DESCRIPTION the application software com-
position is hierarchic by nature as described in chapter 4. When mapping SwCom-
ponentPrototypes onto concrete EcuInstances using the SwcToEcuMapping

789 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

class (section 5.1.1), either SwComponentPrototypes of type AtomicSwCompo-

nentType, or SwComponentPrototypes of type CompositionSwComponentType
are deployed onto one specified EcuInstance.
In order to obtain this ECU-centric view, the hierarchical structure of the System with
category SYSTEM_DESCRIPTION needs to be transformed into a 1-layer representa-
tion, where one distinguished CompositionSwComponentType hosts all SwCompo-
nentPrototypes of type AtomicSwComponentType to run on the EcuInstance.
In the System with category ECU_EXTRACT the resulting RootSwComposition-
Prototype is a flat structure where the included SwComponentPrototypes become
real SWC instances, reflecting the actual resource needs on the targeted EcuIn-
stance.
[TPS_SYST_01140] Ecu Extract contains only SwComponentPrototypes of type
AtomicSwComponentType in the RootSwCompositionPrototype dThe System
with category ECU_EXTRACT only contains SwComponentPrototypes of type
AtomicSwComponentType in the RootSwCompositionPrototype which are ef-
fectively mapped onto the EcuInstance in focus.c()
The transformation from hierarchical to flat Software Component structure includes
a number of steps, to be performed per ECU. The list below outlining this process
assumes that the extraction is done for the first time; if an System with category
ECU_EXTRACT already exists from a previous development cycle, the extract shall
merely be updated instead of created; for more details on iterative development see
section 14.5.
• Create the one CompositionSwComponentType which will represent the
ECU’s SW subsystem (in further steps referred to as ECU flat view)
• To this ECU flat view, add a SwComponentPrototype for each instance of any
AtomicSwComponentType mapped onto the EcuInstance. Copy all the iden-
tifiable information from the originating SwComponentPrototype, but assign an
unique short name to the new element. The newly created SwComponentPro-
totypes are typed by the original AtomicSwComponentType.
• Unroll the connector paths leading to and from the included components:
– For ECU internal communication, use AssemblySwConnector to connect
PortPrototypes.
– For ECU external communication, add delegated PortPrototypes to the
ECU flat view CompositionSwComponentType. The delegated PPort-
Prototypes shall be typed with the PortInterface of the correspond-
ing PPortPrototype of the included SwComponentPrototypes that are
used for the external communication. If the original AssemblySwConnec-
tor references a PortInterfaceMapping then the delegated RPort-
Prototypes shall be typed with the PortInterface of the PPortPro-
totype initially connected (possibly by a chain of multiple original Dele-
gationSwConnectors and the one original AssemblySwConnector ref-
erencing the PortInterfaceMapping) to this PPortPrototype of the

790 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

included SwComponentPrototypes that are used for the external commu-

nication. Each delegated PortPrototype shall be connected via a Del-
egationSwConnector with PortPrototypes of the included SwCompo-
nentPrototypes that are used for the external communication.
– VariableDataPrototypes and ClientServerOperations of the del-
egated PortPrototypes are mapped to SystemSignals.
• If the System with category SYSTEM_DESCRIPTION prescribes an Imple-
mentation for a SwComponentPrototype by using SwcToImplMapping, a
corresponding constraint needs to be created in the System with category
ECU_EXTRACT of the targeted EcuInstance. The SwcToImplMapping’s com-
ponent reference needs to be adjusted to the flat representation, while maintain-
ing the original reference to the Implementation.
• Only ComSpecs on the PortPrototypes of atomic software components are
relevant for the RTE generator (see [TPS_SWCT_01568]). The existence of
ComSpecs on composition level can be taken into account for setting the val-
ues on the atomic level as the atomic level gets created. On the other hand there
is no obligation to respect the ComSpec settings on the composition level for the
creation of the atomic level. Finally the approach for the creation of ComSpec
values on atomic level depends on OEM preferences.
Figure 14.1 illustrates the process of flattening the hierarchical Software Composition
into an ECU Flat View representation, as outlined in the previous paragraphs. The
following sections explain the concrete transformation steps in more detail.
SoftwareComposition

System
Configuration
Description

ECU Flat View

ECU
Extract

Port used only in ECU internal communication SWC mapped to ECU A

Port used in ECU external communication SWC mapped to ECU B

Figure 14.1: Flattening of a hierarchic Software Composition into an ECU Flat View, and
the distinction between ports used in internal and those used in external communica-
tion.

791 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Please note that instantiation specific scheduling of runnables shall be maintained

when generating a System with category ECU_EXTRACT. This maintenance cov-
ers the rewrite of the instanceRef to the RTEEvent respectively the aggregation of the
instantiationRTEEventProps to the next CompositionSwComponentType.

14.2.1 ECU Flat view

The first step of extracting the ECU specific Software View is the creation of a new
CompositionSwComponentType (further referred to as ECU flat view). This new
element serves as a container for collecting all SwComponentPrototypes of type
AtomicSwComponentType deployed on the EcuInstance. In order to include the
ECU flat view into the actual System with category ECU_EXTRACT, the System shall
have its child class RootSwCompositionPrototype pointing to this ECU flat view.
Next, all SwcToEcuMappings present in the System with category SYS-
TEM_DESCRIPTION need to be analyzed according to the precedence rules (Section
5.1.1) in order to establish the exact set of AtomicSwComponentType instances to
be included on this EcuInstance.
For each of these component instances, regardless of their order of depth in the Sys-
tem Configuration Description’s Component hierarchy, exactly one SwComponent-
Prototype shall be created in the ECU flat view CompositionSwComponentType.
The new element’s description and type information shall be taken over from the
original SwComponentPrototype as present in the System with category SYS-
TEM_DESCRIPTION. As an important exception to this rule, the SwComponentPro-
totype’s shortName shall be unique in the name space formed by the ECU flat view.
The special case of prototypes of ParameterSwComponentTypes and Service-
ProxySwComponentTypes is treated in almost the same way. The only difference is
that these component types can be instantiated at most once per EcuInstance and
that for a given prototype in the System, instances on several EcuInstances can
be created. The replication of ParameterSwComponentTypes and ServiceProx-
ySwComponentTypes on several EcuInstances does not require any special treat-
ment of their communication properties. For ParameterSwComponentTypes there
are SwConnectors defined but no communication is involved. For more details see
[TPS_SWCT_01422] in the SwComponentTemplate [5].

14.2.2 Internal Communication

When flattening the RootSwCompositionPrototype for the System with cate-

gory ECU_EXTRACT, not only all of the ECU’s Software Components are to be col-
lected in the ECU flat view, but also any connection existing between PortProto-
types of the included SwComponentPrototypes needs to be projected onto the
same RootSwCompositionPrototype.

792 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

In the hierarchical RootSwCompositionPrototype, communication between Soft-

ware Components is specified by a combination of AssemblySwConnectors and
DelegationSwConnectors. Several DelegationSwConnectors may be com-
bined in case of a multiple-level delegation, however there will always be exactly
one AssemblySwConnector on the outermost CompositionSwComponentType
the port is delegated to.
In the ECU flat view, any such number of stringed together SwConnectors effec-
tively connecting two PortPrototypes of SwComponentPrototypes mapped to
the same EcuInstance are resolved to exactly one AssemblySwConnector per
connected port pair. As there are no additional levels of “inner SwComponentProto-
types”. DelegationSwConnectors are only used to display the outside communi-
cation of an ECU in the ECU flat view.
[constr_3019] In the flat ECU extract each required interface shall be satis-
fied by connected provided interfaces dIn case of the flat System with category
ECU_EXTRACT all VariableDataPrototypes specified by the SenderReceiver-
Interface of the RPortPrototype need to be supplied by some of the PPortPro-
totypes being connected with SwConnectors.c()
For the System with category SYSTEM_DESCRIPTION, the Software Component
Template Specification [5] allows a CompositionSwComponentType’s outer Port-
Prototype to be connected to more than one inner port, observing a set of compatibil-
ity rules between the outer and the inner port’s SenderReceiverInterfaces. Such
a “merge” and “split” functionality for mixing VariableDataPrototypes is used to
limit the number of SwConnectors required to connect PortPrototypes on higher
VFB levels and thus reduce complexity in the wiring of such higher-level Composi-
tionSwComponentTypes. On the other hand this means that an AssemblySwCon-
nector in a hierarchical VFB may expand to more than one Port-Port pair. Naturally,
in the ECU flat view such “hidden” additional connections need to be made explicit by
unrolling them into concrete AssemblySwConnectors.
Additionally PassThroughSwConnector may be used to map PortInterface ele-
ments between require and provide outer ports of CompositionSwComponentTypes
in order to use RTE features for mapping or conversion instead of real software com-
ponents. The following paragraph suggests a way how such an unrolling of SwCon-
nectors may be accomplished.
Starting with the top-level RootSwCompositionPrototype indicating the outer-
most CompositionSwComponentType, the hierarchical software model of SwCom-
ponentPrototypes is recursively iterated; for each prototype of Composition-
SwComponentType, all its AssemblySwConnectors are being iterated. For each
such found AssemblySwConnector both connector ends are evaluated for Delega-
tionSwConnectors further delegating the connection: In order to consider the use
cases of signal “merge” and “split”, all possible communication partners need to be
identified, recursively following DelegationSwConnectors in both directions. For
each identified pair of PPortPrototypes and RPortPrototypes actually exchang-
ing Information one AssemblySwConnector will be created in the ECU flat view.

793 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

In case that a string of SwConnectors started by AssemblySwConnector connects

- directly or via DelegationSwConnectors - to a PassThroughSwConnector the
SwConnector string is conjunct with the SwConnector string of the other end of
the PassThroughSwConnector. Please note that the “merge” and “split” capability
of DelegationSwConnectors and PassThroughSwConnectors requires an indi-
vidual treatment of the single PortInterface elements for the evaluation of the
SwConnector string.
The following rules shall be followed when PortInterfaceMappings are converted
for the flat view. PortInterfaceMappings supports the connection of Ports typed
by two different PortInterfaces with unequal named PortInterface elements.
More details can be found in [5].
• When unrolling a string of SwConnectors into a single SwConnectors all com-
patibility rules and PortInterfaceMappings of the individual SwConnector
need to be considered for determining which VariableDataPrototypes are
being transferred between provider and requester. If VariableDataProto-
types are to be filtered out a PortInterfaceMapping shall be provided to the
flatten connector such that only the transferred VariableDataPrototypes are
included in the mapping.
• When unrolling a string of SwConnectors into a single SwConnector all of the
PortInterfaceMappings of the individual SwConnectors need to be consid-
ered for combining them into a single PortInterfaceMapping to be associ-
ated with a new SwConnector.

14.2.3 External Communication

In a System with category SYSTEM_DESCRIPTION , whenever two SwComponent-

Prototypes are specified to communicate across EcuInstances, the details of this
communication need to be fully specified: VariableDataPrototypes of Sender-
ReceiverInterfaces and ClientServerOperations of ClientServerIn-
terfaces are mapped onto SystemSignals as carriers of information transported
across the network. According to 5.2, each instance of a AutosarDataPrototype
that is to be sent over AUTOSAR COM shall be mapped exactly once onto its individual
SystemSignal, regardless of how many components receive the information or over
how many PhysicalChannels the SystemSignal is transported.
As described above, deriving the System with category ECU_EXTRACT from
System with category SYSTEM_DESCRIPTION or from System with category
SYSTEM_EXTRACT means that all SwComponentPrototypes to be included in the
Ecu extract are recreated in an ECU flat view. Consequently, each DataMapping
concerning a SwComponentPrototype to be mapped onto the EcuInstance re-
quires that a corresponding DataMapping be created in the System with category
ECU_EXTRACT.

794 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

The ECU flat view contains delegated PortPrototypes to display the outside com-
munication of an EcuInstance. VariableDataPrototypes and ClientServer-
Operations of these delegated PortPrototypes are mapped to SystemSignals.
The original instance references indicating the mapped AutosarDataPrototype
need to be adjusted to the new “flat” location in the ECU flat view.
While for the System with category SYSTEM_DESCRIPTION it is sufficient to
describe DataMappings only on the provider side, the System with category
ECU_EXTRACT additionally requires such DataMappings on the requiring side’s ports.
In this case, a new DataMapping maps to the existing SystemSignal, previously
defined in the System with category SYSTEM_DESCRIPTION on the provider side.
This is explained in more detail in figure 14.6, that is a continuation of the example from
figure 13.3 in chapter 13.2.
To derive an ECU_EXTRACT from a System with category SYSTEM_DESCRIPTION
or SYSTEM_EXTRACT unambiguous ClientServerToSignalMappings are re-
quired for inter-ECU n:1 client-server communication. In particular the communication
path from the server to each client shall be uniquely mapped.
In this context, "communication path" encompasses the set of delegation/assem-
bly connectors that connect the server (provide-port on SWC) through to the client
(require-port on SWC).
[constr_3264] Server side ClientServerToSignalMappings in case of a n:1
inter-ECU client-server communication dIf within the System with category SYS-
TEM_DESCRIPTION or SYSTEM_EXTRACT the ClientServerToSignalMappings
for inter-ECU n:1 client-server communication are placed on the provider (server) side,
then each of these ClientServerToSignalMappings shall (in the hierarchy of
SwComponentPrototypes) refer to a "unique communication path" w.r.t. the EcuIn-
stances the client SwComponentPrototypes are mapped to.c()
Note: A "unique communication path" has the property that, starting from the
ClientServerOperation of a PortPrototype, a sequence of Delegation-
SwConnectors and AssemblySwConnectors leads to the client side and termi-
nates at either at most one PortPrototype that is owned by the AtomicSwCompo-
nentType of the client’s SwComponentPrototype or, if the path terminates at more
than one PortPrototype, then the following shall hold: The clients’ SwComponent-
Prototypes typed by AtomicSwComponentTypes owning these PortPrototypes
shall be mapped to the same EcuInstance and the client identifier is used to distin-
guish the different clients (see [TPS_SYST_01087]).
The following example scenarios will show at which PortPrototypes the
ClientServerToSignalMappings are allowed to be specified in a System with
category SYSTEM_DESCRIPTION or SYSTEM_EXTRACT to derive an ECU_EXTRACT.

795 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11
ClientServer Communication

RootTopLevelComposition
ClientComposition
ServerComposition
P1 R1 R Client1

Server P
ClientComposition

P2 R2 R Client 2

SW Component mapped to ECU A

SW Component mapped to ECU B
SW Component mapped to ECU C

Figure 14.2: Client Server Scenario 1

- AUTOSAR Confidential -
10 05.02.2008 ECU Extract - Specification Improvement

For the scenario described in figure 14.2 the following statements apply:
• ClientServerToSignalMappings for the provide-port Server.P are ambigu-
ous and thus [constr_3243] exists to forbid this situation.
• ClientServerToSignalMappings are permitted for ClientComposi-
tion.R1/ClientComponsition.R2 and Client1.R/Client2.R (client-side) or for
ServerComposition.P1/ServerComposition.P2 (provider-side) since there is no
ClientServer Communication
ambiguity.

RootTopLevelComposition
ClientComposition
ServerComposition
P1 R1 R Client 1

Server P

P2 R2 R Client 2

SW Component mapped to ECU A

SW Component mapped to ECU B

Figure 14.3: Client Server Scenario 2

For the scenario described in figure -14.3 the

AUTOSAR following
Confidential - statements apply:
11 05.02.2008 ECU Extract - Specification Improvement

796 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• ClientServerToSignalMappings for the provide-port Server.P are not am-

biguous (since although there is fork in the communication path, both sub-paths
end up at the same ECU).
• ClientServerToSignalMappings are permitted for ClientComposi-
tion.R1/ClientComponsition.R2 and Client1.R/Client2.R (client-side) or for
ServerComposition.P1/ServerComposition.P2 (provider-side) since there is no
ambiguity.
ClientServer Communication

RootTopLevelComposition
ClientComposition
ServerComposition
R1 R Client1

Server P P1
ClientComposition

R2 R Client 2

SW Component mapped to ECU A

SW Component mapped to ECU B
SW Component mapped to ECU C

Figure 14.4: Client Server Scenario 3

- AUTOSAR Confidential -
For
12 the scenario
05.02.2008 described in figureECU14.4 the following
Extract - Specification Improvement statements apply:
• ClientServerToSignalMappings for the provide-ports Server.P and Server-
Composition.P1 are ambiguous and thus [constr_3243] exists to forbid this situa-
tion.
• ClientServerToSignalMappings are permitted for ClientComposi-
tion.R1/ClientComposition.R2 and Client1.R/Client2.R (client-side) since there is
no ambiguity.

797 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11
ClientServer Communication

RootTopLevelComposition
ClientComposition
ServerComposition
R1 R Client 1

Server P P1

R2 R Client 2

SW Component mapped to ECU A

SW Component mapped to ECU B

Figure 14.5: Client Server Scenario 4

For the scenario described in figure 14.5 the following statements apply:
- AUTOSAR Confidential -
13
• ClientServerToSignalMappings
05.02.2008
for the provide-ports Server.P and Server-
ECU Extract - Specification Improvement

Composition.P1 are not ambiguous (since although there is fork in the communi-
cation path, both sub-paths end up at the same ECU).
• ClientServerToSignalMappings are permitted for ClientComposi-
tion.R1/ClientComponsition.R2 and Client1.R/Client2.R (client-side) or for
ServerComposition.P1/ServerComposition.P2 (provider-side) since there is no
ambiguity.
[TPS_SYST_01145] PortInterfaceMappings in the ECU Extract dIn the System
with category ECU_EXTRACT the missing PortInterfaceMappings on the com-
plementary side needs to be supplemented to DelegationSwConnectors.c()
Figure 14.6 shows how the System with category ECU_EXTRACT for ECU A of the
SW composition that is defined in figure 13.3 would look like: Only those SwCompo-
nentPrototypes are included that are mapped to ECU A. The hierarchy present in
the System with category SYSTEM_DESCRIPTION has been flattened into Compo-
sitionSwComponentType ‘EcuAFlatView’, including newly created SwComponent-
Prototype ‘A1E’, ‘A2E’, ‘B1E’ and ‘C1E’ for the component instances mapped to ECU
A.

798 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

EcuAFlatView Mapped to
R SW-C P PDU_X,
B1E SignalX2
SW-C
R Mapped to
A2E
PDU_Z, P
SW-C SignalZ1
P Mapped to Mapped to
A1E
PDU_X, PDU_Y, SW-C
R
SignalX1 SignalY1 C1E

P R

Figure 14.6: Example ECU extract for ECU A of above introduced composition

The SwConnectors to the outside ports (ECUFlatView composition ports) and

SwConnectors that represent intra-ECU communication (in our example, only ‘A1E’
to ‘A2E’) are included. The VariableDataPrototypes and ClientServerOper-
ations in the outside ports are mapped to SystemSignals. This DataMapping and
the communication description is used to identify the source/destination of that data.
Furthermore, the relevant topology information and communication matrix have to be
included, but they are out of scope of this example.
The problem that new mapping rules have to be added arises with the mapping to
‘PDU_Y’, ‘SignalY1’: Since SW component ‘A3’, which was referenced in the original
mapping, is no longer included, the DataMapping needs a new VariableDataPro-
totype in a PortPrototype to reference to. In the example, the data of the required
port of ‘B1E’ is referenced, so that the ECU generator has the information that ‘B1E’
receives the data via ‘PDU_Y’.

14.2.4 Port Groups

A SwComponentType can optionally define PortGroups which allow to group Port-

Prototypes according to logical criteria, e.g. according to shared communication
resources (see [5]). A PortGroup of a CompositionSwComponentType can be
linked to "inner" PortGroups of the aggregated SwComponentPrototypes. Since
the main purpose of this grouping is to configure the behavior of mode managers on
an EcuInstance, this information shall be preserved and broken down into the Sys-
tem with category ECU_EXTRACT.
The resulting CompositionSwComponentType in the ECU flat view will contain a set
of PortGroups which refer to the linked inner port groups of the SwComponentPro-
totypes with AtomicSwComponentType. To get to this result, the following steps
shall be applied in the extraction process:
• Recursively ignore all PortGroups in CompositionSwComponentTypes in the
hierarchical structure, which are not linked to any inner groups to be mapped on
this EcuInstance.

799 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• In the remaining structure of linked PortGroups find out the top level Port-
Groups (i.e. which are not referred by any higher level PortGroup on this
EcuInstance) and put an element representing each top level PortGroup into
the CompositionSwComponentType of the ECU flat view. This can result in
name conflicts, which should be resolved by a suitable algorithm.
• Link these top level PortGroups to the inner PortGroups of the atomic com-
ponent instances of the flat view according to the links found in the hierarchical
structure. Naturally, the top level PortGroups in the ECU flat view are not di-
rectly referring any PortPrototypes and due to the first step they should be
linked to at least one inner PortGroup.
• The PortGroups in SwComponentPrototypes with an AtomicSwCompo-
nentType on the EcuInstance should be unchanged.

14.2.5 Service Needs

Each software component might need services which are provided by the ECU Basic
Software through AUTOSAR Services. ServiceNeeds are used to provide detailed
information what the software component expects from the AUTOSAR Services when
integrated on an actual ECU (see SWComponentTemplate [5] for more details). If an
ECU Extract is created the following rules apply to the existing ServiceNeeds:
[constr_3068] DoIpPowerModeStatusNeeds in the category ECU_EXTRACT dIf
and only if DoIP (i.e. any of the subclasses of DoIpServiceNeeds are present) is
used on an Ecu then the DoIpPowerModeStatusNeeds shall exist exactly once in a
System of category ECU_EXTRACT.c()
[constr_1265] DoIpGidSynchronizationNeeds can only exist once per
ECU_EXTRACT dWithin the context of one System of category ECU_EXTRACT, there
can only be at most one DoIpGidSynchronizationNeeds.c()
[constr_1266] DoIpGidNeeds can only exist once per ECU_EXTRACT dWithin the
context of one System of category ECU_EXTRACT, there can only be at most one
DoIpGidNeeds.c()
[constr_1267] DoIpActivationLineNeeds can only exist once per
ECU_EXTRACT dWithin the context of one System of category ECU_EXTRACT,
there can only be at most one DoIpActivationLineNeeds.c()
[constr_3083] Exactly one AtomicSwComponentType on an EcuInstance
may use GeneralCallbackEventDataChanged / GeneralCallbackEventSta-
tusChange dThe Dem only supports exactly one AtomicSwComponentType
using GeneralCallbackEventDataChanged / GeneralCallbackEventSta-
tusChange on one EcuInstance.c()
[constr_3084] Service port in the role PowerTakeOff dWithin the context of one
EcuInstance, there can only be one service port that uses the role PowerTakeOff in
the RoleBasedPortAssignment.role.c()

800 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_3085] Service port in the role CallbackDCMRequestServices dWithin the

context of one EcuInstance, there can only be one service port that uses the role
CallbackDCMRequestServices in the RoleBasedPortAssignment.role.c()

14.3 Communication
In explaining how SystemSignals are handled in the System with category
ECU_EXTRACT, Section 14.2.3 touched on the topic of inter-ECU Communication.
However, in order to enable the ECU Configuration of the COM-Stack, the relevant in-
formation of all layers of the AUTOSAR COM-Stack needs to be present in the System
with category ECU_EXTRACT, including the central Communication classes ISig-
nal, Pdu and Frame.
The above mentioned Communication elements have dependencies on each other, for
ordinary COM-communication this means:
• Frames are assembled from one or more Pdus.
• ISignalIPdus carry their information in form of ISignals.
• ISignals as interaction points between RTE and COM refer to SystemSig-
nals.
Note that the above list is not complete; TP and NM require additional elements. How-
ever, for the sake of clarity the following paragraphs describes the standard use case of
a direct Signal-based communication between two EcuInstances. Once the handling
of this case is understood, the additional model elements as NPdu, NmPdu, System-
SignalGroup etc. can be handled following the same basic principles.
For the System with category ECU_EXTRACT only the ECU-relevant subset of in-
formation present in the system-wide communication is to be considered. In order to
establish this set of information, the dependencies in the list above are being followed.

14.3.1 Frame

In a complete System with category SYSTEM_DESCRIPTION, every outside com-

munication of an EcuInstance will either be associated with an outgoing or and in-
coming Frame. The exact number and types of Frames to be received or sent by an
EcuInstance is determined by the Communication Matrix (Chapter 6).
According to the selection rules for the Topology (14.1), the System with category
ECU_EXTRACT contains all FrameTriggerings associated with Frames that are of
any interest to the EcuInstance: If a particular FrameTriggering refers to a
FramePort of type ‘out’ the associated Frame is to be sent by the EcuInstance,
if it refers to an ‘in’ port the Frame is to be received. Therefore, the following selection
rule applies:

801 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• The System with category ECU_EXTRACT shall contain all Frame elements
which are referenced by any included FrameTriggering.

14.3.2 PDU

Frames are assembled from one or more Pdus. In order to include all required Pdu
elements, the following selection criteria apply:
• The System with category ECU_EXTRACT shall contain all Pdu elements which
are referenced by any included Frame’s PduToFrameMapping.
• The System with category ECU_EXTRACT shall contain all Pdu elements which
are referenced by any included PduTriggering.
• For multiplexed Pdus, additionally all ISignalIPdus referenced by the Multi-
plexedIPdu’s static and dynamic parts need to be included.
The second criterion is e.g. required in a pure post-build configuration scenario,
where the frame-layout may not be completed at the time of System with category
ECU_EXTRACT creation.

14.3.3 ISignals and ISignalGroups

ISignalIPdus carry their information in form of ISignals or ISignalGroups. In

order to include all required ISignal and ISignalGroup elements, the following
selection criteria apply:
• The System with category ECU_EXTRACT shall contain ISignal elements
which are referenced by included ISignalIPdu’s ISignalToIPduMapping.
One exception are Pdu Gateways. Signal definitions that are not directly relevant
for Gateways in case that the Pdu is routed as a whole (Pdu Routing) shall be
omitted. See Section 14.3.5 for more details.
• The System with category ECU_EXTRACT shall contain all ISignal elements
which are referenced by any included ISignalTriggering.
• The System with category ECU_EXTRACT shall contain ISignalGroup ele-
ments which are referenced by included ISignalIPdu’s ISignalToIPduMap-
ping. One exception are Pdu Gateways. Signal Group definitions that are not
directly relevant for Gateways in case that the Pdu is routed as a whole (Pdu
Routing) shall be omitted. See Section 14.3.5 for more details.
• The System with category ECU_EXTRACT shall contain all ISignalGroup
elements which are referenced by any included ISignalTriggering.
Like in the case of the Pdu inclusion rules, the second and fourth criterion is required
in scenarios with incomplete Pdu modeling due to post-build configurability of the com-
munication matrix.

802 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

14.3.4 SystemSignal and SystemSignalGroup

Whereas the rules specified in Section 14.2.3 for the inclusion of SystemSignal com-
prise all SystemSignals that are being used by the Software Components in the ECU,
the inclusion rules above stated for ISignalIPdus and ISignals may require the in-
clusion of additional SystemSignals. Also, strictly speaking both SystemSignals
and SystemSignalGroup need to be considered. The complete inclusion rules for
SystemSignals and SystemSignalGroups are:
• The System with category ECU_EXTRACT shall contain all SystemSignals
and SystemSignalGroup elements which are referenced by any included
DataMapping.
• The System with category ECU_EXTRACT shall contain all SystemSignal
elements which are referenced by any included ISignal.
• The System with category ECU_EXTRACT shall contain all SystemSignal-
Group elements which are referenced by any included ISignalGroup.
In addition on the receiving EcuInstance the following cases exist:
• only one SystemSignal out of the transmitted SystemSignalGroup is re-
ceived: no SystemSignalGroup is required in the Ecu Extract of the receiving
EcuInstance.
• more than one but not all SystemSignals out of the transmitted SystemSig-
nalGroup are received: new SystemSignalGroup shall be created in the
System with category ECU_EXTRACT of the receiving EcuInstance contain-
ing the received SystemSignals.
• all SystemSignals out of the transmitted SystemSignalGroup are received:
the original SystemSignalGroup shall be the taken over to the System with
category ECU_EXTRACT of the receiving EcuInstance.

14.3.5 Gateways

Gateways that refer the EcuInstance shall be included in the System with cate-
gory ECU_EXTRACT. The complete inclusion rules for Gateways are:
• The System with category ECU_EXTRACT shall contain all FrameMapping
elements that are aggregated by the Gateway element.
• The System with category ECU_EXTRACT shall contain all IPduMapping ele-
ments that are aggregated by the Gateway element.
• The System with category ECU_EXTRACT shall contain all ISignalMapping
elements that are aggregated by the Gateway element.

803 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• ISignal definitions that are not directly relevant for the Gateway in case that
the Pdu containing these ISignals is routed as a whole (Pdu Routing) shall be
omitted .
• ISignalGroup definitions that are not directly relevant for the Gateways in case
that the Pdu containing these ISignalGroups is routed as a whole (Pdu Rout-
ing) shall be omitted .

14.3.6 TP configuration

The TP-configuration element TpConfig and all its associated elements shall be in-
cluded into the System with category ECU_EXTRACT if the EcuInstance has an
TpAddress configured in this TpConfig.

14.3.7 NM configuration

The Nm configuration part of the System with category ECU_EXTRACT shall include
the NmEcu that references the included EcuInstance. In addition a NmCoordinator
composed by this NmEcu shall be included. Furthermore any NmNode referenced by
the NmCoordinator shall be included. For each included NmNode the composing Nm-
Cluster shall be included. For each included NmCluster the composing NmConfig
shall be included.

14.4 Naming Issues

[TPS_SYST_05015] Naming conventions dThe definition of naming conventions may
facilitate the avoidance of name clashes to the further degree. However, these naming
conventions can only be defined on the model level and the System Template does not
define any specific naming conventions.c(RS_SYST_00053)
Please note that a detailed information about mechanisms to resolve naming conflicts
is given in [4]: [TR_METH_03005], [TR_METH_03006], [TR_METH_03007], [TR_-
METH_03008], [TR_METH_03009], [TR_METH_03010].

14.4.1 Package Structure

As detailed in the sections above, extracting information from the System with cat-
egory SYSTEM_DESCRIPTION into an System with category ECU_EXTRACT is a
non-trivial transformation: While some of the model elements are simply copied ver-
batim into the System with category ECU_EXTRACT, it is additionally necessary to
create new elements reducing parts of system-wide structures, most noticeably in flat-
tening of the hierarchical VFB view to the ECU Flat View.

804 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

All such elements being created or modified in the process of generating the System
with category ECU_EXTRACT shall reside in the same ARPackage. In order to avoid
namespace conflicts with existing elements, the package shall exclusively be used for
this purpose.
By creating derivation elements from elements originally contained in the System with
category SYSTEM_DESCRIPTION package structure, duplications of names may oc-
cur. This kind of name clashes shall be resolved by a suitable naming algorithm (see
section 14.4.3).
All Elements that are taken over from the System with category SYS-
TEM_DESCRIPTION unchanged (e.g. AtomicSwComponentType, PortInterface,
ApplicationDataType, EcuInstance, CommunicationCluster) shall remain in
their original packages.
ARElements not used in the System with category ECU_EXTRACT shall not be
copied to the ECU Extract XML file.
In more detail, ARPackages taken over from System with category SYS-
TEM_DESCRIPTION will not be altered by the ECU extraction process, except that
some ARElements will not be included in the actual XML file of the extract: AREle-
ments which exist in the System with category SYSTEM_DESCRIPTION but have
been stripped for the System with category ECU_EXTRACT are not actually deleted
from their ARPackage, but merely are skipped in the XML file forming the extract. Note
that having such a partial view on an ARPackage doesn’t break the original ARPack-
age definition because the composition of PackageableElement, responsible for
adding ARElements to ARPackage, is stereotyped splitable; this means sev-
eral XML files can contribute to an ARPackage, or in case of the ECU Extract an
AUTOSAR description file may contain only a subset of the complete ARPackage.

14.4.2 Naming of Measurement and Calibration Data

The software component descriptions provide several means to declare data proto-
types which have to be available for measurement and calibration (MCD) tools on the
EcuInstance. Together with the System with category ECU_EXTRACT it is required
to provide a list of references to the description of these data for further processing in
the scope of the EcuInstance. In addition, the MCD tools need a unique name for
each instance of such a data prototype. Since the data descriptions are part of the
nested composition structure and are contained in reusable types (components or port
interfaces), the system description itself does in general not provide unique names for
those.
This means, providing such a list with references and unique names for MCD data is
also a task of the ECU extractor tool. This list is part of the artifact ECU Flat Map,
which is further explained below.

805 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

14.4.3 Naming of Derived Elements

When performing the extract process, name clashes may occur, necessitating a nam-
ing scheme for elements derived in ECU generation: By flattening the Software Com-
position hierarchy all component instances present on the considered EcuInstance
are put in one ECU-wide software composition. Name clashes may occur for the fol-
lowing reasons:
1. SwComponentPrototypes taken from different Software Compositions are al-
lowed to have identical short names in the hierarchical structure. As all SwCom-
ponentPrototypes will be located in the same ECU Flat View, the original
name spaces separation no longer exists.
2. Multiple instances of the same CompositionSwComponentType are mapped
to an EcuInstance: In this case, duplicates of all contained SwComponent-
Prototypes will be placed next to each other in the ECU flat composition.
3. The two mechanisms just mentioned may also lead to name clashes in Au-
tosarDataPrototypes if their names shall be used as MCD data names. In
addition, reuse of a PortInterface can also lead to name clashes if it provides
data elements to be used by MCD.
4. The setup of PortGroups in the ECU flat view can result in name clashes, be-
cause two port groups originating from different component types (i.e. different
name spaces) may be aggregated within the flat view.
Therefore the System with category ECU_EXTRACT generator shall take care that all
elements derived or created during the extraction process have unique short names.
These unique names shall be created in an initial step of the extraction process which
leads to the creation of an initial ECU Flat Map. Some ways to satisfy this requirement
may be:
• Use globally unique identifiers (GUID) for generating short names.
• Add a number to the original name; if done consistently the flat map approach
makes this reproducible.
• Expand the name recursively by the names of the containing elements (e.g. com-
positions) until is is unique.
• Allow human interaction (this may be combined with an initially proposed name
expansion).
The creation of a new short name is compulsory only if otherwise a clash would occur.
[constr_2025] Uniqueness of symbol attributes dWith the exception of RunnableEn-
tities that are subject to [constr_1234] (RunnableEntities owned by NvBlockSwCompo-
nentTypes), in the context of a single EcuInstance the values of the RunnableEn-
tity.symbol in combination with the attribute symbol of the meta-class Symbol-
Props owned by AtomicSwComponentType of all deployed RunnableEntities shall
be unique such that no two (or more) combinations of RunnableEntity.symbol and

806 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

the symbol of the meta-class SymbolProps owned by AtomicSwComponentType

in the role symbolProps share the same value.c()

14.4.4 Re-use of short names assigned in previous iterations

As described in the previous section, potential name clashes during ECU extraction
shall be avoided by assigning unique names to the elements specifically created for
the System with category ECU_EXTRACT and for the list of MCD data per EcuIn-
stance. Considering the use case of iterative development (also see Section 14.5),
the same names shall be assigned to existing elements in consecutive iterations. El-
ements which have been modified or newly introduced between two ECU extract iter-
ations shall not use an existing short name. Additionally, the ECU extractor tool shall
not re-use any short name used in any iteration from previous development phases if
the meaning of the element is not exactly the same (i.e. the element’s back reference
into the System Configuration Description is not the same.)

14.5 ECU Extract in subsequent Cycles of Iterative Development

14.5.1 Traceability of model elements created in ECU Extract

For development scenarios in real life projects iterative development shall be sup-
ported.
The following use case shall be considered:
Changes in the System with category SYSTEM_DESCRIPTION require the recre-
ation of an System with category ECU_EXTRACT. In the successive re-run of ECU
configuration, ECU configuration parameters which were configured based on the pre-
vious System with category ECU_EXTRACT need to be maintained for those parts in
the System with category ECU_EXTRACT that didn’t change between iterations.
Consequently, there are two requirements on the extraction process:
• Elements that are present in both versions of the System with category SYS-
TEM_DESCRIPTION shall not change their short names between the two ECU
Extracts either.
• If changes between the two versions of the System with category SYS-
TEM_DESCRIPTION lead to the creation of new model elements in the System
with category ECU_EXTRACT, then these newly created elements shall have
new names that have not been used in previous iterations of the System with
category ECU_EXTRACT. (See also Section 14.4.4).
In order to fulfill these requirements, a back-tracing of the relevant model elements
in the System with category ECU_EXTRACT to their counterparts in the System
with category SYSTEM_DESCRIPTION shall be established. Based on these back

807 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

references, short names shall consistently be re-used in iterations. Relevant elements

are all those which potentially have been modified in the extraction process.
All back-tracing references are collected in one central table per System with cate-
gory ECU_EXTRACT based on the meta-class FlatMap. This table collects “instance”
entries for each Ecu Extract element that is being created in the System with cat-
egory ECU_EXTRACT transformation and for each MCD data object that has to be
available in the EcuInstance. These entries are called FlatInstanceDescrip-
tor.
Each mapping entry owns two references per mapped element, one reference pointing
to the target element in the System with category ECU_EXTRACT, the other one
pointing to the origin in the System with category SYSTEM_DESCRIPTION. Both of
these references are deep “instance" references, requiring a tuple of context/target
description.
ARElement AtpPrototype
AtpBlueprint +flatMap Identifiable
AtpBlueprintable
0..1 «atpSplitable» RootSwCompositionPrototype
FlatMap

«atpVariation,atpSplitable»

+instance 1..*

Identifiable Identifiable
FlatInstanceDescriptor AtpFeature
+upstreamReference
+ role: Identifier [0..1]
«instanceRef» 0..1

+ecuExtractReference

«instanceRef» 0..1

+associatedCrossSwClusterComRtePlugin +subContainer 0..*

EcucIndexableValue
«atpVariation,atpSplitable
RtePluginProps
0..1 Identifiable
+rtePluginProps
+associatedRtePlugin EcucContainerValue
«atpSplitable» 0..1
0..1

+swDataDefProps 0..1

«atpVariation»
SwDataDefProps

+ additionalNativeTypeQualifier: NativeDeclarationString [0..1]

+ displayFormat: DisplayFormatString [0..1]
+ displayPresentation: DisplayPresentationEnum [0..1]
+ stepSize: Float [0..1]
+ swAlignment: AlignmentType [0..1]
+ swCalibrationAccess: SwCalibrationAccessEnum [0..1]
+ swImplPolicy: SwImplPolicyEnum [0..1]
+ swIntendedResolution: Numerical [0..1]
+ swInterpolationMethod: Identifier [0..1]
+ swIsVirtual: Boolean [0..1]
«atpVariation»
+ swValueBlockSize: Numerical [0..1]
+ swValueBlockSizeMult: Numerical [0..*] {ordered}

Figure 14.7: Flat Map (CommonStrucure: FlatMap)

808 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Class FlatMap
Package M2::AUTOSARTemplates::CommonStructure::FlatMap
Note Contains a flat list of references to software objects. This list is used to identify instances and to resolve
name conflicts. The scope is given by the RootSwCompositionPrototype for which it is used, i.e. it can be
applied to a system, system extract or ECU-extract.
An instance of FlatMap may also be used in a preliminary context, e.g. in the scope of a software
component before integration into a system. In this case it is not referred by a RootSwComposition
Prototype.
Tags:atp.recommendedPackage=FlatMaps
Base ARElement, ARObject, AtpBlueprint, AtpBlueprintable, CollectableElement, Identifiable, Multilanguage
Referrable, PackageableElement, Referrable
Attribute Type Mult. Kind Note
instance FlatInstanceDescriptor 1..* aggr A descriptor instance aggregated in the flat map.
The variation point accounts for the fact, that the system
in scope can be subject to variability, and thus the
existence of some instances is variable.
The aggregation has been made splitable because the
content might be contributed by different stakeholders at
different times in the workflow. Plus, the overall size might
be so big that eventually it becomes more manageable if
it is distributed over several files.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=instance.shortName, instance.variation
Point.shortLabel
vh.latestBindingTime=postBuild

Table 14.1: FlatMap

Class FlatInstanceDescriptor
Package M2::AUTOSARTemplates::CommonStructure::FlatMap
Note Represents exactly one node (e.g. a component instance or data element) of the instance tree of a
software system. The purpose of this element is to map the various nested representations of this
instance to a flat representation and assign a unique name (shortName) to it.
Use cases:
• Specify unique names of measurable data to be used by MCD tools
• Specify unique names of calibration data to be used by MCD tool
• Specify a unique name for an instance of a component prototype in the ECU extract of the
system description
Note that in addition it is possible to assign alias names via AliasNameAssignment.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mult. Kind Note
5

809 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class FlatInstanceDescriptor
ecuExtract AtpFeature 0..1 iref Refers to the instance in the ECU extract. This is valid
Reference only, if the FlatMap is used in the context of an ECU
extract.
The reference shall be such that it uniquely defines the
object instance. For example, if a data prototype is
declared as a role within an SwcInternalBehavior, it is not
enough to state the SwcInternalBehavior as context and
the aggregated data prototype as target. In addition, the
reference shall also include the complete path identifying
instance of the component prototype and the Atomic
SoftwareComponentType, which is refered by the
particular SwcInternalBehavior.
Tags:xml.sequenceOffset=40
InstanceRef implemented by:AnyInstanceRef
role Identifier 0..1 attr The role denotes the particular role of the downstream
memory location described by this FlatInstanceDescriptor.
It applies to use case where one upstream object results
in multiple downstream objects, e.g. ModeDeclaration
GroupPrototypes which are measurable. In this case the
RTE will provide locations for current mode, previous
mode and next mode.
rtePluginProps RtePluginProps 0..1 aggr The properties of a communication graph with respect to
the utilization of RTE Implementation Plug-in.
Stereotypes: atpSplitable
Tags:atp.Splitkey=rtePluginProps
swDataDef SwDataDefProps 0..1 aggr The properties of this FlatInstanceDescriptor.
Props
upstream AtpFeature 0..1 iref Refers to the instance in the context of an "upstream"
Reference descriptions, wich could be the system or system extract
description, the basic software module description or (if a
flat map is used in preliminary context) a description of an
atomic component or composition. This reference is
optional in case the flat map is used in ECU context.
The reference shall be such that it uniquely defines the
object instance in the given context. For example, if a
data prototype is declared as a role within an SwcInternal
Behavior, it is not enough to state the SwcInternal
Behavior as context and the aggregated data prototype
as target. In addition, the reference shall also include the
complete path identifying the instance of the component
prototype that contains the particular instance of Swc
InternalBehavior.
Tags:xml.sequenceOffset=20
InstanceRef implemented by:AnyInstanceRef

Table 14.2: FlatInstanceDescriptor

[TPS_SYST_01000] FlatInstanceDescriptor roles dIf a ModeDeclara-

tionGroupPrototype is measurable the FlatMap shall contain three entries where
the particular roles are set to
• CURRENT_MODE specifies the FlatInstanceDescriptor applicable for
current mode value of the ModeDeclarationGroupPrototype
• PREVIOUS_MODE specifies the FlatInstanceDescriptor applicable for
previous mode value of the ModeDeclarationGroupPrototype

810 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• NEXT_MODE specifies the FlatInstanceDescriptor applicable for next

mode value of the ModeDeclarationGroupPrototype
Please note that these entries may exist in a FlatMap even if the ModeDeclara-
tionGroupPrototype is not measurable.c(RS_SYST_00003, RS_SYST_00027)
ARElement ARElement
AtpBlueprint AtpBlueprint
AtpBlueprintable
AtpBlueprintable
AliasNameSet FlatMap

«atpVariation,atpSplitable»
«atpVariation,atpSplitable»
+aliasName 1..*

AliasNameAssignment +instance 1..*

+flatInstance
«atpIdentityContributor» FlatInstanceDescriptor
+ shortLabel: String 0..1
+ role: Identifier [0..1]

MultilanguageReferrable
+identifiable Identifiable
0..1 + category: CategoryString [0..1]
+ uuid: String [0..1]

+label 0..1

MultilanguageLongName

Figure 14.8: Alias Name Assignment (CommonStrucure: AliasNameAssignment)

Class AliasNameSet
Package M2::AUTOSARTemplates::CommonStructure::FlatMap
Note This meta-class represents a set of AliasNames. The AliasNameSet can for example be an input to the
A2L-Generator.
Tags:atp.recommendedPackage=AliasNameSets
Base ARElement, ARObject, AtpBlueprint, AtpBlueprintable, CollectableElement, Identifiable, Multilanguage
Referrable, PackageableElement, Referrable
Attribute Type Mult. Kind Note
aliasName AliasNameAssignment 1..* aggr AliasNames contained in the AliasNameSet.
Stereotypes: atpSplitable; atpVariation
Tags:
atp.Splitkey=aliasName.shortLabel, aliasName.variation
Point.shortLabel
vh.latestBindingTime=preCompileTime

Table 14.3: AliasNameSet

Class AliasNameAssignment
Package M2::AUTOSARTemplates::CommonStructure::FlatMap
5

811 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class AliasNameAssignment
Note This meta-class represents the ability to associate an alternative name to a flat representations or an
Identifiable.
The usage of this name is defined outside of AUTOSAR. For example this name can be used by MCD
tools or as a name for component instances in the ECU extract.
Note that flatInstance and identifiable are mutually exclusive.
Base ARObject
Attribute Type Mult. Kind Note
flatInstance FlatInstanceDescriptor 0..1 ref Assignment of a unique name to a flat representation.
Tags:xml.sequenceOffset=60
identifiable Identifiable 0..1 ref Assignment of a unique name to an Identifiable.
Tags:xml.sequenceOffset=50
label MultilanguageLong 0..1 aggr This represents an "Alias LongName".
Name
Tags:xml.sequenceOffset=20
shortLabel String 1 attr This attribute represents the alias name. It is modeled as
string because the alias name is used outside of
AUTOSAR and therefore no naming conventions can be
applied within AUTOSAR.
Stereotypes: atpIdentityContributor
Tags:xml.sequenceOffset=10

Table 14.4: AliasNameAssignment

During the ECU extraction process, the ECU FlatMap will be processed in the follow-
ing steps:
1. Create the entries shortName and upstreamReference of the FlatMap or, if
a previous version exists, try to reuse them. Resolve name conflicts.
2. Generate the ECU Software Composition.
3. Create the entries ecuExtractReference of the ECU FlatMap.
More details are define be the AUTOSAR methodology, see [4]. The methodology
also allows to have a FlatMap for the whole system. This System FlatMap can be
created and maintained independently from the ECU extraction process, but can be
used as an input for the creation of the ECU FlatMap.
[constr_3378] Maximal one AliasNameAssignment allowed per FlatIn-
stanceDescriptor dIn a given instance of AliasNameSet in the bound system
there shall be at most one aliasName per FlatInstanceDescriptor.c()

14.5.2 Mapping of AUTOSAR attributes to ASAM ASAP2

With the MC Support information AUTOSAR builds a bridge to tools processing ASAM
ASAP2 files. In order to support the interoperability of converter tools the following
mapping of AUTOSAR attributes to ASAM ASAP2 [21] (also known as "A2l" respec-
tively "ASAM MCD 2MC") is recommended:
• If the FlatInstanceDescriptor references DataPrototypes:

812 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

FlatInstanceDescriptor.shortName ->
MEASUREMENT Name
CHARACTERISTIC Name
FlatInstanceDescriptor.(longName + desc |upstreamReference.desc) ->
MEASUREMENT LongIdentifier
CHARACTERISTIC LongIdentifier
AliasNameAssignment.shortLabel ->
MEASUREMENT [-> DISPLAY_IDENTIFIER]
CHARACTERISTIC [-> DISPLAY_IDENTIFIER]
AliasNameAssignment.label(if provided) +
FlatInstanceDescriptor.(desc |upstreamReference.desc) ->
MEASUREMENT LongIdentifier
CHARACTERISTIC LongIdentifier
• If AliasNameAssignment references a SwSystemconstant:
AliasNameAssignment.shortLabel ->
SYSTEM_CONSTANT -> Name for SwSystemconstants
• If AliasNameAssignment references a Unit:
AliasNameAssignment.shortLabel ->
UNIT -> Name for Units

14.5.3 Assigning communication graphs to RTE Implementation Plug-Ins

When RTE Implementation Plug-Ins are used to modularize the RTE implemen-
tation, it’s required to decide which communication graphs are implemented by the RTE
or by an specific RTE Implementation Plug-In. Thereby an RTE Implementa-
tion Plug-In is a part of the overall RTE implementation which is not provided by
the RTE Generator but from an additional source (e.g. a Plug-In Generator or a manu-
ally implemented source code).

813 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

ARElement AtpPrototype
+flatMap
AtpBlueprint Identifiable
AtpBlueprintable 0..1 «atpSplitable»
RootSwCompositionPrototype
FlatMap

«atpVariation,atpSplitable»

+instance 1..*
Identifiable

FlatInstanceDescriptor

+ role: Identifier [0..1]

Identifiable
+ecuExtractReference AtpFeature

«instanceRef» 0..1 «atpVariation,atpSplitable»

+subContainer 0..*

+associatedRtePlugin EcucIndexableValue
RtePluginProps
Identifiable
+rtePluginProps 0..1 EcucContainerValue
+associatedCrossSwClusterComRtePlugin
«atpSplitable» 0..1
0..1

«invariant»
{at least one of the two references shall
be set..}

Figure 14.9: ECU Flat Map and rtePluginProps

Class RtePluginProps
Package M2::AUTOSARTemplates::CommonStructure::FlatMap
Note The properties of a communication graph with respect to the utilization of RTE Implementation Plug-in.
Base ARObject
Attribute Type Mult. Kind Note
associated EcucContainerValue 0..1 ref This associates a communication graph to a specific RTE
CrossSwCluster Implementation Plug-in handling cross Software Cluster
ComRtePlugin communication.
associatedRte EcucContainerValue 0..1 ref This associates a communication graph to a specific RTE
Plugin Implementation Plug-in handling local Software Cluster
communication or communication in a non-cluster ECU.

Table 14.5: RtePluginProps

This assignment is described with the FlatInstanceDescriptor.rtePlugin-

Props, where the RtePluginProps.associatedRtePlugin or RtePlugin-
Props.associatedCrossSwClusterComRtePlugin references the EcucCon-
tainerValue representing the identity of an RTE Implementation Plug-In.
Assigning an communication graphs has following underlying semantic:
[TPS_SYST_02197] Assigning communication graphs to RTE Implementation
Plug-Ins dThe FlatInstanceDescriptor.ecuExtractReference points to
an instance of a VariableDataPrototype and the FlatInstanceDescrip-
tor.rtePluginProps.associatedRtePlugin or RtePluginProps.associat-
edCrossSwClusterComRtePlugin references the EcucContainerValue which
defines the identity of the RTE Implementation Plug-In. This assigns the full
communication graph to the specific RTE Implementation Plug-Ins represented
by according EcucContainerValue.c(RS_SYST_00057)
For instance the FlatInstanceDescriptor.ecuExtractReference points to in-
stance of a VariableDataPrototype defined by the AnyInstanceRef using

814 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• contextElement: RootSwCompositionPrototype
• contextElement: SwComponentPrototype
• contextElement: PPortPrototype
• target: VariableDataPrototype
According the AUTOSAR Meta-Model various further model elements are exist to
describe the complete communication graph, for instance with the means of As-
semblySwConnectors, SwComponentType.ports, RunnableEntitys and Vari-
ableAccesses. Nevertheless all such related elements of this communication graph
are addressed by this single FlatInstanceDescriptor and all access of Exe-
cutableEntitys to this communication graph are handled by the associated RTE
Implementation Plug-In.
[constr_3458] FlatInstanceDescriptor.rtePluginProps shall only ref-
erence a EcucContainerValue representing a RteRipsPlugin dFlatIn-
stanceDescriptor.rtePluginProps shall only reference an EcucContainer-
Value which defines the identity of the RTE Implementation Plug-In. This
requires that the according EcucContainerValue’s definition references a
EcucContainerDef having a destinationUri set to /AUTOSAR/EcucDestina-
tionUriDefSets/RteRipsUriDefSet/RteRipsPluginc()
[constr_5175]{DRAFT} RtePluginProps shall reference at least one EcucCon-
tainerValue representing a RteRipsPlugin dIf a FlatInstanceDescriptor
owns are RtePluginProps this RtePluginProps shall define the associate-
dRtePlugin reference and/or the associatedCrossSwClusterComRtePlugin
reference.c()
To support different work-flows the FlatInstanceDescriptor.rtePluginProps
is defined as atpSplitable. Therefore it’s possible the do the assignment of
communication graphs immediately during the creation of the ECU Flat Map or in a
second processing step after the ECU Flat Map is already created.
Further information, specifications, and applicable constraints on assignments of com-
munication graphs are provided in the document SWS RTE [37] at which specific an-
chor points of an communication graphs the assignment shall be described.
Some further notes about the chosen modeling pattern
In general it is an unusual pattern, that a meta class not being related to ECU configu-
ration references an EcucContainerValue. But the FlatInstanceDescriptor
of the ECU Extract is in any case closely related to the configuration of the ECU.
Furthermore in case of data conversion it’s mandatory to provide for each different
representation a FlatInstanceDescriptor for the communication graph. Further
information about such configurations is provided in the document SWS RTE [37].
The alternative approach to describe the RTE Implementation Plug-In as meta
class is not the right approach since only very few properties of RTE Implementa-
tion Plug-Ins are standardized. There is also no need to exchange information

815 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

between different development parties about those properties. Due to this reason RTE
Implementation Plug-Ins are described by the means of ECU Configuration ele-
ments.
The alternative approach to model the relationship between FlatIn-
stanceDescriptors and the container which represents the RTE Implemen-
tation Plug-In with a mapping pattern was rejected due to the very high number
of expected configuration elements.

14.6 Variant Handling in ECU Extract

The System Template supports the creation of variants in many of its model elements.
Depending on the binding time, some of this variability may have been already resolved
within the System with category SYSTEM_DESCRIPTION at the time of creating the
System with category ECU_EXTRACT, and a cleanup step may have removed some
of the complexity by removing the out-configured variability.
If however binding of a concrete variation condition happens in a later stage of the
AUTOSAR methodology (e.g. during ECU Configuration or even post build), or if for
other process reasons such a cleanup step is not applicable, the variability needs to be
carried over to the System with category ECU_EXTRACT.

14.6.1 System Constants

In the AUTOSAR variant handling concept, SwSystemconst represents a variant se-

lector which needs to have its value assigned latest at binding time of any expression
which refers to it. Such a value assignment may be done literally using a fixed value,
or by specifying a formula, depending on the values of other variant selectors. The
elements to do this are collected in a SwSystemconstantValueSet, aggregating
individual value assignment expressions in the form of SwSystemconstValue.
In the System with category ECU_EXTRACT, all SwSystemconst elements are in-
cluded that influence its variable content. In detail the following rules for the inclusion
of SwSystemconst apply:
• System with category ECU_EXTRACT shall contain all SwSystemconst ele-
ments that are being referenced directly by variable elements contained in the
System with category ECU_EXTRACT.
• Additionally, whenever a SwSystemconst’s value is assigned indirectly using
an SwSystemconstValue’s ConditionByFormula expression, each SwSys-
temconstValue referred to in the assignment formula needs to be included,
too. As such assignments may be nested in multiple levels, the whole directed
acyclic graph of SwSystemconst elements influencing the System with cate-
gory ECU_EXTRACT variability need to be included.

816 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Additionally to the SwSystemconst elements also all relevant SwSystemconst-

Value assignments need to be included. As they are aggregated by SwSystemcon-
stantValueSet, the whole Value Set is included whenever one of its SwSystem-
constValue assignments is relevant for the System with category ECU_EXTRACT.
Note: Typically, the assignment of Variants (“Binding”) will be done in a Variant
Configuration work product, separate from the actual System with category
ECU_EXTRACT. In this case, the relevant information from the Variant Config-
uration also needs to be extracted and delivered in combination with the Sys-
tem with category ECU_EXTRACT. From the model point of view it doesn’t matter
whether System with category ECU_EXTRACT and Variant Configuration are
contained in the same file or in separate files.

14.6.2 Nested Whole/Part class variants

In case of flattening the hierarchical VFB view to the ECU flat view representation,
the case may appear that one conditional SwComponentPrototype is nested within
another SwComponentPrototype depending on another variance condition. As the
resulting ECU flat view only has a flat representation of SwComponentPrototypes,
such a double condition needs to be resolved to a single condition in the resulting
SwComponentPrototypes.
In this case, the variation condition formula needs to be altered such that the two (or
more) individual conditions are combined in a boolean AND function.

14.6.3 Multiple instances of calibration parameters in system scope

Use case: In complex systems the problem occurs that parameter values may depend
on the configuration of the vehicle due to functional side effects. E.g. the calibration
of a lambda sensor depends from the kind of transmission due to mechanical impacts
(e.g due to additional / different curvatures in the exhaust pipe)
The difficulty is that those dependencies are typically detected after design of the soft-
ware components and shall not change the software component design. Furthermore
this is typical use case for post build variability since the ECU SW should not change
due to environmental variability.
[TPS_SYST_02029] Multiple ParameterDataPrototype instances in an EcuEx-
tract dIt shall be possible to instruct the RTE Generator to provide various instances for
a ParameterDataPrototype in the System with category ECU_EXTRACT. There-
fore one FlatInstanceDescriptor per expected data instance has to point to the
ParameterDataPrototype as an atpTarget.c()

817 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

[constr_3114] FlatInstanceDescriptors pointing to the same Parameter-

DataPrototype shall have different postBuildVariantConditions dFlatIn-
stanceDescriptors that are pointing as an atpTarget to the same ParameterDat-
aPrototype instance shall have different postBuildVariantConditions.c()
Note: When several instances of a ParameterDataPrototype are created it shall
be ensured that at most one parameter instance is active in a post build variant.
[constr_3115] FlatInstanceDescriptors pointing to the same Parameter-
DataPrototype instance dWhen several FlatInstanceDescriptors point to the
same ParameterDataPrototype instance as an atpTarget in the context of a Pa-
rameterInterface the different FlatInstanceDescriptors shall point to the
PPortPrototype of the owning ParameterSwComponentType. In this case the
PPortPrototype typed by the ParameterInterface is part of the context of the
according AnyInstanceRef.c()
Please note that the individual FlatInstanceDescriptors are utilized to provide
unique names for the MCD tool as well as individual CalibrationParameter-
Values typically refer to the FlatInstanceDescriptors to provide instance spe-
cific initialization values.

818 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

15 Supported special use-cases

The description means of the communication matrix in the System Template potentially
support a variety of use-cases. Some combinations of description means are explicitly
ruled-out by semantical constraints. But the remaining space for the possible descrip-
tions is so huge, that certain use-cases are actually not supported by tool-vendors
because they did not consider them. This chapter describes special use-cases that
can be specified in the System Template in order to get a harmonized support by tools.

15.1 Support of sending / receiving same Can/Flexray Frame on

same channel (Pdu Gateway Use-Case)
Description: The System Template supports the definition of a communication where
the same Can/Flexray FrameTriggering is sent and received on the same
PhysicalChannel of one Pdu Gateway EcuInstance.
Rationale: This use-case occurs in gateway EcuInstances which are used in sev-
eral vehicle platforms.
Implementation: This usage shall be supported by defining one Frame and one
FrameTriggering with different directions on the referenced FramePorts for
the same PhysicalChannel. Also one Pdu and one PduTriggering with dif-
ferent directions on the referenced IPduPorts for the same PhysicalChannel
shall be used.
Example: In figure 15.1 a sample network setup is shown. The ECU1 is designed to
send the Frame_X on the PhysicalChannel. The ECU2, ECU3 and ECU4 do
receive the information. But since ECU1 is optional, ECU4 is also designed to
send the Frame_X on the network (in case ECU1 is not present). Please note
that in in this example ECU4 is a gateway EcuInstance that is connected to an
additional channel.

Figure 15.1: Example of network setup with one Frame being received and sent on the
same ECU and channel

In the system description there exists one definition for the Frame_X and one
FrameTriggering for the PhysicalChannel (figure 15.2). Each EcuIn-
stance sending or receiving the FrameTriggering does define one Frame-
Port per direction, thus for ECU4 there are two FramePorts defined.

819 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

For each Pdu mapped to the Frame there exists one definition for the Pdu_X and
one PduTriggering for the PhysicalChannel. Each EcuInstance sending
or receiving the Pdu does define one IPduPort per direction, thus for ECU4
there are two IPduPorts defined.
PduPort_ECU1_out
PduPort_ECU2_in
Pdu_X PduTriggering_X PduPort_ECU3_in
PduPort_ECU4_in
PduPort_ECU4_out
PduToFrameMapping
FramePort_ECU1_out
FramePort_ECU2_in
Frame_X FrameTriggering_X FramePort_ECU3_in
FramePort_ECU4_in
FramePort_ECU4_out

Figure 15.2: Structure to reflect the frame- and pdu-triggering setup of one Frame being
received and sent by the same Gateway ECU

In case a System Extract / ECU Extract is build, only the relevant FramePorts
and IPduPorts for the corresponding EcuInstance are extracted. Especially
in case an additional EcuInstance is designed to send and receive the same
Frame all the other ECU extracts will not be affected by this change.

15.2 Support of sending / receiving same Can/Flexray Frame on

same channel (bidirectional routing in COM)
Description: The System Template supports the definition of a communication where
the same Can/Flexray FrameTriggering is sent and received on the same
PhysicalChannel of one EcuInstance and the content of this Frame is pro-
cessed by an Application. Please note that this use case is only applicable for
legacy communication over COM and not for communication over LdCOM.
Rationale: This use-case occurs in case of runtime variation where the same data is
transmitted or received by the same ECU.
Implementation in a System Description: This use-case is supported with the fol-
lowing modelling:
• One Frame and one FrameTriggering with different directions on the
referenced FramePorts for the same PhysicalChannel shall be defined.
• One Pdu and one PduTriggering with different directions on the refer-
enced IPduPorts for the same PhysicalChannel shall be defined.

820 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

• One ISignal and one ISignalTriggering with different directions on

the referenced ISignalPorts for the same PhysicalChannel shall be
defined.
Please note that in case of a bidirectional routing on the ISignal level the COM
Configuration (ComIPdus) needs to be derived from the PduTriggering and
from IPduPorts.
Example: In figure 15.3 a sample network setup is shown. The same data (Frame_X)
is transmitted by Ecu4 and by Ecu1 (runtime variation). Ecu4 is designed to send
and to receive the Frame_X on the network. For Ecu2 and Ecu3 it is transparent
from which sender (Ecu1 or Ecu4) the data is transmitted.

Channel_J

ECU1 ECU2 ECU3 ECU4

Figure 15.3: Example of network setup with one Frame being received and sent on the
same ECU and channel

In the system description there exists one definition for the Frame_X and one
FrameTriggering for the PhysicalChannel (figure 15.4). Each EcuIn-
stance sending or receiving the FrameTriggering does define one Frame-
Port per direction, thus for ECU4 there are two FramePorts defined.
For each Pdu mapped to the Frame there exists one definition for the Pdu_X and
one PduTriggering for the PhysicalChannel. Each EcuInstance sending
or receiving the Pdu does define one IPduPort per direction, thus for ECU4
there are two IPduPorts defined.
For each ISignal mapped to the Pdu there exists one definition for the Signal_X
and one ISignalTriggering for the PhysicalChannel. Each EcuIn-
stance sending or receiving the ISignal does define one ISignalPort per
direction, thus for ECU4 there are two ISignalPorts defined.
Example 15.4 shows a System Description where only the DataMapping for the
PPorts is defined. Please note that in the COM configuration a ComIPdu has a
ComIPduDirection. Therefore two ComIPdus (Tx and Rx) need to be created
from such a System Description.

821 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

DataMapping_X* SWC_PPort on ECU1

SystemSignal_X
DataMapping_X SWC_PPort on ECU4

SignalPort_ECU1_out
SignalPort_ECU2_in
SignalPort_ECU3_in
ISignal_X ISignalTriggering_X SignalPort_ECU4_in
SignalPort_ECU4_out
ISignalToIPduMapping PduPort_ECU1_out
PduPort_ECU2_in
Pdu_X PduTriggering_X PduPort_ECU3_in
PduPort_ECU4_in
PduPort_ECU4_out
PduToFrameMapping
FramePort_ECU1_out
FramePort_ECU2_in
Frame_X FrameTriggering_X FramePort_ECU3_in
FramePort_ECU4_in
FramePort_ECU4_out

Figure 15.4: Structure to reflect the frame- and pdu-triggering setup of one Frame being
received and sent on the same ECU and channel (System Description with ECU1, ECU2,
ECU3 and ECU4)

In case a System Extract / ECU Extract is build, only the relevant FramePorts,
IPduPorts and ISignalPorts for the corresponding EcuInstance are ex-
tracted. Especially in case an additional EcuInstance is designed to send and
receive the same Frame all the other ECU extracts will not be affected by this
change. Figure 15.5 shows a System Extract where only the description for ECU4
is available. Please note that in this example the VariableDataPrototype in
the PPort and the VariableDataPrototype in the RPort of the Software Com-
ponent are mapped to the same SystemSignal.

DataMapping_X* SWC_RPort on ECU4

SystemSignal_X
DataMapping_X SWC_PPort on ECU4

SignalPort_ECU4_in
ISignal_X ISignalTriggering_X
SignalPort_ECU4_out

ISignalToIPduMapping

PduPort_ECU4_in
Pdu_X PduTriggering_X
PduPort_ECU4_out

PduToFrameMapping

FramePort_ECU4_in
Frame_X FrameTriggering_X
FramePort_ECU4_out

Figure 15.5: Structure to reflect the frame-

- AUTOSARand pdu-triggering
Confidential - setup of one Frame being
received and sent on the same ECU and channel (System Extract with ECU4 only)

822 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

15.3 Support of dynamic CAN IDs

To support efficient diagnostics with on-board clients, efficient routing, and efficient
SAE J1939 transport protocol and request handling, AUTOSAR provides access to
dynamic CAN identifier parts in upper layers of the COM stack. This is achieved
by appending parts of the identifier (or the complete identifier) as MetaData
to the Pdu payload. The usage of MetaData is an Ecu Configuration decision. A
System Description does not define whether MetaData shall be used or not.
The System Template uses the following attributes for the configuration of dynamic
CAN IDs:
• The rxMask of a CanFrameTriggering defines the relevant bits in a CAN
identifier and thus defines a range of CAN identifiers that match these
bits and may vary in the other bits.
• The txMask of a CanFrameTriggering defines the static bits in a CAN iden-
tifier and thus allows to set the other bits using the data appended to the
payload.
These parameters are sufficient to support the following scenarios:
• A Pdu is transmitted from one AUTOSAR node to another with variable ID parts.
In this case, rxMask and txMask will be identical, and the variable identifier
parts placed in the Pdu MetaData by the sender will be routed transparently and
received in the same way.
• A Pdu is transmitted by one node with a static identifier and received using
the rxMask. In this case, the MetaData is not used, and the receiver is tolerant
regarding dynamic address parts.
• J1939 Pdu is sent with fixed priority, but priority is ignored by the receiver. Here,
the MetaData may or may not be used, and the rxMask differs from the txMask
just in the three priority bits.

15.4 N:1 Sender Receiver communication description in a System

Extract over one PhysicalChannel
Description: The System Template supports a System Extract description of a
n:1 sender-receiver communication over one PhysicalChannel where each
sender and the receiver are located on different Ecus. Each sender Ecu sends
the same data marked with a different frame identifier (e.g. CAN Identifier) to the
receiver Ecu over the PhysicalChannel.
Implementation: This usage shall be supported by defining one Frame and sev-
eral FrameTriggerings on the same PhysicalChannel. Each defined
FrameTriggering refers to the same Frame. The senders and receivers of
a specific FrameTriggering are defined with references to FramePorts.

823 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

For every defined Pdu that is contained in the Frame exactly one PduTrig-
gering is defined. This also means that all defined FrameTriggerings refer
to the same PduTriggerings with the FrameTriggering.pduTriggering
reference.
The communication direction of the Pdu is defined by PduTriggering refer-
ences to IPduPorts. All sender IPduPorts and receiver IPduPorts are ref-
erenced by the same PduTriggering.
The description of ISignals and ISignalTriggerings shall be defined ac-
cordingly. Please also note that in case of n:1 sender-receiver communication
each sender shall be represented by the same SystemSignal according to
[constr_3086].
Example: In figure 15.6 a small example is shown. Three different Ecus (Ecu1, Ecu2,
Ecu3) are sending the same Frame to Ecu4.
• Ecu1 sends the Frame with CanId = 3 as described with FrameTriggering3.
• Ecu2 sends the Frame with CanId = 2 as described with FrameTriggering2.
• Ecu3 sends the Frame with CanId = 1 as described with FrameTriggering1.
The Frame contains one single Pdu. Only one PduTriggering is defined
here that refers to three IPduPorts with communicationDirection "out"
(Ecu1OutPort, Ecu2OutPort and Ecu3OutPort) and to one IPduPort with com-
municationDirection "in" (Ecu4InPort). Please note that the references
between the Triggering elements (FrameTriggering.pduTriggering and
PduTriggering.iSignalTriggering) are not visible in figure 15.6 for the
sake of clarity.
The description of the ISignal that is included in the Pdu and the ISignal-
Triggering is defined accordingly.
Upstream Mapping: In the basic Ecu configuration for the receiving Ecu that is de-
rived from such a System Extract all FrameTriggerings shall be mapped
to the same Pdu that is passed to a upper layer module (e.g. Nm, PduR).
This corresponds to the upstream mapping rules for COM Signals defined in
[TPS_SYST_01066] and [TPS_SYST_01067].
• CanIf: several CanIfRxPduCfg containers need to be created with different
CanIfRxPduCanIds that all point to the same Pdu (CanIfRxPduRef).
• FrIf: several FrIfFrameTriggering containers need to be created that all point
to the same Pdu (FrIfFrameStructure/FrIfPdusInFrame/FrIfPduRef)

824 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

:ISignalTriggering +iSignalPort Ecu1OutPort: ISignalPort

communicationDirection = out

+iSignalPort Ecu2OutPort: ISignalPort

communicationDirection = out

+iSignalPort Ecu3OutPort: ISignalPort

communicationDirection = out

+iSignalPort Ecu4InPort: ISignalPort

+iSignal communicationDirection = in
+iSignal
Signal: ISignal

:ISignalToIPduMapping

+pdu Pdu: ISignalIPdu

+iSignalToIPduMapping

+iPdu

:PduTriggering +iPduPort Ecu1OutPort: IPduPort

communicationDirection = out

«atpPrototype» +iPduPort Ecu2OutPort: IPduPort

:PduToFrameMapping communicationDirection = out

+pduToFrameMapping +iPduPort Ecu3OutPort: IPduPort

communicationDirection = out

+iPduPort Ecu4InPort: IPduPort

communicationDirection = in
:Frame

+frame +frame +frame

A 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 ([43]).
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.

828 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-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.

829 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-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.

830 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-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.

831 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

B Detailed Representation of InstanceRef

Associations in the System Template
As a special type of association "instanceRef" refers to an exact instance of the ref-
erenced class, requiring additional information of the target and the context. This is
explained in detail in the AUTOSAR Generic Structure Template [2]. This chapter con-
tains the detailed InstanceRef Diagrams.

B.1 Usage of InstanceRefs in Data Mapping diagrams

AtpStructureElement
Identifiable
ClientServerOperation

+ diagArgIntegrity: Boolean [0..1]

+clientServerOperation 1 +clientServerOperation 1
+targetOperation 1
{redefines
atpTarget} «instanceRef» «instanceRef»

DataMapping Identifiable
ClientServerToSignalMapping ClientIdDefinition

+ clientId: Numerical

1 +clientServerOperation +clientServerOperation 1

AtpInstanceRef
OperationInSystemInstanceRef

AutosarDataPrototype
VariableDataPrototype

1 +dataElement 1 +dataElement 0..1

0..1
+dataElement +targetDataPrototype {redefines
atpTarget}
«instanceRef» «instanceRef» «instanceRef»

DataMapping DataMapping DataMapping

SenderReceiverToSignalMapping SenderReceiverToSignalGroupMapping SenderReceiverCompositeElementToSignalMapping

+dataElement 1 +dataElement 1 +dataElement 0..1

AtpInstanceRef
VariableDataPrototypeInSystemInstanceRef

Figure B.1: Data Mapping Instance Ref Usage

832 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

DataMapping
TriggerToSignalMapping

+trigger 1

AtpInstanceRef
TriggerInSystemInstanceRef
«instanceRef»

1
{redefines
+trigger 1 +targetTrigger atpTarget}
AtpStructureElement
Identifiable
Trigger

+ swImplPolicy: SwImplPolicyEnum [0..1]

Figure B.2: Modeling of InstanceRef usage for TriggerInSystemInstanceRef

B.2 Usage of InstanceRefs in SW Mapping diagrams

Identifiable
SystemMapping

«atpVariation» «atpVariation,atpSplitable» «atpVariation»

+resourceEstimation * +swcToApplicationPartitionMapping 0..* +mappingConstraint *

Identifiable MappingConstraint
EcuResourceEstimation
SwcToApplicationPartitionMapping

«atpVariation»
«atpVariation»
+swCompToEcuMapping

ComponentSeparation ComponentClustering

+swImplMapping *

Identifiable
+swMapping 0..* * SwcToImplMapping

Identifiable
SwcToEcuMapping

+separatedComponent 2 +clusteredComponent 1..*

AtpInstanceRef
+swComponentPrototype
ComponentInSystemInstanceRef
0..1
+component
ARElement
1..*
J1939ControllerApplication
+swComponentPrototype

0..1
+component

1..*

Figure B.3: SW Mapping Instance Ref Usage

833 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

B.3 Usage of InstanceRefs in Signal Path Constraint diagrams

SignalPaths::SwcToSwcOperationArguments
SignalPaths::
SwcToSwcSignal + direction: SwcToSwcOperationArgumentsDirectionEnum

+dataElement 2 +operation 2
AtpInstanceRef AtpInstanceRef
InstanceRefs::VariableDataPrototypeInSystemInstanceRef InstanceRefs::
OperationInSystemInstanceRef

Figure B.4: SW Mapping Instance Ref Usage

B.4 Usage of InstanceRefs in PncMapping

Identifiable
SystemMapping

«atpVariation»

+pncMapping *
Describable
PncMapping

+ pncIdentifier: PositiveInteger
+ pncWakeupEnable: Boolean [0..1]
+ shortLabel: Identifier [0..1]

+vfc 0..*

AtpInstanceRef
PortGroupInSystemInstanceRef

Figure B.5: Partial Network Mapping Instance Ref Usage

834 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

B.5 Usage of InstanceRefs in ComManagementMapping

Identifiable
ComManagementMapping

+comManagementPortGroup 0..*

AtpInstanceRef
PortGroupInSystemInstanceRef
«instanceRef»

1
+target {redefines atpTarget} +comManagementPortGroup 0..*
+innerGroup 0..*
AtpStructureElement
Identifiable «instanceRef»
PortGroup

Figure B.6: ComManagementMapping Instance Ref Usage

835 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

B.6 "SWC in System" InstanceRef

«instanceRef»
AtpInstanceRef

ARElement
AtpStructureElement
System

+base

«atpDerived»
0..1
{redefines
atpBase}

«atpVariation,atpSplitable»
+rootSoftwareComposition 0..1
AtpPrototype
ComponentInSystemInstanceRef Identifiable
+contextComposition
RootSwCompositionPrototype
0..1
{subsets
atpContextElement}

«isOfType»

1
*
{redefines 1
{ordered,
atpTarget} {redefines
subsets
+targetComponent +contextComponent +softwareComposition
atpContextElement} atpType}
AtpPrototype
CompositionSwComponentType
SwComponentPrototype
+component

0..* «atpVariation,atpSplitable»

«isOfType»

0..1
{redefines
+type atpType}

ARElement
AtpBlueprint
AtpBlueprintable
AtpType
SwComponentType

Figure B.7: ComponentInSystem InstanceRef

Class ComponentInSystemInstanceRef
Package M2::AUTOSARTemplates::SystemTemplate::InstanceRefs
Note
Base ARObject, AtpInstanceRef
Attribute Type Mult. Kind Note
base System 0..1 ref Stereotypes: atpDerived
Tags:xml.sequenceOffset=10
context SwComponent * ref Tags:xml.sequenceOffset=30
Component Prototype
(ordered)
context RootSwComposition 0..1 ref Tags:xml.sequenceOffset=20
Composition Prototype
target SwComponent 1 ref Tags:xml.sequenceOffset=40
Component Prototype

Table B.1: ComponentInSystemInstanceRef

836 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

If the referenced SwComponentPrototype is located within the RootSwComposi-

tionPrototype of a System then the contextComposition to the RootSwCom-
positionPrototype shall be provided. In this scenario we have a System Ex-
tract where the RootSwComposition may contain other compositions. If the refer-
enced SwComponentPrototype is the RootSwCompositionPrototype itself then
contextComposition reference to the RootSwCompositionPrototype shall be
skipped and only the targetComponent to the RootSwCompositionPrototype
shall be used. In this scenario we have an Ecu Extract where the RootSwComposition
contains PortPrototypes that describe the external communication.

837 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

B.7 "Operation in System" InstanceRef

«instanceRef»

AtpInstanceRef

ARElement
+base
AtpStructureElement
«atpDerived» 0..1 System
{redefines
atpBase}

«atpVariation,atpSplitable»
+rootSoftwareComposition 0..1

AtpPrototype
OperationInSystemInstanceRef
Identifiable
1 +contextComposition RootSwCompositionPrototype
{redefines 0..1
+targetOperation atpTarget} {subsets
AtpStructureElement atpContextElement}
«isOfType»
Identifiable
1
ClientServerOperation {redefines
subsets atpContextElement} +softwareComposition
atpType}

+operation 0..* CompositionSwComponentType

+contextComponent

«atpVariation»
{ordered,
0..*

ClientServerInterface +component 0..*

«atpVariation,atpSplitable»

AtpPrototype
SwComponentPrototype «isOfType»

0..1
{redefines
atpType} +type
ARElement
AtpBlueprint
AtpBlueprintable
AtpType
SwComponentType

1
{subsets «atpVariation,atpSplitable»
atpContextElement}
+contextPort +port 0..*

AtpBlueprintable
AtpPrototype
PortPrototype

ARElement
AtpBlueprint
AtpBlueprintable
AtpType
PortInterface

Figure B.8: OperationInSystem InstanceRef

Class OperationInSystemInstanceRef
Package M2::AUTOSARTemplates::SystemTemplate::InstanceRefs
Note
Base ARObject, AtpInstanceRef
Attribute Type Mult. Kind Note
5

838 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class OperationInSystemInstanceRef
base System 0..1 ref Stereotypes: atpDerived
Tags:xml.sequenceOffset=10
context SwComponent * ref Tags:xml.sequenceOffset=30
Component Prototype
(ordered)
context RootSwComposition 0..1 ref Tags:xml.sequenceOffset=20
Composition Prototype
contextPort PortPrototype 1 ref Tags:xml.sequenceOffset=40
targetOperation ClientServerOperation 1 ref Tags:xml.sequenceOffset=50

Table B.2: OperationInSystemInstanceRef

If the referenced ClientServerOperation is part of a PortInterface of a

SwComponentPrototype that is located within the RootSwCompositionProto-
type then the contextComposition reference to the RootSwComposition-
Prototype shall be provided. In this scenario we have a System Extract
where the RootSwComposition may contain other compositions. If the refer-
enced ClientServerOperation is part of a PortInterface of the RootSwCom-
positionPrototype itself then the contextComposition reference to the
RootSwCompositionPrototype shall be skipped and the RootSwComposition-
Prototype shall be referenced as contextComponent. In this scenario we have an
Ecu Extract where the RootSwComposition contains PortPrototypes that describe
the external communication.

839 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

B.8 "VariableDataPrototype" InstanceRef

«instanceRef»
AtpInstanceRef

ARElement
AtpStructureElement
System
+base

«atpDerived»
0..1
{redefines
atpBase}

«atpVariation,atpSplitable»
+rootSoftwareComposition 0..1
VariableDataPrototypeInSystemInstanceRef AtpPrototype
+contextComposition Identifiable
RootSwCompositionPrototype
0..1
{subsets
atpContextElement}

«isOfType»
0..1
{redefines
+targetDataPrototype atpTarget} 1
{redefines
+softwareComposition
AutosarDataPrototype atpType}

VariableDataPrototype CompositionSwComponentType

+dataElement 0..*

*
{ordered, «atpVariation,atpSplitable»
subsets
+contextComponent atpContextElement} +component 0..*

AtpPrototype
SenderReceiverInterface
SwComponentPrototype

«isOfType»
1 0..1
{subsets {redefines atpType} +type
+contextPort atpContextElement} ARElement
DataInterface AtpBlueprintable AtpBlueprint
AtpPrototype +port AtpBlueprintable
PortPrototype AtpType
0..*«atpVariation,atpSplitable» SwComponentType

ARElement
AtpBlueprint
AtpBlueprintable
AtpType

PortInterface

Figure B.9: VariableDataPrototypeInSystem InstanceRef

Class VariableDataPrototypeInSystemInstanceRef
Package M2::AUTOSARTemplates::SystemTemplate::InstanceRefs
Note
Base ARObject, AtpInstanceRef
5

840 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Class VariableDataPrototypeInSystemInstanceRef
Attribute Type Mult. Kind Note
base System 0..1 ref Stereotypes: atpDerived
context SwComponent * ref
Component Prototype
(ordered)
context RootSwComposition 0..1 ref
Composition Prototype
contextPort PortPrototype 1 ref
targetData VariableDataPrototype 0..1 ref
Prototype

Table B.3: VariableDataPrototypeInSystemInstanceRef

If the referenced VariableDataPrototype is part of a PortInterface of a

SwComponentPrototype that is located within the RootSwCompositionProto-
type then the contextComposition reference to the RootSwCompositionPro-
totype shall be provided. In this scenario we have a System Extract where the
RootSwComposition may contain other compositions. If the referenced Variable-
DataPrototype is part of a PortInterface of the RootSwCompositionProto-
type itself then the contextComposition reference to the RootSwComposition-
Prototype shall be skipped and the RootSwCompositionPrototype shall be ref-
erenced as contextComponent. In this scenario we have an Ecu Extract where the
RootSwComposition contains PortPrototypes that describe the external communi-
cation.
Please note that the xml.sequenceOffset is not set for this InstanceRef and therefore
the properties are serialized in an alphabetical order.

841 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

AtpInstanceRef
TriggerInSystemInstanceRef

ARElement
+base AtpStructureElement
«atpDerived» System
0..1
{redefines
atpBase}

«atpVariation,atpSplitable»
+rootSoftwareComposition 0..1
AtpPrototype
+contextComposition Identifiable
RootSwCompositionPrototype
0..1
{subsets
atpContextElement} «isOfType»
1 1
+softwareComposition {redefines atpType}
{redefines
+targetTrigger atpTarget}
CompositionSwComponentType

atpContextElement}
AtpStructureElement
Identifiable
Trigger
0..*

{subsets
+trigger 0..* {ordered,
subsets «atpVariation,atpSplitable»

+contextComponent atpContextElement} +component 0..* +contextPort

1
AtpPrototype AtpBlueprintable
TriggerInterface
SwComponentPrototype AtpPrototype
PortPrototype

+port 0..*
0..1 «isOfType»
{redefines «atpVariation,atpSplitable»
ARElement atpType} +type
AtpBlueprint ARElement
AtpBlueprintable
AtpBlueprint
AtpType

AtpBlueprintable
PortInterface AtpType
SwComponentType

Figure B.10: TriggerInSystemInstanceRef

Class TriggerInSystemInstanceRef
Package M2::AUTOSARTemplates::SystemTemplate::InstanceRefs
Note
Base ARObject, AtpInstanceRef
Attribute Type Mult. Kind Note
base System 0..1 ref This represents that base of the InstanceRef
Stereotypes: atpDerived
Tags:xml.sequenceOffset=10
context SwComponent * ref This represents the set of context components. The
Component Prototype association is ordered because it needs to respect the
(ordered) nesting order.
Tags:xml.sequenceOffset=30
context RootSwComposition 0..1 ref This represents the reference to the RootSw
Composition Prototype Compositiontype representing a context of the Instance
Ref.
Tags:xml.sequenceOffset=20
contextPort PortPrototype 1 ref This represents the PortPrototype in which the target
Trigger is located.
Tags:xml.sequenceOffset=40
targetTrigger Trigger 1 ref This represents the target Trigger.
Tags:xml.sequenceOffset=50

Table B.4: TriggerInSystemInstanceRef

842 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

If the referenced Trigger is part of a PortInterface of a SwComponentPro-

totype that is located within the RootSwCompositionPrototype then the base
reference and the contextComposition reference to the RootSwComposition-
Prototype shall be provided. If the referenced Trigger is part of a PortInter-
face of the RootSwCompositionPrototype itself then the base reference and
the contextComposition reference to the RootSwCompositionPrototype shall
be skipped and the RootSwCompositionPrototype shall be referenced as con-
textComponent.

843 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

B.9 "PortGroup in System" InstanceRef

«instanceRef»
AtpInstanceRef ARElement
AtpStructureElement
System
+base

«atpDerived»
0..1
{redefines
atpBase}

«atpVariation,atpSplitable»
+rootSoftwareComposition 0..1
AtpPrototype
PortGroupInSystemInstanceRef Identifiable
+contextComposition
RootSwCompositionPrototype
0..1
{subsets
atpContextElement}

«isOfType»
*
{ordered,
subsets 1
+contextComponent atpContextElement} {redefines
+softwareComposition
atpType}
AtpPrototype
SwComponentPrototype +component CompositionSwComponentType

0..* «atpVariation,atpSplitable»

«isOfType»
1 0..1
{redefines {redefines
+type
+target atpTarget} atpType}
AtpStructureElement +portGroup ARElement
Identifiable 0..* AtpBlueprint
AtpBlueprintable
PortGroup «atpVariation»
AtpType
SwComponentType
+innerGroup
0..*

«instanceRef»

Figure B.11: PortGroupInSystem InstanceRef

Class PortGroupInSystemInstanceRef
Package M2::AUTOSARTemplates::SystemTemplate::InstanceRefs
Note
Base ARObject, AtpInstanceRef
Attribute Type Mult. Kind Note
base System 0..1 ref Stereotypes: atpDerived
Tags:xml.sequenceOffset=10
context SwComponent * ref Tags:xml.sequenceOffset=30
Component Prototype
(ordered)
context RootSwComposition 0..1 ref Tags:xml.sequenceOffset=20
Composition Prototype
target PortGroup 1 ref Link to a PortGroup that is defined in a component which
is part of this CompositionSwComponentType.
Tags:xml.sequenceOffset=40

Table B.5: PortGroupInSystemInstanceRef

If the referenced PortGroup is part of a SwComponentPrototype that is located

within the RootSwCompositionPrototype then the contextComposition refer-
ence to the RootSwCompositionPrototype shall be provided. In this scenario we

844 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

have a System Extract where the RootSwComposition may contain other composi-
tions. If the referenced PortGroup is part of the RootSwCompositionPrototype
itself then the contextComposition reference to the RootSwCompositionPro-
totype shall be skipped and the RootSwCompositionPrototype shall be refer-
enced as contextComponent. In this scenario we have an Ecu Extract where the
RootSwComposition contains PortPrototypes that describe the external communi-
cation.

845 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

B.10 "DataPrototype in PortInterface" InstanceRef

ARElement
AtpBlueprint
AtpBlueprintable
AtpType
PortInterface

+ isService: Boolean [0..1]

+ serviceKind: ServiceProviderEnum [0..1]

+/abstractBase 0..1
{redefines
atpBase}
«atpAbstract»

AtpInstanceRef
DataPrototypeInPortInterfaceInstanceRef

«atpAbstract»

1
{redefines
+targetDataPrototype atpTarget}
AtpPrototype
DataPrototype
«atpAbstract» «atpAbstract»

0..1 0..*
{subsets {ordered,
+rootDataPrototype atpContextElement} +contextDataPrototype subsets atpContextElement}

AutosarDataPrototype ApplicationCompositeElementDataPrototype

Figure B.12: DataPrototypeInPortInterfaceInstanceRef InstanceRef

Class DataPrototypeInPortInterfaceInstanceRef (abstract)

Package M2::AUTOSARTemplates::SystemTemplate::Transformer::InstanceRef
Note This meta-class represents the ability to:
• refer to a DataPrototype in the context of a PortInterface.
• refer to the internal structure of a DataPrototype which is typed by an ApplicationDatatype in the
context of a PortInterface.
Base ARObject, AtpInstanceRef
Subclasses DataPrototypeInClientServerInterfaceInstanceRef, DataPrototypeInSenderReceiverInterfaceInstanceRef
Attribute Type Mult. Kind Note
abstractBase PortInterface 0..1 ref Stereotypes: atpAbstract
contextData ApplicationComposite * ref Stereotypes: atpAbstract
Prototype ElementDataPrototype Tags:xml.sequenceOffset=20
(ordered)
rootData AutosarDataPrototype 0..1 ref Stereotypes: atpAbstract
Prototype Tags:xml.sequenceOffset=10
targetData DataPrototype 1 ref Stereotypes: atpAbstract
Prototype Tags:xml.sequenceOffset=30

Table B.6: DataPrototypeInPortInterfaceInstanceRef

If the referenced target DataPrototype is the root AutosarDataPrototype in a

PortInterface then only the targetDataPrototype reference shall be provided.

846 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

If the referenced DataPrototype is part of a root AutosarDataPrototype that

is part of a PortInterface then the rootDataPrototype shall be provided.
The referenced ApplicationCompositeElementDataPrototype can be arbitrar-
ily nested within a DataPrototype. In such a case additional contextDataProto-
type references shall be provided.
Please note that the specializations DataPrototypeInSenderReceiverIn-
terfaceInstanceRef and DataPrototypeInClientServerInterfaceIn-
stanceRef work in the same way.

847 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

C Harmonization between Upstream Templates and

ECU Configuration
This chapter describes the mapping of the ECU Configuration parameters (M1 model)
onto the meta-classes and attributes of the AUTOSAR upstream templates (System
Template, SW Component Template and ECU Resource Template).
The relationships between upstream templates and ECU Configuration are described
in order to answer typical questions like:
• How shall a supplier use the information in a System Description in order to fulfill
the needs defined by the systems engineer?
• How is a tool vendor supposed to generate an ECU Configuration Description out
of ECU Extract of System Description?
In addition to adhering to the mapping rules defined in this appendix an automated
generation of an ECU Configuration Description out of ECU Extract of System De-
scription should apply a certain implementation-specific name mangling when deriving
the shortName of the EcucContainerValue elements to ensure that the resulting
ECU Configuration Description is valid with respect to constr_2508 of [2].
Please note that the tables contain the following columns:
bsw module: Name of BSW module
bsw context: Reference to parameter container
bsw type: Type of parameter
bsw param: Name of the BSW parameter
bsw desc: Description from the configuration document
m2 template: System Template, SW Component Template, ECU Resource Template
m2 param: Name of the upstream template parameter
m2 description: Description from the upstream template definition
mapping rule: Textual description on how to transform between M2 and BSW do-
mains
mapping type:
• local: no mapping needed since parameter local to BSW
• partial: some data can be automatically mapped but not all
• full: all data can be automatically mapped

848 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

C.1 ComStack

C.1.1 Com Mapping

BSW Module BSW Context

Com Com
BSW Parameter BSW Type
ComConfig ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container contains the configuration parameters and sub containers of the AUTOSAR COM module.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00337]

BSW Module BSW Context

Com Com/ComConfig
BSW Parameter BSW Type
ComDataMemSize ECUC-INTEGER-PARAM-DEF
BSW Description
Size of internal Com data in units of bytes (static memory allocation) - memory required by post-build configuration must be
smaller than this constant. This parameter is needed only in case of post-build loadable implementation using static memory
allocation.
Template Description

BSW Module BSW Context

Com Com/ComConfig/ComGwMapping/ComGwDestination/ComGwDestinationDescription/ComFilter
BSW Parameter BSW Type
ComFilterMin ECUC-INTEGER-PARAM-DEF
BSW Description
The name of this attribute corresponds to the parameter name in the [17] specification of Reception Filtering.
Template Description
Value to specify the lower boundary
M2 Parameter
CommonStructure::Filter::DataFilter.min
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00318]

BSW Module BSW Context

Com Com/ComConfig/ComGwMapping/ComGwDestination/ComGwDestinationDescription/ComFilter
BSW Parameter BSW Type
ComFilterOffset ECUC-INTEGER-PARAM-DEF
BSW Description
The name of this attribute corresponds to the parameter name in the [17] specification of Reception Filtering.
Range = 0..(ComFilterPeriod-1)
Template Description
Specifies the initial number of messages to occur before the first message is passed
M2 Parameter
CommonStructure::Filter::DataFilter.offset
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00313]

BSW Module BSW Context

Com Com/ComConfig/ComGwMapping/ComGwDestination/ComGwDestinationDescription/ComFilter
BSW Parameter BSW Type
ComFilterPeriod ECUC-INTEGER-PARAM-DEF
BSW Description
This parameter defines the period of the ComFilterAlgorithm ONE_EVERY_N.
5

853 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Com Com/ComConfig/ComGwMapping/ComGwDestination
BSW Parameter BSW Type
ComGwSignal ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container allows specifying a gateway source or destination respectively with a reference to a ComSignal or a Com
GroupSignal.
Template Description

BSW Module BSW Context

Com Com/ComConfig/ComGwMapping/ComGwSource
BSW Parameter BSW Type
ComGwSourceDescription ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Description of a gateway source. This container allows defining a gateway source without the configuration of a complete
COM signal. This allows adding / changing gateway relations post build without the configuration of new signals.
Template Description
An ISignalToIPduMapping describes the mapping of ISignals to ISignalIPdus and defines the position of the ISignal within an
ISignalIPdu.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::ISignalToIPduMapping
Mapping Rule Mapping Type
Informations can be derived from ISignalToIPduMapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00548]

BSW Module BSW Context

Com Com/ComConfig/ComGwMapping/ComGwSource/ComGwSourceDescription
BSW Parameter BSW Type
ComBitPosition ECUC-INTEGER-PARAM-DEF
BSW Description
Starting position within the I-PDU. This parameter refers to the position in the I-PDU and not in the shadow buffer. If the
endianness conversion is configured to Opaque the parameter ComBitPosition shall define the bit0 of the first byte like in little
endian byte order
Template Description
This parameter is necessary to describe the bitposition of a signal within an SignalIPdu. It denotes the least significant bit for
"Little Endian" and the most significant bit for "Big Endian" packed signals within the IPdu (see the description of the packing
ByteOrder attribute). In AUTOSAR the bit counting is always set to "sawtooth" and the bit order is set to "Decreasing". The bit
counting in byte 0 starts with bit 0 (least significant bit). The most significant bit in byte 0 is bit 7.
Please note that the way the bytes will be actually sent on the bus does not impact this representation: they will always be
seen by the software as a byte array.
If a mapping for the ISignalGroup is defined, this attribute is irrelevant and shall be ignored.
M2 Parameter
5

859 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

Com Com/ComConfig/ComGwMapping/ComGwSource/ComGwSourceDescription
BSW Parameter BSW Type
ComUpdateBitPosition ECUC-INTEGER-PARAM-DEF
BSW Description
Bit position of update-bit inside I-PDU. If this attribute is omitted then there is no update-bit. This setting must be consistently
on sender and on receiver side.
Range: 0..63 for CAN and LIN, 0..511 for CAN FD, 0..2031 for FlexRay, 0..4294967295 for TP.
Template Description
5

862 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
The UpdateIndicationBit indicates to the receivers that the signal (or the signal group) was updated by the sender. Length is
always one bit. The UpdateIndicationBitPosition attribute describes the position of the update bit within the SignalIPdu. For
Signals of a ISignalGroup this attribute is irrelevant and shall be ignored.
Note that the exact bit position of the updateIndicationBitPosition is linked to the value of the attribute packingByteOrder
because the method of finding the bit position is different for the values mostSignificantByteFirst and mostSignificantByte
Last. This means that if the value of packingByteOrder is changed while the value of updateIndicationBitPosition remains
unchanged the exact bit position of updateIndicationBitPosition within the enclosing ISignalIPdu still undergoes a change.
This attribute denotes the least significant bit for "Little Endian" and the most significant bit for "Big Endian" packed signals
within the IPdu (see the description of the packingByteOrder attribute). In AUTOSAR the bit counting is always set to
"sawtooth" and the bit order is set to "Decreasing". The bit counting in byte 0 starts with bit 0 (least significant bit). The most
significant bit in byte 0 is bit 7.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::ISignalToIPduMapping.updateIndicationBitPosition
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00257]

BSW Module BSW Context

Com Com/ComConfig
BSW Parameter BSW Type
ComIPdu ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Contains the configuration parameters of the AUTOSAR COM module’s I-PDUs.
Template Description
Represents the IPdus handled by Com. The ISignalIPdu assembled and disassembled in AUTOSAR COM consists of one or
more signals. In case no multiplexing is performed this IPdu is routed to/from the Interface Layer.
A maximum of one dynamic length signal per IPdu is allowed.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::ISignalIPdu
Mapping Rule Mapping Type
create container for each SignalIPdu that is transmitted by the regarded ECU. full
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00340]

BSW Module BSW Context

Com Com/ComConfig/ComIPdu
BSW Parameter BSW Type
ComIPduCallout ECUC-FUNCTION-NAME-DEF
BSW Description
This parameter defines the existence and the name of a callout function for the corresponding I-PDU. If this parameter is
omitted no I-PDU callout shall take place for the corresponding I-PDU.
Template Description

M2 Parameter

863 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Mapping Rule Mapping Type
local
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00387]

BSW Module BSW Context

Com Com/ComConfig/ComIPdu
BSW Parameter BSW Type
ComIPduCancellationSupport ECUC-BOOLEAN-PARAM-DEF
BSW Description
Defines for I-PDUs with ComIPduType NORMAL: If the underlying IF-modul supports cancellation of transmit requests.
Defines for I-PDUs with ComIPduType TP: If the underlying TP-module supports RX and TX cancellation of ongoing requests.
Template Description

Com Com/ComConfig/ComIPdu
BSW Parameter BSW Type
ComIPduHandleId ECUC-INTEGER-PARAM-DEF
BSW Description
The numerical value used as the ID of this I-PDU. The ComIPduHandleId is required by the API calls Com_RxIndication,
Com_TpRxIndication, Com_StartOfReception and Com_CopyRxData to receive I-PDUs from the PduR (ComIP-duDirection:
Receive), as well as the PduId passed to an Rx-I-PDU-callout. For Tx-I-PDUs (ComIPduDirection: Send), this handle Id is
used for the APIs calls Com_TxConfirmation, Com_TriggerTransmit, Com_TriggerIPDUSend or Com_TriggerIPDUSendWith
MetaData, Com_CopyTxData and Com_TpTxConfirmation to transmit respectively confirm transmissions of I-PDUs, as well
as the PduId passed to the Tx-I-PDU-callout configured with ComIPduCallout and/or ComIPduTriggerTransmitCallout.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00175]

BSW Module BSW Context

Com Com/ComConfig/ComIPdu
BSW Parameter BSW Type
ComIPduMainFunctionRef ECUC-CHOICE-REFERENCE-DEF
BSW Description
Reference to the Com_MainFunctionRx/Com_MainFunctionTx this I-PDU belongs to.
Mandatory, if multiple main functions of the relevant type are defined.
Template Description

M2 Parameter

Mapping Rule Mapping Type

4
SystemTemplate::Fibex::FibexCore::CoreCommunication::ISignalToIPduMapping
Mapping Rule Mapping Type
Find ISignal in the IPdu which refers to a SystemSignal and create reference to this Signal. full
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00518]

BSW Module BSW Context

Com Com/ComConfig/ComIPdu
BSW Parameter BSW Type
ComIPduTriggerTransmitCallout ECUC-FUNCTION-NAME-DEF
BSW Description
If there is a trigger transmit callout defined for this I-PDU this parameter contains the name of the callout function.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00765]

BSW Module BSW Context

Com Com/ComConfig/ComIPdu
BSW Parameter BSW Type
ComIPduType ECUC-ENUMERATION-PARAM-DEF
BSW Description
Defines if this I-PDU is a normal I-PDU that can be sent unfragmented or if this is a large I-PDU that shall be sent via the
Transport Protocol of the underlying bus.
Template Description
Contains all configuration elements for AUTOSAR TP.
M2 Parameter
SystemTemplate::TransportProtocols::TpConfig
Mapping Rule Mapping Type
If this PduTriggering is referenced by a TpConnection then set this EnumerationLiteral to TP. full
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00761]

BSW Module BSW Context

Com Com/ComConfig/ComIPdu
BSW Parameter BSW Type
ComMainFunctionRouteSignalsRef ECUC-REFERENCE-DEF
BSW Description
5

867 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Reference to ComMainFunctionRouteSignals which performs signal gateway related activities.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Com_10021]

BSW Module BSW Context

Com Com/ComConfig/ComIPdu
BSW Parameter BSW Type
ComPduIdRef ECUC-REFERENCE-DEF
BSW Description
Reference to the "global" Pdu structure to allow harmonization of handle IDs in the COM-Stack.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00711]

Com Com/ComConfig/ComIPdu/ComTxIPdu
BSW Parameter BSW Type
ComTxIPduUnusedAreasDefault ECUC-INTEGER-PARAM-DEF
BSW Description
The AUTOSAR COM module fills not used areas of an I-PDU with this byte pattern. This attribute is mandatory to avoid
undefined behaviour. This byte-pattern will be repeated throughout the I-PDU before any init-values or update-bits were set.
5

870 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Template Description
AUTOSAR COM and AUTOSAR IPDUM are filling not used areas of an IPDU with this bit-pattern. This attribute is mandatory
to avoid undefined behavior. This byte-pattern will be repeated throughout the IPdu.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::ISignalIPdu.unusedBitPattern
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00017]

BSW Module BSW Context

Com Com/ComConfig/ComIPdu/ComTxIPdu
BSW Parameter BSW Type
ComTxModeFalse ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container contains the configuration parameters of the AUTOSAR COM module’s transmission modes in the case the
ComFilter evaluates to false.
Template Description

M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::Timing::TransmissionModeDeclaration.
transmissionModeFalseTiming
Mapping Rule Mapping Type
Create Container if a timing specification is defined for this IPdu. full
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00454]

BSW Module BSW Context

Com Com/ComConfig/ComIPdu/ComTxIPdu/ComTxModeFalse/ComTxMode
BSW Parameter BSW Type
ComTxModeTimeOffset ECUC-FLOAT-PARAM-DEF
BSW Description
Defines the period in seconds between the start of the I-PDU by Com_IpduGroupStart and the first transmission request in
case ComTxModeMode is configured to PERIODIC or MIXED. In case of the mixed transmission mode only the periodic part
is affected.
In case ComTxModeTimeOffset is omitted or configured to 0, the first periodic transmission shall be transmitted within the
next invocation of Com_MainFunctionTx.
Template Description

M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::Timing::CyclicTiming.timeOffset
Mapping Rule Mapping Type
The value for the True and the False Transmission Mode can be derived from IPdu full
Timing.TransmissionModeDeclaration.TransmissionModeTiming element
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00180]

BSW Module BSW Context

Com Com/ComConfig/ComIPdu/ComTxIPdu/ComTxModeFalse/ComTxMode
BSW Parameter BSW Type
ComTxModeTimePeriod ECUC-FLOAT-PARAM-DEF
5

873 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
BSW Description
Defines the repetition period in seconds of the periodic transmission requests in case ComTxModeMode is configured to
PERIODIC or MIXED. In case of the mixed transmission mode only the periodic part is affected.
Template Description

M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::Timing::CyclicTiming.timePeriod
Mapping Rule Mapping Type
The value for the True and the False Transmission Mode can be derived from IPdu full
Timing.TransmissionModeDeclaration.TransmissionModeTiming element
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00178]

BSW Module BSW Context

Com Com/ComConfig/ComIPdu/ComTxIPdu
BSW Parameter BSW Type
ComTxModeTrue ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container contains the configuration parameters of the AUTOSAR COM module’s transmission modes in the case the
ComFilter evaluates to true.
Template Description

M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::Timing::TransmissionModeDeclaration.
transmissionModeTrueTiming
Mapping Rule Mapping Type
Create Container if a timing specification is defined for this IPdu. full
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00455]

BSW Module BSW Context

Com Com/ComConfig/ComIPdu/ComTxIPdu/ComTxModeTrue
BSW Parameter BSW Type
ComTxMode ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container contains the configuration parameters of the AUTOSAR COM module’s transmission modes.
Template Description
If the COM Transmission Mode is false the timing is aggregated by the TransmissionModeTiming element in the role of
transmissionModeFalseTiming. If the COM Transmission Mode is true the timing is aggregated by the TransmissionMode
Timing element in the role of transmissionModeTrueTiming.
COM supports the following Transmission Modes:
• Periodic (Cyclic Timing)
• Direct /n-times (EventControlledTiming)
• Mixed (Cyclic and EventControlledTiming are assigned)
• None (no timing is assigned)
5

874 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::Timing::TransmissionModeTiming
Mapping Rule Mapping Type
Create Container if a timing specification is defined for this IPdu. full
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00351]

877 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
If the IPduGroup has a reference to a contained IPduGroup then create this reference. Please note full
that in COM the contained IPduGroup points to the containing IPduGroup and in System Template
the containing ISignalIPduGroup points to the contained ISignalIPduGroup.
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00185]

BSW Module BSW Context

Com Com/ComConfig/ComIPduGroup
BSW Parameter BSW Type
ComIPduGroupHandleId ECUC-INTEGER-PARAM-DEF
BSW Description
The numerical value used as the ID of this I-PDU Group . The ComIPduGroupHandleId is required by the API calls to start
and stop I-PDU Groups.
Range: 0 .. (ComSupportedIPduGroups-1)
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00184]

BSW Module BSW Context

Com Com/ComConfig
BSW Parameter BSW Type
ComMainFunctionRouteSignals ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Each element of this container defines one instance of Com_MainFunctionRouteSignals.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Com_10013]

BSW Module BSW Context

Com Com/ComConfig/ComMainFunctionRouteSignals
BSW Parameter BSW Type
ComMainRouteSignalsPartitionRef ECUC-REFERENCE-DEF
BSW Description
5

878 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Com Com/ComConfig/ComMainFunctionTx
BSW Parameter BSW Type
ComMainTxPartitionRef ECUC-REFERENCE-DEF
BSW Description
Reference to EcucPartition, where the according Com_MainFunction instance is assigned to.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Com_10019]

BSW Module BSW Context

Com Com/ComConfig/ComMainFunctionTx
BSW Parameter BSW Type
ComMainTxTimeBase ECUC-FLOAT-PARAM-DEF
BSW Description
The period between successive calls to according instance of Com_MainFunctionTx in seconds. This parameter may be used
by the COM generator to transform the values of the reception related timing configuration parameters of the COM module to
internal implementation specific counter or tick values. The COM module’s internal timing handling is implementation specific.
The COM module (generator) may rely on the fact that Com_MainFunctionTx is scheduled according to the value configured
here.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Com_10010]

BSW Module BSW Context

Com Com/ComConfig/ComMainFunctionTx
BSW Parameter BSW Type
ComPreparationNotification ECUC-FUNCTION-NAME-DEF
BSW Description
5

881 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
This callback function indicates that the signals/signal groups to be sent via a dedicated Com_MainFunctionTx instance will
now be prepared for transmission.
If this parameter is omitted no notification shall take place.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Com_10020]

BSW Module BSW Context

Com Com/ComConfig
BSW Parameter BSW Type
ComMaxIPduCnt ECUC-INTEGER-PARAM-DEF
BSW Description
Maximum number of IPdus. This parameter is needed only in case of post-build loadable implementation using static memory
allocation.
Template Description

M2 Parameter

Mapping Rule Mapping Type

886 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
M2 Parameter
CommonStructure::Filter::DataFilter.offset
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00313]

BSW Module BSW Context

Com Com/ComConfig/ComSignal/ComFilter
BSW Parameter BSW Type
ComFilterPeriod ECUC-INTEGER-PARAM-DEF
BSW Description
This parameter defines the period of the ComFilterAlgorithm ONE_EVERY_N.
Template Description
Specifies number of messages to occur before the message is passed again
M2 Parameter
CommonStructure::Filter::DataFilter.period
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00312]

BSW Module BSW Context

Com Com/ComConfig/ComSignal/ComFilter
BSW Parameter BSW Type
ComFilterX ECUC-INTEGER-PARAM-DEF
BSW Description
The name of this attribute corresponds to the parameter name in the [17] specification of Reception Filtering.
Template Description
Value to compare with
M2 Parameter
CommonStructure::Filter::DataFilter.x
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00147]

BSW Module BSW Context

Com Com/ComConfig/ComSignal
BSW Parameter BSW Type
ComFirstTimeout ECUC-FLOAT-PARAM-DEF
5

887 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
BSW Description
Defines the length of the first deadline monitoring timeout period in seconds. This timeout is used immediately after start (or
restart) of the deadline monitoring service. The timeout period of the successive periods is configured by ECUC_Com_00263.
Template Description
• ISignalPort with communicationDirection = in:
Optional first timeout value in seconds for the reception of the ISignal.
• ISignalPort with communicationDirection = out:
Optional first timeout value in seconds for transmission deadline monitoring.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::ISignalPort.firstTimeout
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00183]

BSW Module BSW Context

Com Com/ComConfig/ComSignal
BSW Parameter BSW Type
ComHandleId ECUC-INTEGER-PARAM-DEF
BSW Description
The numerical value used as the ID.
This ID identifies signals and signal groups in the COM APIs using Com_SignalIdType or Com_SignalGroupIdType parameter
respectively.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00165]

BSW Module BSW Context

Com Com/ComConfig/ComSignal
BSW Parameter BSW Type
ComInitialValueOnly ECUC-BOOLEAN-PARAM-DEF
BSW Description
This parameter defines that the respective signal’s initial value shall be put into the respective PDU but there will not be any
update of the value through the users (e.g. RTE, SwCluC). Thus the Com implementation does not need to expect any API
calls for this signal (group).
Template Description
Connectors reception or send port on the referenced channel referenced by an ISignalTriggering. If different timeouts or Data
Filters for ISignals need to be specified several ISignalPorts may be created.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::ISignalPort
5

888 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Mapping Rule Mapping Type
Tx: If an ISignal has no ISignalPort assigned a ComSignal shall always be created in the full
transmitting ECUs in order to send the init value. Rx: If an ISignal has no ISignalPort assigned
there is no need for the existence of a ComSignal in the rec. Ecu
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00811]

BSW Module BSW Context

Com Com/ComConfig/ComSignal
BSW Parameter BSW Type
ComInvalidNotification ECUC-FUNCTION-NAME-DEF
BSW Description
Only valid on receiver side: Name of Com_CbkInv callback function to be called. Name of the function which notifies the RTE
about the reception of an invalidated signal/ signal group. Only applicable if ComDataInvalidAction is configured to NOTIFY.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00315]

BSW Module BSW Context

Com Com/ComConfig/ComSignal
BSW Parameter BSW Type
ComNotification ECUC-FUNCTION-NAME-DEF
BSW Description
On sender side: Name of Com_CbkTxAck callback function to be called. On receiver side: Name of Com_CbkRxAck
callback function to be called.
If this parameter is omitted no notification shall take place.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00498]

BSW Module BSW Context

Com Com/ComConfig/ComSignal
BSW Parameter BSW Type
ComRxDataTimeoutAction ECUC-ENUMERATION-PARAM-DEF
5

889 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

System Template
AUTOSAR CP R21-11

4
4
Representation.networkRepresentation.swBaseType if not defined on ComSpec: Common
Structure::ImplementationDataTypes::ImplementationDataType.swDataDefProps.swBaseType Find
the ImplementationDataType according to TPS_SYST_02079 and access SwDataDefProps.sw
BaseType. Consequence: If two SenderReceiverToSignalMappings that point to the same System
Signal result in incompatible BaseTypes (see constr_1220 in SoftwareComponentTemplate) =>
ComSignalType should not be configured. - ISignal.dataTypePolicy = portInterfaceDefinition –>
option has atpStatus "removed", in consequence no mapping is available." - ISignal.dataTypePolicy
= transformingISignal Hardcoded to UINT8_N or UINT8_DYN. Datatype can be derived from
SystemSignal.dynamicLength: UINT8_N should be used if SystemSignal.dynamicLength = false
UINT8_DYN should be used if SystemSignal.dynamicLength = true
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00127]

BSW Module BSW Context

Com Com/ComConfig/ComSignal
BSW Parameter BSW Type
ComSystemTemplateSystemSignalRef ECUC-FOREIGN-REFERENCE-DEF
BSW Description
Reference to the ISignalToIPduMapping that contains a reference to the ISignal (System Template) which this ComSignal (or
ComGroupSignal) represents.
Template Description
An ISignalToIPduMapping describes the mapping of ISignals to ISignalIPdus and defines the position of the ISignal within an
ISignalIPdu.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::ISignalToIPduMapping
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00002]

BSW Module BSW Context

Com Com/ComConfig/ComSignal
BSW Parameter BSW Type
ComTimeout ECUC-FLOAT-PARAM-DEF
BSW Description
Defines the length of the deadline monitoring timeout period in seconds. The period for the first timeout period can be
configured separately by ECUC_Com_00183.
Template Description
ISignalPort.timeout:
• ISignalPort with communicationDirection = in:
Optional timeout value in seconds for the reception of the ISignal. The attribute value is used to configure the ComTimeout in
the COM module. The RTE ignores this attribute. The timeout can also be specified with the NonqueuedReceiverCom
Spec.aliveTimeout attribute. If a full DataMapping exists for the SystemSignal and the value is available in the configured
ReceiverComSpec, then the timeout value in the ReceiverComSpec overrides this optional timeout specification during the
creation of the Base Ecu Configuration of the COM module.
• ISignalPort with communicationDirection = out:
5

893 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
4
Optional timeout value in seconds for the transmission of the ISignal. The attribute value is used to configure the Com
Timeout in the COM module. The RTE ignores this attribute. The timeout can also be specified with the enderCom
Spec.transmissionAcknowledge.timeout attribute. If a full DataMapping exists for the SystemSignal and the value is available
in the configured SenderComSpec, then the timeout value in the SenderComSpec overrides this optional timeout
specification during the creation of the Base Ecu Configuration of the COM module.
This attribute can be used in the following cases:
• legacy signal where the System Description doesn’t use a complete Software Component Description (VFB View)
and where the DataMapping is missing.
• bus monitoring use cases in which the DataMapping is ignored.
TransmissionAcknowledgementRequest.timeout:
Number of seconds before an error is reported or in case of allowed redundancy, the value is sent again.
NonqueuedReceiverComSpec.aliveTimeout:
Specify the amount of time (in seconds) after which the software component (via the RTE) needs to be notified if the
corresponding data item have not been received according to the specified timing description.
If the aliveTimeout attribute is 0 no timeout monitoring shall be performed.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::ISignalPort.timeout, SWComponent
Template::Communication::TransmissionAcknowledgementRequest.timeout, SWComponent
Template::Communication::NonqueuedReceiverComSpec.aliveTimeout
Mapping Rule Mapping Type
TX Signals: If a full DataMapping exist for the SystemSignal this information may be available from full
a configured SenderComSpec.transmissionAcknowledge.timeout that specifies the amount of time
(in seconds) after which the software component (via the RTE) needs to be notified if the
corresponding data item have not been transmitted according to the specified timing description. In
this case the timeout value in SenderComSpec overrides the optional timeout specification in the
System Template defined on the ISignalPort. RX Signals: If a full DataMapping exist for the
SystemSignal this information may be available from a configured NonqueuedReceiverCom
Spec.aliveTimeout. In this case the timeout value in ReceiverComSpec overrides the optional
timeout specification in the System Template defined on the ISignalPort. Please note that the
SWS_RTE defines an algorithm to finally set the applicable timeout value.
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00263]

BSW Module BSW Context

Com Com/ComConfig/ComSignal
BSW Parameter BSW Type
ComTimeoutNotification ECUC-FUNCTION-NAME-DEF
BSW Description
On sender side: Name of Com_CbkTxTOut callback function to be called. On receiver side: Name of Com_CbkRxTOut
callback function to be called.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00552]

894 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

Com Com/ComConfig/ComSignal
BSW Parameter BSW Type
ComTimeoutSubstitutionValue ECUC-STRING-PARAM-DEF
BSW Description
The signal substitution value will be used in case of a timeout and ComRxDataTimeoutAction is set to SUBSTITUTE. In case
of UINT8_N the default value is a string of length ComSignalLength with all bytes set to 0x00.
In case ofUINT8_DYN the initial size shall be 0.
In case the ComSignalType is UINT8, UINT16, UINT32, UINT64, SINT8, SINT16, SINT32, SINT64 the string shall be
interpreted as defined in the chapter Integer Type in the AUTOSAR EcuC specification.
In case the ComSignalType is FLOAT32, FLOAT64 the string shall be interpreted as defined in the chapter Float Type in the
AUTOSAR EcuC specification.
In case the ComSignalType is BOOLEAN the string shall be interpreted as defined in the chapter Boolean Type in the
AUTOSAR EcuC specification.
In case the ComSignal is a UINT8_N, UINT8_DYN the string shall be interpreted as a decimal representation of the
characters separated by blanks, e.g. "97 98 100" means a string "abd", where the char "a" is in byte 0(lowest address), "b" is
in byte 1, and "d" is in byte 2 and (highest address). For the ComSignalType UINT8_DYN the dynamic length shall be set to
the number of configured characters. An empty string "" shall be interpreted as 0-sized dynamic signal.
Template Description
Defines and enables the ComTimeoutSubstituition for this ISignal.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::ISignal.timeoutSubstitutionValue
Mapping Rule Mapping Type
The mapping of ComTimeoutSubstitutionValue depends on the setting in the ISignal.dataType full
Policy: - ISignal.dataTypePolicy = override or legacy: SystemTemplate::Fibex::FibexCore::Core
Communication::ISignal.timeoutSubstitutionValue - ISignal.dataTypePolicy = network
RepresentationFromComSpec: SWComponentTemplate::Communication::NonequeuedReceiver
ComSpec.timeoutSubstitutionValue - ISignal.dataTypePolicy = transformingISignal this is not
supported.
Mapping Status ECUC Parameter ID
valid [ECUC_Com_10006]

BSW Module BSW Context

Com Com/ComConfig/ComSignal
BSW Parameter BSW Type
ComTransferProperty ECUC-ENUMERATION-PARAM-DEF
BSW Description
Defines if a write access to this signal can trigger the transmission of the corresponding I-PDU. If the I-PDU is triggered,
depends also on the transmission mode of the corresponding I-PDU.
Template Description
Defines how the referenced ISignal contributes to the send triggering of the ISignalIPdu.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::ISignalToIPduMapping.transferProperty
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
5

895 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
valid [ECUC_Com_00232]

System Template
AUTOSAR CP R21-11

4
4
in the configured SenderComSpec, then the timeout value in the SenderComSpec overrides this optional timeout
specification during the creation of the Base Ecu Configuration of the COM module.
This attribute can be used in the following cases:
• legacy signal where the System Description doesn’t use a complete Software Component Description (VFB View)
and where the DataMapping is missing.
• bus monitoring use cases in which the DataMapping is ignored.
TransmissionAcknowledgementRequest.timeout:
Number of seconds before an error is reported or in case of allowed redundancy, the value is sent again.
NonqueuedReceiverComSpec.aliveTimeout:
Specify the amount of time (in seconds) after which the software component (via the RTE) needs to be notified if the
corresponding data item have not been received according to the specified timing description.
If the aliveTimeout attribute is 0 no timeout monitoring shall be performed.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::ISignalPort.timeout, SWComponent
Template::Communication::TransmissionAcknowledgementRequest.timeout, SWComponent
Template::Communication::NonqueuedReceiverComSpec.aliveTimeout
Mapping Rule Mapping Type
TX Signals: If a full DataMapping exist for the SystemSignal this information may be available from full
a configured SenderComSpec.transmissionAcknowledge.timeout that specifies the amount of time
(in seconds) after which the software component (via the RTE) needs to be notified if the
corresponding data item have not been transmitted according to the specified timing description. In
this case the timeout value in SenderComSpec overrides the optional timeout specification in the
System Template defined on the ISignalPort. RX Signals: If a full DataMapping exist for the
SystemSignal this information may be available from a configured NonqueuedReceiverCom
Spec.aliveTimeout. In this case the timeout value in ReceiverComSpec overrides the optional
timeout specification in the System Template defined on the ISignalPort. Please note that the
SWS_RTE defines an algorithm to finally set the applicable timeout value.
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00263]

BSW Module BSW Context

Com Com/ComConfig/ComSignalGroup
BSW Parameter BSW Type
ComTimeoutNotification ECUC-FUNCTION-NAME-DEF
BSW Description
On sender side: Name of Com_CbkTxTOut callback function to be called. On receiver side: Name of Com_CbkRxTOut
callback function to be called.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00552]

BSW Module BSW Context

Com Com/ComConfig/ComSignalGroup
5

911 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
BSW Parameter BSW Type
ComTransferProperty ECUC-ENUMERATION-PARAM-DEF
BSW Description
Defines if a write access to this signal can trigger the transmission of the corresponding I-PDU. If the I-PDU is triggered,
depends also on the transmission mode of the corresponding I-PDU.
Template Description
Defines how the referenced ISignal contributes to the send triggering of the ISignalIPdu.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::ISignalToIPduMapping.transferProperty
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00232]

BSW Module BSW Context

Com Com/ComConfig/ComSignalGroup
BSW Parameter BSW Type
ComUpdateBitPosition ECUC-INTEGER-PARAM-DEF
BSW Description
Bit position of update-bit inside I-PDU. If this attribute is omitted then there is no update-bit. This setting must be consistently
on sender and on receiver side.
Range: 0..63 for CAN and LIN, 0..511 for CAN FD, 0..2031 for FlexRay, 0..4294967295 for TP.
Template Description
The UpdateIndicationBit indicates to the receivers that the signal (or the signal group) was updated by the sender. Length is
always one bit. The UpdateIndicationBitPosition attribute describes the position of the update bit within the SignalIPdu. For
Signals of a ISignalGroup this attribute is irrelevant and shall be ignored.
Note that the exact bit position of the updateIndicationBitPosition is linked to the value of the attribute packingByteOrder
because the method of finding the bit position is different for the values mostSignificantByteFirst and mostSignificantByte
Last. This means that if the value of packingByteOrder is changed while the value of updateIndicationBitPosition remains
unchanged the exact bit position of updateIndicationBitPosition within the enclosing ISignalIPdu still undergoes a change.
This attribute denotes the least significant bit for "Little Endian" and the most significant bit for "Big Endian" packed signals
within the IPdu (see the description of the packingByteOrder attribute). In AUTOSAR the bit counting is always set to
"sawtooth" and the bit order is set to "Decreasing". The bit counting in byte 0 starts with bit 0 (least significant bit). The most
significant bit in byte 0 is bit 7.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::ISignalToIPduMapping.updateIndicationBitPosition
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00257]

BSW Module BSW Context

Com Com/ComConfig
BSW Parameter BSW Type
ComUserModule ECUC-PARAM-CONF-CONTAINER-DEF
5

912 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

BSW Module BSW Context

Com Com/ComGeneral
BSW Parameter BSW Type
ComCancellationSupport ECUC-BOOLEAN-PARAM-DEF
BSW Description
5

913 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
This parameter enables/disables the cancellation feature: true: enabled false: disabled
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_Com_10000]

BSW Module BSW Context

Com Com/ComGeneral
BSW Parameter BSW Type
ComConfigurationUseDet ECUC-BOOLEAN-PARAM-DEF
BSW Description
The error hook shall contain code to call the Det. If this parameter is configured COM_DEV_ERROR_DETECT shall be set to
ON as output of the configuration tool. (as input for the source code).
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00141]

BSW Module BSW Context

Com Com/ComGeneral
BSW Parameter BSW Type
ComEnableMDTForCyclicTransmission ECUC-BOOLEAN-PARAM-DEF
BSW Description
Enables globally for the whole Com module the minimum delay time monitoring for cyclic and repeated transmissions (Com
TxModeMode=PERIODIC or ComTxModeMode=MIXED for the cyclic transmissions, ComTxModeNumberOfRepetitions > 0
for repeated transmissions).
Template Description
Enables for the Com module of this EcuInstance the minimum delay time monitoring for cyclic and repeated transmissions
(TransmissionModeTiming has cyclicTiming assigned or eventControlledTiming with numberOfRepetitions > 0).
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreTopology::EcuInstance.comEnableMDTForCyclicTransmission
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00788]

914 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

Com Com/ComGeneral
BSW Parameter BSW Type
ComEnableSignalGroupArrayApi ECUC-BOOLEAN-PARAM-DEF
BSW Description
Activate/Deactivate the signal group array access APIs (Com_SendSignalGroupArray, Com_ReceiveSignalGroupArray).
true: signal group array access APIs activated
false: signal group array access APIs deactivated
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Com_10002]

BSW Module BSW Context

Com Com/ComGeneral
BSW Parameter BSW Type
ComMetaDataSupport ECUC-BOOLEAN-PARAM-DEF
BSW Description
This parameter enables/disables the support of meta-data feature including the API Com_TriggerIPDUSendWithMetaData.
true: enabled false: disabled
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_Com_10004]

BSW Module BSW Context

Com Com/ComGeneral
BSW Parameter BSW Type
ComRetryFailedTransmitRequests ECUC-BOOLEAN-PARAM-DEF
BSW Description
If this Parameter is set to true, retry of failed transmission requests is enabled. If this Parameter is not present, the default
value is assumed.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
5

915 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

System Template
AUTOSAR CP R21-11

4
Mapping Rule Mapping Type
local
Mapping Status ECUC Parameter ID
valid [ECUC_Com_00438]

C.1.2 LdCom Mapping

BSW Module BSW Context

LdCom LdCom
BSW Parameter BSW Type
LdComConfig ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container contains the configuration parameters and sub containers of the AUTOSAR LdCom module.
Template Description

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_LdCom_-
00005]

BSW Module BSW Context

LdCom LdCom/LdComConfig/LdComIPdu
BSW Parameter BSW Type
LdComIPduDirection ECUC-ENUMERATION-PARAM-DEF
BSW Description
The direction defines if this IPdu, and therefore the contributing signal, shall be sent or received.
Template Description
5

918 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Communication Direction of the Connector Port (input or output Port).
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreTopology::CommConnectorPort.communicationDirection
Mapping Rule Mapping Type
Find IPduTriggering of the regarded SignalIPdu. The IPduTriggering contains a reference to an full
IPduPort that is aggegated by the regarded ECU. If the communicationDirection of the Comm
ConnectorPort is "in" than the IPdu is received.
Mapping Status ECUC Parameter ID
valid [ECUC_LdCom_-
00007]

BSW Module BSW Context

LdCom LdCom/LdComConfig/LdComIPdu
BSW Parameter BSW Type
LdComPduRef ECUC-REFERENCE-DEF
BSW Description
Reference to the global Pdu.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_LdCom_-
00010]

BSW Module BSW Context

LdCom LdCom/LdComConfig/LdComIPdu
BSW Parameter BSW Type
LdComRxCopyRxData ECUC-FUNCTION-NAME-DEF
BSW Description
Only on receiver side: Name of Rte_LdComCbkCopyRxData callback function to be called.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_LdCom_-
00013]

919 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

LdCom LdCom/LdComConfig/LdComIPdu
BSW Parameter BSW Type
LdComRxIndication ECUC-FUNCTION-NAME-DEF
BSW Description
Only on receiver side: Name of Rte_LdComCbkRxIndication callback function to be called.
Template Description

M2 Parameter

LdCom LdCom/LdComConfig
BSW Parameter BSW Type
5

922 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

923 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

LdCom LdCom/LdComGeneral
BSW Parameter BSW Type
LdComDevErrorDetect ECUC-BOOLEAN-PARAM-DEF
BSW Description
Switches the development error detection and notification on or off.
• true: detection and notification is enabled.
• false: detection and notification is disabled.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_LdCom_-
00020]

BSW Module BSW Context

LdCom LdCom/LdComGeneral
BSW Parameter BSW Type
LdComVersionInfoApi ECUC-BOOLEAN-PARAM-DEF
BSW Description
Activate/Deactivate the version information API (LdCom_GetVersionInfo).
• True: version information API activated
• False: version information API deactivated
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_LdCom_-
00012]

C.1.3 IPduM Mapping

BSW Module BSW Context

IpduM IpduM
BSW Parameter BSW Type
IpduMConfig ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
5

924 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
This container contains the sub containers of the IpduM module.
• The IpduMTxPathway subcontainer includes information about sent I-PDUs.
• The IpduMRxPathway includes information about received I-PDUs.
• The IpduMContainerTxPdu and IpduMContainedTxPdu include information about the sending of ContainerPdus.
• The IpduMContainerRxPdu and IpduMContainedRxPdu include information about the reception of ContainerPdus.
Template Description

M2 Parameter

IpduM IpduM/IpduMConfig/IpduMContainedRxPdu
BSW Parameter BSW Type
IpduMContainedRxPduRef ECUC-REFERENCE-DEF
BSW Description
Reference to the Pdu which represents this ContainedPdu and is used for reception indication.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_IpduM_00175]

BSW Module BSW Context

IpduM IpduM/IpduMConfig/IpduMContainedRxPdu
BSW Parameter BSW Type
IpduMContainedRxPduShortHeaderId ECUC-INTEGER-PARAM-DEF
BSW Description
ShortHeader Id which is part of the ContainerPdu when this ContainedPdu is inside.
Template Description
Defines the header id this IPdu shall have in case this IPdu is put inside a ContainerIPdu with headerType = shortHeader.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::ContainedIPduProps.headerIdShortHeader
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_IpduM_00202]

BSW Module BSW Context

IpduM IpduM/IpduMConfig/IpduMContainedRxPdu
BSW Parameter BSW Type
IpduMPduUpdateBitPosition ECUC-INTEGER-PARAM-DEF
BSW Description
This value specifies where the PDU’s Update-Bit is stored in the Container PDU (bit location of PDU’s Update-Bit in the
Container PDU).
Template Description
The updateIndicationBit specifies the bit location of ContainedIPdu Update-Bit in the Container PDU. It indicates to the
receivers that the ContainedIPdu in the ContainerIPdu was updated.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::ContainedIPduProps.updateIndicationBitPosition
Mapping Rule Mapping Type
5

927 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
If the ContainerIPdu directly references the PduTriggering in the role ContainerIPdu.containedPdu full
Triggering then this attribute is derived from IPdu.containedIPduProps. If the ContainerIPdu
indirectly references the PduTriggering via ContainerIPdu.containedIPduTriggeringProps then this
attribute is derived from that ContainerIPdu.containedIPduTriggeringProps.
Mapping Status ECUC Parameter ID
valid [ECUC_IpduM_00207]

BSW Module BSW Context

IpduM IpduM/IpduMConfig
BSW Parameter BSW Type
IpduMContainedTxPdu ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Configuration of a sender ContainedPdu.
Template Description

BSW Module BSW Context

IpduM IpduM/IpduMConfig/IpduMContainedTxPdu/IpduMContainedTxPduCollectionSemantics
BSW Parameter BSW Type
IPDUM_COLLECT_LAST_IS_BEST ECUC-ENUMERATION-LITERAL-DEF
BSW Description
The IpduMContainedTxPdu data will be fetched via TriggerTransmit just before the transmission executes.
Template Description
The ContainedIPdu data will be fetched via TriggerTransmit just before the transmission executes.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::ContainedIPduCollectionSemanticsEnum.lastIsBest
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid

IpduM IpduM/IpduMConfig/IpduMContainedTxPdu
BSW Parameter BSW Type
IpduMContainedTxPduPriority ECUC-INTEGER-PARAM-DEF
BSW Description
Defines a priority of a ContainedTxPdu. 255 represents the lowest priority and 0 represent the highest priority.
Template Description
Defines a priority of a ContainedTxPdu. 255 represents the lowest priority and 0 represent the highest priority.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::ContainedIPduProps.priority
Mapping Rule Mapping Type
5

931 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Priority handling for a ContainerIPdu is enabled if at least one ContainedIPdu contains the attribute full
"priority" within its aggregated ContainerIPduProps, and there are different priorities configured
within one ContainerIPdu (Reason: When all ContainedIPdus have the same priority, they cannot
be prioritized). If the ContainerIPdu directly references the PduTriggering in the role Container
IPdu.containedPduTriggering then this attribute is derived from IPdu.containedIPduProps. If the
ContainerIPdu indirectly references the PduTriggering via ContainerIPdu.containedIPduTriggering
Props then this attribute is derived from that ContainerIPdu.containedIPduTriggeringProps.
Mapping Status ECUC Parameter ID
valid [ECUC_IpduM_00210]

BSW Module BSW Context

IpduM IpduM/IpduMConfig/IpduMContainedTxPdu
BSW Parameter BSW Type
IpduMContainedTxPduRef ECUC-REFERENCE-DEF
BSW Description
Reference to the Pdu which represents this ContainedPdu and is used for transmission.
Template Description

BSW Module BSW Context

IpduM IpduM/IpduMConfig/IpduMContainedTxPdu
BSW Parameter BSW Type
IpduMPduUpdateBitPosition ECUC-INTEGER-PARAM-DEF
BSW Description
This value specifies where the PDU’s Update-Bit is stored in the Container PDU (bit location of PDU’s Update-Bit in the
Container PDU).
Template Description
The updateIndicationBit specifies the bit location of ContainedIPdu Update-Bit in the Container PDU. It indicates to the
receivers that the ContainedIPdu in the ContainerIPdu was updated.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::ContainedIPduProps.updateIndicationBitPosition
Mapping Rule Mapping Type
If the ContainerIPdu directly references the PduTriggering in the role ContainerIPdu.containedPdu full
Triggering then this attribute is derived from IPdu.containedIPduProps. If the ContainerIPdu
indirectly references the PduTriggering via ContainerIPdu.containedIPduTriggeringProps then this
attribute is derived from that ContainerIPdu.containedIPduTriggeringProps.
Mapping Status ECUC Parameter ID
valid [ECUC_IpduM_00207]

BSW Module BSW Context

IpduM IpduM/IpduMConfig
BSW Parameter BSW Type
IpduMContainerRxPdu ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Configuration of a receiver ContainerPdu which may collect several ContainedPdus.
Template Description

System Template
AUTOSAR CP R21-11

4
No Header is used and the location of each containedPdu in the ContainerPdu is statically configured.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::ContainerIPduHeaderTypeEnum.noHeader
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid

BSW Module BSW Context

IpduM IpduM/IpduMConfig/IpduMContainerRxPdu/IpduMContainerHeaderSize
BSW Parameter BSW Type
IPDUM_HEADERTYPE_SHORT ECUC-ENUMERATION-LITERAL-DEF
BSW Description
Header size is 32 bit:
• Header Id 24 bit
• Dlc 8 bit
Template Description
Header size is 32 bit:
• Header Id 24 bit
• Dlc 8 bit.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::ContainerIPduHeaderTypeEnum.shortHeader
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid

BSW Module BSW Context

IpduM IpduM/IpduMConfig/IpduMContainerRxPdu
BSW Parameter BSW Type
IpduMContainerPduProcessing ECUC-ENUMERATION-PARAM-DEF
BSW Description
Defines whether the handling of this ContainerPdu shall be done in the context of the caller (IMMEDIATE) or in the next call to
IpduM_MainFunctionRx (DEFERRED).
Template Description

System Template
AUTOSAR CP R21-11

4
BSW Description
The IpduMContainedRxPdus which are referencing this IpduMContainerRxPdu are expected inside this IpduMContainerRx
Pdu, but there may also occur other Pdus inside this IpduMContainerRxPdu as well. This also supports the case where no
IpduMContainedRxPdu references the IpduMContainerRxPdu.
Template Description
No fixed set of containedIPdus is defined for reception, any known containedIPdu (based on headerId) shall be expected
within this ContainerIPdu.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::RxAcceptContainedIPduEnum.acceptAll
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid

BSW Module BSW Context

IpduM IpduM/IpduMConfig/IpduMContainerRxPdu/IpduMContainerRxAcceptContainedPdu
BSW Parameter BSW Type
IPDUM_ACCEPT_CONFIGURED ECUC-ENUMERATION-LITERAL-DEF
BSW Description
Only the IpduMContainedRxPdus which are referencing this IpduMContainerRxPdu are expected inside this IpduMContainer
RxPdu.
Template Description
A fixed set of containedIPdus is defined for reception. Only these assigned containedIPdus (based on headerId) are expected
in this ContainerIPdu. If a not assigned containedIPdu is received within this ContainerIPdu this containedIPdu is discarded.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::RxAcceptContainedIPduEnum.acceptConfigured
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid

BSW Module BSW Context

IpduM IpduM/IpduMConfig/IpduMContainerRxPdu
BSW Parameter BSW Type
IpduMContainerRxHandleId ECUC-INTEGER-PARAM-DEF
BSW Description
Handle Id used by the PduR for RxIndication.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_IpduM_00187]

938 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

IpduM IpduM/IpduMConfig/IpduMContainerRxPdu
BSW Parameter BSW Type
IpduMContainerRxPduRef ECUC-REFERENCE-DEF
BSW Description
Reference to the Pdu which represents the container and is used for reception.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_IpduM_00189]

BSW Module BSW Context

IpduM IpduM/IpduMConfig/IpduMContainerRxPdu
BSW Parameter BSW Type
IpduMMainFunctionRxRef ECUC-REFERENCE-DEF
BSW Description
Reference to the IpduM_MainFunctionRx instance this container PDU belongs to.
Mandatory, if more than one IpduM_MainFunctionRx is defined.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_IpduM_00212]

BSW Module BSW Context

IpduM IpduM/IpduMConfig
BSW Parameter BSW Type
IpduMContainerTxPdu ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Configuration of a transmitted container Pdu.
Template Description

BSW Module BSW Context

IpduM IpduM/IpduMConfig/IpduMContainerTxPdu
BSW Parameter BSW Type
IpduMContainerTxFirstContainedPduTrigger ECUC-BOOLEAN-PARAM-DEF
BSW Description
Defines if the transmission of this IpduMContainerTxPdu shall be requested right after the first IpduMContainedTxPdu was
put into it.
Template Description
Defines if the transmission of the ContainerIPdu shall be requested right after the first ContainedIPdu was put into it. This
attribute shall be ignored on receiver side.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::ContainerIPdu.containerTrigger
Mapping Rule Mapping Type
TRUE if ContainerIPdu.containerTrigger = firstContainedTrigger, else FALSE. full
Mapping Status ECUC Parameter ID
valid [ECUC_IpduM_00199]

BSW Module BSW Context

IpduM IpduM/IpduMConfig/IpduMContainerTxPdu
BSW Parameter BSW Type
IpduMContainerTxHandleId ECUC-INTEGER-PARAM-DEF
BSW Description
Handle Id used by the PduR for TxConfirmation and for TriggerTransmit of the ContainerPdu.
Template Description

IpduM IpduM/IpduMConfig/IpduMContainerTxPdu
BSW Parameter BSW Type
IpduMContainerTxTriggerMode ECUC-ENUMERATION-PARAM-DEF
BSW Description
Defines whether this ContainerPdu is fetched via trigger transmit.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_IpduM_00196]

BSW Module BSW Context

IpduM IpduM/IpduMConfig/IpduMContainerTxPdu
BSW Parameter BSW Type
IpduMMainFunctionTxRef ECUC-REFERENCE-DEF
BSW Description
Reference to the IpduM_MainFunctionTx instance this container PDU belongs to.
Mandatory, if more than one IpduM_MainFunctionTx is defined.
Template Description

local
Mapping Status ECUC Parameter ID
valid [ECUC_IpduM_00217]

BSW Module BSW Context

IpduM IpduM/IpduMConfig/IpduMMainFunctionTx
BSW Parameter BSW Type
IpduMMainTxTimeBase ECUC-FLOAT-PARAM-DEF
BSW Description
5

946 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

IpduM IpduM/IpduMConfig/IpduMRxPathway/IpduMRxIndication
BSW Parameter BSW Type
IpduMRxStaticPart ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container contains the configuration for the static part of incoming RxIndication calls. On reception, the new outgoing
I-PDU for the static part is constructed as defined by the segments (defined in the IpduMStaticSegment container) and sent
out with the I-PDU ID referenced by IpduMOutgoingStaticPduRef.
Template Description
Some parts/signals of the I-PDU may be the same regardless of the selector field. Such a part is called static part. The static
part is optional.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::StaticPart
5

952 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Mapping Rule Mapping Type
Create container if StaticPart exists in the MultiplexedIPdu. full
Mapping Status ECUC Parameter ID
valid [ECUC_IpduM_00049]

BSW Module BSW Context

IpduM IpduM/IpduMConfig/IpduMRxPathway/IpduMRxIndication/IpduMRxStaticPart
BSW Parameter BSW Type
IpduMOutgoingStaticPduRef ECUC-REFERENCE-DEF
BSW Description
When the new I-PDU is sent out it is sent with this I-PDU ID. Reference to the sent Pdu representation in the ECU
Configuration Description exchange file.
Template Description

BSW Module BSW Context

IpduM IpduM/IpduMConfig/IpduMRxPathway/IpduMRxIndication/IpduMSelectorField
BSW Parameter BSW Type
IpduMSelectorFieldLength ECUC-INTEGER-PARAM-DEF
BSW Description
Length of the selector field in bits.
Template Description
The size in bits of the selector field shall be configurable in a range of 1-16 bits. In a complete System Description this
attribute is mandatory. If a MultiplexedPdu is received by a Pdu Gateway and is not delivered to the IPduM but routed directly
to a bus interface then the content of the MulitplexedPdu doesn’t need to be described in the System Extract/Ecu Extract. To
support this use case the multiplicity is set to 0..1.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::MultiplexedIPdu.selectorFieldLength
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_IpduM_00160]

BSW Module BSW Context

IpduM IpduM/IpduMConfig/IpduMRxPathway/IpduMRxIndication/IpduMSelectorField
BSW Parameter BSW Type
IpduMSelectorFieldPosition ECUC-INTEGER-PARAM-DEF
BSW Description
Selector field bit position in the multiplexed Pdu.
Range: 0..63 for CAN/ LIN I-PDUs, 0..511 for CAN FD I-PDUs, 0..2031 for FlexRay I-PDUs.
Template Description
This parameter is necessary to describe the position of the selector field within the IPdu.
Note that the absolute position of the selectorField in the MultiplexedIPdu is determined by the definition of the selectorField
ByteOrder attribute of the Multiplexed Pdu. If Big Endian is specified, the start position indicates the bit position of the most
significant bit in the IPdu. If Little Endian is specified, the start position indicates the bit position of the least significant bit in
the IPdu. In AUTOSAR the bit counting is always set to "sawtooth" and the bit order is set to "Decreasing". The bit counting in
byte 0 starts with bit 0 (least significant bit). The most significant bit in byte 0 is bit 7.
In a complete System Description this attribute is mandatory. If a MultiplexedPdu is received by a Pdu Gateway and is not
delivered to the IPduM but routed directly to a bus interface then the content of the MulitplexedPdu doesn’t need to be
described in the System Extract/Ecu Extract. To support this use case the multiplicity is set to 0..1.
5

955 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::MultiplexedIPdu.selectorFieldStartPosition
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_IpduM_00161]

BSW Module BSW Context

IpduM IpduM/IpduMConfig
BSW Parameter BSW Type
IpduMTxPathway ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Contains the configuration parameters transmitted I-PDUs by the IpduM module.
Template Description
A MultiplexedPdu (i.e. NOT a COM I-PDU) contains a DynamicPart, an optional StaticPart and a selectorField. In case of
multiplexing this IPdu is routed between the Pdu Multiplexer and the Interface Layer.
A multiplexer is used to define variable parts within an IPdu that may carry different signals. The receivers of such a IPdu can
determine which signalPdus are transmitted by evaluating the selector field, which carries a unique selector code for each
sub-part.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::MultiplexedIPdu
Mapping Rule Mapping Type
Create container for each transmitted multiplexed Ipdu (IPduTriggering that references the full
MultiplexedIPdu contains a reference to an "Out" Pdu Port.
Mapping Status ECUC Parameter ID
valid [ECUC_IpduM_00070]

BSW Module BSW Context

IpduM IpduM/IpduMConfig/IpduMTxPathway
BSW Parameter BSW Type
IpduMTxRequest ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container is used to specify the configuration for Transmit requests. There will be one instance of this container for each
I-PDU that can be requested for transmission (the outgoing I-PDUs) by the IpduM.
Template Description
A MultiplexedPdu (i.e. NOT a COM I-PDU) contains a DynamicPart, an optional StaticPart and a selectorField. In case of
multiplexing this IPdu is routed between the Pdu Multiplexer and the Interface Layer.
A multiplexer is used to define variable parts within an IPdu that may carry different signals. The receivers of such a IPdu can
determine which signalPdus are transmitted by evaluating the selector field, which carries a unique selector code for each
sub-part.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::MultiplexedIPdu
Mapping Rule Mapping Type
Create container for each transmitted multiplexed Ipdu full
Mapping Status ECUC Parameter ID
5

956 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
valid [ECUC_IpduM_00052]

IpduM IpduM/IpduMConfig/IpduMTxPathway/IpduMTxRequest
BSW Parameter BSW Type
IpduMSelectorField ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This contains the location and the length of the selector field.
5

958 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Template Description
The StaticPart and the DynamicPart can be separated in multiple segments within the multiplexed PDU.
The ISignalIPdus are copied bit by bit into the MultiplexedIPdu. If the space of the first segment is 5 bits large than the first 5
bits of the ISignalIPdu are copied into this first segment and so on.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::SegmentPosition
Mapping Rule Mapping Type
Can be derived from the segmentPosition. full
Mapping Status ECUC Parameter ID
valid [ECUC_IpduM_00054]

BSW Module BSW Context

IpduM IpduM/IpduMConfig/IpduMTxPathway/IpduMTxRequest/IpduMSelectorField
BSW Parameter BSW Type
IpduMSelectorFieldLength ECUC-INTEGER-PARAM-DEF
BSW Description
Length of the selector field in bits.
Template Description
The size in bits of the selector field shall be configurable in a range of 1-16 bits. In a complete System Description this
attribute is mandatory. If a MultiplexedPdu is received by a Pdu Gateway and is not delivered to the IPduM but routed directly
to a bus interface then the content of the MulitplexedPdu doesn’t need to be described in the System Extract/Ecu Extract. To
support this use case the multiplicity is set to 0..1.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::MultiplexedIPdu.selectorFieldLength
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_IpduM_00160]

BSW Module BSW Context

IpduM IpduM/IpduMConfig/IpduMTxPathway/IpduMTxRequest/IpduMSelectorField
BSW Parameter BSW Type
IpduMSelectorFieldPosition ECUC-INTEGER-PARAM-DEF
BSW Description
Selector field bit position in the multiplexed Pdu.
Range: 0..63 for CAN/ LIN I-PDUs, 0..511 for CAN FD I-PDUs, 0..2031 for FlexRay I-PDUs.
Template Description
5

959 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
This parameter is necessary to describe the position of the selector field within the IPdu.
Note that the absolute position of the selectorField in the MultiplexedIPdu is determined by the definition of the selectorField
ByteOrder attribute of the Multiplexed Pdu. If Big Endian is specified, the start position indicates the bit position of the most
significant bit in the IPdu. If Little Endian is specified, the start position indicates the bit position of the least significant bit in
the IPdu. In AUTOSAR the bit counting is always set to "sawtooth" and the bit order is set to "Decreasing". The bit counting in
byte 0 starts with bit 0 (least significant bit). The most significant bit in byte 0 is bit 7.
In a complete System Description this attribute is mandatory. If a MultiplexedPdu is received by a Pdu Gateway and is not
delivered to the IPduM but routed directly to a bus interface then the content of the MulitplexedPdu doesn’t need to be
described in the System Extract/Ecu Extract. To support this use case the multiplicity is set to 0..1.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::MultiplexedIPdu.selectorFieldStartPosition
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_IpduM_00161]

BSW Module BSW Context

IpduM IpduM/IpduMConfig/IpduMTxPathway/IpduMTxRequest
BSW Parameter BSW Type
IpduMTxConfirmationPduId ECUC-INTEGER-PARAM-DEF
BSW Description
Handle Id used by the PduR for confirmation (IpduM_TxConfirmation)<b> </b>and for TriggerTransmit (IpduM_Trigger
Transmit). The existence of this parameter is essential for the PduR generation tool to actually find a symbolicNameValue for
the OutgoingPdu.
Template Description

IpduM IpduM/IpduMConfig/IpduMTxPathway/IpduMTxRequest/IpduMTxDynamicPart
BSW Parameter BSW Type
IpduMTxDynamicHandleId ECUC-INTEGER-PARAM-DEF
BSW Description
This defines an incoming handle id. When the handle of an incoming Tx Request matches this id, the configured dynamic
segments are copied and the IpduMTxTriggerMode is honored.
5

961 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_IpduM_00127]

BSW Module BSW Context

IpduM IpduM/IpduMConfig/IpduMTxPathway/IpduMTxRequest/IpduMTxDynamicPart
BSW Parameter BSW Type
IpduMTxDynamicPduRef ECUC-REFERENCE-DEF
BSW Description
Reference to the Pdu representation in the ECU Configuration Description exchange file to be transmitted.
Template Description

BSW Module BSW Context

IpduM IpduM/IpduMConfig/IpduMTxPathway/IpduMTxRequest/IpduMTxStaticPart
BSW Parameter BSW Type
IpduMJitUpdate ECUC-BOOLEAN-PARAM-DEF
BSW Description
If configured to true fetch the data of this part Just-In-Time via the triggerTransmit API of the PduR.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_IpduM_00167]

BSW Module BSW Context

IpduM IpduM/IpduMConfig/IpduMTxPathway/IpduMTxRequest/IpduMTxStaticPart
BSW Parameter BSW Type
IpduMTxStaticConfirmation ECUC-BOOLEAN-PARAM-DEF
BSW Description
A transmit request can be confirmed by the lower layer. If this parameter is set to true a confirmation of the I-PDU in COM
representing the static part is generated.
Template Description

M2 Parameter

IpduM IpduM/IpduMConfig/IpduMTxPathway/IpduMTxRequest
BSW Parameter BSW Type
IpduMTxStaticSegment ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
The static part of the multiplexed outgoing I-Pdu (referenced by IpduMOutgoingPduRef) can be separated into several
segments. For each segment one IpduMTxStaticSegment container shall be created that contains the location and the length
of the segment.
Please note that each segment in the source I-Pdu that is referenced in the IpduMTxStaticPart container will be copied to the
same location in the multiplexed outgoing I-Pdu.
Template Description
The StaticPart and the DynamicPart can be separated in multiple segments within the multiplexed PDU.
The ISignalIPdus are copied bit by bit into the MultiplexedIPdu. If the space of the first segment is 5 bits large than the first 5
bits of the ISignalIPdu are copied into this first segment and so on.
5

965 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_IpduM_00130]

BSW Module BSW Context

IpduM IpduM/IpduMGeneral
BSW Parameter BSW Type
IpduMContainedTxPduPriorityHandling ECUC-BOOLEAN-PARAM-DEF
BSW Description
This parameter enables/disables handling of priority for IpduMContainedTxPdu’s with IpduMContainedTxPduCollection
Semantics IPDUM_LAST_IS_BEST. true: enabled false: disabled
Template Description

M2 Parameter
5

967 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Mapping Rule Mapping Type
local
Mapping Status ECUC Parameter ID
valid [ECUC_IpduM_00209]

BSW Module BSW Context

IpduM IpduM/IpduMGeneral
BSW Parameter BSW Type
IpduMDevErrorDetect ECUC-BOOLEAN-PARAM-DEF
BSW Description
Switches the development error detection and notification on or off.
• true: detection and notification is enabled.
• false: detection and notification is disabled.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_IpduM_00132]

970 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Mapping Status ECUC Parameter ID
valid [ECUC_IpduM_00141]

BSW Module BSW Context

IpduM IpduM/IpduMPublishedInformation
BSW Parameter BSW Type
IpduMRxDirectComInvocation ECUC-BOOLEAN-PARAM-DEF
BSW Description
If set to TRUE the COM invocation optimization as defined in IPDUM140 is implemented.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_IpduM_00142]

C.1.4 SecOc Mapping

BSW Module BSW Context

SecOC SecOC
BSW Parameter BSW Type
SecOCGeneral ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Contains the general configuration parameters of the SecOC module.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_SecOC_-
00002]

BSW Module BSW Context

SecOC SecOC/SecOCGeneral
BSW Parameter BSW Type
SecOCDefaultAuthenticationInformationPattern ECUC-INTEGER-PARAM-DEF
BSW Description
5

971 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
The parameter describes the behaviour of SecOC when authentication build counter has reached the configuration value Sec
OCAuthenticationBuildAttempts, or the query of the freshness function returns E_NOT_OK or the calculation of the
authenticator has returned a non-recoverable error such as returning E_NOT_OK or KEY_FAILURE. If the configuration
parameter is not present, SecOC module shall remove the Authentic I-PDU from its internal buffer and cancel the
transmission request If the configuration parameter is present, SecOC will use this value for each byte of Freshness Value
and Authenticator when building the Authentication Information, and will not cancel the transmission request.
Template Description

Mapping Status ECUC Parameter ID

valid [ECUC_SecOC_-
00114]

BSW Module BSW Context

SecOC SecOC/SecOCGeneral
BSW Parameter BSW Type
SecOCIgnoreVerificationResult ECUC-BOOLEAN-PARAM-DEF
BSW Description
The result of the authentication process (e.g. MAC Verify) is ignored after the first try and the SecOC proceeds like the result
was a success. The calculation of the authenticator is still done, only its result will be ignored.
• true: enabled (verification result is ignored).
• false: disabled (verification result is NOT ignored).
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_SecOC_-
00052]

BSW Module BSW Context

SecOC SecOC/SecOCGeneral
BSW Parameter BSW Type
SecOCMaxAlignScalarType ECUC-STRING-PARAM-DEF
BSW Description
The scalar type which has the maximum alignment restrictions on the given platform. This type can be e.g. uint8, uint16 or
uint32.
Template Description

M2 Parameter

973 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Mapping Rule Mapping Type
local
Mapping Status ECUC Parameter ID
valid [ECUC_SecOC_-
00047]

BSW Module BSW Context

SecOC SecOC/SecOCGeneral
BSW Parameter BSW Type
SecOCOverrideStatusWithDataId ECUC-BOOLEAN-PARAM-DEF
BSW Description
This option defines if the parameter "ValueId" of the function SecOC_VerifyStatusOverride() accepts the freshness value (as
a collection of one or more Secured I-PDUs to freshness) or the dataID for individual Secured I-PDUs.
• true: Function SecOC_VerifyStatusOverride accepts SecOCDataId as parameter.
• false: Function SecOC_VerifyStatusOverride accepts SecOCFreshnessValueId as parameter.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_SecOC_-
00099]

BSW Module BSW Context

SecOC SecOC/SecOCGeneral
BSW Parameter BSW Type
SecOCPropagateOnlyFinalVerificationStatus ECUC-BOOLEAN-PARAM-DEF
BSW Description
This parameter Is used to specify if the verification status shall be reported only after the final determination of the verification
status (TRUE) or on every verification attempt (FALSE).
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_SecOC_-
00117]

975 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

SecOC SecOC/SecOCGeneral/SecOCSecurityEventRefs
BSW Parameter BSW Type
SECOC_SEV_MAC_VERIFICATION_FAILED ECUC-REFERENCE-DEF
BSW Description
MAC verification of a received PDU failed.
Template Description

System Template
AUTOSAR CP R21-11

4
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::SecureCommunicationProps.authenticationBuildAttempts
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_SecOC_-
00079]

BSW Module BSW Context

SecOC SecOC/SecOCRxPduProcessing
BSW Parameter BSW Type
SecOCAuthenticationVerifyAttempts ECUC-INTEGER-PARAM-DEF
BSW Description
This parameter specifies the number of authentication verify attempts that are to be carried out when the verification of the
authentication information failed for a given Secured I-PDU. If zero is set, then only one authentication verification attempt is
done.
Template Description
This attribute defines the additional number of authentication attempts that are to be carried out when the generation of the
authentication information failed for a given SecuredIPdu. If zero is set than only one authentication attempt is done.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::SecureCommunicationProps.authenticationRetries
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_SecOC_-
00080]

BSW Module BSW Context

SecOC SecOC/SecOCRxPduProcessing
BSW Parameter BSW Type
SecOCClientServerVerificationStatusPropagationMode ECUC-ENUMERATION-PARAM-DEF
BSW Description
This parameter is used to determine the propagation of the verification status through the client/server interface to an SW-C.
Template Description

M2 Parameter

Mapping Rule Mapping Type

4
1:1 mapping full
Mapping Status ECUC Parameter ID
valid

BSW Module BSW Context

SecOC SecOC/SecOCRxPduProcessing
BSW Parameter BSW Type
SecOCFreshnessValueId ECUC-INTEGER-PARAM-DEF
BSW Description
This parameter defines the Id of the Freshness Value. The Freshness Value might be a normal counter or a time value.
Template Description
This attribute defines the Id of the Freshness Value. The Freshness Value might be a normal counter or a time value.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::SecureCommunicationProps.freshnessValueId
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid

BSW Module BSW Context

SecOC SecOC/SecOCRxPduProcessing
BSW Parameter BSW Type
SecOCFreshnessValueLength ECUC-INTEGER-PARAM-DEF
BSW Description
This parameter defines the complete length in bits of the Freshness Value. As long as the key doesn’t change the counter
shall not overflow. The length of the counter shall be determined based on the expected life time of the corresponding key
and frequency of usage of the counter.
Template Description
This attribute defines the complete length in bits of the Freshness Value. As long as the key doesn’t change the counter shall
not overflow. The length of the counter shall be determined based on the expected life time of the corresponding key and
frequency of usage of the counter.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::SecureCommunicationFreshnessProps.
freshnessValueLength
Mapping Rule Mapping Type
1:1 mapping if value is set by SecureCommunicationFreshnessProps.freshnessValueLength. If the full
attribute is not set to a value the parameter value of 0 shall be assumed which means that no
Freshness Value is included in the Secured I-PDU.
Mapping Status ECUC Parameter ID
valid

BSW Module BSW Context

SecOC SecOC/SecOCRxPduProcessing
5

983 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
BSW Parameter BSW Type
SecOCFreshnessValueTruncLength ECUC-INTEGER-PARAM-DEF
BSW Description
This parameter defines the length in bits of the Freshness Value to be included in the payload of the Secured I-PDU. This
length is specific to the least significant bits of the complete Freshness Counter. If the parameter is 0 no Freshness Value is
included in the Secured I-PDU.
Template Description
This attribute defines the length in bits of the Freshness Value to be included in the payload of the Secured I-PDU. This length
is specific to the least significant bits of the complete Freshness Counter. If the attribute is 0 no Freshness Value is included
in the Secured I-PDU.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::SecureCommunicationFreshnessProps.
freshnessValueTxLength
Mapping Rule Mapping Type
1:1 mapping if value is set by SecureCommunicationFreshnessProps.freshnessValueTxLength. If full
the attribute is not set to a value the parameter value of 0 shall be assumed which means that no
Freshness Value is included in the Secured I-PDU.
Mapping Status ECUC Parameter ID
valid

BSW Module BSW Context

SecOC SecOC/SecOCRxPduProcessing
BSW Parameter BSW Type
SecOCReceptionOverflowStrategy ECUC-ENUMERATION-PARAM-DEF
BSW Description
This parameter defines the overflow strategy for receiving PDUs
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_SecOC_-
00076]

BSW Module BSW Context

SecOC SecOC/SecOCRxPduProcessing
BSW Parameter BSW Type
SecOCReceptionQueueSize ECUC-INTEGER-PARAM-DEF
BSW Description
This parameter defines the queue size in case the overflow strategy for receiving PDUs is set to QUEUE.
Template Description

M2 Parameter

Mapping Rule Mapping Type

984 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
local
Mapping Status ECUC Parameter ID
valid [ECUC_SecOC_-
00077]

BSW Module BSW Context

SecOC SecOC/SecOCRxPduProcessing
BSW Parameter BSW Type
SecOCRxAuthServiceConfigRef ECUC-REFERENCE-DEF
BSW Description
This reference is used to define which crypto service function is called for authentication. If PDUs with a dynamic length are
used (e.g. CanTP or Dynamic Length PDUs) a MAC algorithm has to be chosen, that is not vulnerable to length extension
attack (e.g. CMAC/HMAC).
Template Description
This reference identifies the crypto profile applicable to the usage (send, receive) of the also referenced SecuredIPdu.
Obviously, this reference is only applicable if the Pdutriggering also references a SecuredIPdu in the role iPdu.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::PduTriggering.secOcCryptoMapping
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_SecOC_-
00048]

BSW Module BSW Context

SecOC SecOC/SecOCRxPduProcessing
BSW Parameter BSW Type
SecOCRxAuthenticPduLayer ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container specifies the Pdu that is transmitted by the SecOC module to the PduR after the Mac was verified.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_SecOC_-
00044]

System Template
AUTOSAR CP R21-11

4
SystemTemplate::Fibex::FibexCore::CoreCommunication::SecureCommunicationProps.securedAreaLength
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_SecOC_-
00091]

BSW Module BSW Context

SecOC SecOC/SecOCRxPduProcessing/SecOCRxPduSecuredArea
BSW Parameter BSW Type
SecOCSecuredRxPduOffset ECUC-INTEGER-PARAM-DEF
BSW Description
This parameter defines the start position (offset in bytes) of the area within the Pdu which is secured
Template Description
This attribute defines the start position (offset in byte) of the area within the payload Pdu which will be secured.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::SecureCommunicationProps.securedAreaOffset
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_SecOC_-
00090]

BSW Module BSW Context

SecOC SecOC/SecOCRxPduProcessing
BSW Parameter BSW Type
SecOCRxSecuredPduLayer ECUC-CHOICE-CONTAINER-DEF
BSW Description
This container specifies the Pdu that is received by the SecOC module from the PduR. For this Pdu the Mac verification is
provided.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_SecOC_-
00041]

BSW Module BSW Context

SecOC SecOC/SecOCRxPduProcessing/SecOCRxSecuredPduLayer
BSW Parameter BSW Type
5

988 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

SecOC SecOC/SecOCRxPduProcessing/SecOCRxSecuredPduLayer/SecOCRxSecuredPdu
BSW Parameter BSW Type
SecOCRxSecuredLayerPduRef ECUC-REFERENCE-DEF
BSW Description
Reference to the global Pdu.
Template Description

M2 Parameter

Mapping Rule Mapping Type

993 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
local
Mapping Status ECUC Parameter ID
valid [ECUC_SecOC_-
00065]

BSW Module BSW Context

SecOC SecOC/SecOCRxPduProcessing/SecOCRxSecuredPduLayer/SecOCRxSecuredPduCollection/
SecOCRxCryptographicPdu
BSW Parameter BSW Type
SecOCRxCryptographicPduRef ECUC-REFERENCE-DEF
BSW Description
Reference to the global Pdu.
Template Description
Reference to a Pdu that will be protected against unauthorized manipulation and replay attacks.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::SecuredIPdu.payload
Mapping Rule Mapping Type
Reference to the EcuC Pdu which represents the received Cryptographic SecuredIPdu Pdu full
Triggering
Mapping Status ECUC Parameter ID
valid [ECUC_SecOC_-
00066]

BSW Module BSW Context

SecOC SecOC/SecOCRxPduProcessing/SecOCRxSecuredPduLayer/SecOCRxSecuredPduCollection
BSW Parameter BSW Type
SecOCSecuredRxPduVerification ECUC-BOOLEAN-PARAM-DEF
BSW Description
This parameter defines whether the signature authentication or MAC verification shall be performed on this Secured I-PDU. If
set to false, the SecOC module extracts the Authentic I-PDU from the Secured I-PDU without verification.
Template Description
This attribute defines the bypassing of signature authentication or MAC verification in the receiving ECU. If not defined or set
to true the signature authentication or MAC verification shall be performed for the SecuredIPdu. If set to false the signature
authentication or MAC verification shall not be performed for the SecuredIPdu.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::IPduPort.rxSecurityVerification
Mapping Rule Mapping Type
SecOCSecuredRxPduVerification is true if rxSecurityVerification is not defined, otherwise Sec full
OCSecuredRxPduVerification = rxSecurityVerification.
Mapping Status ECUC Parameter ID
valid [ECUC_SecOC_-
00092]

994 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

SecOC SecOC/SecOCRxPduProcessing/SecOCRxSecuredPduLayer/SecOCRxSecuredPduCollection
BSW Parameter BSW Type
SecOCUseMessageLink ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
SecOC links an Authentic I-PDU and Cryptographic I-PDU together by repeating a specific part (Message Linker) of the
Authentic I-PDU in the Cryptographic I-PDU.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_SecOC_-
00074]

BSW Module BSW Context

SecOC SecOC/SecOCRxPduProcessing/SecOCRxSecuredPduLayer/SecOCRxSecuredPduCollection/
SecOCUseMessageLink
BSW Parameter BSW Type
SecOCMessageLinkLen ECUC-INTEGER-PARAM-DEF
BSW Description
Length of the Message Linker inside the Authentic I-PDU in bits.
Template Description
SecOC links an AuthenticIPdu and CryptographicIPdu together by repeating a specific part (Message Linker) of the Authentic
IPdu in the CryptographicIPdu. This attribute defines the length in bits of the messageLinker.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::SecureCommunicationProps.messageLinkLength
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_SecOC_-
00060]

BSW Module BSW Context

SecOC SecOC/SecOCRxPduProcessing/SecOCRxSecuredPduLayer/SecOCRxSecuredPduCollection/
SecOCUseMessageLink
BSW Parameter BSW Type
SecOCMessageLinkPos ECUC-INTEGER-PARAM-DEF
BSW Description
The position of the Message Linker inside the Authentic I-PDU in bits.
The bit counting is done according to 01068 and the bit ordering is done according to TPS_SYST_01069.
Template Description
5

995 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
SecOC links an AuthenticIPdu and CryptographicIPdu together by repeating a specific part (Message Linker) of the Authentic
IPdu in the CryptographicIPdu. This attribute defines the startPosition in bits of the messageLinker.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::SecureCommunicationProps.messageLinkPosition
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_SecOC_-
00059]

BSW Module BSW Context

SecOC SecOC/SecOCRxPduProcessing
BSW Parameter BSW Type
SecOCSameBufferPduRef ECUC-REFERENCE-DEF
BSW Description
This reference is used to collect Pdus that are using the same SecOC buffer.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid

BSW Module BSW Context

SecOC SecOC/SecOCTxPduProcessing
BSW Parameter BSW Type
SecOCFreshnessValueLength ECUC-INTEGER-PARAM-DEF
BSW Description
This parameter defines the complete length in bits of the Freshness Value. As long as the key doesn’t change the counter
shall not overflow. The length of the counter shall be determined based on the expected life time of the corresponding key
and frequency of usage of the counter.
Template Description
This attribute defines the complete length in bits of the Freshness Value. As long as the key doesn’t change the counter shall
not overflow. The length of the counter shall be determined based on the expected life time of the corresponding key and
frequency of usage of the counter.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::SecureCommunicationFreshnessProps.
freshnessValueLength
Mapping Rule Mapping Type
1:1 mapping if value is set by SecureCommunicationFreshnessProps.freshnessValueLength. If the full
attribute is not set to a value the parameter value of 0 shall be assumed which means that no
Freshness Value is included in the Secured I-PDU.
Mapping Status ECUC Parameter ID
valid

BSW Module BSW Context

SecOC SecOC/SecOCTxPduProcessing
BSW Parameter BSW Type
SecOCFreshnessValueTruncLength ECUC-INTEGER-PARAM-DEF
BSW Description
This parameter defines the length in bits of the Freshness Value to be included in the payload of the Secured I-PDU. This
length is specific to the least significant bits of the complete Freshness Counter. If the parameter is 0 no Freshness Value is
included in the Secured I-PDU.
Template Description
This attribute defines the length in bits of the Freshness Value to be included in the payload of the Secured I-PDU. This length
is specific to the least significant bits of the complete Freshness Counter. If the attribute is 0 no Freshness Value is included
in the Secured I-PDU.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::SecureCommunicationFreshnessProps.
freshnessValueTxLength
Mapping Rule Mapping Type
1:1 mapping if value is set by SecureCommunicationFreshnessProps.freshnessValueTxLength. If full
the attribute is not set to a value the parameter value of 0 shall be assumed which means that no
Freshness Value is included in the Secured I-PDU.
Mapping Status ECUC Parameter ID
5

1000 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
valid

BSW Module BSW Context

SecOC SecOC/SecOCTxPduProcessing
BSW Parameter BSW Type
SecOCProvideTxTruncatedFreshnessValue ECUC-BOOLEAN-PARAM-DEF
BSW Description
This parameter specifies if the Tx query freshness function provides the truncated freshness info instead of generating this by
SecOC In this case, SecOC shall add this data to the Authentic PDU instead of truncating the freshness value.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_SecOC_-
00084]

BSW Module BSW Context

SecOC SecOC/SecOCTxPduProcessing
BSW Parameter BSW Type
SecOCReAuthenticateAfterTriggerTransmit ECUC-BOOLEAN-PARAM-DEF
BSW Description
This parameter specifies if the authentication information of the Secured PDU is updated after the successful transmission of
a triggered transmission was confirmed.
TRUE if the authentication information shall be updated after triggered transmission. FALSE if the authentication information
shall not be updated after triggered transmission.
Note: This parameter should only be set to FALSE if the upper layer SecOC_IfTransmit have the same or a higher frequency
than the SecOC_TriggerTransmit calls.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_SecOC_-
00103]

BSW Module BSW Context

SecOC SecOC/SecOCTxPduProcessing
BSW Parameter BSW Type
SecOCSameBufferPduRef ECUC-REFERENCE-DEF
BSW Description
5

1001 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
This reference is used to collect Pdus that are using the same SecOC buffer.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid

BSW Module BSW Context

SecOC SecOC/SecOCTxPduProcessing
BSW Parameter BSW Type
SecOCTxAuthServiceConfigRef ECUC-REFERENCE-DEF
BSW Description
This reference is used to define which crypto service function is called for authentication. If PDUs with a dynamic length are
used (e.g. CanTP or Dynamic Length PDUs) a MAC algorithm has to be chosen, that is not vulnerable to length extension
attack (e.g. CMAC/HMAC).
Template Description
This reference identifies the crypto profile applicable to the usage (send, receive) of the also referenced SecuredIPdu.
Obviously, this reference is only applicable if the Pdutriggering also references a SecuredIPdu in the role iPdu.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::PduTriggering.secOcCryptoMapping
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_SecOC_-
00013]

BSW Module BSW Context

SecOC SecOC/SecOCTxPduProcessing
BSW Parameter BSW Type
SecOCTxAuthenticPduLayer ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container specifies the Pdu that is received by the SecOC module from the PduR. For this Pdu the Mac generation is
provided.
Template Description

M2 Parameter

SecOC SecOC/SecOCTxPduProcessing/SecOCTxAuthenticPduLayer
BSW Parameter BSW Type
SecOCTxAuthenticLayerPduRef ECUC-REFERENCE-DEF
BSW Description
Reference to the global Pdu.
Template Description
Reference to a Pdu that will be protected against unauthorized manipulation and replay attacks.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::SecuredIPdu.payload
Mapping Rule Mapping Type
Reference to the EcuC Pdu which represents the to be secured SecuredIPdu PduTriggering full
5

1003 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Mapping Status ECUC Parameter ID
valid [ECUC_SecOC_-
00025]

BSW Module BSW Context

SecOC SecOC/SecOCTxPduProcessing
BSW Parameter BSW Type
SecOCTxPduMainFunctionRef ECUC-REFERENCE-DEF
BSW Description
Reference to the SecOC_MainFunctionTx this PDU belongs to. Mandatory, if multiple main functions are defined.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_SecOC_-
00111]

BSW Module BSW Context

SecOC SecOC/SecOCTxPduProcessing
BSW Parameter BSW Type
SecOCTxPduSecuredArea ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container specifies an area in the Authentic I-Pdu that will be the input to the Authenticator generation algorithm. If this
container does not exist in the configuration the complete Authentic I-Pdu will be the input to the Authenticator generation
algorithm.
Template Description
This attribute defines the start position (offset in byte) of the area within the payload Pdu which will be secured.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::SecureCommunicationProps.securedAreaOffset
Mapping Rule Mapping Type
Create container if the securedAreaOffset and securedAreaLength is defined for the SecuredIPdu full
in the System Description.
Mapping Status ECUC Parameter ID
valid [ECUC_SecOC_-
00086]

BSW Module BSW Context

SecOC SecOC/SecOCTxPduProcessing/SecOCTxPduSecuredArea
BSW Parameter BSW Type
SecOCSecuredTxPduLength ECUC-INTEGER-PARAM-DEF
BSW Description
5

1004 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
This parameter defines the length (in bytes) of the area within the Pdu which shall be secured
Template Description
This attribute defines the length in bytes of the area within the payload Pdu which will be secured.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::SecureCommunicationProps.securedAreaLength
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_SecOC_-
00088]

BSW Module BSW Context

SecOC SecOC/SecOCTxPduProcessing/SecOCTxPduSecuredArea
BSW Parameter BSW Type
SecOCSecuredTxPduOffset ECUC-INTEGER-PARAM-DEF
BSW Description
This parameter defines the start position (offset in bytes) of the area within the Pdu which shall be secured
Template Description
This attribute defines the start position (offset in byte) of the area within the payload Pdu which will be secured.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::SecureCommunicationProps.securedAreaOffset
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_SecOC_-
00087]

BSW Module BSW Context

SecOC SecOC/SecOCTxPduProcessing
BSW Parameter BSW Type
SecOCTxPduUnusedAreasDefault ECUC-INTEGER-PARAM-DEF
BSW Description
The AUTOSAR SecOC module fills not used areas of a transmitted Secured Pdu or a transmitted Cryptographic Pdu with this
byte pattern. This attribute is mandatory to avoid undefined behavior.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_SecOC_-
00101]

1005 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

SecOC SecOC/SecOCTxPduProcessing
BSW Parameter BSW Type
SecOCTxSecuredPduLayer ECUC-CHOICE-CONTAINER-DEF
BSW Description
This container specifies the Pdu that is transmitted by the SecOC module to the PduR after the Mac was generated.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_SecOC_-
00024]

BSW Module BSW Context

SecOC SecOC/SecOCTxPduProcessing/SecOCTxSecuredPduLayer
BSW Parameter BSW Type
SecOCTxSecuredPdu ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container specifies one Pdu that is transmitted by the SecOC module to the PduR after the Mac was generated. This
Pdu contains the cryptographic information.
Template Description
If this attribute is set to true the SecuredIPdu contains the Authentication Information for an AuthenticIPdu that is transmitted
in a separate message. The AuthenticIPdu contains the original payload, i.e. the secured data.
If this attribute is set to false this SecuredIPdu contains the payload of an Authentic IPdu supplemented by additional
Authentication Information.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::SecuredIPdu.useAsCryptographicIPdu
Mapping Rule Mapping Type
Create the SecOCTxSecuredPdu if the SecuredIPdu is sent by the regarded ECU and the attribute full
useAsCryptographicIPdu = false or not defined
Mapping Status ECUC Parameter ID
valid [ECUC_SecOC_-
00070]

BSW Module BSW Context

SecOC SecOC/SecOCTxPduProcessing/SecOCTxSecuredPduLayer/SecOCTxSecuredPdu
BSW Parameter BSW Type
SecOCAuthPduHeaderLength ECUC-INTEGER-PARAM-DEF
BSW Description
This parameter indicates the length (in bytes) of the Secured I-PDU Header in the Secured I-PDU. The length of zero means
there’s no header in the PDU.
5

1006 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Template Description
This attribute defines the size of the header which is inserted into the SecuredIPdu. If this attribute is set to anything but no
Header, the SecuredIPdu contains the Secured I-PDU Header to indicate the length of the AuthenticIPdu. The AuthenticIPdu
contains the original payload, i.e. the secured data.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::SecuredIPdu.useSecuredPduHeader
Mapping Rule Mapping Type
The SecOCAuthPduHeaderLength value shall be derived from useSecuredPduHeader in the full
following way: If useSecuredIPduHeader is set to "noHeader" the value shall be 0. If useSecured
IPduHeader is set to "securedPduHeader08Bit" the value shall be 1. If useSecuredIPduHeader is
set to "securedPduHeader16Bit" the value shall be 2. If useSecuredIPduHeader is set to "secured
PduHeader32Bit" the value shall be 4.
Mapping Status ECUC Parameter ID
valid [ECUC_SecOC_-
00093]

BSW Module BSW Context

SecOC SecOC/SecOCTxPduProcessing/SecOCTxSecuredPduLayer/SecOCTxSecuredPdu
BSW Parameter BSW Type
SecOCTxSecuredLayerPduId ECUC-INTEGER-PARAM-DEF
BSW Description
PDU identifier assigned by SecOC module. Used by PduR for confirmation (SecOC_[If|Tp]TxConfirmation) and for Trigger
Transmit.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_SecOC_-
00028]

BSW Module BSW Context

SecOC SecOC/SecOCTxPduProcessing/SecOCTxSecuredPduLayer/SecOCTxSecuredPdu
BSW Parameter BSW Type
SecOCTxSecuredLayerPduRef ECUC-REFERENCE-DEF
BSW Description
Reference to the global Pdu.
Template Description

M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::PduTriggering.iPdu
Mapping Rule Mapping Type
Reference to the EcuC Pdu which represents the sent SecuredIPdu PduTriggering full
Mapping Status ECUC Parameter ID
5

1007 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_PduR_00340]

BSW Module BSW Context

PduR PduR/PduRBswModules
BSW Parameter BSW Type
PduRCancelTransmit ECUC-BOOLEAN-PARAM-DEF
BSW Description
Specifies if the BSW module supports the CancelTransmit API or not. Value true the API is supported.
Template Description

M2 Parameter

PduR PduR/PduRBswModules
BSW Parameter BSW Type
PduRLowerModule ECUC-BOOLEAN-PARAM-DEF
BSW Description
5

1015 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

local
Mapping Status ECUC Parameter ID
valid [ECUC_PduR_00361]

1017 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

PduR PduR/PduRBswModules
BSW Parameter BSW Type
PduRTpTxConfirmation ECUC-BOOLEAN-PARAM-DEF
BSW Description
Specifies if the Transport protocol module supports the TpTxConfirmation API or not. Value true the API is supported.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_PduR_00363]

BSW Module BSW Context

PduR PduR/PduRBswModules
BSW Parameter BSW Type
PduRTransmit ECUC-BOOLEAN-PARAM-DEF
BSW Description
Specifies if BSW module supports the (IF) Transmit API or not. Value true the API is supported.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_PduR_00357]

BSW Module BSW Context

PduR PduR/PduRBswModules
BSW Parameter BSW Type
PduRTransportProtocol ECUC-BOOLEAN-PARAM-DEF
BSW Description
The PDU Router module shall use the API parameters specified for transport protocol interface.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_PduR_00312]

1018 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Mapping Rule Mapping Type
local
Mapping Status ECUC Parameter ID
valid [ECUC_PduR_00338]

BSW Module BSW Context

PduR PduR
BSW Parameter BSW Type
PduRGeneral ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container is a subcontainer of PduR and specifies the general configuration parameters of the PDU Router.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_PduR_00305]

BSW Module BSW Context

PduR PduR/PduRGeneral
BSW Parameter BSW Type
PduRDevErrorDetect ECUC-BOOLEAN-PARAM-DEF
BSW Description
Switches the development error detection and notification on or off.
• true: detection and notification is enabled.
• false: detection and notification is disabled.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_PduR_00302]

BSW Module BSW Context

PduR PduR/PduRGeneral
BSW Parameter BSW Type
PduRMetaDataSupport ECUC-BOOLEAN-PARAM-DEF
BSW Description
5

1020 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

PduR PduR
5

1021 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

M2 Parameter

1024 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Mapping Rule Mapping Type
local
Mapping Status ECUC Parameter ID
valid [ECUC_PduR_00339]

BSW Module BSW Context

PduR PduR/PduRRoutingPaths
BSW Parameter BSW Type
PduRMaxRoutingPathCnt ECUC-INTEGER-PARAM-DEF
BSW Description
Maximum number of RoutingPaths in all RoutingTables. This parameter is needed only in case of post-build loadable
implementation using static memory allocation.
Template Description

M2 Parameter

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

PduR PduR/PduRRoutingPaths/PduRRoutingPath
BSW Parameter BSW Type
PduRDestBufferRef ECUC-REFERENCE-DEF
BSW Description
Reference to a buffer in the PduR. This buffer is required for communication interface gatewaying, and for transport protocol
gatewaying or for fan-in reception routing for communication interface modules.
Template Description

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_PduR_00356]

1028 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

PduR PduR/PduRRoutingPaths/PduRRoutingPath
BSW Parameter BSW Type
PduRRoutingPathGroupRef ECUC-REFERENCE-DEF
BSW Description
Reference to routing paths.
Template Description

M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::PdurIPduGroup.iPdu
Mapping Rule Mapping Type
If the PduTriggering this PduRRoutingPath is derived from is the target of a PdurIPduGroup.iPdu full
reference then a PduRRoutingPathGroupRef shall be created at the PduRRoutingPath and the
respective PduRRoutingPathGroup shall be referenced from the PduRRoutingPathGroupRef.
Mapping Status ECUC Parameter ID
valid [ECUC_PduR_00352]

BSW Module BSW Context

PduR PduR/PduRRoutingPaths/PduRRoutingPath
BSW Parameter BSW Type
PduRSrcPduRRef ECUC-REFERENCE-DEF
BSW Description

Template Description

M2 Parameter

System Template
AUTOSAR CP R21-11

4
CanNmCluster:
Can specific NmCluster attributes
FlexrayNmCluster:
FlexRay specific NM cluster attributes.
UdpNmCluster:
Udp specific NmCluster attributes
M2 Parameter
SystemTemplate::NetworkManagement::CanNmCluster, SystemTemplate::NetworkManagement::FlexrayNmCluster,
SystemTemplate::NetworkManagement::UdpNmCluster
Mapping Rule Mapping Type
Bus Type can be derived from the BusNm Configuration in the System Description. full
Mapping Status ECUC Parameter ID
valid [ECUC_Nm_00218]

BSW Module BSW Context

Nm Nm/NmChannelConfig/NmBusType
BSW Parameter BSW Type
NmGenericBusNmConfig ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description

Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_Nm_00225]

BSW Module BSW Context

Nm Nm/NmChannelConfig/NmBusType/NmGenericBusNmConfig
BSW Parameter BSW Type
NmGenericBusNmPrefix ECUC-STRING-PARAM-DEF
BSW Description
The prefix which identifies the generic <BusNm>. This will be used to determine the API name to be called by Nm for the
provided interfaces of the <BusNm>. This string will used for the module prefix before the "_" character in the API call name.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_Nm_00219]

1034 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

Nm Nm/NmChannelConfig/NmBusType/NmGenericBusNmConfig
BSW Parameter BSW Type
NmGenericBusNmShutdownTime ECUC-FLOAT-PARAM-DEF
BSW Description
This parameter shall be used to calculate shutdown delay time.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_Nm_00239]

BSW Module BSW Context

Nm Nm/NmChannelConfig/NmBusType
BSW Parameter BSW Type
NmStandardBusNmConfig ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description

Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_Nm_00226]

BSW Module BSW Context

Nm Nm/NmChannelConfig/NmBusType/NmStandardBusNmConfig
BSW Parameter BSW Type
NmStandardBusType ECUC-ENUMERATION-PARAM-DEF
BSW Description
Identifies the bus type of the channel for standard AUTOSAR <BusNm>s and is used to determine which set of API calls to
be called by Nm for the <BusNm>s. Note: The Ethernet bus’ NM is UdpNm !
Template Description

Nm Nm/NmChannelConfig
BSW Parameter BSW Type
NmPnEnabled ECUC-BOOLEAN-PARAM-DEF
BSW Description
If this parameter is true, then this NM channel supports Partial Networking.
Template Description
Defines whether this NmCluster contributes to the partial network mechanism.
M2 Parameter
SystemTemplate::NetworkManagement::NmCluster.nmPncParticipation
Mapping Rule Mapping Type
Set to true if the NmCluster has nmPncParticipation set to true. full
Mapping Status ECUC Parameter ID
valid [ECUC_Nm_00254]

BSW Module BSW Context

Nm Nm/NmChannelConfig
BSW Parameter BSW Type
NmPnEraCalcEnabled ECUC-BOOLEAN-PARAM-DEF
BSW Description
Specifies if NmIf calculates the PN request information for external requests. (ERA)
Template Description
Defines whether this NmCluster contributes to the partial network mechanism.
5

1038 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
M2 Parameter
SystemTemplate::NetworkManagement::NmCluster.nmPncParticipation
Mapping Rule Mapping Type
Set to true if at least one NmCluster has nmPncParticipation set to true. full
Mapping Status ECUC Parameter ID
valid [ECUC_Nm_00259]

BSW Module BSW Context

Nm Nm/NmChannelConfig
BSW Parameter BSW Type
NmPnFilterMaskByte ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Information for the filter of the PNC bit vector.
Template Description
Bit mask for NM-Pdu Payload used to configure the NM filter mask for the Network Management.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreTopology::CommunicationConnector.pncFilterArrayMask
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Nm_00255]

BSW Module BSW Context

Nm Nm/NmChannelConfig/NmPnFilterMaskByte
BSW Parameter BSW Type
NmPnFilterMaskByteIndex ECUC-INTEGER-PARAM-DEF
BSW Description
Index of the filter mask byte. Specifies the position within the filter mask byte array.
Template Description
Bit mask for NM-Pdu Payload used to configure the NM filter mask for the Network Management.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreTopology::CommunicationConnector.pncFilterArrayMask
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Nm_00256]

BSW Module BSW Context

Nm Nm/NmChannelConfig/NmPnFilterMaskByte
BSW Parameter BSW Type
5

1039 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
NmPnFilterMaskByteValue ECUC-INTEGER-PARAM-DEF
BSW Description
Parameter to configure the filter mask byte.
Template Description
Bit mask for NM-Pdu Payload used to configure the NM filter mask for the Network Management.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreTopology::CommunicationConnector.pncFilterArrayMask
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Nm_00257]

BSW Module BSW Context

Nm Nm/NmChannelConfig
BSW Parameter BSW Type
NmPncBitVectorLength ECUC-INTEGER-PARAM-DEF
BSW Description
Parameter to configure the length of the PNC bit request information in bytes, which is transmitted within NM PDU by the
corresponding <Bus>Nm.
Template Description
System.pncVectorLength:
Length of the partial networking request release information vector (in bytes).
NmCluster.pncClusterVectorLength:
Optionally defines the length of the PNC Vector per CommunicationCluster (and VLAN in case of UdpNm). If not defined then
System.pncVectorLength applies.
Should only make the PNC Vector shorter (or same length as defined in System.pncVectorLength).
M2 Parameter
SystemTemplate::System.pncVectorLength, SystemTemplate::NetworkManagement::NmCluster.
pncClusterVectorLength
Mapping Rule Mapping Type
If NmCluster.pncClusterVectorLength is defined then the value is taken from NmCluster.pncCluster full
VectorLength, otherwise the value is taken from System.pncVectorLength.
Mapping Status ECUC Parameter ID
valid [ECUC_Nm_00258]

BSW Module BSW Context

Nm Nm/NmChannelConfig
BSW Parameter BSW Type
NmStateReportEnabled ECUC-BOOLEAN-PARAM-DEF
BSW Description
Specifies if the NMS shall be set for the corresponding network. false: No NMS shall be set true: The NMS shall be set
Template Description

M2 Parameter
5

1040 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Mapping Rule Mapping Type
local
Mapping Status ECUC Parameter ID
valid [ECUC_Nm_00231]

BSW Module BSW Context

Nm Nm/NmChannelConfig
BSW Parameter BSW Type
NmStateReportSignalRef ECUC-REFERENCE-DEF
BSW Description
Reference to the signal for setting the NMS by calling Com_SendSignal for the respective channel.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Nm_00232]

BSW Module BSW Context

Nm Nm/NmChannelConfig
BSW Parameter BSW Type
NmSynchronizingNetwork ECUC-BOOLEAN-PARAM-DEF
BSW Description
If this parameter is true, then this network is a synchronizing network for the NM coordination cluster which it belongs to. The
network is expected to call Nm_SynchronizationPoint() at regular intervals.
Template Description
If this parameter is true, then this network is a synchronizing network for the NM coordination cluster which it belongs to. The
network is expected to call Nm_SynchronizationPoint() at regular intervals.
M2 Parameter
SystemTemplate::NetworkManagement::NmCluster.nmSynchronizingNetwork
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Nm_00223]

BSW Module BSW Context

Nm Nm
BSW Parameter BSW Type
NmGlobalConfig ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
5

1041 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
This container contains all global configuration parameters of the Nm Interface.
Template Description
A NM coordinator is an ECU, which is connected to at least two busses, and where the requirement exists that shutdown of
NM of at least two of these busses (also referred to as coordinated busses) has to be performed synchronously.
M2 Parameter
SystemTemplate::NetworkManagement::NmCoordinator
Mapping Rule Mapping Type
local
Mapping Status ECUC Parameter ID
valid [ECUC_Nm_00196]

BSW Module BSW Context

Nm Nm/NmGlobalConfig
BSW Parameter BSW Type
NmEcucPartitionRef ECUC-REFERENCE-DEF
BSW Description
Reference to EcucPartition, where Nm module is assigned to.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Nm_00245]

BSW Module BSW Context

Nm Nm/NmGlobalConfig
BSW Parameter BSW Type
NmGlobalConstants ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description

Template Description

Nm Nm/NmGlobalConfig/NmGlobalFeatures
BSW Parameter BSW Type
NmCoordinatorSupportEnabled ECUC-BOOLEAN-PARAM-DEF
BSW Description
Pre-processor switch for enabling NM Coordinator support.
Template Description
A NM coordinator is an ECU, which is connected to at least two busses, and where the requirement exists that shutdown of
NM of at least two of these busses (also referred to as coordinated busses) has to be performed synchronously.
M2 Parameter
SystemTemplate::NetworkManagement::NmCoordinator
Mapping Rule Mapping Type
If NmCoordinators are defined set this parameter to true. full
Mapping Status ECUC Parameter ID
valid [ECUC_Nm_00206]

BSW Module BSW Context

Nm Nm/NmGlobalConfig/NmGlobalFeatures
BSW Parameter BSW Type
NmCoordinatorSyncSupport ECUC-BOOLEAN-PARAM-DEF
BSW Description
Enables/disables the coordinator synchronisation support.
Template Description
Switch for enabling NmCoordinatorSync (coordination of nested busses) support.
M2 Parameter
SystemTemplate::NetworkManagement::NmCoordinator.nmCoordSyncSupport
Mapping Rule Mapping Type
If NmCoordinator is present then the value of NmCoordinatorSyncSupport shall be set to the value full
of nmCoordSyncSupport.
Mapping Status ECUC Parameter ID
valid [ECUC_Nm_00240]

BSW Module BSW Context

Nm Nm/NmGlobalConfig/NmGlobalFeatures
BSW Parameter BSW Type
NmDynamicPncToChannelMappingSupport ECUC-BOOLEAN-PARAM-DEF
BSW Description
Precompile time switch to enable the dynamic PNC-to-channel-mapping handling.
False: Dynamic PNC-to-channel-mapping is disabled True: Dynamic PNC-to-channel-mapping is enabled
5

1045 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

Nm Nm/NmGlobalConfig/NmGlobalFeatures
BSW Parameter BSW Type
NmSynchronizedPncShutdownEnabled ECUC-BOOLEAN-PARAM-DEF
BSW Description
Enables or disables support of synchronized PNC shutdown.
FALSE: synchronized PNC shutdown is disabled
TRUE: synchronized PNC shutdown is enabled
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_Nm_00249]

BSW Module BSW Context

Nm Nm/NmGlobalConfig/NmGlobalFeatures
BSW Parameter BSW Type
NmUserDataEnabled ECUC-BOOLEAN-PARAM-DEF
BSW Description
Pre-processor switch for enabling User Data support.
Template Description
Switch for enabling user data support.
M2 Parameter
SystemTemplate::NetworkManagement::NmEcu.nmUserDataEnabled
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Nm_00211]

BSW Module BSW Context

Nm Nm/NmGlobalConfig
BSW Parameter BSW Type
NmGlobalProperties ECUC-PARAM-CONF-CONTAINER-DEF
5

1048 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
BSW Description

Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Nm_00199]

BSW Module BSW Context

Nm Nm/NmGlobalConfig/NmGlobalProperties
BSW Parameter BSW Type
NmCycletimeMainFunction ECUC-FLOAT-PARAM-DEF
BSW Description
The period between successive calls to the Main Function of the NM Interface in seconds.
Template Description
The period between successive calls to the Main Function of the NM Interface in seconds.
M2 Parameter
SystemTemplate::NetworkManagement::NmEcu.nmCycletimeMainFunction
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Nm_00205]

BSW Module BSW Context

Nm Nm/NmGlobalConfig/NmGlobalProperties
BSW Parameter BSW Type
NmDevErrorDetect ECUC-BOOLEAN-PARAM-DEF
BSW Description
Switches the development error detection and notification on or off.
• true: detection and notification is enabled.
• false: detection and notification is disabled.
Template Description

System Template
AUTOSAR CP R21-11

4
Absolute offset (with respect to the NM-PDU) of the partial networking request release information vector that is defined in
bytes as an index starting with 0.
M2 Parameter
SystemTemplate::System.pncVectorOffset
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Nm_00252]

BSW Module BSW Context

Nm Nm/NmGlobalConfig/NmGlobalProperties
BSW Parameter BSW Type
NmVersionInfoApi ECUC-BOOLEAN-PARAM-DEF
BSW Description
Pre-processor switch for enabling Version Info API support.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Nm_00204]

C.1.7 EcuC

BSW Module BSW Context

EcuC EcuC
BSW Parameter BSW Type
EcucConfigSet ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container contains the configuration parameters and sub containers of the global PduCollection.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_EcuC_00061]

BSW Module BSW Context

EcuC EcuC/EcucConfigSet
5

1051 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
BSW Parameter BSW Type
EcucPduCollection ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Collection of all Pdu objects flowing through the Com-Stack.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_EcuC_00002]

BSW Module BSW Context

EcuC EcuC/EcucConfigSet/EcucPduCollection
BSW Parameter BSW Type
MetaDataType ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Meta data serves to transport information through the AUTOSAR layers. It is transported by the PduInfoType structure via a
separate pointer to a byte array alongside the length of and a pointer to the payload of the PDU. This container defines the
content of the meta data.
Template Description

M2 Parameter

Mapping Rule Mapping Type

1053 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
SWComponentTemplate::PortInterface::MetaDataItem.metaDataItemType == ADDRESS_ full
EXTENSION_16
Mapping Status ECUC Parameter ID
valid

BSW Module BSW Context

EcuC EcuC/EcucConfigSet/EcucPduCollection/MetaDataType/MetaDataItem/MetaDataItemType
BSW Parameter BSW Type
CAN_ID_32 ECUC-ENUMERATION-LITERAL-DEF
BSW Description
CAN ID according to ISO 11898-2, either 29 bits or 11 bits. Encoding according to Can_IdType. Size: 32 bits.
Template Description
This aggregation contributes the specification of the concrete meta-data item type.
M2 Parameter
SWComponentTemplate::PortInterface::MetaDataItem.metaDataItemType
Mapping Rule Mapping Type
SWComponentTemplate::PortInterface::MetaDataItem.metaDataItemType == CAN_ID_32 full
Mapping Status ECUC Parameter ID
valid

BSW Module BSW Context

EcuC EcuC/EcucConfigSet/EcucPduCollection/MetaDataType/MetaDataItem/MetaDataItemType
BSW Parameter BSW Type
ETHERNET_MAC_64 ECUC-ENUMERATION-LITERAL-DEF
BSW Description
Ethernet MAC address. Size: 64 bits.
Template Description
This aggregation contributes the specification of the concrete meta-data item type.
M2 Parameter
SWComponentTemplate::PortInterface::MetaDataItem.metaDataItemType
Mapping Rule Mapping Type
SWComponentTemplate::PortInterface::MetaDataItem.metaDataItemType == ETHERNET_ full
MAC_64
Mapping Status ECUC Parameter ID
valid

BSW Module BSW Context

EcuC EcuC/EcucConfigSet/EcucPduCollection/MetaDataType/MetaDataItem/MetaDataItemType
BSW Parameter BSW Type
LIN_NAD_8 ECUC-ENUMERATION-LITERAL-DEF
BSW Description
LIN node address as used in the LIN transport protocol. Size: 8 bits.
5

1054 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

EcuC EcuC/EcucConfigSet/EcucPduCollection
BSW Parameter BSW Type
Pdu ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
One Pdu flowing through the COM-Stack. This Pdu is used by all Com-Stack modules to agree on referencing the same Pdu.
Template Description

M2 Parameter

1056 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_EcuC_00001]

BSW Module BSW Context

EcuC EcuC/EcucConfigSet/EcucPduCollection/Pdu
BSW Parameter BSW Type
DynamicLength ECUC-BOOLEAN-PARAM-DEF
BSW Description
This parameter defines whether the Pdu has dynamic length (true) or not (false). Please note that the usage of this attribute
is restricted by [constr_3448].
Template Description
This attribute defines whether the Pdu has dynamic length (true) or not (false). Please note that the usage of this attribute is
restricted by [constr_3448].
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::Pdu.hasDynamicLength
Mapping Rule Mapping Type
Attribute can be derived from Pdu.hasDynamicLength attribute that is only relevant for UserDefined full
Pdus, UserDefinedIPdus, J1939DcmIPdus.
Mapping Status ECUC Parameter ID
valid [ECUC_EcuC_00078]

BSW Module BSW Context

EcuC EcuC/EcucConfigSet/EcucPduCollection/Pdu
BSW Parameter BSW Type
EcucPduDedicatedPartition ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Module specific container for Pdu to partition assignment.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_EcuC_00079]

BSW Module BSW Context

EcuC EcuC/EcucConfigSet/EcucPduCollection/Pdu/EcucPduDedicatedPartition
BSW Parameter BSW Type
EcucPduDedicatedPartitionBswModuleRef ECUC-FOREIGN-REFERENCE-DEF
BSW Description
Reference to BSW module, for which the according dedicated Pdu assignment is valid.
5

1057 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Template Description

EcuC EcuC/EcucConfigSet/EcucPduCollection/Pdu
BSW Parameter BSW Type
PduLength ECUC-INTEGER-PARAM-DEF
BSW Description
Length of the Pdu in bytes. It should be noted that in former AUTOSAR releases (Rel 2.1, Rel 3.0, Rel 3.1, Rel 4.0 Rev. 1)
this parameter was defined in bits.
Template Description
Pdu.length:
Pdu length in bytes. In case of dynamic length IPdus (containing a dynamical length signal), this value indicates the
maximum data length. It should be noted that in former AUTOSAR releases (Rel 2.1, Rel 3.0, Rel 3.1, Rel 4.0 Rev. 1) this
parameter was defined in bits.
The Pdu length of zero bytes is allowed.
IPduMapping.pduMaxLength:
Define the maximum length in bytes which limits the length of the Pdu during gateway operation if the runtime length of the
received Pdu exceeds this limit.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::Pdu.length, SystemTemplate::Fibex::Fibex4Multiplatform::IPdu
Mapping.pduMaxLength
Mapping Rule Mapping Type
1:1 mapping of Pdu.length in case that IPduMapping is not used. In case IPduMapping is used: full
1:1 (sourceIPdu:targetIPdu) routing: When the SysTPduToPduTriggeringRef PduTriggering is
referenced by an IPduMapping in the role sourceIPdu or targetIPdu,respectively, and that IPdu
Mapping has a pduMaxLength defined then IPduMapping.pduMaxLength shall be used as Pdu
Length for the derived PduRSrcPdu and PduRDestPdu, respectively. Otherwise use Pdu.length.
1:N (sourceIPdu:targetIPdu) routing: If 1:N (sourceIPdu:targetIPdu) routing is modeled, then the
maximum length of the available IPduMapping.pduMaxLength and Pdu.length shall be derived for
the PduRSrcPdu. The derivation of the length of each PduRDestPdu shall follow the rule for 1:1
routing. N:1 (sourceIPdu:targetIPdu): If N:1 (sourceIPdu:targetIPdu) routing is modeled, then the
maximum length of the available IPduMapping.pduMaxLength and Pdu.length shall be derived for
the PduRDestPdu. The derivation of the length of each PduRSrcPdu shall follow the rule for 1:1
routing.
Mapping Status ECUC Parameter ID
valid [ECUC_EcuC_00003]

BSW Module BSW Context

EcuC EcuC/EcucConfigSet/EcucPduCollection/Pdu
5

1060 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
BSW Parameter BSW Type
SysTPduToFrameTriggeringRef ECUC-FOREIGN-REFERENCE-DEF
BSW Description
Reference to the FrameTriggering from the SystemTemplate which this Pdu belongs to.
SysTPduToFrameTriggeringRef shall be used for UserDefinedPdus, NmPdus and NPdus which are not going through the
Pdu Router. This reference shall not be used if SysTPduToPduTriggeringRef exists.
Template Description
The FrameTriggering describes the instance of a frame sent on a channel and defines the manner of triggering (timing
information) and identification of a frame on the channel, on which it is sent.
For the same frame, if FrameTriggerings exist on more than one channel of the same cluster the fan-out/in is handled by the
Bus interface.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::FrameTriggering
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_EcuC_00052]

BSW Module BSW Context

EcuC EcuC/EcucConfigSet/EcucPduCollection/Pdu
BSW Parameter BSW Type
SysTPduToPduTriggeringRef ECUC-FOREIGN-REFERENCE-DEF
BSW Description
Reference to the PduTriggering from the SystemTemplate which this Pdu represents.
SysTPduToPduTriggeringRef shall be used for all Pdus except UserDefinedPdus, NmPdus and NPdus which are not going
through the Pdu Router. For these Pdus, SysTPduToFrameTriggeringRef shall be used.
Template Description
The PduTriggering describes on which channel the IPdu is transmitted. The Pdu routing by the PduR is only allowed for
subclasses of IPdu.
Depending on its relation to entities such channels and clusters it can be unambiguously deduced whether a fan-out is
handled by the Pdu router or the Bus Interface.
If the fan-out is specified between different clusters it shall be handled by the Pdu Router. If the fan-out is specified between
different channels of the same cluster it shall be handled by the Bus Interface.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::PduTriggering
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_EcuC_00054]

BSW Module BSW Context

EcuC EcuC/EcucConfigSet/EcucPduCollection
BSW Parameter BSW Type
PduIdTypeEnum ECUC-ENUMERATION-PARAM-DEF
5

1061 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

EcuC EcuC/EcucPartitionCollection/EcucPartition
BSW Parameter BSW Type
EcucEcuPartitionRef ECUC-FOREIGN-REFERENCE-DEF
BSW Description
Reference to the EcuPartition to define the link to the partition described in the System description.
Template Description

M2 Parameter

Mapping Rule Mapping Type

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_EcuC_00006]

BSW Module BSW Context

EcuC EcuC
BSW Parameter BSW Type
EcucPostBuildVariants ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Collection of toplevel PostBuildSelectable variants. The PredefinedVariants linked inside this container will determine how
many PostBuildSelectableVariants exist. If this container exist the name pattern for initialization of BSW modules will be
<Mip>_Config_<PredefinedVariant.shortName>. If this container does not exist the name pattern for initialization of BSW
modlues will be <Mip>_Config.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_EcuC_00070]

1066 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

EcuC EcuC/EcucPostBuildVariants
BSW Parameter BSW Type
EcucPostBuildVariantRef ECUC-FOREIGN-REFERENCE-DEF
BSW Description
Reference to a PredefinedVariant that defines one toplevel postBuild configuration set (covering all post-build capable BSW
modules). PredefinedVariants that are referenced here shall contain only PostBuildVariantCriterionValueSets.
Template Description
This specifies one predefined variant. It is characterized by the union of all system constant values and post-build variant
criterion values aggregated within all referenced system constant value sets and post build variant criterion value sets plus
the value sets of the included variants.
M2 Parameter
GenericStructure::VariantHandling::PredefinedVariant
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_EcuC_00071]

BSW Module BSW Context

EcuC EcuC
BSW Parameter BSW Type
EcucUnitGroupAssignment ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Collection of UnitGroup references to support the generation of ASAM MCD file.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_EcuC_00063]

BSW Module BSW Context

EcuC EcuC/EcucUnitGroupAssignment
BSW Parameter BSW Type
EcucUnitGroupRef ECUC-FOREIGN-REFERENCE-DEF
BSW Description
Optional reference to the UnitGroup to support the generation of ASAM MCD file. These UnitGroups are selecting a set of
units for a specific country.
Template Description
5

1067 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
This meta-class represents the ability to specify a logical grouping of units.The category denotes the unit system that the
referenced units are associated to.
In this way, e.g. country-specific unit systems (CATEGORY="COUNTRY") can be defined as well as specific unit systems for
certain application domains.
In the same way a group of equivalent units, can be defined which are used in different countries, by setting
CATEGORY="EQUIV_UNITS". KmPerHour and MilesPerHour could such be combined to one group named "vehicle_speed".
The unit MeterPerSec would not belong to this group because it is normally not used for vehicle speed. But all of the
mentioned units could be combined to one group named "speed".
Note that the UnitGroup does not ensure the physical compliance of the units. This is maintained by the physical dimension.
M2 Parameter
AsamHdo::Units::UnitGroup
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_EcuC_00062]

BSW Module BSW Context

EcuC EcuC
BSW Parameter BSW Type
EcucVariationResolver ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Collection of PredefinedVariant elements containing definition of values for SwSystemconst which shall be applied when
resolving the variability during ECU Configuration.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_EcuC_00009]

BSW Module BSW Context

EcuC EcuC/EcucVariationResolver
BSW Parameter BSW Type
PredefinedVariantRef ECUC-FOREIGN-REFERENCE-DEF
BSW Description

Template Description
This specifies one predefined variant. It is characterized by the union of all system constant values and post-build variant
criterion values aggregated within all referenced system constant value sets and post build variant criterion value sets plus
the value sets of the included variants.
M2 Parameter
GenericStructure::VariantHandling::PredefinedVariant
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
5

1068 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
valid [ECUC_EcuC_00010]

ComM ComM/ComMConfigSet/ComMChannel
BSW Parameter BSW Type
ComMFullCommRequestNotificationEnabled ECUC-BOOLEAN-PARAM-DEF
BSW Description
5

1071 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Defines if the optional SenderReceiver Port of Interface ComM_CurrentChannelRequest will be provided for this channel.
True means enabled. False means disabled
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_ComM_-
00787]

BSW Module BSW Context

ComM ComM/ComMConfigSet/ComMChannel
BSW Parameter BSW Type
ComMMainFunctionPeriod ECUC-FLOAT-PARAM-DEF
BSW Description
Specifies the period in seconds that the MainFunction has to be triggered with.
Comment: ComM scheduling shall be at least as fast as the communication stack and a schedule longer than 100ms makes
no sense for communication.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_ComM_-
00556]

ComM ComM/ComMConfigSet/ComMChannel/ComMNetworkManagement
BSW Parameter BSW Type
ComMNmVariant ECUC-ENUMERATION-PARAM-DEF
BSW Description
Defines the functionality of the networkmanagement.
Shall be harmonized with NM configuration.
Template Description

M2 Parameter
SystemTemplate::NetworkManagement::NmNode.controller
Mapping Rule Mapping Type
5

1073 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_ComM_-
00884]

BSW Module BSW Context

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_ComM_-
00878]

BSW Module BSW Context

ComM ComM/ComMConfigSet
BSW Parameter BSW Type
ComMUser ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container contains a list of identifiers that are needed to refer to a user in the system which is designated to request
Communication modes.
Template Description
Specifies the abstract needs on the configuration of the Communication Manager for one "user".
M2 Parameter
CommonStructure::ServiceNeeds::ComMgrUserNeeds
5

1083 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Mapping Rule Mapping Type
In case the owner of the ComMgrUserNeeds is a BSW module then the ComMUser.shortName = full
{capitalizedMip}_{ServiceDependency.symbolicNameProps.symbol}.
Mapping Status ECUC Parameter ID
valid [ECUC_ComM_-
00653]

BSW Module BSW Context

ComM ComM/ComMConfigSet/ComMUser
BSW Parameter BSW Type
ComMUserEcucPartitionRef ECUC-REFERENCE-DEF
BSW Description
Denotes in which "EcucPartition" the requester is executed. When the partition is stopped, the communication request shall
be cancelled in the ComM to avoid a stay-awake situation of the bus due to a stopped partition.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_ComM_-
00786]

BSW Module BSW Context

ComM ComM/ComMConfigSet/ComMUser
BSW Parameter BSW Type
ComMUserIdentifier ECUC-INTEGER-PARAM-DEF
BSW Description
An identifier that is needed to refer to a user in the system which is designated to request Communication Modes.
ImplementationType: ComM_UserHandleType
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_ComM_-
00654]

BSW Module BSW Context

ComM ComM
BSW Parameter BSW Type
5

1084 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

ComM ComM/ComMGeneral
BSW Parameter BSW Type
ComMDirectUserMapping ECUC-BOOLEAN-PARAM-DEF
BSW Description
If this parameter is set to true the configuration tool shall automatically create a ComMUser per ComMPnc and a ComMUser
per ComMChannel.
The shortName of the generated ComMUsers shall follow the following naming convention: PNCUser_ComMPncId, e.g.
PNCUser_13 ChannelUser_ComMChannelId, e.g. ChannelUser_25
Restriction: ComMUser, which are created due to this configuration parameter, shall not be used by SWCs (only available for
BswM).
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_ComM_-
00840]

BSW Module BSW Context

ComM ComM/ComMGeneral
BSW Parameter BSW Type
ComMDynamicPncToChannelMappingSupport ECUC-BOOLEAN-PARAM-DEF
BSW Description
Precompile time switch to enable the dynamic PNC-to-channel-mapping handling.
False: Dynamic PNC-to-channel-mapping is disabled True: Dynamic PNC-to-channel-mapping is enabled
Template Description
Defines if this EcuInstance shall implement the dynamic PNC-to-channel-mapping functionality on this Communication
Connector and its respective PhysicalChannel.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreTopology::CommunicationConnector.dynamicPncToChannelMappingEnabled
Mapping Rule Mapping Type
If at least one dynamicPncToChannelMappingEnabled attribute is defined and if at least one full
CommunicationConnector of the EcuInstance has dynamicPncToChannelMappingEnabled set to
true, then ComMDynamicPncToChannelMappingSupport shall be set to true. Otherwise Com
MDynamicPncToChannelMappingSupport shall be set to false.
Mapping Status ECUC Parameter ID
valid [ECUC_ComM_-
00895]

BSW Module BSW Context

ComM ComM/ComMGeneral
BSW Parameter BSW Type
5

1086 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

ComM ComM/ComMGeneral
BSW Parameter BSW Type
ComMPncPrepareSleepTimer ECUC-FLOAT-PARAM-DEF
BSW Description
Time in seconds the PNC state machine shall wait in COMM_PNC_PREPARE_SLEEP.
Template Description
Time in seconds the PNC state machine shall wait in PNC_PREPARE_SLEEP.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreTopology::EcuInstance.pncPrepareSleepTimer
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_ComM_-
00841]

BSW Module BSW Context

ComM ComM/ComMGeneral
5

1088 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
BSW Parameter BSW Type
ComMPncSupport ECUC-BOOLEAN-PARAM-DEF
BSW Description
Enables or disables support of partial networking.
False: Partial Networking is disabled True: Partial Networking is enabled
Template Description
Describes a mapping between one or several Virtual Function Clusters onto Partial Network Clusters. A Virtual Function
Cluster is realized by a PortGroup. A Partial Network Cluster is realized by one or more IPduGroups.
M2 Parameter
SystemTemplate::PncMapping::PncMapping
Mapping Rule Mapping Type
If at least one Pnc is configured this parameter shall be set to true. Otherwise false. full
Mapping Status ECUC Parameter ID
valid [ECUC_ComM_-
00839]

BSW Module BSW Context

ComM ComM/ComMGeneral
BSW Parameter BSW Type
ComMResetAfterForcingNoComm ECUC-BOOLEAN-PARAM-DEF
BSW Description
ComM shall perform a reset after entering "No Communication" mode because of an active mode limitation to "No
Communication" mode.
true: Enabled false: Disabled
Template Description

M2 Parameter

ComM ComM/ComMGeneral
BSW Parameter BSW Type
5

1090 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
ComMVersionInfoApi ECUC-BOOLEAN-PARAM-DEF
BSW Description
Switches the possibility to read the version information with the service ComM_GetVersionInfo(). true: Enabled false:
Disabled
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_ComM_-
00622]

BSW Module BSW Context

ComM ComM/ComMGeneral
BSW Parameter BSW Type
ComMWakeupInhibitionEnabled ECUC-BOOLEAN-PARAM-DEF
BSW Description
true if wake up inhibition functionality enabled.
true: Enabled false: Disabled
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_ComM_-
00559]

C.1.9 Xcp

BSW Module BSW Context

Xcp Xcp
BSW Parameter BSW Type
XcpConfig ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container contains the configuration parameters and sub containers of the AUTOSAR Xcp module.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

Xcp Xcp/XcpConfig/XcpCommunicationChannel
BSW Parameter BSW Type
XcpChannelTxPduRef ECUC-REFERENCE-DEF
BSW Description
Reference to the XCP Tx PDU.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

Mapping Rule Mapping Type

Mapping Rule Mapping Type

Mapping Rule Mapping Type

Mapping Rule Mapping Type

Xcp Xcp/XcpConfig
BSW Parameter BSW Type
XcpEventChannel ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container contains the configuration of event channels on the XCP slave.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_Xcp_00150]

BSW Module BSW Context

Xcp Xcp/XcpConfig/XcpEventChannel
BSW Parameter BSW Type
XcpEventChannelConsistency ECUC-ENUMERATION-PARAM-DEF
BSW Description
Type of consistency used by event channel
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_Xcp_00171]

BSW Module BSW Context

Xcp Xcp/XcpConfig/XcpEventChannel
BSW Parameter BSW Type
XcpEventChannelMaxDaqList ECUC-INTEGER-PARAM-DEF
BSW Description
Maximum amount of DAQ lists that are handled by this event channel.
Template Description

M2 Parameter
5

1099 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

1101 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

M2 Parameter
5

1102 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

M2 Parameter
5

1103 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_Xcp_00191]

BSW Module BSW Context

Xcp Xcp/XcpConfig/XcpPageSwitching/XcpSegment
BSW Parameter BSW Type
XcpWorkingPageAddress ECUC-LINKER-SYMBOL-DEF
BSW Description
Memory address address of the working page (Page ID = 1).
Template Description

M2 Parameter

Mapping Rule Mapping Type

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Xcp_00106]

BSW Module BSW Context

Xcp Xcp/XcpConfig/XcpPdu/XcpRxPdu
BSW Parameter BSW Type
XcpRxPduRef ECUC-REFERENCE-DEF
BSW Description

Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Xcp_00107]

BSW Module BSW Context

Xcp Xcp/XcpConfig/XcpPdu
BSW Parameter BSW Type
XcpTxPdu ECUC-PARAM-CONF-CONTAINER-DEF
5

1105 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
BSW Description
This container specifies transmission PDUs.
Template Description

BSW Module BSW Context

Xcp Xcp/XcpConfig/XcpPdu/XcpTxPdu
BSW Parameter BSW Type
XcpTxPduId ECUC-INTEGER-PARAM-DEF
BSW Description
The PDU identifier, which has to be used by the lower layer BSW module for TxConfirmations or TriggerTransmits.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Xcp_00103]

BSW Module BSW Context

Xcp Xcp/XcpConfig/XcpPdu/XcpTxPdu
BSW Parameter BSW Type
XcpTxPduRef ECUC-REFERENCE-DEF
BSW Description
Reference to the external PDU definition.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_Xcp_00004]

1109 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

Xcp Xcp/XcpGeneral
BSW Parameter BSW Type
XcpMaxDto ECUC-INTEGER-PARAM-DEF
BSW Description
MAX_DTO shows the maximum length of a DTO packet in bytes.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_Xcp_00005]

BSW Module BSW Context

Xcp Xcp/XcpGeneral
BSW Parameter BSW Type
XcpMaxEventChannel ECUC-INTEGER-PARAM-DEF
BSW Description

Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_Xcp_00011]

BSW Module BSW Context

Xcp Xcp/XcpGeneral
BSW Parameter BSW Type
XcpMinDaq ECUC-INTEGER-PARAM-DEF
BSW Description
Indicates the number of predefined, read only DAQ lists on the XCP slave.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_Xcp_00002]

1115 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

C.1.10 Bus Mirroring

BSW Module BSW Context

Mirror Mirror
BSW Parameter BSW Type
MirrorConfigSet ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Contains the configuration parameters and sub containers of the Bus Mirroring module.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_Mirror_00008]

BSW Module BSW Context

Mirror Mirror/MirrorConfigSet
BSW Parameter BSW Type
MirrorDestNetwork ECUC-CHOICE-CONTAINER-DEF
BSW Description
Destination bus to which frames are sent by the Bus Mirroring module.
Template Description
This element defines a bus mirroring in which the traffic from one communication bus (sourceChannel) is forwarded to
another one (targetChannel).
M2 Parameter
SystemTemplate::BusMirror::BusMirrorChannelMapping
Mapping Rule Mapping Type
Create a container for each BusMirrorChannel that is composed by an instance of a concrete full
subclass of BusMirrorChannelMapping in role targetChannel which is available in the System
Extract.
Mapping Status ECUC Parameter ID
valid [ECUC_Mirror_00051]

BSW Module BSW Context

Mirror Mirror/MirrorConfigSet/MirrorDestNetwork
BSW Parameter BSW Type
MirrorDestNetworkCan ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Destination bus representing a CAN network.
Template Description
This element defines the bus mirroring between a CAN or LIN sourceChannel and a CAN targetChannel.
M2 Parameter
SystemTemplate::BusMirror::BusMirrorChannelMappingCan
5

1116 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Mapping Rule Mapping Type
Create a container for each BusMirrorChannel that is composed by an instance of a BusMirro full
ChannelMappingCan in the role targetChannel which is available in the SystemExtract.
Mapping Status ECUC Parameter ID
valid [ECUC_Mirror_00052]

BSW Module BSW Context

Mirror Mirror/MirrorConfigSet/MirrorDestNetwork/MirrorDestNetworkCan
BSW Parameter BSW Type
MirrorComMNetworkHandleRef ECUC-REFERENCE-DEF
BSW Description
Reference to the ComMChannel that represents the bus.
Template Description
Reference to PhysicalChannel that is used in the bus mirroring as sourceChannel or targetChannel.
M2 Parameter
SystemTemplate::BusMirror::BusMirrorChannel.channel
Mapping Rule Mapping Type
This reference shall be derived from the: - CanCluster that aggregates the AbstractCanPhysical full
Channel that is referenced by the BusMirrorChannel in case that this reference is used in the
MirrorDestNetworkCan container - FlexrayCluster that aggregates the PhysicalChannel that is
referenced by the BusMirrorChannel in case that this reference is used in the MirrorDestNetwork
Flexray container - EthernetPhysicalChannel that is referenced by the BusMirrorChannel in case
that this reference is used in the MirrorDestNetworkIp container - UserDefinedCluster that
aggregates the PhysicalChannel that is referenced by the BusMirrorChannel in case that this
reference is used in the MirrorDestNetworkCdd container
Mapping Status ECUC Parameter ID
valid [ECUC_Mirror_00064]

BSW Module BSW Context

Mirror Mirror/MirrorConfigSet/MirrorDestNetwork/MirrorDestNetworkCan
BSW Parameter BSW Type
MirrorDestPdu ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
I-PDU used for transmission of the mirrored frames on the destination bus.
Template Description
Reference to the PduTriggering that is used for transmission of the mirrored frames on the targetChannel. Please note that
on FlexRay several targetPduTriggerings may be used. For all other communication channels only a single targetPdu
Triggering is supported.
M2 Parameter
SystemTemplate::BusMirror::BusMirrorChannelMapping.targetPduTriggering
Mapping Rule Mapping Type
Create container for the Pdu that is referenced by the PduTriggering that is referenced by the full
instance of the BusMirrorChannelMapping in the targetPduTriggering role.
Mapping Status ECUC Parameter ID
valid [ECUC_Mirror_00055]

1117 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

Mirror Mirror/MirrorConfigSet/MirrorDestNetwork/MirrorDestNetworkCan
BSW Parameter BSW Type
MirrorStatusCanId ECUC-INTEGER-PARAM-DEF
BSW Description
CAN ID of the CAN status frame.
If configured, a status frame will be sent on the CAN destination bus that contains the state of all active source buses.
Template Description
CAN ID of the CAN status frame.
If configured, a status frame will be sent on the CAN destination bus that contains the state of all active source buses.
M2 Parameter
SystemTemplate::BusMirror::BusMirrorChannelMappingCan.mirrorStatusCanId
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Mirror_00061]

Mirror Mirror/MirrorConfigSet/MirrorDestNetwork/MirrorDestNetworkCdd
BSW Parameter BSW Type
MirrorNetworkId ECUC-INTEGER-PARAM-DEF
BSW Description
Network ID of the bus.
Template Description
This attribute defines the networkId of the communication channel.
M2 Parameter
SystemTemplate::BusMirror::BusMirrorChannel.busMirrorNetworkId
Mapping Rule Mapping Type
5

1123 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
If this parameter is aggregated by MirrorDestNetworkCan container take the value from the Bus full
MirrorChannel that is aggregated in the role targetChannel by the instance of BusMirrorChannel
MappingCan. If this parameter is aggregated by MirrorDestNetworkFlexray container take the
value from the BusMirrorChannel that is aggregated in the role targetChannel by the instance of
BusMirrorChannelMappingFlexray. If this parameter is aggregated by MirrorDestNetworkIp
container take the value from the BusMirrorChannel that is aggregated in the role targetChannel by
the instance of BusMirrorChannelMappingIp. If this parameter is aggregated by MirrorDestNetwork
Cdd container take the value from the BusMirrorChannel that is aggregated in the role target
Channel by the instance of BusMirrorChannelMappingUserDefined. If this parameter is
aggregated by MirrorSourceNetworkCan container take the value from the BusMirrorChannel that
is aggregated in the role sourceChannel by the instance of BusMirrorChannelMapping. If this
parameter is aggregated by MirrorSourceNetworkFlexray container take the value from the Bus
MirrorChannel that is aggregated in the role sourceChannel by the instance of BusMirrorChannel
Mapping. If this parameter is aggregated by MirrorSourceNetworkLin container take the value from
the BusMirrorChannel that is aggregated in the role sourcetChannel by the instance of BusMirror
ChannelMapping.
Mapping Status ECUC Parameter ID
valid [ECUC_Mirror_00012]

Mirror Mirror/MirrorConfigSet/MirrorDestNetwork/MirrorDestNetworkIp/MirrorDestPdu
BSW Parameter BSW Type
MirrorDestPduId ECUC-INTEGER-PARAM-DEF
BSW Description
I-PDU identifier used for TxConfirmation from PduR.
Template Description

M2 Parameter

Mirror Mirror/MirrorConfigSet/MirrorDestNetwork/MirrorDestNetworkIp
BSW Parameter BSW Type
MirrorNetworkId ECUC-INTEGER-PARAM-DEF
BSW Description
Network ID of the bus.
Template Description
This attribute defines the networkId of the communication channel.
M2 Parameter
SystemTemplate::BusMirror::BusMirrorChannel.busMirrorNetworkId
Mapping Rule Mapping Type
5

1131 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

Mirror Mirror/MirrorConfigSet
BSW Parameter BSW Type
MirrorInitialDestNetworkRef ECUC-REFERENCE-DEF
BSW Description
Reference to the destination bus that is selected after initialization of the Bus Mirroring module.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Mirror_00007]

BSW Module BSW Context

Mirror Mirror/MirrorConfigSet
BSW Parameter BSW Type
MirrorSourceNetwork ECUC-CHOICE-CONTAINER-DEF
BSW Description
Source bus from which frames are received by the Bus Mirroring module.
Template Description
Reference to PhysicalChannel that is used in the bus mirroring as sourceChannel or targetChannel.
M2 Parameter
SystemTemplate::BusMirror::BusMirrorChannel.channel
Mapping Rule Mapping Type
Create a container for each BusMirrorChannel that is composed by an instance of a concrete full
subclass of BusMirrorChannelMapping in role sourceChannel which is available in the System
Extract.
Mapping Status ECUC Parameter ID
5

1132 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
valid [ECUC_Mirror_00009]

BSW Module BSW Context

Mirror Mirror/MirrorConfigSet/MirrorSourceNetwork
BSW Parameter BSW Type
MirrorSourceNetworkCan ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Source bus representing a CAN network.
Template Description
Reference to PhysicalChannel that is used in the bus mirroring as sourceChannel or targetChannel.
M2 Parameter
SystemTemplate::BusMirror::BusMirrorChannel.channel
Mapping Rule Mapping Type
Create a container for each CanPhysicalChannel which is available in the SystemExtract and is full
referenced by BusMirrorChannel that is composed by an instance of a BusMirrorChannelMapping
in the role sourceChannel.
Mapping Status ECUC Parameter ID
valid [ECUC_Mirror_00010]

BSW Module BSW Context

Mirror Mirror/MirrorConfigSet/MirrorSourceNetwork/MirrorSourceNetworkCan
BSW Parameter BSW Type
MirrorComMNetworkHandleRef ECUC-REFERENCE-DEF
BSW Description
Reference to the ComMChannel that represents the bus.
Template Description
Reference to PhysicalChannel that is used in the bus mirroring as sourceChannel or targetChannel.
M2 Parameter
SystemTemplate::BusMirror::BusMirrorChannel.channel
Mapping Rule Mapping Type
This reference shall be derived from the: - CanCluster that aggregates the AbstractCanPhysical full
Channel that is referenced by the BusMirrorChannel in case that this reference is used in the
MirrorDestNetworkCan container - FlexrayCluster that aggregates the PhysicalChannel that is
referenced by the BusMirrorChannel in case that this reference is used in the MirrorDestNetwork
Flexray container - EthernetPhysicalChannel that is referenced by the BusMirrorChannel in case
that this reference is used in the MirrorDestNetworkIp container - UserDefinedCluster that
aggregates the PhysicalChannel that is referenced by the BusMirrorChannel in case that this
reference is used in the MirrorDestNetworkCdd container
Mapping Status ECUC Parameter ID
valid [ECUC_Mirror_00064]

BSW Module BSW Context

Mirror Mirror/MirrorConfigSet/MirrorSourceNetwork/MirrorSourceNetworkCan
5

1133 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
BSW Parameter BSW Type
MirrorNetworkId ECUC-INTEGER-PARAM-DEF
BSW Description
Network ID of the bus.
Template Description
This attribute defines the networkId of the communication channel.
M2 Parameter
SystemTemplate::BusMirror::BusMirrorChannel.busMirrorNetworkId
Mapping Rule Mapping Type
If this parameter is aggregated by MirrorDestNetworkCan container take the value from the Bus full
MirrorChannel that is aggregated in the role targetChannel by the instance of BusMirrorChannel
MappingCan. If this parameter is aggregated by MirrorDestNetworkFlexray container take the
value from the BusMirrorChannel that is aggregated in the role targetChannel by the instance of
BusMirrorChannelMappingFlexray. If this parameter is aggregated by MirrorDestNetworkIp
container take the value from the BusMirrorChannel that is aggregated in the role targetChannel by
the instance of BusMirrorChannelMappingIp. If this parameter is aggregated by MirrorDestNetwork
Cdd container take the value from the BusMirrorChannel that is aggregated in the role target
Channel by the instance of BusMirrorChannelMappingUserDefined. If this parameter is
aggregated by MirrorSourceNetworkCan container take the value from the BusMirrorChannel that
is aggregated in the role sourceChannel by the instance of BusMirrorChannelMapping. If this
parameter is aggregated by MirrorSourceNetworkFlexray container take the value from the Bus
MirrorChannel that is aggregated in the role sourceChannel by the instance of BusMirrorChannel
Mapping. If this parameter is aggregated by MirrorSourceNetworkLin container take the value from
the BusMirrorChannel that is aggregated in the role sourcetChannel by the instance of BusMirror
ChannelMapping.
Mapping Status ECUC Parameter ID
valid [ECUC_Mirror_00012]

BSW Module BSW Context

Mirror Mirror/MirrorConfigSet/MirrorSourceNetwork/MirrorSourceNetworkCan
BSW Parameter BSW Type
MirrorSourceCanFilter ECUC-CHOICE-CONTAINER-DEF
BSW Description
Pre-configured filter for CAN frames.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_Mirror_00021]

BSW Module BSW Context

Mirror Mirror/MirrorConfigSet/MirrorSourceNetwork/MirrorSourceNetworkCan/MirrorSourceCanFilter/
MirrorSourceCanFilterMask
BSW Parameter BSW Type
5

1135 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
MirrorSourceCanFilterId ECUC-INTEGER-PARAM-DEF
BSW Description
Unique identifier of the pre-configured CAN filter.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_Mirror_00018]

BSW Module BSW Context

Mirror Mirror/MirrorConfigSet/MirrorSourceNetwork/MirrorSourceNetworkCan/MirrorSourceCanFilter
BSW Parameter BSW Type
MirrorSourceCanFilterRange ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Pre-configured range filter for CAN frames.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Mirror_00015]

BSW Module BSW Context

Mirror Mirror/MirrorConfigSet/MirrorSourceNetwork/MirrorSourceNetworkCan/MirrorSourceCanFilter/
MirrorSourceCanFilterRange
BSW Parameter BSW Type
MirrorSourceCanFilterId ECUC-INTEGER-PARAM-DEF
BSW Description
Unique identifier of the pre-configured CAN filter.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_Mirror_00018]

BSW Module BSW Context

Mirror Mirror/MirrorConfigSet/MirrorSourceNetwork/MirrorSourceNetworkCan/MirrorSourceCanFilter/
MirrorSourceCanFilterRange
5

1136 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
BSW Parameter BSW Type
MirrorSourceCanFilterLower ECUC-INTEGER-PARAM-DEF
BSW Description
Lowest CAN ID that is accepted by the filter.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_Mirror_00016]

BSW Module BSW Context

Mirror Mirror/MirrorConfigSet/MirrorSourceNetwork/MirrorSourceNetworkCan/MirrorSourceCanFilter/
MirrorSourceCanFilterRange
BSW Parameter BSW Type
MirrorSourceCanFilterUpper ECUC-INTEGER-PARAM-DEF
BSW Description
Highest CAN ID that is accepted by the filter.
Template Description

M2 Parameter

Mapping Rule Mapping Type

1138 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
M2 Parameter
SystemTemplate::BusMirror::BusMirrorCanIdRangeMapping.sourceCanIdMask
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Mirror_00027]

BSW Module BSW Context

Mirror Mirror/MirrorConfigSet/MirrorSourceNetwork/MirrorSourceNetworkCan
BSW Parameter BSW Type
MirrorSourceCanSingleIdMapping ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Rule for remapping a single CAN ID.
Template Description
This element defines a rule for remapping a single CAN ID.
M2 Parameter
SystemTemplate::BusMirror::BusMirrorCanIdToCanIdMapping
Mapping Rule Mapping Type
Create container in case that the BusMirrorCanIdToCanIdMapping is aggregated by BusMirror full
ChannelMappingCan in the role canIdToCanIdMapping.
Mapping Status ECUC Parameter ID
valid [ECUC_Mirror_00022]

BSW Module BSW Context

Mirror Mirror/MirrorConfigSet/MirrorSourceNetwork/MirrorSourceNetworkCan/MirrorSourceCanSingleId
Mapping
BSW Parameter BSW Type
MirrorSourceCanSingleIdMappingDestCanId ECUC-INTEGER-PARAM-DEF
BSW Description
Mapped CAN ID.
Template Description
This attribute defines the CanId on the targetChannel.
M2 Parameter
SystemTemplate::BusMirror::BusMirrorCanIdToCanIdMapping.remappedCanId
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Mirror_00024]

BSW Module BSW Context

1139 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Mirror Mirror/MirrorConfigSet/MirrorSourceNetwork/MirrorSourceNetworkCan/MirrorSourceCanSingleId
Mapping
BSW Parameter BSW Type
MirrorSourceCanSingleIdMappingSourceCanId ECUC-INTEGER-PARAM-DEF
BSW Description
Original CAN ID.
Template Description
This reference points to the sourceFrame with sourceCanId on the sourceChannel.
M2 Parameter
SystemTemplate::BusMirror::BusMirrorCanIdToCanIdMapping.souceCanId
Mapping Rule Mapping Type
Take the value from the identifier attribute of the referenced CanFrameTriggering. full
Mapping Status ECUC Parameter ID
valid [ECUC_Mirror_00023]

BSW Module BSW Context

Mirror Mirror/MirrorConfigSet/MirrorSourceNetwork/MirrorSourceNetworkCan
BSW Parameter BSW Type
MirrorSourceMaxDynamicFilters ECUC-INTEGER-PARAM-DEF
BSW Description
Maximum number of filters that can be dynamically added using Mirror_AddXxxFilter().
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Mirror_00013]

System Template
AUTOSAR CP R21-11

1143 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

Mirror Mirror/MirrorConfigSet/MirrorSourceNetwork/MirrorSourceNetworkFlexRay
BSW Parameter BSW Type
MirrorSourceMaxDynamicFilters ECUC-INTEGER-PARAM-DEF
BSW Description
Maximum number of filters that can be dynamically added using Mirror_AddXxxFilter().
Template Description

Mirror Mirror/MirrorConfigSet/MirrorSourceNetwork/MirrorSourceNetworkLin
BSW Parameter BSW Type
MirrorSourceLinFilter ECUC-CHOICE-CONTAINER-DEF
BSW Description
Pre-configured filter for LIN frames.
Template Description

M2 Parameter
5

1146 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Mapping Rule Mapping Type
local
Mapping Status ECUC Parameter ID
valid [ECUC_Mirror_00030]

BSW Module BSW Context

Mirror Mirror/MirrorConfigSet/MirrorSourceNetwork/MirrorSourceNetworkLin/MirrorSourceLinFilter
BSW Parameter BSW Type
MirrorSourceLinFilterMask ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Pre-configured mask based filter for LIN frames.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Mirror_00035]

BSW Module BSW Context

Mirror Mirror/MirrorConfigSet/MirrorSourceNetwork/MirrorSourceNetworkLin/MirrorSourceLinFilter/Mirror
SourceLinFilterMask
BSW Parameter BSW Type
MirrorSourceLinFilterId ECUC-INTEGER-PARAM-DEF
BSW Description
Unique identifier of the pre-configured LIN filter.
Template Description

M2 Parameter

Mirror Mirror/MirrorConfigSet/MirrorSourceNetwork/MirrorSourceNetworkLin/MirrorSourceLinFilter/Mirror
SourceLinFilterRange
BSW Parameter BSW Type
MirrorSourceLinFilterId ECUC-INTEGER-PARAM-DEF
BSW Description
5

1148 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Mirror Mirror/MirrorConfigSet/MirrorSourceNetwork/MirrorSourceNetworkLin
BSW Parameter BSW Type
5

1149 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
MirrorSourceLinToCanBaseId ECUC-INTEGER-PARAM-DEF
BSW Description
Base ID merged with the LIN frame ID to form the CAN ID.
Template Description
Base ID merged with the LIN frame ID to form the CAN ID.
Only required when a BusMirrorChannel that refers to a LinPhysicalChannel in the role channel is referenced in the role
sourceChannel.
M2 Parameter
SystemTemplate::BusMirror::BusMirrorChannelMappingCan.mirrorSourceLinToCanRangeBaseId
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Mirror_00041]

BSW Module BSW Context

Mirror Mirror/MirrorConfigSet/MirrorSourceNetwork/MirrorSourceNetworkLin
BSW Parameter BSW Type
MirrorSourceLinToCanIdMapping ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Rule for mapping a LIN frame ID to a special CAN ID.
Template Description
This element defines a rule for remapping a single LIN Frame.
M2 Parameter
SystemTemplate::BusMirror::BusMirrorLinPidToCanIdMapping
Mapping Rule Mapping Type
Create container in case that the BusMirrorLinPidToCanIdMapping is aggregated by BusMirror full
ChannelMappingCan in the role linPidToCanIdMapping.
Mapping Status ECUC Parameter ID
valid [ECUC_Mirror_00038]

BSW Module BSW Context

Mirror Mirror/MirrorConfigSet/MirrorSourceNetwork/MirrorSourceNetworkLin/MirrorSourceLinToCanId
Mapping
BSW Parameter BSW Type
MirrorSourceLinToCanIdMappingCanId ECUC-INTEGER-PARAM-DEF
BSW Description
CAN ID which lies outside of the range mapping.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_Mirror_00040]

1150 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

Mirror Mirror/MirrorConfigSet/MirrorSourceNetwork/MirrorSourceNetworkLin/MirrorSourceLinToCanId
Mapping
BSW Parameter BSW Type
MirrorSourceLinToCanIdMappingLinId ECUC-INTEGER-PARAM-DEF
BSW Description
Frame ID which is excluded from the range mapping.
Template Description

Mirror Mirror/MirrorGeneral
BSW Parameter BSW Type
MirrorStbRef ECUC-REFERENCE-DEF
BSW Description
Reference to the StbM time base to use for acquiring the time stamps used in the mirroring protocol.
This reference is not required if all destination buses are CAN.
Template Description

M2 Parameter

Mapping Rule Mapping Type

1153 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Mapping Status ECUC Parameter ID
valid [ECUC_Mirror_00065]

BSW Module BSW Context

Mirror Mirror/MirrorGeneral
BSW Parameter BSW Type
MirrorVersionInfoApi ECUC-BOOLEAN-PARAM-DEF
BSW Description
Pre-processor switch for enabling version info API support.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Mirror_00005]

C.2 Can

C.2.1 Can Driver Mapping

BSW Module BSW Context

Can Can
BSW Parameter BSW Type
CanConfigSet ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container contains the configuration parameters and sub containers of the AUTOSAR Can module.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Can_00343]

BSW Module BSW Context

Can Can/CanConfigSet
BSW Parameter BSW Type
CanController ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
5

1154 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Can Can/CanConfigSet/CanController
BSW Parameter BSW Type
CanControllerBaseAddress ECUC-INTEGER-PARAM-DEF
5

1155 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
BSW Description
Specifies the CAN controller base address.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Can_00382]

BSW Module BSW Context

Can Can/CanConfigSet/CanController
BSW Parameter BSW Type
CanControllerBaudrateConfig ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container contains bit timing related configuration parameters of the CAN controller(s).
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Can_00387]

BSW Module BSW Context

Can Can/CanConfigSet/CanController/CanControllerBaudrateConfig
BSW Parameter BSW Type
CanControllerBaudRate ECUC-FLOAT-PARAM-DEF
BSW Description
Specifies the baudrate of the controller in kbps.
Template Description
Channels speed in bits/s.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreTopology::CommunicationCluster.baudrate
Mapping Rule Mapping Type
SystemTemplate speed is in bps, so divide it by 1000 to get kbps full
Mapping Status ECUC Parameter ID
valid [ECUC_Can_00005]

BSW Module BSW Context

Can Can/CanConfigSet/CanController/CanControllerBaudrateConfig
5

1156 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
BSW Parameter BSW Type
CanControllerBaudRateConfigID ECUC-INTEGER-PARAM-DEF
BSW Description
This ID is used by SetBaudrate API and uniquely identifies a specific baud rate configuration within a controller configuration.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Can_00471]

BSW Module BSW Context

Can Can/CanConfigSet/CanController/CanControllerBaudrateConfig
BSW Parameter BSW Type
CanControllerFdBaudrateConfig ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This optional container contains bit timing related configuration parameters of the CAN controller(s) for payload and CRC of a
CAN FD frame. If this container exists the controller supports CAN FD frames.
Template Description

M2 Parameter

1158 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

Can Can/CanConfigSet/CanController/CanControllerBaudrateConfig
BSW Parameter BSW Type
CanControllerSeg2 ECUC-INTEGER-PARAM-DEF
BSW Description
Specifies phase segment 2 in time quantas.
Template Description
Specifies phase segment 2 in time quantas.
timeSeg2 = Phase_Seg2
M2 Parameter
SystemTemplate::Fibex::Fibex4Can::CanTopology::CanControllerConfiguration.timeSeg2
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Can_00075]

BSW Module BSW Context

Can Can/CanConfigSet/CanController/CanControllerBaudrateConfig
BSW Parameter BSW Type
CanControllerSyncJumpWidth ECUC-INTEGER-PARAM-DEF
BSW Description
Specifies the synchronization jump width for the controller in time quantas.
Template Description
The number of quanta in the Synchronization Jump Width, SJW. The (Re-)Synchronization Jump Width (SJW) defines how
far a resynchronization may move the Sample Point inside the limits defined by the Phase Buffer Segments to compensate
for edge phase errors.
M2 Parameter
SystemTemplate::Fibex::Fibex4Can::CanTopology::CanControllerConfiguration.syncJumpWidth
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Can_00383]

1161 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

Can Can/CanConfigSet/CanController
BSW Parameter BSW Type
CanControllerDefaultBaudrate ECUC-REFERENCE-DEF
BSW Description
Reference to baudrate configuration container configured for the Can Controller.
Template Description
Channels speed in bits/s.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreTopology::CommunicationCluster.baudrate
Mapping Rule Mapping Type
Set the reference to the container of the CanControllerBaudRate parameter that has been full
configured for SystemTemplate::Fibex::FibexCore::CoreTopology::CommunicationCluster.baudrate
Mapping Status ECUC Parameter ID
valid [ECUC_Can_00435]

BSW Module BSW Context

Can Can/CanConfigSet/CanController
BSW Parameter BSW Type
CanControllerEcucPartitionRef ECUC-REFERENCE-DEF
BSW Description
Maps the CAN controller to zero or one ECUC partitions. The ECUC partition referenced is a subset of the ECUC partitions
where the CAN driver is mapped to.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Can_00492]

BSW Module BSW Context

Can Can/CanConfigSet/CanController
BSW Parameter BSW Type
CanControllerId ECUC-INTEGER-PARAM-DEF
BSW Description
This parameter provides the controller ID which is unique in a given CAN Driver. The value for this parameter starts with 0
and continue without any gaps.
Template Description

M2 Parameter

Mapping Rule Mapping Type

1162 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
local
Mapping Status ECUC Parameter ID
valid [ECUC_Can_00316]

BSW Module BSW Context

Can Can/CanConfigSet/CanController
BSW Parameter BSW Type
CanCpuClockRef ECUC-REFERENCE-DEF
BSW Description
Reference to the CPU clock configuration, which is set in the MCU driver configuration
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Can_00313]

BSW Module BSW Context

Can Can/CanConfigSet/CanController
BSW Parameter BSW Type
CanRxProcessing ECUC-ENUMERATION-PARAM-DEF
BSW Description
Enables / disables API Can_MainFunction_Read() for handling PDU reception events in polling mode.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Can_00317]

BSW Module BSW Context

Can Can/CanConfigSet/CanController
BSW Parameter BSW Type
CanTTController ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
CanTTController is specified in the SWS TTCAN and contains the configuration parameters of the TTCAN controller(s)
(which are needed in addition to the configuration parameters of the CAN controller(s)).
This container is only included and valid if TTCAN is supported by the controller, enabled (see CanSupportTTCANRef,
ECUC_Can_00430), and used.
5

1163 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_Can_00001]

BSW Module BSW Context

Can Can/CanConfigSet/CanController/CanTTController
BSW Parameter BSW Type
CanTTControllerApplWatchdogLimit ECUC-INTEGER-PARAM-DEF
BSW Description
Defines the maximum time period (unit is 256 times NTU) after which the application has to serve the watchdog.
Template Description
The Appl_Watchdog_Limit shall be an 8-bit value specifying the period for the application watchdog in Appl_Watchdog_Limit
times 256 NTUs.
M2 Parameter
SystemTemplate::Fibex::Fibex4Ttcan::TtcanTopology::TtcanCommunicationController.applWatchdogLimit
Mapping Rule Mapping Type
1:1 mapping local
Mapping Status ECUC Parameter ID
valid [ECUC_Can_00139]

BSW Module BSW Context

Can Can/CanConfigSet/CanController/CanTTController
BSW Parameter BSW Type
CanTTControllerCycleCountMax ECUC-INTEGER-PARAM-DEF
BSW Description
Defines the value for cycle_count_max. Allowed values: 0x00: 1 basic cycle 0x01: 2 basic cycles 0x03: 4 basic cycles 0x07:
8 basic cycles 0x0F: 16 basic cycles 0x1F: 32 basic cycles 0x3F: 64 basic cycles
Template Description

BSW Module BSW Context

Can Can/CanConfigSet/CanController/CanTTController
BSW Parameter BSW Type
CanTTControllerGlobalTimeFiltering ECUC-BOOLEAN-PARAM-DEF
BSW Description
Enables/disables the global time filtering. TRUE: Global time filtering enabled. FALSE: Global time filtering disabled.
This parameter shall only be configurable if parameter CanTTControllerLevel2 equals TRUE.
Template Description

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Can_00142]

BSW Module BSW Context

Can Can/CanConfigSet/CanController
BSW Parameter BSW Type
CanTxProcessing ECUC-ENUMERATION-PARAM-DEF
BSW Description
Enables / disables API Can_MainFunction_Write() for handling PDU transmission events in polling mode.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Can_00318]

BSW Module BSW Context

Can Can/CanConfigSet/CanController
BSW Parameter BSW Type
CanWakeupProcessing ECUC-ENUMERATION-PARAM-DEF
BSW Description
Enables / disables API Can_MainFunction_Wakeup() for handling wakeup events in polling mode.
Template Description

M2 Parameter

Mapping Rule Mapping Type

1171 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
local
Mapping Status ECUC Parameter ID
valid [ECUC_Can_00319]

BSW Module BSW Context

Can Can/CanConfigSet/CanController
BSW Parameter BSW Type
CanWakeupSourceRef ECUC-REFERENCE-DEF
BSW Description
This parameter contains a reference to the Wakeup Source for this controller as defined in the ECU State Manager.
Implementation Type: reference to EcuM_WakeupSourceType
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Can_00359]

BSW Module BSW Context

Can Can/CanConfigSet/CanController
BSW Parameter BSW Type
CanWakeupSupport ECUC-BOOLEAN-PARAM-DEF
BSW Description
CAN driver support for wakeup over CAN Bus.
Template Description
Defines whether the ECU shall be woken up by this CommunicationController.
TRUE: wake up is possible
FALSE: wake up is not supported
Note: If wakeUpByControllerSupported is set to TRUE the feature shall be supported by both hardware and basic software.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreTopology::CommunicationController.wakeUpByControllerSupported
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Can_00330]

BSW Module BSW Context

Can Can/CanConfigSet
BSW Parameter BSW Type
5

1172 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
CanHardwareObject ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container contains the configuration (parameters) of CAN Hardware Objects.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_Can_00490]

BSW Module BSW Context

Can Can/CanConfigSet/CanHardwareObject
BSW Parameter BSW Type
CanHwFilter ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container is only valid for HRHs and contains the configuration (parameters) of one hardware filter.
Template Description

M2 Parameter

1174 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

1175 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Number of hardware objects used to implement one HOH. In case of a HRH this parameter defines the number of elements
in the hardware FIFO or the number of shadow buffers, in case of a HTH it defines the number of hardware objects used for
multiplexed transmission or for a hardware FIFO used by a FullCAN HTH.
Template Description

M2 Parameter

Mapping Rule Mapping Type

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Can_00438]

BSW Module BSW Context

Can Can/CanConfigSet/CanHardwareObject
BSW Parameter BSW Type
CanObjectId ECUC-INTEGER-PARAM-DEF
BSW Description
Holds the handle ID of HRH or HTH. The value of this parameter is unique in a given CAN Driver, and it should start with 0
and continue without any gaps.
The HRH and HTH Ids share a common ID range.
Example: HRH0-0, HRH1-1, HTH0-2, HTH1-3
Template Description

M2 Parameter

Mapping Rule Mapping Type

1177 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
local
Mapping Status ECUC Parameter ID
valid [ECUC_Can_00326]

BSW Module BSW Context

Can Can/CanConfigSet/CanHardwareObject
BSW Parameter BSW Type
CanObjectPayloadLength ECUC-ENUMERATION-PARAM-DEF
BSW Description
Specifies the maximum L-PDU payload length in bytes the hardware object can store. If the parameter is not provided, Can
driver configuration generators have to assume the maximum length of the underlying CAN derivate, e.g. 8 bytes for CAN, 64
bytes for CAN-FD.
Template Description
The CAN protocol supports two types of frame formats. The standard frame format uses 11-bit identifiers and is defined in
the CAN specification 2.0 A. Additionally the extended frame format allows 29-bit identifiers and is defined in the CAN
specification 2.0 B.
M2 Parameter
SystemTemplate::Fibex::Fibex4Can::CanCommunication::CanFrameTriggering.canAddressingMode
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Can_00495]

BSW Module BSW Context

Can Can/CanConfigSet/CanHardwareObject/CanObjectPayloadLength
BSW Parameter BSW Type
CAN_OBJECT_PL_12 ECUC-ENUMERATION-LITERAL-DEF
BSW Description
Payload length of 12 Bytes
Template Description
Standard 11-bit-identifiers are used (CAN 2.0A)
M2 Parameter
SystemTemplate::Fibex::Fibex4Can::CanCommunication::CanAddressingModeType.standard
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid

BSW Module BSW Context

Can Can/CanConfigSet/CanHardwareObject/CanObjectPayloadLength
BSW Parameter BSW Type
CAN_OBJECT_PL_16 ECUC-ENUMERATION-LITERAL-DEF
5

1178 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

Can Can/CanConfigSet/CanHardwareObject/CanObjectPayloadLength
BSW Parameter BSW Type
CAN_OBJECT_PL_8 ECUC-ENUMERATION-LITERAL-DEF
BSW Description
Payload length of 8 Bytes
Template Description
Standard 11-bit-identifiers are used (CAN 2.0A)
M2 Parameter
SystemTemplate::Fibex::Fibex4Can::CanCommunication::CanAddressingModeType.standard
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid

BSW Module BSW Context

Can Can/CanConfigSet/CanHardwareObject
BSW Parameter BSW Type
CanObjectType ECUC-ENUMERATION-PARAM-DEF
BSW Description
Specifies if the HardwareObject is used as Transmit or as Receive object
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Can_00327]

BSW Module BSW Context

Can Can/CanConfigSet/CanHardwareObject
BSW Parameter BSW Type
CanTTHardwareObjectTrigger ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
5

1181 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
CanTTHardwareObjectTrigger is specified in the SWS TTCAN and contains the configuration (parameters) of TTCAN triggers
for Hardware Objects, which are additional to the configuration (parameters) of CAN Hardware Objects.
This container is only included and valid if TTCAN is supported by the controller and, enabled (see CanSupportTTCANRef,
ECUC_Can_00430), and used.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_Can_00002]

BSW Module BSW Context

Can Can/CanConfigSet/CanHardwareObject/CanTTHardwareObjectTrigger
BSW Parameter BSW Type
CanTTHardwareObjectBaseCycle ECUC-INTEGER-PARAM-DEF
BSW Description
Defines the cycle_offset. CanTTHardwareObjectBaseCycle must be not greater than cycle_count_max.
Template Description
The first communication cycle where the frame is sent.
This value is incremented at the beginning of each new cycle, ranging from 0 to 63, and is reset to 0 after a sequence of 64
cycles.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreTopology::CycleRepetition.BaseCycle
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Can_00147]

BSW Module BSW Context

Can Can/CanConfigSet/CanHardwareObject/CanTTHardwareObjectTrigger
BSW Parameter BSW Type
CanTTHardwareObjectCycleRepetition ECUC-INTEGER-PARAM-DEF
BSW Description
Defines the repeat_factor.
CanTTHardwareObjectCycleRepetition shall be a power of two (2), greater than cycle_offset but not greater than cycle_
count_max + 1.
Template Description
The number of communication cycles (after the first cycle) whenever the frame described by this timing is sent again.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreTopology::CycleRepetition.CycleRepetition
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
5

1182 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

System Template
AUTOSAR CP R21-11

4
Mapping Rule Mapping Type
local
Mapping Status ECUC Parameter ID
valid [ECUC_Can_00145]

BSW Module BSW Context

Can Can/CanConfigSet/CanHardwareObject
BSW Parameter BSW Type
CanTriggerTransmitEnable ECUC-BOOLEAN-PARAM-DEF
BSW Description
This parameter defines if or if not Can supports the trigger-transmit API for this handle.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Can_00486]

BSW Module BSW Context

Can Can
BSW Parameter BSW Type
CanGeneral ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container contains the parameters related each CAN Driver Unit.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Can_00497]

BSW Module BSW Context

Can Can/CanGeneral
BSW Parameter BSW Type
CanDevErrorDetect ECUC-BOOLEAN-PARAM-DEF
BSW Description
Switches the development error detection and notification on or off.
• true: detection and notification is enabled.
• false: detection and notification is disabled.
5

1184 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Can_00064]

BSW Module BSW Context

Can Can/CanGeneral
BSW Parameter BSW Type
CanEcucPartitionRef ECUC-REFERENCE-DEF
BSW Description
Maps the CAN driver to zero or multiple ECUC partitions to make the modules API available in this partition. The CAN driver
will operate as an independent instance in each of the partitions.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Can_00491]

BSW Module BSW Context

Can Can/CanGeneral
BSW Parameter BSW Type
CanEnableSecurityEventReporting ECUC-BOOLEAN-PARAM-DEF
BSW Description
Switches the reporting of security events to the IdsM: - true: reporting is enabled. - false: reporting is disabled.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_Can_00496]

BSW Module BSW Context

Can Can/CanGeneral
BSW Parameter BSW Type
CanGlobalTimeSupport ECUC-BOOLEAN-PARAM-DEF
BSW Description
5

1185 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Can Can/CanGeneral
BSW Parameter BSW Type
CanMainFunctionBusoffPeriod ECUC-FLOAT-PARAM-DEF
5

1186 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Can Can/CanGeneral/CanMainFunctionRWPeriods
BSW Parameter BSW Type
5

1187 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
CanMainFunctionPeriod ECUC-FLOAT-PARAM-DEF
BSW Description
This parameter describes the period for cyclic call to Can_MainFunction_Read or Can_MainFunction_Write depending on
the referring item. Unit is seconds. Different poll-cycles will be configurable if more than one CanMainFunctionPeriod is
configured. In this case multiple Can_MainFunction_Read() or Can_MainFunction_Write() will be provided by the CAN Driver
module.
Template Description

BSW Module BSW Context

CanIf CanIf
BSW Parameter BSW Type
CanIfCtrlDrvCfg ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Configuration parameters for all the underlying CAN Driver modules are aggregated under this container. For each CAN
Driver module a seperate instance of this container has to be provided.
Template Description

M2 Parameter
5

1190 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Mapping Rule Mapping Type
local
Mapping Status ECUC Parameter ID
valid [ECUC_CanIf_00253]

BSW Module BSW Context

CanIf CanIf/CanIfCtrlDrvCfg
BSW Parameter BSW Type
CanIfCtrlCfg ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container contains the configuration (parameters) of an adressed CAN controller by an underlying CAN Driver module.
This container is configurable per CAN controller.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanIf_00546]

BSW Module BSW Context

CanIf CanIf/CanIfCtrlDrvCfg/CanIfCtrlCfg
BSW Parameter BSW Type
CanIfCtrlCanCtrlRef ECUC-REFERENCE-DEF
BSW Description
This parameter references to the logical handle of the underlying CAN controller from the CAN Driver module to be served by
the CAN Interface module. The following parameters of CanController config container shall be referenced by this link: Can
ControllerId, CanWakeupSourceRef
Range: 0..max. number of underlying supported CAN controllers
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanIf_00636]

BSW Module BSW Context

CanIf CanIf/CanIfCtrlDrvCfg/CanIfCtrlCfg
BSW Parameter BSW Type
CanIfCtrlId ECUC-INTEGER-PARAM-DEF
5

1191 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

1194 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

BSW Module BSW Context

CanIf CanIf/CanIfDispatchCfg
BSW Parameter BSW Type
CanIfDispatchUserCtrlBusOffName ECUC-FUNCTION-NAME-DEF
5

1195 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

System Template
AUTOSAR CP R21-11

4
Mapping Rule Mapping Type
local
Mapping Status ECUC Parameter ID
valid [ECUC_CanIf_00686]

BSW Module BSW Context

CanIf CanIf/CanIfDispatchCfg
BSW Parameter BSW Type
CanIfDispatchUserValidateWakeupEventName ECUC-FUNCTION-NAME-DEF
BSW Description
This parameter defines the name of <User_ValidateWakeupEvent>. This parameter depends on the parameter CanIf
DispatchUserValidateWakeupEventUL. If CanIfDispatchUserValidateWakeupEventUL equals ECUM, the name of <User_
ValidateWakeupEvent> is fixed. If CanIfDispatchUserValidateWakeupEventUL equals CDD, the name of <User_Validate
WakeupEvent> is selectable.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanIf_00531]

BSW Module BSW Context

CanIf CanIf/CanIfDispatchCfg
BSW Parameter BSW Type
CanIfDispatchUserValidateWakeupEventUL ECUC-ENUMERATION-PARAM-DEF
BSW Description
This parameter defines the upper layer (UL) module to which the notifications about positive former requested wake up
sources have to be routed via <User_ValidateWakeupEvent>.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanIf_00549]

BSW Module BSW Context

CanIf CanIf
BSW Parameter BSW Type
CanIfInitCfg ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
5

1198 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

1200 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
local
Mapping Status ECUC Parameter ID
valid [ECUC_CanIf_00257]

BSW Module BSW Context

CanIf CanIf/CanIfInitCfg/CanIfInitHohCfg
BSW Parameter BSW Type
CanIfHrhCfg ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container contains configuration parameters for each hardware receive object (HRH).
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanIf_00259]

BSW Module BSW Context

CanIf CanIf/CanIfInitCfg/CanIfInitHohCfg/CanIfHrhCfg
BSW Parameter BSW Type
CanIfHrhCanCtrlIdRef ECUC-REFERENCE-DEF
BSW Description
Reference to controller Id to which the HRH belongs to. A controller can contain one or more HRHs.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanIf_00631]

BSW Module BSW Context

CanIf CanIf/CanIfInitCfg/CanIfInitHohCfg/CanIfHrhCfg
BSW Parameter BSW Type
CanIfHrhIdSymRef ECUC-REFERENCE-DEF
BSW Description
The parameter refers to a particular HRH object in the CanDrv configuration (see CanHardwareObject ECUC_Can_00324).
CanIf receives the following information of the CanDrv module by this reference:
• CanHandleType (see ECUC_Can_00323)
• CanObjectId (see ECUC_Can_00326)
5

1201 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

CanIf CanIf/CanIfInitCfg/CanIfInitHohCfg/CanIfHrhCfg/CanIfHrhRangeCfg
BSW Parameter BSW Type
CanIfHrhRangeMask ECUC-INTEGER-PARAM-DEF
5

1202 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

CanIf CanIf/CanIfInitCfg/CanIfInitHohCfg/CanIfHthCfg
BSW Parameter BSW Type
CanIfHthCanCtrlIdRef ECUC-REFERENCE-DEF
BSW Description
Reference to controller Id to which the HTH belongs to. A controller can contain one or more HTHs.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanIf_00625]

BSW Module BSW Context

CanIf CanIf/CanIfInitCfg/CanIfInitHohCfg/CanIfHthCfg
BSW Parameter BSW Type
CanIfHthIdSymRef ECUC-REFERENCE-DEF
BSW Description
The parameter refers to a particular HTH object in the CanDrv configuration (see CanHardwareObject ECUC_Can_00324).
CanIf receives the following information of the CanDrv module by this reference:
• CanHandleType (see ECUC_Can_00323)
• CanObjectId (see ECUC_Can_00326)
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanIf_00627]

BSW Module BSW Context

CanIf CanIf/CanIfInitCfg
BSW Parameter BSW Type
CanIfMaxBufferSize ECUC-INTEGER-PARAM-DEF
BSW Description
Maximum total size of all Tx buffers. This parameter is needed only in case of post-build loadable implementation using static
memory allocation.
5

1205 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

BSW Module BSW Context

CanIf CanIf/CanIfInitCfg
BSW Parameter BSW Type
CanIfRxPduCfg ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
5

1206 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
This container contains the configuration (parameters) of each receive CAN L-PDU.
The SHORT-NAME of "CanIfRxPduConfig" container itself represents the symolic name of Receive L-PDU.
This L-SDU produces a meta data item of type CAN_ID_32.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanIf_00249]

BSW Module BSW Context

CanIf CanIf/CanIfInitCfg/CanIfRxPduCfg
BSW Parameter BSW Type
CanIfRxPduCanId ECUC-INTEGER-PARAM-DEF
BSW Description
CAN Identifier of Receive CAN L-PDUs used by the CAN Interface. Exa: Software Filtering. This parameter is used if exactly
one Can Identifier is assigned to the Pdu. If a range is assigned then the CanIfRxPduCanIdRange parameter shall be used.
Range: 11 Bit For Standard CAN Identifier ... 29 Bit For Extended CAN identifier
Template Description
This attribute is used to define the identifier this frame shall use on the CAN network.
M2 Parameter
SystemTemplate::Fibex::Fibex4Can::CanCommunication::CanFrameTriggering.identifier
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_CanIf_00598]

BSW Module BSW Context

CanIf CanIf/CanIfInitCfg/CanIfRxPduCfg
BSW Parameter BSW Type
CanIfRxPduCanIdMask ECUC-INTEGER-PARAM-DEF
BSW Description
Identifier mask which denotes relevant bits in the CAN Identifier. This parameter defines a CAN Identifier range in an
alternative way to CanIfRxPduCanIdRange. It identifies the bits of the configured CAN Identifier that must match the received
CAN Identifier. Range: 11 bits for Standard CAN Identifier, 29 bits for Extended CAN Identifier.
Template Description
Identifier mask which denotes the relevant bits in the CAN Identifier. Together with the identifier, this parameter defines a
CAN identifier range.
M2 Parameter
SystemTemplate::Fibex::Fibex4Can::CanCommunication::CanFrameTriggering.rxMask
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
5

1207 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

CanIf CanIf/CanIfInitCfg/CanIfRxPduCfg/CanIfRxPduCanIdType
BSW Parameter BSW Type
STANDARD_FD_CAN ECUC-ENUMERATION-LITERAL-DEF
BSW Description
CAN FD frame with standard identifier (11 bits)
Template Description
CanFrameTriggering.canAddressingMode:
The CAN protocol supports two types of frame formats. The standard frame format uses 11-bit identifiers and is defined in
the CAN specification 2.0 A. Additionally the extended frame format allows 29-bit identifiers and is defined in the CAN
specification 2.0 B.
CanFrameTriggering.canFrameRxBehavior:
Defines which CAN protocol shall be expected for frame reception.
M2 Parameter
SystemTemplate::Fibex::Fibex4Can::CanCommunication::CanFrameTriggering.canAddressingMode, System
Template::Fibex::Fibex4Can::CanCommunication::CanFrameTriggering.canFrameRxBehavior
Mapping Rule Mapping Type
canAddressingMode = "standard" and canFrameRxBehavior = "canFd". full
Mapping Status ECUC Parameter ID
valid

BSW Module BSW Context

CanIf CanIf/CanIfInitCfg/CanIfRxPduCfg/CanIfRxPduCanIdType
BSW Parameter BSW Type
STANDARD_NO_FD_CAN ECUC-ENUMERATION-LITERAL-DEF
BSW Description
5

1211 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
CAN 2.0 frame with standard identifier (11 bits)
Template Description
CanFrameTriggering.canAddressingMode:
The CAN protocol supports two types of frame formats. The standard frame format uses 11-bit identifiers and is defined in
the CAN specification 2.0 A. Additionally the extended frame format allows 29-bit identifiers and is defined in the CAN
specification 2.0 B.
CanFrameTriggering.canFrameRxBehavior:
Defines which CAN protocol shall be expected for frame reception.
M2 Parameter
SystemTemplate::Fibex::Fibex4Can::CanCommunication::CanFrameTriggering.canAddressingMode, System
Template::Fibex::Fibex4Can::CanCommunication::CanFrameTriggering.canFrameRxBehavior
Mapping Rule Mapping Type
canAddressingMode = "standard" and canFrameRxBehavior = "can20". full
Mapping Status ECUC Parameter ID
valid

CanIf CanIf/CanIfInitCfg/CanIfRxPduCfg
BSW Parameter BSW Type
CanIfRxPduReadData ECUC-BOOLEAN-PARAM-DEF
BSW Description
5

1213 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

CanIf CanIf/CanIfInitCfg/CanIfRxPduCfg
5

1214 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
BSW Parameter BSW Type
CanIfRxPduUserRxIndicationName ECUC-FUNCTION-NAME-DEF
BSW Description
This parameter defines the name of the <User_RxIndication>. This parameter depends on the parameter CanIfRxPduUserRx
IndicationUL. If CanIfRxPduUserRxIndicationUL equals CAN_TP, CAN_NM, PDUR, XCP, CAN_TSYN, J1939NM or J1939TP,
the name of the <User_RxIndication> is fixed. If CanIfRxPduUserRxIndicationUL equals CDD, the name of the <User_Rx
Indication> is selectable.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_CanIf_00133]

BSW Module BSW Context

CanIf CanIf/CanIfInitCfg/CanIfRxPduCfg/CanIfTTRxFrameTriggering
BSW Parameter BSW Type
CanTTRxJoblistTimeMark ECUC-INTEGER-PARAM-DEF
BSW Description
Defines the point in time, when the joblist execution funciton (JLEF) shall be called for the referenced rx trigger. Value is given
in cycle time. This parameter is only configurable if a joblist is enabled by parameter CanIfTTJobList.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_CanIf_00136]

BSW Module BSW Context

CanIf CanIf/CanIfInitCfg
BSW Parameter BSW Type
CanIfTxPduCfg ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
5

1216 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

BSW Module BSW Context

CanIf CanIf/CanIfInitCfg/CanIfTxPduCfg/CanIfTxPduCanIdType
BSW Parameter BSW Type
EXTENDED_CAN ECUC-ENUMERATION-LITERAL-DEF
BSW Description
CAN frame with extended identifier (29 bits)
Template Description
CanFrameTriggering.canAddressingMode:
The CAN protocol supports two types of frame formats. The standard frame format uses 11-bit identifiers and is defined in
the CAN specification 2.0 A. Additionally the extended frame format allows 29-bit identifiers and is defined in the CAN
specification 2.0 B.
CanFrameTriggering.canFrameTxBehavior:
Defines which CAN protocol shall be used for frame transmission.
M2 Parameter
SystemTemplate::Fibex::Fibex4Can::CanCommunication::CanFrameTriggering.canAddressingMode, System
Template::Fibex::Fibex4Can::CanCommunication::CanFrameTriggering.canFrameTxBehavior
Mapping Rule Mapping Type
canAddressingMode = "extended" and canFrameRxBehavior = "can20". full
Mapping Status ECUC Parameter ID
valid

BSW Module BSW Context

CanIf CanIf/CanIfInitCfg/CanIfTxPduCfg/CanIfTxPduCanIdType
BSW Parameter BSW Type
EXTENDED_FD_CAN ECUC-ENUMERATION-LITERAL-DEF
BSW Description
CAN FD frame with extended identifier (29 bits)
Template Description
CanFrameTriggering.canAddressingMode:
The CAN protocol supports two types of frame formats. The standard frame format uses 11-bit identifiers and is defined in
the CAN specification 2.0 A. Additionally the extended frame format allows 29-bit identifiers and is defined in the CAN
specification 2.0 B.
CanFrameTriggering.canFrameTxBehavior:
Defines which CAN protocol shall be used for frame transmission.
M2 Parameter
SystemTemplate::Fibex::Fibex4Can::CanCommunication::CanFrameTriggering.canAddressingMode, System
Template::Fibex::Fibex4Can::CanCommunication::CanFrameTriggering.canFrameTxBehavior
Mapping Rule Mapping Type
canAddressingMode = "extended" and canFrameRxBehavior = "canFd". full
Mapping Status ECUC Parameter ID
valid

BSW Module BSW Context

CanIf CanIf/CanIfInitCfg/CanIfTxPduCfg/CanIfTxPduCanIdType
5

1220 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

CanIf CanIf/CanIfInitCfg/CanIfTxPduCfg
BSW Parameter BSW Type
CanIfTxPduPnFilterPdu ECUC-BOOLEAN-PARAM-DEF
BSW Description
If CanIfPublicPnFilterSupport is enabled, by this parameter PDUs could be configured which will pass the CanIfPnFilter. If
there is no CanIfTxPduPnFilterPdu configured per controller, the corresponding controller applies no CanIfPnFilter.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanIf_00773]

BSW Module BSW Context

CanIf CanIf/CanIfInitCfg/CanIfTxPduCfg
BSW Parameter BSW Type
CanIfTxPduReadNotifyStatus ECUC-BOOLEAN-PARAM-DEF
BSW Description
Enables and disables transmit confirmation for each transmit CAN L-SDU for reading its notification status.
True: Enabled False: Disabled
Template Description

M2 Parameter

CanIf CanIf/CanIfInitCfg/CanIfTxPduCfg
BSW Parameter BSW Type
CanIfTxPduTruncation ECUC-BOOLEAN-PARAM-DEF
BSW Description
Enables/disables truncation of PDUs that exceed the configured size.
Template Description

1225 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
CanIfFixedBuffer ECUC-BOOLEAN-PARAM-DEF
BSW Description
This parameter defines if the buffer element length shall be fixed to 8 Bytes for buffers to which only PDUs < 8 Bytes are
assigned.
TRUE: Minimum buffer element length is fixed to 8 Bytes. FALSE: Buffer element length depends on the configured length of
the referenced global PDUs (see ECUC_EcuC_00078).
Template Description

Mapping Status ECUC Parameter ID

valid [ECUC_CanIf_00675]

BSW Module BSW Context

CanIf CanIf/CanIfPrivateCfg
BSW Parameter BSW Type
CanIfTTGeneral ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
CanIfTTGeneral is specified in the SWS TTCAN Interface and defines if and in which way TTCAN is supported.
This container is only included and valid if TTCAN is supported by the controller, enabled (see CanIfSupportTTCAN, ECUC_
CanIf_00675), and used.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanIf_00005]

BSW Module BSW Context

CanIf CanIf/CanIfPrivateCfg/CanIfTTGeneral
BSW Parameter BSW Type
CanIfTTDemEventParameterRefs ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Container for the references to DemEventParameter elements which shall be invoked using the API Dem_SetEventStatus in
case the corresponding error occurs. The EventId is taken from the referenced DemEventParameter’s DemEventId symbolic
value. The standardized errors are provided in this container and can be extended by vendor-specific error references.
Template Description

M2 Parameter

Mapping Rule Mapping Type

1227 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Mapping Status ECUC Parameter ID
valid [ECUC_CanIf_00835]

BSW Module BSW Context

CanIf CanIf/CanIfPrivateCfg/CanIfTTGeneral/CanIfTTDemEventParameterRefs
BSW Parameter BSW Type
CANIF_TT_E_JLE_SYNC ECUC-REFERENCE-DEF
BSW Description
Reference to configured DEM event to report that the JLEF lost synchronization to the local time of the TTCAN controller.
Template Description

Mapping Status ECUC Parameter ID

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_CanIf_00854]

BSW Module BSW Context

CanIf CanIf/CanIfPublicCfg
BSW Parameter BSW Type
CanIfMetaDataSupport ECUC-BOOLEAN-PARAM-DEF
BSW Description
Enable support for dynamic ID handling using L-SDU MetaData.
5

1230 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

CanIf CanIf/CanIfPublicCfg
BSW Parameter BSW Type
CanIfPublicMultipleDrvSupport ECUC-BOOLEAN-PARAM-DEF
5

1231 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

CanIf CanIf/CanIfPublicCfg
BSW Parameter BSW Type
CanIfPublicTxBuffering ECUC-BOOLEAN-PARAM-DEF
BSW Description
Enables and disables the buffering of transmit L-PDUs (rejected by the CanDrv) within the CAN Interface module.
True: Enabled False: Disabled
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanIf_00618]

BSW Module BSW Context

CanIf CanIf/CanIfPublicCfg
BSW Parameter BSW Type
CanIfPublicTxConfirmPollingSupport ECUC-BOOLEAN-PARAM-DEF
BSW Description
Configuration parameter to enable/disable the API to poll for Tx Confirmation state.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanIf_00733]

BSW Module BSW Context

CanIf CanIf/CanIfPublicCfg
BSW Parameter BSW Type
CanIfPublicWakeupCheckValidByNM ECUC-BOOLEAN-PARAM-DEF
BSW Description
If enabled, only NM messages shall validate a detected wake-up event in CanIf. If disabled, all received messages
corresponding to a configured Rx PDU shall validate such a wake-up event. This parameter depends on CanIfPublicWakeup
CheckValidSupport and shall only be configurable, if it is enabled.
True: Enabled False: Disabled
5

1234 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanIf_00741]

BSW Module BSW Context

CanIf CanIf/CanIfPublicCfg
BSW Parameter BSW Type
CanIfPublicWakeupCheckValidSupport ECUC-BOOLEAN-PARAM-DEF
BSW Description
Selects support for wake up validation
True: Enabled False: Disabled
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanIf_00611]

BSW Module BSW Context

CanIf CanIf/CanIfPublicCfg
BSW Parameter BSW Type
CanIfSecurityEventRefs ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Container for the references to IdsMEvent elements representing the security events that the CanIf module shall report to the
IdsM in case the coresponding security related event occurs (and if CanIfEnableSecurityEventReporting is set to "true"). The
standardized security events in this container can be extended by vendor-specific security events.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_CanIf_00849]

BSW Module BSW Context

CanIf CanIf/CanIfPublicCfg/CanIfSecurityEventRefs
BSW Parameter BSW Type
5

1235 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

BSW Module BSW Context

CanIf CanIf/CanIfPublicCfg/CanIfSecurityEventRefs
BSW Parameter BSW Type
5

1236 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
CANIF_SEV_TX_ERROR_DETECTED ECUC-REFERENCE-DEF
BSW Description
A transmission related error was detected. Depending on the context data this could indicate suspicious CAN activity.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_CanIf_00850]

BSW Module BSW Context

CanIf CanIf/CanIfPublicCfg
BSW Parameter BSW Type
CanIfSetBaudrateApi ECUC-BOOLEAN-PARAM-DEF
BSW Description
Configuration parameter to enable/disable the CanIf_SetBaudrate API to change the baud rate of a CAN Controller. If this
parameter is set to true the CanIf_SetBaudrate API shall be supported. Otherwise the API is not supported.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanIf_00838]

BSW Module BSW Context

CanIf CanIf/CanIfPublicCfg
BSW Parameter BSW Type
CanIfTriggerTransmitSupport ECUC-BOOLEAN-PARAM-DEF
BSW Description
Enables the CanIf_TriggerTransmit API at Pre-Compile-Time. Therefore, this parameter defines if there shall be support for
trigger transmit transmissions. TRUE: Enabled FALSE: Disabled
Template Description

Mapping Status ECUC Parameter ID

1238 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
valid [ECUC_CanIf_00843]

BSW Module BSW Context

CanIf CanIf
BSW Parameter BSW Type
CanIfTrcvDrvCfg ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container contains the configuration (parameters) of all addressed CAN transceivers by each underlying CAN
Transceiver Driver module. For each CAN transceiver Driver a seperate instance of this container shall be provided.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanIf_00273]

BSW Module BSW Context

CanIf CanIf/CanIfTrcvDrvCfg
BSW Parameter BSW Type
CanIfTrcvCfg ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container contains the configuration (parameters) of one addressed CAN transceiver by the underlying CAN Transceiver
Driver module. For each CAN transceiver a seperate instance of this container has to be provided.
Template Description

M2 Parameter

System Template
AUTOSAR CP R21-11

1241 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
valid [ECUC_CanTrcv_-
00101]

BSW Module BSW Context

CanTrcv CanTrcv/CanTrcvConfigSet/CanTrcvChannel/CanTrcvAccess
BSW Parameter BSW Type
CanTrcvDioAccess ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Container gives CAN transceiver driver information about accessing ports and port pins. In addition relation between CAN
transceiver hardware pin names and Dio port access information is given. If a CAN transceiver hardware has no Dio
interface, there is no instance of this container.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_CanTrcv_-
00145]

BSW Module BSW Context

CanTrcv CanTrcv/CanTrcvConfigSet/CanTrcvChannel/CanTrcvAccess/CanTrcvDioAccess
BSW Parameter BSW Type
CanTrcvDioChannelAccess ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Container gives DIO channel access by single Can transceiver channel.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_CanTrcv_-
00157]

BSW Module BSW Context

CanTrcv CanTrcv/CanTrcvConfigSet/CanTrcvChannel/CanTrcvAccess/CanTrcvDioAccess/CanTrcvDio
ChannelAccess
BSW Parameter BSW Type
CanTrcvDioSymNameRef ECUC-CHOICE-REFERENCE-DEF
BSW Description
Choice Reference to a DIO Port, DIO Channel or DIO Channel Group. This reference replaces the CANTRCV_DIO_PORT_
SYM_NAME, CANTRCV_DIO_CHANNEL_SYM_NAME and CANTRCV_DIO_GROUP_SYM_NAME references in the Can
Trcv SWS.
5

1242 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

1245 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

BSW Module BSW Context

CanTrcv CanTrcv/CanTrcvConfigSet/CanTrcvChannel/CanTrcvDemEventParameterRefs
BSW Parameter BSW Type
5

1246 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

1247 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

CanTrcv CanTrcv/CanTrcvConfigSet/CanTrcvChannel
BSW Parameter BSW Type
CanTrcvInitState ECUC-ENUMERATION-PARAM-DEF
BSW Description
State of CAN transceiver after call to CanTrcv_Init.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_CanTrcv_-
00146]

BSW Module BSW Context

CanTrcv CanTrcv/CanTrcvConfigSet/CanTrcvChannel
BSW Parameter BSW Type
CanTrcvMaxBaudrate ECUC-INTEGER-PARAM-DEF
BSW Description
Indicates the data transfer rate in kbps. Maximum data transfer rate in kbps for transceiver hardware type. Only used for
validation purposes. This value can be used by configuration tools.
Template Description

CanTrcv CanTrcv/CanTrcvConfigSet/CanTrcvChannel/CanTrcvPartialNetwork
BSW Parameter BSW Type
CanTrcvBusErrFlag ECUC-BOOLEAN-PARAM-DEF
BSW Description
Indicates if the Bus Error (BUSERR) flag is managed by the BSW. This flag is set if a bus failure is detected by the
transceiver. TRUE = Supported by transceiver and managed by BSW. FALSE = Not managed by BSW.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_CanTrcv_-
00171]

BSW Module BSW Context

CanTrcv CanTrcv/CanTrcvConfigSet/CanTrcvChannel/CanTrcvPartialNetwork
BSW Parameter BSW Type
CanTrcvPnCanIdIsExtended ECUC-BOOLEAN-PARAM-DEF
BSW Description
Indicates whether extended or standard ID is used. TRUE = Extended Can identifier is used. FALSE = Standard Can
identifier is used
Template Description
5

1249 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Defines whether pncWakeupCanId and pncWakeupCanIdMask shall be interpreted as extended or standard CAN ID.
M2 Parameter
SystemTemplate::Fibex::Fibex4Can::CanTopology::CanCommunicationConnector.pncWakeupCanIdExtended
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_CanTrcv_-
00164]

BSW Module BSW Context

CanTrcv CanTrcv/CanTrcvConfigSet/CanTrcvChannel/CanTrcvPartialNetwork
BSW Parameter BSW Type
CanTrcvPnEnabled ECUC-BOOLEAN-PARAM-DEF
BSW Description
Indicates whether the selective wake-up function is enabled or disabled in HW.
TRUE = Selective wakeup feature is enabled in the transceiver hardware FALSE = Selective wakeup feature is disabled in the
transceiver hardware
Template Description

M2 Parameter

Mapping Rule Mapping Type

1251 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Bit mask for CAN Payload used to configure the CAN Transceiver for partial network wakeup.
M2 Parameter
SystemTemplate::Fibex::Fibex4Can::CanTopology::CanCommunicationConnector.pncWakeupDataMask
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_CanTrcv_-
00166]

BSW Module BSW Context

CanTrcv CanTrcv/CanTrcvConfigSet/CanTrcvChannel
BSW Parameter BSW Type
CanTrcvPorWakeupSourceRef ECUC-REFERENCE-DEF
BSW Description
Symbolic name reference to specify the wakeup sources that should be used in the calls to EcuM_SetWakeupEvent as
specified in [SWS_CanTrcv_00183] and [SWS_CanTrcv_00184].
This reference is mandatory if the HW supports POR or SYSERR flags
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_CanTrcv_-
00181]

BSW Module BSW Context

CanTrcv CanTrcv/CanTrcvConfigSet/CanTrcvChannel
BSW Parameter BSW Type
CanTrcvSyserrWakeupSourceRef ECUC-REFERENCE-DEF
BSW Description
Symbolic name reference to specify the wakeup sources that should be used in the calls to EcuM_SetWakeupEvent as
specified in [SWS_CanTrcv_00183] and [SWS_CanTrcv_00184]
This reference is mandatory if the HW supports POR or SYSERR flags
Template Description

M2 Parameter
5

1253 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_CanTrcv_-
00182]

BSW Module BSW Context

CanTrcv CanTrcv/CanTrcvConfigSet/CanTrcvChannel
BSW Parameter BSW Type
CanTrcvWakeupByBusUsed ECUC-BOOLEAN-PARAM-DEF
BSW Description
Is wake up by bus supported? If CAN transceiver hardware does not support wake up by bus value is always FALSE. If CAN
transceiver hardware supports wake up by bus value is TRUE or FALSE depending whether it is used or not. TRUE = Is
used. FALSE = Is not used.
Template Description
Defines whether the ECU shall be woken up by this CommunicationController.
TRUE: wake up is possible
FALSE: wake up is not supported
Note: If wakeUpByControllerSupported is set to TRUE the feature shall be supported by both hardware and basic software.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreTopology::CommunicationController.wakeUpByControllerSupported
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_CanTrcv_-
00148]

BSW Module BSW Context

CanTrcv CanTrcv/CanTrcvConfigSet/CanTrcvChannel
BSW Parameter BSW Type
CanTrcvWakeupSourceRef ECUC-REFERENCE-DEF
BSW Description
Reference to a wakeup source in the EcuM configuration.
This reference is only needed if CanTrcvWakeupByBusUsed is true.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

Mapping Rule Mapping Type

1255 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Mapping Status ECUC Parameter ID
valid [ECUC_CanTrcv_-
00090]

BSW Module BSW Context

CanTrcv CanTrcv/CanTrcvGeneral
BSW Parameter BSW Type
CanTrcvDevErrorDetect ECUC-BOOLEAN-PARAM-DEF
BSW Description
Switches the development error detection and notification on or off.
• true: detection and notification is enabled.
• false: detection and notification is disabled.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_CanTrcv_-
00152]

BSW Module BSW Context

CanTrcv CanTrcv/CanTrcvGeneral
BSW Parameter BSW Type
CanTrcvEcucPartitionRef ECUC-REFERENCE-DEF
BSW Description
Maps the CAN transceiver driver to zero or multiple ECUC partitions to make the modules API available in this partition. The
module will operate as an independent instance in each of the partitions.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_CanTrcv_-
00186]

BSW Module BSW Context

CanTrcv CanTrcv/CanTrcvGeneral
BSW Parameter BSW Type
CanTrcvTimerType ECUC-ENUMERATION-PARAM-DEF
5

1257 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

BSW Module BSW Context

CanTrcv CanTrcv/CanTrcvGeneral
5

1258 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
BSW Parameter BSW Type
CanTrcvWakeUpSupport ECUC-ENUMERATION-PARAM-DEF
BSW Description
Informs whether wake up is supported by polling or not supported. In case no wake up is supported by the hardware, setting
has to be NOT_SUPPORTED. Only in the case of wake up supported by polling, function CanTrcv_MainFunction has to be
present and to be invoked by the scheduler.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_CanTrcv_-
00154]

C.2.4 CanNm Mapping

BSW Module BSW Context

CanNm CanNm
BSW Parameter BSW Type
CanNmGlobalConfig ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container contains the global configuration parameter of the CanNm. The parameters and the parameters of the sub
containers shall be mapped to the C data type CanNm_ConfigType (for parameters where it is possible) which is passed to
the CanNm_Init function.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanNm_-
00001]

BSW Module BSW Context

CanNm CanNm/CanNmGlobalConfig
BSW Parameter BSW Type
CanNmBusLoadReductionEnabled ECUC-BOOLEAN-PARAM-DEF
BSW Description
Pre-processor switch for enabling busload reduction support.
Template Description
Enables busload reduction support
M2 Parameter
SystemTemplate::NetworkManagement::CanNmClusterCoupling.nmBusloadReductionEnabled
Mapping Rule Mapping Type
5

1259 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

1263 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
If set to true this attribute enables the support of CarWakeUp bit evaluation in received NmPdus.
M2 Parameter
SystemTemplate::NetworkManagement::CanNmNode.nmCarWakeUpRxEnabled
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_CanNm_-
00074]

BSW Module BSW Context

CanNm CanNm/CanNmGlobalConfig/CanNmChannelConfig
BSW Parameter BSW Type
CanNmComMNetworkHandleRef ECUC-REFERENCE-DEF
BSW Description
This reference points to the unique channel defined by the ComMChannel and provides access to the unique channel index
value in ComMChannelId.
Template Description

1267 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

CanNm CanNm/CanNmGlobalConfig/CanNmChannelConfig
BSW Parameter BSW Type
CanNmPnEraRxNSduRef ECUC-REFERENCE-DEF
BSW Description
Reference to a Pdu in the COM-Stack. The SduRef is required for every CanNm Channel, because ERA is reported per
channel.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanNm_-
00079]

BSW Module BSW Context

CanNm CanNm/CanNmGlobalConfig/CanNmChannelConfig
BSW Parameter BSW Type
CanNmPnHandleMultipleNetworkRequests ECUC-BOOLEAN-PARAM-DEF
BSW Description
Specifies if CanNm performs an additional transition from Network Mode to Repeat Message State (true) or not (false).
Template Description

System Template
AUTOSAR CP R21-11

4
M2 Parameter
SystemTemplate::NetworkManagement::NmCluster.nmRepeatMsgIndEnabled
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_CanNm_-
00089]

BSW Module BSW Context

CanNm CanNm/CanNmGlobalConfig/CanNmChannelConfig
BSW Parameter BSW Type
CanNmRxPdu ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container is used to configure the Rx PDU properties that are used for the CanNm Channel.
Template Description

M2 Parameter
SystemTemplate::NetworkManagement::NmNode.rxNmPdu
Mapping Rule Mapping Type
Create container for each NmPdu that is received on the regarded Nm cluster full
Mapping Status ECUC Parameter ID
valid [ECUC_CanNm_-
00038]

BSW Module BSW Context

CanNm CanNm/CanNmGlobalConfig/CanNmChannelConfig/CanNmRxPdu
BSW Parameter BSW Type
CanNmRxPduId ECUC-INTEGER-PARAM-DEF
BSW Description
This parameter defines the Rx PDU ID of the CanIf L-PDU range that is associated with this CanNm channel.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanNm_-
00054]

BSW Module BSW Context

CanNm CanNm/CanNmGlobalConfig/CanNmChannelConfig/CanNmRxPdu
BSW Parameter BSW Type
5

1272 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
CanNmRxPduRef ECUC-REFERENCE-DEF
BSW Description
Reference to the global PDU that is used by this CanNm channel.
Template Description

M2 Parameter

System Template
AUTOSAR CP R21-11

4
Handle Id to be used by the Lower Layer to confirm the transmission of the CanNmTxPdu to the LowerLayer.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanNm_-
00048]

BSW Module BSW Context

CanNm CanNm/CanNmGlobalConfig/CanNmChannelConfig/CanNmTxPdu
BSW Parameter BSW Type
CanNmTxPduRef ECUC-REFERENCE-DEF
BSW Description
The reference to the common PDU structure.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanNm_-
00037]

CanNm CanNm/CanNmGlobalConfig
BSW Parameter BSW Type
CanNmImmediateTxconfEnabled ECUC-BOOLEAN-PARAM-DEF
BSW Description
Enable/disable the immediate tx confirmation.
5

1279 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanNm_-
00041]

BSW Module BSW Context

CanNm CanNm/CanNmGlobalConfig
BSW Parameter BSW Type
CanNmMainFunctionPeriod ECUC-FLOAT-PARAM-DEF
BSW Description
Call cycle in seconds of CanNm_MainFunction.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanNm_-
00032]

BSW Module BSW Context

CanNm CanNm/CanNmGlobalConfig
BSW Parameter BSW Type
CanNmPassiveModeEnabled ECUC-BOOLEAN-PARAM-DEF
BSW Description
Pre-processor switch for enabling support of the Passive Mode.
Template Description
Enables support of the Passive Mode. The passive mode is configurable per channel.
M2 Parameter
SystemTemplate::NetworkManagement::NmNode.nmPassiveModeEnabled
Mapping Rule Mapping Type
1:1 mapping. nmNode.nmPassiveModeEnabled shall always have the same value in all Nm full
Clusters with the same bus protocol in the scope of one EcuInstance.
Mapping Status ECUC Parameter ID
valid [ECUC_CanNm_-
00010]

1280 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

CanNm CanNm/CanNmGlobalConfig
BSW Parameter BSW Type
CanNmPduRxIndicationEnabled ECUC-BOOLEAN-PARAM-DEF
BSW Description
Pre-processor switch for enabling the PDU Rx Indication.
Template Description
Switch for enabling the PDU Rx Indication.
M2 Parameter
SystemTemplate::NetworkManagement::NmEcu.nmPduRxIndicationEnabled
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_CanNm_-
00011]

BSW Module BSW Context

CanNm CanNm/CanNmGlobalConfig
BSW Parameter BSW Type
CanNmPnEiraCalcEnabled ECUC-BOOLEAN-PARAM-DEF
BSW Description
Specifies if CanNm calculates the PN request information for internal an external requests. (EIRA) true: PN request are
calculated false: PN request are not calculated
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanNm_-
00070]

BSW Module BSW Context

CanNm CanNm/CanNmGlobalConfig
BSW Parameter BSW Type
CanNmPnEiraRxNSduRef ECUC-REFERENCE-DEF
BSW Description
Reference to a Pdu in the COM-Stack. Only one SduRef is required for CanNm because the EIRA is the aggregation over all
Can Channels.
Template Description

M2 Parameter

Mapping Rule Mapping Type

1281 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
local
Mapping Status ECUC Parameter ID
valid [ECUC_CanNm_-
00072]

BSW Module BSW Context

CanNm CanNm/CanNmGlobalConfig
BSW Parameter BSW Type
CanNmPnInfo ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
PN information configuration
Template Description

System Template
AUTOSAR CP R21-11

4
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreTopology::EcuInstance.pnResetTime
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_CanNm_-
00059]

BSW Module BSW Context

CanNm CanNm/CanNmGlobalConfig
BSW Parameter BSW Type
CanNmPnShutdownMessageRetransmissionDuration ECUC-FLOAT-PARAM-DEF
BSW Description
Specifies the duration in seconds of the retransmission phase of a PN shutdown message. A retransmission shall be
performed per affected NM channel, as long as the PN shutdown message could not be successfully sent and the
retransmission timer is running. The value shall be a multiple integral of CanNmMainFunctionPeriod.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanNm_-
00098]

BSW Module BSW Context

CanNm CanNm/CanNmGlobalConfig
BSW Parameter BSW Type
CanNmPnSyncShutdownErrorReactionEnabled ECUC-BOOLEAN-PARAM-DEF
BSW Description
Pre-processor switch for enabling reaction, if a top-level PNC coordinator received a PN shutdown message on a
NM-channel which refer to a ComM channel that is actively coordinated by a PNC gateway.
Template Description

System Template
AUTOSAR CP R21-11

4
SystemTemplate::NetworkManagement::NmEcu.nmUserDataEnabled
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_CanNm_-
00004]

BSW Module BSW Context

CanNm CanNm/CanNmGlobalConfig
BSW Parameter BSW Type
CanNmVersionInfoApi ECUC-BOOLEAN-PARAM-DEF
BSW Description
Pre-processor switch for enabling version info API support.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanNm_-
00003]

C.2.5 CanTp Mapping

BSW Module BSW Context

CanTp CanTp
BSW Parameter BSW Type
CanTpConfig ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container contains the configuration parameters and sub containers of the AUTOSAR CanTp module.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanTp_-
00290]

BSW Module BSW Context

CanTp CanTp/CanTpConfig
5

1287 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
BSW Parameter BSW Type
CanTpChannel ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container contains the configuration parameters of the CanTp channel.
Template Description
Configuration parameters of the CanTp channel.
M2 Parameter
SystemTemplate::TransportProtocols::CanTpChannel
Mapping Rule Mapping Type
Create Container ifor each CanTpChannel that exist in ECU Extract. full
Mapping Status ECUC Parameter ID
valid [ECUC_CanTp_-
00288]

BSW Module BSW Context

CanTp CanTp/CanTpConfig/CanTpChannel
BSW Parameter BSW Type
CanTpRxNSdu ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
The following parameters needs to be configured for each CAN N-SDU that the CanTp module receives via the CanTp
Channel. This N-SDU produces meta data items of type SOURCE_ADDRESS_16, TARGET_ADDRESS_16 and
ADDRESS_EXTENSION_8.
Template Description

M2 Parameter
SystemTemplate::TransportProtocols::CanTpConnection.tpSdu
Mapping Rule Mapping Type
Create container for each existing CanTpConnection that contains a reference to an N-SDU that is full
received.
Mapping Status ECUC Parameter ID
valid [ECUC_CanTp_-
00137]

BSW Module BSW Context

CanTp CanTp/CanTpConfig/CanTpChannel/CanTpRxNSdu
BSW Parameter BSW Type
CanTpBs ECUC-INTEGER-PARAM-DEF
BSW Description
Sets the number of N-PDUs the CanTp receiver allows the sender to send, before waiting for an authorization to continue
transmission of the following N-PDUs.For further details on this parameter value see ISO 15765-2 specification.
Template Description
The maximum number of N-PDUs the CanTp receiver allows the sender to send, before waiting for an authorization to
continue transmission of the following N-PDUs. For further details on this parameter value see ISO 15765-2 specification.
Note: For reasons of buffer length, the CAN Transport Layer can adapt the BS value within the limit of this maximum BS
M2 Parameter
5

1288 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

CanTp CanTp/CanTpConfig/CanTpChannel/CanTpRxNSdu/CanTpNTa
BSW Parameter BSW Type
CanTpNTa ECUC-INTEGER-PARAM-DEF
BSW Description
This parameter contains the transport protocol target address value.
Template Description
An ECUs TP address on the referenced channel. This represents the diagnostic Address.
M2 Parameter
SystemTemplate::TransportProtocols::CanTpAddress.tpAddress
Mapping Rule Mapping Type
The CanTPConnection contains a reference to the SDU and a relation to the TpNode that contains full
the TpAddress.
Mapping Status ECUC Parameter ID
valid [ECUC_CanTp_-
00255]

BSW Module BSW Context

CanTp CanTp/CanTpConfig/CanTpChannel/CanTpRxNSdu
BSW Parameter BSW Type
CanTpNar ECUC-FLOAT-PARAM-DEF
BSW Description
Value in seconds of the N_Ar timeout. N_Ar is the time for transmission of a CAN frame (any N_PDU) on the receiver side.
Template Description
This attribute states the timeout between the PDU transmit request of the Transport Layer to the Can Interface and the
corresponding confirmation of the Can Interface on the receiver side (for FC or AF). Specified in seconds.
M2 Parameter
SystemTemplate::TransportProtocols::CanTpNode.timeoutAr
Mapping Rule Mapping Type
1:1 mapping full
5

1291 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Mapping Status ECUC Parameter ID
valid [ECUC_CanTp_-
00277]

BSW Module BSW Context

CanTp CanTp/CanTpConfig/CanTpChannel/CanTpRxNSdu
BSW Parameter BSW Type
CanTpNbr ECUC-FLOAT-PARAM-DEF
BSW Description
Value in seconds of the performance requirement for (N_Br + N_Ar). N_Br is the elapsed time between the receiving
indication of a FF or CF or the transmit confirmation of a FC, until the transmit request of the next FC.
Template Description
Value in seconds of the performance requirement for (N_Br + N_Ar). N_Br is the elapsed time between the receiving
indication of a FF or CF or the transmit confirmation of a FC, until the transmit request of the next FC.
M2 Parameter
SystemTemplate::TransportProtocols::CanTpConnection.timeoutBr
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_CanTp_-
00245]

BSW Module BSW Context

CanTp CanTp/CanTpConfig/CanTpChannel/CanTpRxNSdu
BSW Parameter BSW Type
CanTpNcr ECUC-FLOAT-PARAM-DEF
BSW Description
Value in seconds of the N_Cr timeout. N_Cr is the time until reception of the next Consecutive Frame N_PDU.
Template Description
This parameter defines the timeout value for waiting for a CF or FF-x (in case of retry) after receiving the last CF or after
sending an FC or AF on the receiver side. Specified in seconds.
M2 Parameter
SystemTemplate::TransportProtocols::CanTpConnection.timeoutCr
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_CanTp_-
00279]

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanTp_-
00257]

BSW Module BSW Context

CanTp CanTp/CanTpConfig/CanTpChannel/CanTpRxNSdu
BSW Parameter BSW Type
CanTpRxNSduId ECUC-INTEGER-PARAM-DEF
BSW Description
Unique identifier user by the upper layer to call CanTp_CancelReceive, CanTp_ChangeParameter and CanTp_Read
Parameter.
Template Description

BSW Module BSW Context

CanTp CanTp/CanTpConfig/CanTpChannel/CanTpRxNSdu/CanTpRxTaType
BSW Parameter BSW Type
CANTP_FUNCTIONAL ECUC-ENUMERATION-LITERAL-DEF
BSW Description
Functional request type
Template Description
Functional request type
M2 Parameter
SystemTemplate::TransportProtocols::NetworkTargetAddressType.functional
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid

BSW Module BSW Context

CanTp CanTp/CanTpConfig/CanTpChannel/CanTpRxNSdu/CanTpRxTaType
BSW Parameter BSW Type
CANTP_PHYSICAL ECUC-ENUMERATION-LITERAL-DEF
BSW Description
Physical request type
Template Description
Physical request type
M2 Parameter
SystemTemplate::TransportProtocols::NetworkTargetAddressType.physical
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid

BSW Module BSW Context

CanTp CanTp/CanTpConfig/CanTpChannel/CanTpRxNSdu
BSW Parameter BSW Type
CanTpRxWftMax ECUC-INTEGER-PARAM-DEF
BSW Description
5

1296 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
This parameter indicates how many Flow Control wait N-PDUs can be consecutively transmitted by the receiver. It is local to
the node and is not transmitted inside the FC protocol data unit.
CanTpRxWftMax is used to avoid sender nodes being potentially hooked-up in case of a temporarily reception inability on the
part of the receiver nodes, whereby the sender could be waiting continuously.
Template Description
This attribute defines the maximum number of flow control PDUs that can be consecutively be transmitted by a receiver.
M2 Parameter
SystemTemplate::TransportProtocols::CanTpNode.maxFcWait
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_CanTp_-
00251]

BSW Module BSW Context

CanTp CanTp/CanTpConfig/CanTpChannel/CanTpRxNSdu
BSW Parameter BSW Type
CanTpSTmin ECUC-FLOAT-PARAM-DEF
BSW Description
Sets the duration of the minimum time the CanTp sender shall wait between the transmissions of two CF N-PDUs.
For further details on this parameter value see ISO 15765-2 specification.
Template Description
Sets the duration of the minimum time the CanTp sender shall wait between the transmissions of two CF N-PDUs.
M2 Parameter
SystemTemplate::TransportProtocols::CanTpNode.stMin
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_CanTp_-
00252]

BSW Module BSW Context

CanTp CanTp/CanTpConfig/CanTpChannel/CanTpRxNSdu
BSW Parameter BSW Type
CanTpTxFcNPdu ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Used for grouping of the ID of a PDU and the Reference to a PDU. This N-PDU produces a meta data item of type CAN_
ID_32.
Template Description

M2 Parameter
SystemTemplate::TransportProtocols::CanTpConnection.flowControlPdu
Mapping Rule Mapping Type
Create container if the CanTpConnection contains a reference to a FlowControlNPdu that is full
received by the regarded ECU.
5

1297 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Mapping Status ECUC Parameter ID
valid [ECUC_CanTp_-
00259]

BSW Module BSW Context

CanTp CanTp/CanTpConfig/CanTpChannel/CanTpRxNSdu/CanTpTxFcNPdu
BSW Parameter BSW Type
CanTpTxFcNPduConfirmationPduId ECUC-INTEGER-PARAM-DEF
BSW Description
Handle Id to be used by the CanIf to confirm the transmission of the CanTpTxFcNPdu to the CanIf module.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanTp_-
00287]

BSW Module BSW Context

CanTp CanTp/CanTpConfig/CanTpChannel/CanTpRxNSdu/CanTpTxFcNPdu
BSW Parameter BSW Type
CanTpTxFcNPduRef ECUC-REFERENCE-DEF
BSW Description
Reference to a Pdu in the COM-Stack.
Template Description

System Template
AUTOSAR CP R21-11

4
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_CanTp_-
00263]

BSW Module BSW Context

CanTp CanTp/CanTpConfig/CanTpChannel/CanTpTxNSdu
BSW Parameter BSW Type
CanTpNbs ECUC-FLOAT-PARAM-DEF
BSW Description
Value in seconds of the N_Bs timeout. N_Bs is the time of transmission until reception of the next Flow Control N_PDU.
Template Description
This parameter defines the timeout for waiting for an FC or AF on the sender side in an 1:1 connection. Specified in seconds.
M2 Parameter
SystemTemplate::TransportProtocols::CanTpConnection.timeoutBs
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_CanTp_-
00264]

BSW Module BSW Context

CanTp CanTp/CanTpConfig/CanTpChannel/CanTpTxNSdu
BSW Parameter BSW Type
CanTpNcs ECUC-FLOAT-PARAM-DEF
BSW Description
Value in seconds of the performance requirements relating to N_Cs. CanTpNcs is the time in which CanTp is allowed to
request from PduR the Tx data of a Consecutive Frame N_PDU.
Template Description
The attribute timeoutCs represents the time (in seconds) which elapses between the transmit request of a CF N-PDU until the
transmit request of the next CF N-PDU.
M2 Parameter
SystemTemplate::TransportProtocols::CanTpConnection.timeoutCs
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_CanTp_-
00265]

BSW Module BSW Context

CanTp CanTp/CanTpConfig/CanTpChannel/CanTpTxNSdu
5

1302 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

CanTp CanTp/CanTpConfig/CanTpChannel/CanTpTxNSdu
BSW Parameter BSW Type
CanTpTc ECUC-BOOLEAN-PARAM-DEF
BSW Description
Switch for enabling Transmit Cancellation.
Template Description
With this switch Tx Cancellation can be turned on or off. Please note that the Rx Cancellation is always enabled.
M2 Parameter
SystemTemplate::TransportProtocols::CanTpConnection.cancellation
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_CanTp_-
00282]

BSW Module BSW Context

CanTp CanTp/CanTpConfig/CanTpChannel/CanTpTxNSdu
BSW Parameter BSW Type
CanTpTxAddressingFormat ECUC-ENUMERATION-PARAM-DEF
BSW Description
Declares which communication addressing format is supported for this TxNSdu. Definition of Enumeration values: CanTp
Standard to use normal addressing format. CanTpExtended to use extended addressing format. CanTpMixed to use mixed
11 bit addressing format. CanTpNormalFixed to use normal fixed addressing format. CanTpMixed29Bit to use mixed 29 bit
addressing format.
Template Description
Declares which communication addressing mode is supported.
M2 Parameter
SystemTemplate::TransportProtocols::CanTpConnection.addressingFormat
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_CanTp_-
00262]

BSW Module BSW Context

CanTp CanTp/CanTpConfig/CanTpChannel/CanTpTxNSdu
BSW Parameter BSW Type
5

1304 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
CanTpTxNPdu ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Used for grouping of the ID of a PDU and the Reference to a PDU. This N-PDU produces a meta data item of type CAN_
ID_32.
Template Description

BSW Module BSW Context

CanTp CanTp/CanTpConfig/CanTpChannel/CanTpTxNSdu/CanTpTxNPdu
BSW Parameter BSW Type
CanTpTxNPduConfirmationPduId ECUC-INTEGER-PARAM-DEF
BSW Description
Handle Id to be used by the CanIf to confirm the transmission of the CanTpTxNPdu to the CanIf module.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanTp_-
00286]

BSW Module BSW Context

CanTp CanTp/CanTpConfig/CanTpChannel/CanTpTxNSdu/CanTpTxNPdu
BSW Parameter BSW Type
CanTpTxNPduRef ECUC-REFERENCE-DEF
BSW Description
Reference to a Pdu in the COM-Stack.
Template Description

M2 Parameter

CanTp CanTp/CanTpConfig/CanTpChannel/CanTpTxNSdu
BSW Parameter BSW Type
CanTpTxPaddingActivation ECUC-ENUMERATION-PARAM-DEF
BSW Description
Defines if the transmit frame use padding or not. This parameter is restricted to 8 byte N-PDUs.
Definition of Enumeration values:
CanTpOn The transmit N-PDU uses padding for SF, FC and the last CF. (N-PDU length is always 8 bytes in case of CAN 2.0)
CanTpOff The transmit N-PDU does not use padding for SF, CF and the last CF. (N-PDU length is dynamic - any valid DLC
value). Note: The mandatory mapping to the next higher valid DLC value for N-PDUs with a length > 8 bytes is not affected
by this parameter.
Template Description
5

1306 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
This specifies whether or not Sfs, FCs and the last CF shall be padded to 8 bytes length in case it contains less payload.
true: The N-PDU received uses padding for SF, FC and the last CF. (N-PDU length is always 8 bytes)
false: The N-PDU received does not use padding for SF, CF and the last CF. (N-PDU length is dynamic)
M2 Parameter
SystemTemplate::TransportProtocols::CanTpConnection.paddingActivation
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_CanTp_-
00269]

BSW Module BSW Context

CanTp CanTp/CanTpConfig/CanTpChannel/CanTpTxNSdu
BSW Parameter BSW Type
CanTpTxTaType ECUC-ENUMERATION-PARAM-DEF
BSW Description
Declares the communication type of this TxNsdu.
Enumeration values: CanTpPhysical. Used for 1:1 communication. CanTpFunctional. Used for 1:n communication.
Template Description
Network Target Address type.
M2 Parameter
SystemTemplate::TransportProtocols::CanTpConnection.taType
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_CanTp_-
00270]

BSW Module BSW Context

CanTp CanTp/CanTpConfig
BSW Parameter BSW Type
CanTpMainFunctionPeriod ECUC-FLOAT-PARAM-DEF
BSW Description
Allow to configure the time for the MainFunction (as float in seconds). The CanTpMainFunctionPeriod should be assigned a
value which is optimal regarding all of the timers configured for CanTp in TX and RX data transfer i.e. the differences from the
configured timing should be as small as possible. Please note: This period shall be the same as call cycle time of the periodic
task were CanTp Main function is called.
Template Description
The period between successive calls to the Main Function of the AUTOSAR TP. Specified in seconds.
M2 Parameter
SystemTemplate::TransportProtocols::CanTpEcu.cycleTimeMainFunction
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
5

1307 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
valid [ECUC_CanTp_-
00240]

BSW Module BSW Context

CanTp CanTp/CanTpConfig
BSW Parameter BSW Type
CanTpMaxChannelCnt ECUC-INTEGER-PARAM-DEF
BSW Description
Maximum number of channels. This parameter is needed only in case of post-build loadable implementation using static
memory allocation.
Template Description

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanTp_-
00302]

BSW Module BSW Context

CanTp CanTp/CanTpGeneral
BSW Parameter BSW Type
5

1309 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
CanTpFlexibleDataRateSupport ECUC-BOOLEAN-PARAM-DEF
BSW Description
Enable support for CAN FD frames.
Template Description

1311 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_CanSM_-
00123]

BSW Module BSW Context

CanSM CanSM/CanSMConfiguration
BSW Parameter BSW Type
CanSMManagerNetwork ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container contains the CAN network specific parameters of each CAN network
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_CanSM_-
00126]

BSW Module BSW Context

CanSM CanSM/CanSMConfiguration/CanSMManagerNetwork
BSW Parameter BSW Type
CanSMBorCounterL1ToL2 ECUC-INTEGER-PARAM-DEF
BSW Description
This threshold defines the count of bus-offs until the bus-off recovery switches from level 1 (short recovery time) to level 2
(long recovery time).
Template Description
This threshold defines the count of bus-offs until the bus-off recovery switches from level 1 (short recovery time) to level 2
(long recovery time).
M2 Parameter
SystemTemplate::Fibex::Fibex4Can::CanTopology::CanClusterBusOffRecovery.borCounterL1ToL2
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_CanSM_-
00131]

System Template
AUTOSAR CP R21-11

4
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanSM_-
00338]

BSW Module BSW Context

CanSM CanSM/CanSMConfiguration/CanSMManagerNetwork/CanSMController
BSW Parameter BSW Type
CanSMControllerId ECUC-REFERENCE-DEF
BSW Description
Unique handle to identify one certain CAN controller. Reference to one of the CAN controllers managed by the CanIf module.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_CanSM_-
00141]

BSW Module BSW Context

CanSM CanSM/CanSMConfiguration/CanSMManagerNetwork
BSW Parameter BSW Type
CanSMDemEventParameterRefs ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Container for the references to DemEventParameter elements which shall be invoked using the API Dem_SetEventStatus in
case the corresponding error occurs. The EventId is taken from the referenced DemEventParameter’s DemEventId symbolic
value. The standardized errors are provided in this container and can be extended by vendor-specific error references.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanSM_-
00127]

BSW Module BSW Context

CanSM CanSM/CanSMConfiguration/CanSMManagerNetwork/CanSMDemEventParameterRefs
5

1315 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
BSW Parameter BSW Type
CANSM_E_BUS_OFF ECUC-REFERENCE-DEF
BSW Description
Reference to configured DEM event to report bus off errors for this CAN network.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_CanSM_-
00070]

BSW Module BSW Context

CanSM CanSM/CanSMConfiguration/CanSMManagerNetwork/CanSMDemEventParameterRefs
BSW Parameter BSW Type
CANSM_E_MODE_REQUEST_TIMEOUT ECUC-REFERENCE-DEF
BSW Description
Reference to configured DEM event to report bus off errors for this CAN network.
Template Description

CanSM CanSM
BSW Parameter BSW Type
CanSMGeneral ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Container for general pre-compile parameters of the CanSM module
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_CanSM_-
00314]

BSW Module BSW Context

CanSM CanSM/CanSMGeneral
BSW Parameter BSW Type
CanSMDevErrorDetect ECUC-BOOLEAN-PARAM-DEF
BSW Description
Switches the development error detection and notification on or off.
• true: detection and notification is enabled.
• false: detection and notification is disabled.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanSM_-
00133]

BSW Module BSW Context

CanSM CanSM/CanSMGeneral
BSW Parameter BSW Type
CanSMGetBusOffDelayFunction ECUC-FUNCTION-NAME-DEF
BSW Description
This parameter configures the name of the <User_GetBusOffDelay> callout function, which is used by CanSM to acquire an
additional L1/L2 delay time. This function is only called for channels where CanSMEnableBusOffDelay is enabled.
5

1318 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanSM_-
00347]

BSW Module BSW Context

CanSM CanSM/CanSMGeneral
BSW Parameter BSW Type
CanSMGetBusOffDelayHeader ECUC-STRING-PARAM-DEF
BSW Description
This parameter configures the header file containing the prototype of the <User_GetBusOffDelay> callout function.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanSM_-
00348]

CanSM CanSM/CanSMGeneral
BSW Parameter BSW Type
CanSMTxOfflineActiveSupport ECUC-BOOLEAN-PARAM-DEF
BSW Description
Determines whether the ECU passive feature is supported by CanSM. True: Enabled False: Disabled
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

1320 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
valid [ECUC_CanSM_-
00349]

BSW Module BSW Context

CanSM CanSM/CanSMGeneral
BSW Parameter BSW Type
CanSMVersionInfoApi ECUC-BOOLEAN-PARAM-DEF
BSW Description
Activate/Deactivate the version information API (CanSM_GetVersionInfo).
true: version information API activated false: version information API deactivated
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_CanSM_-
00311]

C.3 J1939

C.3.1 J1939Tp Mapping

BSW Module BSW Context

J1939Tp J1939Tp
BSW Parameter BSW Type
J1939TpConfiguration ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container contains the configuration parameters and sub containers of the J1939Tp module that define the
communication paths.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_J1939Tp_-
00052]

System Template
AUTOSAR CP R21-11

J1939Tp J1939Tp/J1939TpConfiguration/J1939TpRxChannel
BSW Parameter BSW Type
J1939TpRxDynamicBlockCalculation ECUC-BOOLEAN-PARAM-DEF
BSW Description
Enable dynamic calculation of "number of packets that can be sent" value in TP.CM_CTS, based on the size of buffers in
upper layers reported via StartOfReception and PduR_J1939TpCopyRxData.
Template Description
Enable support for dynamic block size calculation.
M2 Parameter
SystemTemplate::TransportProtocols::J1939TpConnection.dynamicBs
Mapping Rule Mapping Type
Please note that in the System Template the dynamic block size calculation support is defined per full
J1939TpConnection. All J1939TpConnections in an ECU shall have the same value.
Mapping Status ECUC Parameter ID
valid [ECUC_J1939Tp_-
00187]

BSW Module BSW Context

J1939Tp J1939Tp/J1939TpConfiguration/J1939TpRxChannel
BSW Parameter BSW Type
J1939TpRxDynamicBufferRatio ECUC-INTEGER-PARAM-DEF
BSW Description
Percentage of available buffer that shall be used for retry. This parameter is only applicable when "J1939TpRxRetrySupport"
and "J1939TpRxDynamicBlockCalculation" are enabled.
Template Description
Defines usage of available data for dynamic block size calculation when protocol retry is enabled. This attribute describes in
percent of available buffer that shall be used for retry.
5

1325 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
M2 Parameter
SystemTemplate::TransportProtocols::J1939TpConnection.bufferRatio
Mapping Rule Mapping Type
Please note that in the System Template this attribute is defined per J1939TpConnection. All full
J1939TpConnections in an ECU shall have the same value.
Mapping Status ECUC Parameter ID
valid [ECUC_J1939Tp_-
00188]

BSW Module BSW Context

J1939Tp J1939Tp/J1939TpConfiguration/J1939TpRxChannel
BSW Parameter BSW Type
J1939TpRxPacketsPerBlock ECUC-INTEGER-PARAM-DEF
BSW Description
Number of TP.DT frames the receiving J1939Tp module allows the sender to send before waiting for another TP.CM_CTS.
This parameter is transmitted in the TP.CM_CTS frame, and is thus only relevant for reception of messages via CMDT. When
J1939TpRxDynamicBlockCalculation is enabled, this parameter specifies a maximum for the calculated value. For further
details on this parameter value see SAE J1939/21.
Template Description
Set maximum block size (number of packets in TP.CM_CTS).
M2 Parameter
SystemTemplate::TransportProtocols::J1939TpConnection.maxBs
Mapping Rule Mapping Type
Please note that in the System Template the maximum block size is defined per J1939Tp full
Connection. All J1939TpConnections in an ECU shall have the same value.
Mapping Status ECUC Parameter ID
valid [ECUC_J1939Tp_-
00189]

BSW Module BSW Context

J1939Tp J1939Tp/J1939TpConfiguration/J1939TpRxChannel
BSW Parameter BSW Type
J1939TpRxPg ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Parameter group received by the J1939 transport layer.
Template Description
A J1939TpPg represents one J1939 message (parameter group, PG) identified by the PGN (parameter group number) that
can be received or transmitted via J1939Tp.
M2 Parameter
SystemTemplate::TransportProtocols::J1939TpPg
Mapping Rule Mapping Type
Create container for each Rx J1939TpPg that is available in the Ecu Extract. full
Mapping Status ECUC Parameter ID
valid [ECUC_J1939Tp_-
00050]

1326 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

J1939Tp J1939Tp/J1939TpConfiguration/J1939TpRxChannel/J1939TpRxPg
BSW Parameter BSW Type
J1939TpRxDirectNPdu ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This N-PDU represents the short frame that is used for a dynamic length PGN when it has a length of less that 8 bytes. This
N-PDU consumes a meta data item of type CAN_ID_32.
Please note: This sub container is only necessary when J1939TpRxPgDynLength is TRUE.
Template Description

M2 Parameter
SystemTemplate::TransportProtocols::J1939TpPg.directPdu
Mapping Rule Mapping Type
Information can be derived from a received directlNPdu that is referenced by the J1939TpPg. full
Mapping Status ECUC Parameter ID
valid [ECUC_J1939Tp_-
00130]

BSW Module BSW Context

J1939Tp J1939Tp/J1939TpConfiguration/J1939TpRxChannel/J1939TpRxPg/J1939TpRxDirectNPdu
BSW Parameter BSW Type
J1939TpRxDirectNPduId ECUC-INTEGER-PARAM-DEF
BSW Description
The N-PDU identifier used for communication with CanIf.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_J1939Tp_-
00131]

BSW Module BSW Context

J1939Tp J1939Tp/J1939TpConfiguration/J1939TpRxChannel/J1939TpRxPg/J1939TpRxDirectNPdu
BSW Parameter BSW Type
J1939TpRxDirectNPduRef ECUC-REFERENCE-DEF
BSW Description
Reference to the Pdu object representing the N-PDU.
Template Description

M2 Parameter

Mapping Rule Mapping Type

1327 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
local
Mapping Status ECUC Parameter ID
valid [ECUC_J1939Tp_-
00132]

BSW Module BSW Context

J1939Tp J1939Tp/J1939TpConfiguration/J1939TpRxChannel/J1939TpRxPg
BSW Parameter BSW Type
J1939TpRxNSdu ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container describes the parameters that are relevant for the reception of a specific N-SDU. This N-SDU produces meta
data items of type SOURCE_ADDRESS_16, TARGET_ADDRESS_16, and PRIORITY_8.
Template Description

M2 Parameter
SystemTemplate::TransportProtocols::J1939TpPg.sdu
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_J1939Tp_-
00063]

BSW Module BSW Context

J1939Tp J1939Tp/J1939TpConfiguration/J1939TpRxChannel/J1939TpRxPg/J1939TpRxNSdu
BSW Parameter BSW Type
J1939TpRxNSduId ECUC-INTEGER-PARAM-DEF
BSW Description
This is a unique identifier for a received N-SDU. This Id is used in the CancelReceive and ChangeParameter API call.
Template Description

BSW Module BSW Context

J1939Tp J1939Tp/J1939TpConfiguration/J1939TpRxChannel/J1939TpTxFcNPdu
BSW Parameter BSW Type
J1939TpTxFcNPduRef ECUC-REFERENCE-DEF
BSW Description
Reference to the Pdu object representing the N-PDU.
Please note: When two channels have identical but exchanged source and destination addresses, the Pdu referenced by this
parameter is shared with J1939TpTxCmNPduRef of the corresponding J1939TpTxChannel.
Template Description

M2 Parameter

Mapping Rule Mapping Type

1331 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
local
Mapping Status ECUC Parameter ID
valid [ECUC_J1939Tp_-
00136]

BSW Module BSW Context

J1939Tp J1939Tp/J1939TpConfiguration/J1939TpRxChannel/J1939TpTxFcNPdu
BSW Parameter BSW Type
J1939TpTxFcNPduTxConfId ECUC-INTEGER-PARAM-DEF
BSW Description
The N-PDU identifier used for Tx confirmation from CanIf.
Template Description

J1939Tp J1939Tp/J1939TpConfiguration/J1939TpTxChannel/J1939TpRxFcNPdu
BSW Parameter BSW Type
J1939TpRxFcNPduId ECUC-INTEGER-PARAM-DEF
BSW Description
The N-PDU identifier used for communication with CanIf.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_J1939Tp_-
00145]

BSW Module BSW Context

J1939Tp J1939Tp/J1939TpConfiguration/J1939TpTxChannel/J1939TpRxFcNPdu
BSW Parameter BSW Type
J1939TpRxFcNPduRef ECUC-REFERENCE-DEF
BSW Description
Reference to the Pdu object representing the N-PDU.
Please note: When two channels have identical but exchanged source and destination addresses, the Pdu referenced by this
parameter is shared with J1939TpRxCmNPduRef of the corresponding J1939TpRxChannel.
Template Description

M2 Parameter

Mapping Rule Mapping Type

1333 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_J1939Tp_-
00170]

BSW Module BSW Context

J1939Tp J1939Tp/J1939TpConfiguration/J1939TpTxChannel
BSW Parameter BSW Type
J1939TpTxDa ECUC-INTEGER-PARAM-DEF
BSW Description
Destination address (DA) of this channel. This parameter is only required for channels with fixed DA which use N-PDUs with
MetaData containing the DA.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_J1939Tp_-
00180]

1335 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

J1939Tp J1939Tp/J1939TpConfiguration/J1939TpTxChannel
BSW Parameter BSW Type
J1939TpTxDtNPdu ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This N-PDU represents the TP.DT frame of a J1939 transport protocol session. TP.DT is used both by BAM and CMDT to
transfer the contents of an N-SDU. This N-PDU produces a meta data item of type CAN_ID_32.
Template Description

M2 Parameter
SystemTemplate::TransportProtocols::J1939TpConnection.dataPdu
Mapping Rule Mapping Type
Information can be derived from a transmitted NPdu that is referenced by the J1939TpConnection. full
Mapping Status ECUC Parameter ID
valid [ECUC_J1939Tp_-
00142]

BSW Module BSW Context

J1939Tp J1939Tp/J1939TpConfiguration/J1939TpTxChannel/J1939TpTxDtNPdu
BSW Parameter BSW Type
J1939TpTxDtNPduRef ECUC-REFERENCE-DEF
BSW Description
Reference to the Pdu object representing the N-PDU.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_J1939Tp_-
00143]

BSW Module BSW Context

J1939Tp J1939Tp/J1939TpConfiguration/J1939TpTxChannel/J1939TpTxDtNPdu
BSW Parameter BSW Type
J1939TpTxDtNPduTxConfId ECUC-INTEGER-PARAM-DEF
BSW Description
The N-PDU identifier used for Tx confirmation from CanIf.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
5

1336 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_J1939Tp_-
00149]

BSW Module BSW Context

J1939Tp J1939Tp/J1939TpConfiguration/J1939TpTxChannel/J1939TpTxPg/J1939TpTxNSdu
BSW Parameter BSW Type
J1939TpTxNSduRef ECUC-REFERENCE-DEF
BSW Description
Reference to the Pdu object representing the N-SDU.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_J1939Tp_-
00151]

BSW Module BSW Context

J1939Tp J1939Tp/J1939TpConfiguration/J1939TpTxChannel/J1939TpTxPg
BSW Parameter BSW Type
J1939TpTxPgDynLength ECUC-BOOLEAN-PARAM-DEF
BSW Description
This flag is set to TRUE when the N-SDU refers to a PGN with variable length.
Please note: When this attribute is TRUE, the sub container J1939TpTxDirectNPdu is required.
Template Description
The length of dynamic length signals is variable in run-time. Only a maximum length of such a signal is specified in the
configuration (attribute length in ISignal element).
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::SystemSignal.dynamicLength
Mapping Rule Mapping Type
If a tpSdu that is referenced by the J1939TpPg contains a dynamicLengthSignal than set this full
parameter to true.
Mapping Status ECUC Parameter ID
5

1340 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
valid [ECUC_J1939Tp_-
00148]

BSW Module BSW Context

J1939Tp J1939Tp/J1939TpConfiguration/J1939TpTxChannel/J1939TpTxPg
BSW Parameter BSW Type
J1939TpTxPgPGN ECUC-INTEGER-PARAM-DEF
BSW Description
PGN of the referenced N-SDUs.
Template Description
Parameter group number (PGN) of a J1939 message (parameter group, PG) that can be received or transmitted via J1939Tp.
The PGN may be omitted when the a directPdu is referenced and is mapped into a CanFrameTriggering with an identifier.
M2 Parameter
SystemTemplate::TransportProtocols::J1939TpPg.pgn
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_J1939Tp_-
00150]

BSW Module BSW Context

J1939Tp J1939Tp/J1939TpConfiguration/J1939TpTxChannel
BSW Parameter BSW Type
J1939TpTxProtocolType ECUC-ENUMERATION-PARAM-DEF
BSW Description
Protocol type used by this channel. This parameter is only required for channels with fixed destination address.
Template Description
BAM (Broadcast Announce Message) is a broadcast protocol. If this attribute is set to true broadcast is used. Since address
FF is the only broadcast address, there’s no reason to configure it.
M2 Parameter
SystemTemplate::TransportProtocols::J1939TpConnection.broadcast
Mapping Rule Mapping Type
If the braodcast attribute is set to true than set this parameter to J1939TP_PROTOCOL_BAM full
Mapping Status ECUC Parameter ID
valid [ECUC_J1939Tp_-
00137]

BSW Module BSW Context

J1939Tp J1939Tp/J1939TpConfiguration/J1939TpTxChannel
BSW Parameter BSW Type
J1939TpTxRetrySupport ECUC-BOOLEAN-PARAM-DEF
BSW Description
5

1341 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Enable support for repetition of failed transmission using TP.CM_CTS with a packet number that has already been sent.
Retransmission is handled via the retry feature of PduR_J1939TpCopyTxData.
Template Description
Enable support for protocol retry.
M2 Parameter
SystemTemplate::TransportProtocols::J1939TpConnection.retry
Mapping Rule Mapping Type
Please note that in the System Template the retry support is defined per J1939TpConnection. All full
J1939TpConnections in an ECU shall have the same value.
Mapping Status ECUC Parameter ID
valid [ECUC_J1939Tp_-
00193]

BSW Module BSW Context

J1939Tp J1939Tp/J1939TpConfiguration/J1939TpTxChannel
BSW Parameter BSW Type
J1939TpTxSa ECUC-INTEGER-PARAM-DEF
BSW Description
Source address (SA) of this channel. This parameter is only required for channels with fixed SA which use N-PDUs with Meta
Data containing the SA.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_J1939Tp_-
00181]

BSW Module BSW Context

J1939Tp J1939Tp
BSW Parameter BSW Type
J1939TpGeneral ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container describes the general configuration parameters of the J1939Tp module.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_J1939Tp_-
00033]

1342 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

J1939Tp J1939Tp/J1939TpGeneral
BSW Parameter BSW Type
J1939TpCancellationSupport ECUC-BOOLEAN-PARAM-DEF
BSW Description
Enable transmit and receive cancellation. The APIs J1939Tp_CancelTransmit() and J1939Tp_CancelReceive() will only be
available when this parameter is enabled.
Template Description
Enable support for Tx/Rx cancellation.
M2 Parameter
SystemTemplate::TransportProtocols::J1939TpConnection.cancellation
Mapping Rule Mapping Type
Please note that in the System Template the cancellation support is defined per J1939Tp full
Connection. All J1939TpConnections in an ECU shall have the same value.
Mapping Status ECUC Parameter ID
valid [ECUC_J1939Tp_-
00174]

BSW Module BSW Context

J1939Tp J1939Tp/J1939TpGeneral
BSW Parameter BSW Type
J1939TpDevErrorDetect ECUC-BOOLEAN-PARAM-DEF
BSW Description
Switches the development error detection and notification on or off.
• true: detection and notification is enabled.
• false: detection and notification is disabled.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_J1939Tp_-
00042]

BSW Module BSW Context

J1939Tp J1939Tp/J1939TpGeneral
BSW Parameter BSW Type
J1939TpMainFunctionPeriod ECUC-FLOAT-PARAM-DEF
BSW Description
Allow to configure the time for the MainFunction (in seconds). Please note: This configuration value shall be equal to the
value in the ScheduleManager module.
5

1343 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

J1939Nm J1939Nm/J1939NmConfigSet/J1939NmChannel
BSW Parameter BSW Type
J1939NmChannelUsesAddressArbitration ECUC-BOOLEAN-PARAM-DEF
BSW Description
Defines whether the nodes attached to this channel use an initial address claim, and whether they react to contending
address claims of other nodes.
True: The initial address claim is sent, and the node reacts to address claims of other nodes. False: The node only sends an
address claim upon request, and does not react to other address claims.
Template Description
Defines whether the nodes attached to this channel use an initial address claim, and whether they react to contending
address claims of other nodes.
True: The initial address claim is sent, and the node reacts to address claims of other nodes.
False: The node only sends an address claim upon request, and does not care for contending address claims.
M2 Parameter
SystemTemplate::Fibex::Fibex4Can::CanTopology::J1939Cluster.usesAddressArbitration
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_J1939Nm_-
00035]

BSW Module BSW Context

J1939Nm J1939Nm/J1939NmConfigSet/J1939NmChannel
BSW Parameter BSW Type
J1939NmRxPdu ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Contains the configuration of the PDU used to receive the AddressClaimed PG. This PDU consumes a meta data item of type
CAN_ID_32.
Template Description

System Template
AUTOSAR CP R21-11

4
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_J1939Nm_-
00045]

BSW Module BSW Context

J1939Nm J1939Nm/J1939NmConfigSet/J1939NmExternalNode
BSW Parameter BSW Type
J1939NmExternalNodeNameIndustryGroup ECUC-INTEGER-PARAM-DEF
BSW Description
Industry Group field of the NAME of this external node.
Template Description
Industry Group field of the NAME of this node.
M2 Parameter
SystemTemplate::NetworkManagement::J1939NodeName.industryGroup
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_J1939Nm_-
00046]

BSW Module BSW Context

J1939Nm J1939Nm/J1939NmConfigSet/J1939NmExternalNode
BSW Parameter BSW Type
J1939NmExternalNodeNameManufacturerCode ECUC-INTEGER-PARAM-DEF
BSW Description
Manufacturer Code field of the NAME of this external node.
Template Description
Manufacturer Code field of the NAME of this node.
M2 Parameter
SystemTemplate::NetworkManagement::J1939NodeName.manufacturerCode
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_J1939Nm_-
00047]

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

J1939Nm J1939Nm/J1939NmConfigSet/J1939NmNode
BSW Parameter BSW Type
J1939NmNodeNameVehicleSystem ECUC-INTEGER-PARAM-DEF
BSW Description
Vehicle System field of the NAME of this node.
Template Description
Vehicle System field of the NAME of this node.
M2 Parameter
SystemTemplate::NetworkManagement::J1939NodeName.vehicleSystem
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_J1939Nm_-
00021]

BSW Module BSW Context

J1939Nm J1939Nm/J1939NmConfigSet/J1939NmNode
BSW Parameter BSW Type
J1939NmNodeNameVehicleSystemInstance ECUC-INTEGER-PARAM-DEF
BSW Description
Vehicle System Instance field of the NAME of this node.
Template Description
Vehicle System Instance field of the NAME of this node.
M2 Parameter
SystemTemplate::NetworkManagement::J1939NodeName.vehicleSystemInstance
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_J1939Nm_-
00020]

BSW Module BSW Context

J1939Nm J1939Nm/J1939NmConfigSet/J1939NmNode
BSW Parameter BSW Type
5

1353 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

System Template
AUTOSAR CP R21-11

4
BSW Parameter BSW Type
J1939DcmRxPdu ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Contains parameters to configure the J1939DcmRxPdu.
This PDU consumes meta data items of type CAN_ID_32 for PDUs received from CanIf, and of type SOURCE_
ADDRESS_16, TARGET_ADDRESS_16, and PRIORITY_8 for PDUs received from J1939Tp.
Template Description
Represents the IPdus handled by J1939Dcm.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::J1939DcmIPdu
Mapping Rule Mapping Type
The direction of the J1939DcmIPdu shall be derived from the PduTriggering and the references to full
IPduPorts.
Mapping Status ECUC Parameter ID
valid [ECUC_J1939Dcm_-
00046]

BSW Module BSW Context

J1939Dcm J1939Dcm/J1939DcmConfigSet/J1939DcmNode/J1939DcmDiagnosticMessageSupport
BSW Parameter BSW Type
J1939DcmTxPdu ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Contains parameters to configure the J1939DcmTxPdu.
This PDU produces meta data items of type CAN_ID_32 for PDUs transmitted via CanIf, and of type SOURCE_
ADDRESS_16, TARGET_ADDRESS_16, and PRIORITY_8 for PDUs transmitted via J1939Tp.
Template Description
Represents the IPdus handled by J1939Dcm.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::J1939DcmIPdu
Mapping Rule Mapping Type
The direction of the J1939DcmIPdu shall be derived from the PduTriggering and the references to full
IPduPorts.
Mapping Status ECUC Parameter ID
valid [ECUC_J1939Dcm_-
00045]

C.3.4 J1939Rm Mapping

BSW Module BSW Context

J1939Rm J1939Rm/J1939RmConfigSet
BSW Parameter BSW Type
J1939RmChannel ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Contains the parameters for a CAN channel supported by the J1939 Request Manager.
5

1356 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

J1939Rm J1939Rm/J1939RmConfigSet/J1939RmNode
BSW Parameter BSW Type
J1939RmUser ECUC-CHOICE-CONTAINER-DEF
BSW Description
Contains the configuration of a module that uses the request and acknowledgement interfaces of J1939Rm.
Template Description

M2 Parameter

1358 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Mapping Rule Mapping Type
+ J1939NM user exists always, UserPGN has 0x0ee00 as solitary value + J1939DCM user exists if full
transmitted J1939DcmIPdus exist which are requestable + COM user exists if transmitted ISignal
IPdus exist which are requestable + CDD user exists if transmitted UserDefinedPdus or User
DefinedIPdus exist which are requestable + RTE users cannot be derived
Mapping Status ECUC Parameter ID
valid [ECUC_J1939Rm_-
00010]

J1939Rm J1939Rm/J1939RmGeneral
BSW Parameter BSW Type
J1939RmSupportRequest2 ECUC-BOOLEAN-PARAM-DEF
BSW Description
Pre-processor switch for enabling support of the Request2 PG. Please note: Transfer is not supported.
Template Description
5

1361 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Enables support for the Request2 PGN (RQST2).
M2 Parameter
SystemTemplate::Fibex::Fibex4Can::CanTopology::J1939Cluster.request2Support
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_J1939Rm_-
00073]

Mapping Status ECUC Parameter ID

1363 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Fr Fr/FrGeneral
BSW Parameter BSW Type
FrPrepareLPduSupport ECUC-BOOLEAN-PARAM-DEF
BSW Description
Enables or disables API function Fr_PrepareLPdu.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Fr_00453]

BSW Module BSW Context

Fr Fr/FrGeneral
BSW Parameter BSW Type
FrReconfigLPduSupport ECUC-BOOLEAN-PARAM-DEF
BSW Description
Enables or disabled API function Fr_ReconfigLPdu.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Fr_00454]

BSW Module BSW Context

Fr Fr/FrGeneral
BSW Parameter BSW Type
FrRxStringentCheck ECUC-BOOLEAN-PARAM-DEF
BSW Description
If stringent check is enabled (true), received frames are accepted only if no slot status error occurred.
Template Description

M2 Parameter

Mapping Rule Mapping Type

1365 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

System Template
AUTOSAR CP R21-11

4
Mapping Rule Mapping Type
local
Mapping Status ECUC Parameter ID
valid [ECUC_Fr_00397]

BSW Module BSW Context

Fr Fr/FrMultipleConfiguration
BSW Parameter BSW Type
FrController ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Configuration of the individual controller.
Template Description
FlexRay bus specific communication port attributes.
M2 Parameter
SystemTemplate::Fibex::Fibex4Flexray::FlexrayTopology::FlexrayCommunicationController
Mapping Rule Mapping Type
Container shall be created if the ECU contains a FlexRay communication controller that is full
connected to the regarded communication cluster.
Mapping Status ECUC Parameter ID
valid [ECUC_Fr_00083]

BSW Module BSW Context

Fr Fr/FrMultipleConfiguration/FrController
BSW Parameter BSW Type
FrAbsoluteTimer ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Specifies the absolute timer configuration parameters of the Fr.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_Fr_00432]

BSW Module BSW Context

Fr Fr/FrMultipleConfiguration/FrController/FrAbsoluteTimer
BSW Parameter BSW Type
FrAbsTimerIdx ECUC-INTEGER-PARAM-DEF
BSW Description
Contains the index of an absolute timer contained in Fr on a certain FlexRay CC.
5

1367 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Fr Fr/FrMultipleConfiguration/FrController
BSW Parameter BSW Type
5

1368 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
FrCtrlEcucPartitionRef ECUC-REFERENCE-DEF
BSW Description
Maps one single Flexray controller to zero or one ECUC partitions. The ECUC partition referenced is a subset of the ECUC
partitions where the Flexray driver is mapped to.
Template Description

M2 Parameter

Mapping Rule Mapping Type

Mapping Status ECUC Parameter ID

valid [ECUC_Fr_00458]

BSW Module BSW Context

Fr Fr/FrMultipleConfiguration/FrController
BSW Parameter BSW Type
FrCtrlIdx ECUC-INTEGER-PARAM-DEF
BSW Description
Determines index of CC within Fr.
Template Description

Fr Fr/FrMultipleConfiguration/FrController/FrFifo
BSW Parameter BSW Type
FrChannels ECUC-ENUMERATION-PARAM-DEF
BSW Description
FIFO channel admittance criteria.
Template Description

M2 Parameter
SystemTemplate::Fibex::Fibex4Flexray::FlexrayTopology::FlexrayFifoConfiguration.channel
5

1370 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Mapping Rule Mapping Type
If channelA is referenced set Parameter to FR_CHANNEL_A. If channelB is referenced set full
parameter to FR_CHANNEL_B. If two identical FlexrayFifoConfiguration elements exist with
references to A and B only one FrFifo container shall be created (FR_CHANNEL_AB
Mapping Status ECUC Parameter ID
valid [ECUC_Fr_00449]

BSW Module BSW Context

Fr Fr/FrMultipleConfiguration/FrController/FrFifo
BSW Parameter BSW Type
FrCycleRepetition ECUC-INTEGER-PARAM-DEF
BSW Description
FIFO cycle counter acceptance criteria. Valid values are 1,2,4,5,8,10,16,20,32,40,50,64. Remark: Values 1,2,4,8,16,32,64
are valid only for FlexRay Protocol 2.1 Rev A compliance.
Template Description
FIFO cycle counter acceptance criteria.
M2 Parameter
SystemTemplate::Fibex::Fibex4Flexray::FlexrayTopology::FlexrayFifoConfiguration.cycleRepetition
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Fr_00008]

BSW Module BSW Context

Fr Fr/FrMultipleConfiguration/FrController/FrFifo
BSW Parameter BSW Type
FrFifoDepth ECUC-INTEGER-PARAM-DEF
BSW Description
FrFifoDepth configures the maximum number of rx-frames which can be contained in the FIFO.
Template Description
FrFifoDepth configures the maximum number of rx-frames which can be contained in the FIFO.
M2 Parameter
SystemTemplate::Fibex::Fibex4Flexray::FlexrayTopology::FlexrayFifoConfiguration.fifoDepth
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Fr_00010]

BSW Module BSW Context

Fr Fr/FrMultipleConfiguration/FrController/FrFifo
BSW Parameter BSW Type
5

1371 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

Fr Fr/FrMultipleConfiguration/FrController
BSW Parameter BSW Type
FrPAllowPassiveToActive ECUC-INTEGER-PARAM-DEF
BSW Description
Number of consecutive even/odd cycle pairs that must have valid clock correction terms before the CC will be allowed to
transition from the POC:normal passive state to POC:normal active state. If set to zero, the CC is not allowed to transition
from POC:normal passive to POC:normal active
Template Description
Number of consecutive even/odd cycle pairs that shall have valid clock correction terms before the Communication Controller
will be allowed to transition from the POC:normal passive state to POC:normal active state. If set to 0, the Communication
Controller is not allowed to transition from POC:norm
M2 Parameter
SystemTemplate::Fibex::Fibex4Flexray::FlexrayTopology::FlexrayCommunicationController.allowPassiveToActive
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Fr_00403]

BSW Module BSW Context

Fr Fr/FrMultipleConfiguration/FrController
BSW Parameter BSW Type
FrPChannels ECUC-ENUMERATION-PARAM-DEF
BSW Description
Channels to which the node is connected. Implementation Type: Fr_ChannelType
Template Description

BSW Module BSW Context

Fr Fr/FrMultipleConfiguration/FrController
BSW Parameter BSW Type
FrPDelayCompensationB ECUC-INTEGER-PARAM-DEF
BSW Description
Value used to compensate for reception delays on the indicated channel. This covers assumed propagation delay up to c
PropagationDelayMax for microticks in the range of 0.0125us to 0.05us [Microticks]. Remark: Lower limit 4 for FlexRay
Protocol 3.0 compliance. Remark: Upper limit 200 for FlexRay Protocol 2.1 Rev A compliance.
Template Description
Value used to compensate for reception delays on channel B. Unit: Microticks. This optional parameter shall only be filled out
if channel B is used.
M2 Parameter
SystemTemplate::Fibex::Fibex4Flexray::FlexrayTopology::FlexrayCommunicationController.delayCompensationB
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Fr_00408]

BSW Module BSW Context

Fr Fr/FrMultipleConfiguration/FrController
BSW Parameter BSW Type
FrPExternalSync ECUC-BOOLEAN-PARAM-DEF
BSW Description
Flag indicating whether the node is externally synchronized (operating as time gateway sink in an TT-E cluster) or locally
synchronized.
If FrPExternalSync is set to ’true’ then FrPTwoKeySlotMode must also be set to ’true’. Remarks: Set to ’false’ for FlexRay
Protocol 2.1 Rev. A compliance.
Template Description
Flag indicating whether the node is externally synchronized (operating as Time Gateway Sink in an TT-E Time Triggered
External Sync cluster) or locally synchronized.
M2 Parameter
SystemTemplate::Fibex::Fibex4Flexray::FlexrayTopology::FlexrayCommunicationController.externalSync
Mapping Rule Mapping Type
1:1 mapping full
5

1376 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Mapping Status ECUC Parameter ID
valid [ECUC_Fr_00448]

Fr Fr/FrMultipleConfiguration/FrController
BSW Parameter BSW Type
5

1379 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
FrPMacroInitialOffsetB ECUC-INTEGER-PARAM-DEF
BSW Description
Integer number of macroticks between the static slot boundary and the following macrotick boundary of the secondary time
reference point based on the nominal macrotick duration [Macroticks].
Template Description
Integer number of macroticks between the static slot boundary and the closest macrotick boundary of the secondary time
reference point based on the nominal macrotick duration. (pMacroInitialOffset). This optional parameter shall only be filled
out if channel B is used.
M2 Parameter
SystemTemplate::Fibex::Fibex4Flexray::FlexrayTopology::FlexrayCommunicationController.macroInitialOffsetB
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Fr_00416]

BSW Module BSW Context

Fr Fr/FrMultipleConfiguration/FrController
BSW Parameter BSW Type
FrPMicroInitialOffsetA ECUC-INTEGER-PARAM-DEF
BSW Description
Number of microticks between the secondary time reference point and the macrotick boundary immediately following the
secondary time reference point. The parameter depends on FrPDelayCompensationA and therefore it has to be set
independently for each channel [Microticks].
Template Description
Number of microticks between the closest macrotick boundary described by gMacroInitialOffset and the secondary time
reference point. The parameter depends on pDelayCompensationA and therefore it has to be set independently for each
channel. This optional parameter shall only be filled out if channel A is used.
M2 Parameter
SystemTemplate::Fibex::Fibex4Flexray::FlexrayTopology::FlexrayCommunicationController.microInitialOffsetA
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_Fr_00417]

BSW Module BSW Context

Fr Fr/FrMultipleConfiguration/FrController
BSW Parameter BSW Type
FrPMicroInitialOffsetB ECUC-INTEGER-PARAM-DEF
BSW Description
Number of microticks between the secondary time reference point and the macrotick boundary immediately following the
secondary time reference point. The parameter depends on FrPDelayCompensationB and therefore it has to be set
independently for each channel [Microticks].
Template Description
Number of microticks between the closest macrotick boundary described by gMacroInitialOffset and the secondary time
reference point. The parameter depends on pDelayCompensationB and therefore it has to be set independently for each
channel. This optional parameter shall only be filled out if channel B is used.
5

1380 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

1384 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_06093]

BSW Module BSW Context

FrIf FrIf/FrIfConfig/FrIfCluster/FrIfClusterDemEventParameterRefs
BSW Parameter BSW Type
FRIF_E_NIT_CH_B ECUC-REFERENCE-DEF
BSW Description
Reference to the DemEventParameter which shall be issued when an error in NIT on channel B was detected. If the
reference is not configured the error shall not be reported.
Template Description

M2 Parameter

FrIf FrIf/FrIfConfig/FrIfCluster
BSW Parameter BSW Type
FrIfController ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container contains the configuration of FlexRay CC.
Template Description
FlexRay bus specific communication port attributes.
M2 Parameter
SystemTemplate::Fibex::Fibex4Flexray::FlexrayTopology::FlexrayCommunicationController
Mapping Rule Mapping Type
Container shall be created if the ECU contains a FlexRay communication controller that is full
connected to the regarded communication cluster.
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_05363]

BSW Module BSW Context

FrIf FrIf/FrIfConfig/FrIfCluster/FrIfController
BSW Parameter BSW Type
FrIfCtrlIdx ECUC-INTEGER-PARAM-DEF
5

1390 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
BSW Description
This parameter provides a zero-based consecutive index of the FlexRay Communication Controllers. Upper layer BSW
modules and the FrIf itself use this index to identify a FlexRay CC.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_06045]

BSW Module BSW Context

FrIf FrIf/FrIfConfig/FrIfCluster/FrIfController
BSW Parameter BSW Type
FrIfFrCtrlRef ECUC-REFERENCE-DEF
BSW Description
Reference to a Controller, which is handled by a specific Driver. This reference is unique for the ECU.
Template Description

M2 Parameter

FrIf FrIf/FrIfConfig/FrIfCluster/FrIfController/FrIfFrameTriggering
BSW Parameter BSW Type
FrIfBaseCycle ECUC-INTEGER-PARAM-DEF
BSW Description
This parameter contains the FlexRay Base Cycle used to transmit this FlexRay Frame.
Template Description
5

1392 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
The first communication cycle where the frame is sent.
This value is incremented at the beginning of each new cycle, ranging from 0 to 63, and is reset to 0 after a sequence of 64
cycles.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreTopology::CycleRepetition.BaseCycle
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_06051]

BSW Module BSW Context

FrIf FrIf/FrIfConfig/FrIfCluster/FrIfController/FrIfFrameTriggering
BSW Parameter BSW Type
FrIfChannel ECUC-ENUMERATION-PARAM-DEF
BSW Description
This parameter contains the FlexRay Channel used to transmit this FlexRay Frame.
Template Description

M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreTopology::PhysicalChannel.frameTriggering
Mapping Rule Mapping Type
FrameTriggering element in the System Template is aggregated by the PhysicalChannel that is full
used to transmit this FlexRay Frame
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_06052]

BSW Module BSW Context

FrIf FrIf/FrIfConfig/FrIfCluster/FrIfController/FrIfFrameTriggering
BSW Parameter BSW Type
FrIfCycleRepetition ECUC-INTEGER-PARAM-DEF
BSW Description
This parameter contains the FlexRay Cycle Repetition used to transmit this FlexRay Frame.
Possible values for FlexRay Protocol version 2.1: 1,2,4,8,16,32,64 Possible values for FlexRay Protocol version 3.0:
1,2,4,5,8,10,16,20,32,40,50,64
Template Description
The number of communication cycles (after the first cycle) whenever the frame described by this timing is sent again.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreTopology::CycleRepetition.CycleRepetition
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_06053]

1393 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

FrIf FrIf/FrIfConfig/FrIfCluster/FrIfController/FrIfFrameTriggering
BSW Parameter BSW Type
FrIfFrameStructureRef ECUC-REFERENCE-DEF
BSW Description
Reference to the Construction Plan of the FlexRay Frame.
Template Description

M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::FrameTriggering.frame
Mapping Rule Mapping Type
Reference shall comply to the reference in the System Description between the FrameTriggering full
element and the Frame.element.
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_06048]

BSW Module BSW Context

FrIf FrIf/FrIfConfig/FrIfCluster/FrIfController/FrIfFrameTriggering
BSW Parameter BSW Type
FrIfFrameTriggeringDemEventParameterRefs ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Container for the references to DemEventParameter elements which shall be invoked using the API Dem_SetEventStatus in
case the corresponding error occurs. The EventId is taken from the referenced DemEventParameter’s DemEventId symbolic
value. The standardized errors are provided in this container and can be extended by vendor-specific error references.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_06099]

BSW Module BSW Context

FrIf FrIf/FrIfConfig/FrIfCluster/FrIfController/FrIfFrameTriggering/FrIfFrameTriggeringDemEvent
ParameterRefs
BSW Parameter BSW Type
FRIF_E_LPDU_SLOTSTATUS ECUC-REFERENCE-DEF
BSW Description
Reference to DEM event Id that is reported when FlexRay driver module detects slot errors. If this parameter is not
configured, no event reporting happens.
Template Description

M2 Parameter

Mapping Rule Mapping Type

1394 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

FrIf FrIf/FrIfConfig/FrIfCluster/FrIfController/FrIfLPdu
BSW Parameter BSW Type
FrIfLPduIdx ECUC-INTEGER-PARAM-DEF
BSW Description
This parameter identifies the L-PDU in the interaction between FlexRay Interface and FlexRay Driver.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_06058]

BSW Module BSW Context

FrIf FrIf/FrIfConfig/FrIfCluster/FrIfController/FrIfLPdu
BSW Parameter BSW Type
FrIfReconfigurable ECUC-BOOLEAN-PARAM-DEF
BSW Description
This parameter specifies that this LPdu is reconfigurable using FrIf_ReconfigLPdu. This means that this LPdu can be
assigned to a different FrameTriggering at runtime. However, this reconfiguration is limited by hardware constraints. The
direction of the LPdu cannot be reconfigured.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_00008]

BSW Module BSW Context

FrIf FrIf/FrIfConfig/FrIfCluster/FrIfController/FrIfLPdu
5

1397 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
BSW Parameter BSW Type
FrIfVBTriggeringRef ECUC-REFERENCE-DEF
BSW Description
Reference to the assigned Frame triggering.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_06057]

BSW Module BSW Context

FrIf FrIf/FrIfConfig/FrIfCluster/FrIfController
BSW Parameter BSW Type
FrIfTransceiver ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Up to two FlexRay Transceivers may connect a Controller to a Cluster. This container realizes a Controller-Transceiver
assignment.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_05391]

BSW Module BSW Context

FrIf FrIf/FrIfConfig/FrIfCluster/FrIfController/FrIfTransceiver
BSW Parameter BSW Type
FrIfClusterChannel ECUC-ENUMERATION-PARAM-DEF
BSW Description
This parameter identifies to which one of the two Channels (A, B, A and B) of the Cluster the Transceiver is connected. FrIf
ClusterChannel shall map to Fr_ChannelType: FRIF_CHANNEL_A == FR_CHANNEL_A FRIF_CHANNEL_B == FR_
CHANNEL_B FR_CHANNEL_AB shall not be used.
Template Description

FrIf FrIf/FrIfConfig/FrIfCluster
BSW Parameter BSW Type
FrIfGCycleCountMax ECUC-INTEGER-PARAM-DEF
BSW Description
Maximum cycle counter value in a given cluster. Remark: Set to 63 for FlexRay Protocol 2.1 Rev. A compliance.
Template Description
Maximum cycle counter value in a given cluster. Remark: Set to 63 for FlexRay Protocol 2.1 Rev. A compliance.
M2 Parameter
SystemTemplate::Fibex::Fibex4Flexray::FlexrayTopology::FlexrayCluster.cycleCountMax
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_06086]

BSW Module BSW Context

FrIf FrIf/FrIfConfig/FrIfCluster
BSW Parameter BSW Type
FrIfGListenNoise ECUC-INTEGER-PARAM-DEF
5

1400 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
BSW Description
Upper limit for the start up listen timeout and wake up listen timeout in the presence of noise. It is used as a multiplier of the
node parameter pdListenTimeout.
Template Description
Upper limit for the start up and wake up listen timeout in the presence of noise. Expressed as a multiple of the cluster
constant pdListenTimeout. Unit microticks
M2 Parameter
SystemTemplate::Fibex::Fibex4Flexray::FlexrayTopology::FlexrayCluster.listenNoise
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_06009]

BSW Module BSW Context

FrIf FrIf/FrIfConfig/FrIfCluster
BSW Parameter BSW Type
FrIfGMacroPerCycle ECUC-INTEGER-PARAM-DEF
BSW Description
Number of macroticks in a communication cycle.
Note: Lower limit 10 for FlexRay Protocol 2.1 Rev. A compliance
Template Description
The number of macroticks in a communication cycle
M2 Parameter
SystemTemplate::Fibex::Fibex4Flexray::FlexrayTopology::FlexrayCluster.macroPerCycle
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_06010]

BSW Module BSW Context

FrIf FrIf/FrIfConfig/FrIfCluster
BSW Parameter BSW Type
FrIfGMaxWithoutClockCorrectFatal ECUC-INTEGER-PARAM-DEF
BSW Description
Threshold used for testing the vClockCorrectionFailed counter. Defines the number of consecutive even/odd Cycle pairs with
missing clock correction terms that will cause the protocol to transition from the POC:normal active or POC:normal passive
state into the POC:halt state. [Even/odd cycle pairs].
Template Description
Threshold concerning vClockCorrectionFailedCounter. Defines the number of consecutive even/odd Cycle pairs with missing
clock correction terms that will cause the protocol to transition from the POC:normal active or POC:normal passive state into
the POC:halt state.
M2 Parameter
SystemTemplate::Fibex::Fibex4Flexray::FlexrayTopology::FlexrayCluster.maxWithoutClockCorrectionFatal
Mapping Rule Mapping Type
5

1401 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_06011]

BSW Module BSW Context

FrIf FrIf/FrIfConfig/FrIfCluster
BSW Parameter BSW Type
FrIfGMaxWithoutClockCorrectPassive ECUC-INTEGER-PARAM-DEF
BSW Description
Threshold used for testing the vClockCorrectionFailed counter. Defines the number of consecutive even/odd Cycle pairs with
missing clock correction terms that will cause the protocol to transition from the POC:normal active state to the POC:normal
passive state. [Even/Odd cycle pairs]
Template Description
Threshold concerning vClockCorrectionFailedCounter. Defines the number of consecutive even/odd Cycle pairs with missing
clock correction terms that will cause the protocol to transition from the POC:normal active state to the POC:normal passive
state.
M2 Parameter
SystemTemplate::Fibex::Fibex4Flexray::FlexrayTopology::FlexrayCluster.maxWithoutClockCorrectionPassive
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_06012]

BSW Module BSW Context

FrIf FrIf/FrIfConfig/FrIfCluster
BSW Parameter BSW Type
FrIfGNetworkManagementVectorLength ECUC-INTEGER-PARAM-DEF
BSW Description
Length of the Network Management vector in a cluster [bytes]
Template Description
Length of the Network Management vector in a cluster [bytes]
M2 Parameter
SystemTemplate::Fibex::Fibex4Flexray::FlexrayTopology::FlexrayCluster.networkManagementVectorLength
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_06013]

BSW Module BSW Context

FrIf FrIf/FrIfConfig/FrIfCluster
BSW Parameter BSW Type
FrIfGNumberOfMinislots ECUC-INTEGER-PARAM-DEF
5

1402 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

FrIf FrIf/FrIfConfig/FrIfCluster
BSW Parameter BSW Type
FrIfGdCasRxLowMax ECUC-INTEGER-PARAM-DEF
BSW Description
Upper limit of the CAS acceptance windows [gdBit]
Remark: Range 67 to 99 for FlexRay Protocol 2.1 Rev. A compliance
Template Description
Upper limit of the Collision Avoidance Symbol (CAS) acceptance window. Unit:bitDuration
M2 Parameter
SystemTemplate::Fibex::Fibex4Flexray::FlexrayTopology::FlexrayCluster.casRxLowMax
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_06024]

BSW Module BSW Context

FrIf FrIf/FrIfConfig/FrIfCluster
BSW Parameter BSW Type
FrIfGdCycle ECUC-FLOAT-PARAM-DEF
BSW Description
Length of the cycle, expressed in [s] Remark: Lower limit 0.000024 for FlexRay Protocol 3.0 compliance.
Template Description
Length of the cycle. Unit: seconds
M2 Parameter
SystemTemplate::Fibex::Fibex4Flexray::FlexrayTopology::FlexrayCluster.cycle
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_06025]

BSW Module BSW Context

FrIf FrIf/FrIfConfig/FrIfCluster
BSW Parameter BSW Type
FrIfGdDynamicSlotIdlePhase ECUC-INTEGER-PARAM-DEF
5

1405 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

FrIf FrIf/FrIfConfig/FrIfCluster
BSW Parameter BSW Type
FrIfGdSampleClockPeriod ECUC-ENUMERATION-PARAM-DEF
BSW Description
Sample clock period
Template Description
Sample clock period. Unit: seconds
M2 Parameter
SystemTemplate::Fibex::Fibex4Flexray::FlexrayTopology::FlexrayCluster.sampleClockPeriod
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_06035]

BSW Module BSW Context

FrIf FrIf/FrIfConfig/FrIfCluster
BSW Parameter BSW Type
FrIfGdStaticSlot ECUC-INTEGER-PARAM-DEF
BSW Description
Duration of a static slot [Macroticks]. Remark: Range 4-661 for FlexRay Protocol 2.1 Rev. A compliance.
Template Description
The duration of a slot in the static segment. Unit: macroticks
M2 Parameter
SystemTemplate::Fibex::Fibex4Flexray::FlexrayTopology::FlexrayCluster.staticSlotDuration
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_06036]

BSW Module BSW Context

FrIf FrIf/FrIfConfig/FrIfCluster
BSW Parameter BSW Type
FrIfGdSymbolWindow ECUC-INTEGER-PARAM-DEF
BSW Description
5

1408 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

FrIf FrIf/FrIfConfig/FrIfCluster
BSW Parameter BSW Type
FrIfGdWakeupTxActive ECUC-INTEGER-PARAM-DEF
BSW Description
Number of bits used by the node to transmit the LOW phase of awakeup symbol and the HIGH and LOW phases of a
WUDOP [gdBit].
Remarks: This parameter maps to FlexRay Protocol 2.1 Rev. A parameter gdWakeupSymbolTxLow.
Template Description
Number of bits used by the node to transmit the LOW phase of awakeup symbol and the HIGH and LOW phases of a
WUDOP. Unit:bitDuration
M2 Parameter
SystemTemplate::Fibex::Fibex4Flexray::FlexrayTopology::FlexrayCluster.wakeupTxActive
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_06043]

BSW Module BSW Context

FrIf FrIf/FrIfConfig/FrIfCluster
BSW Parameter BSW Type
FrIfGdWakeupTxIdle ECUC-INTEGER-PARAM-DEF
BSW Description
Number of bits used by the node to transmit the ’idle’ part of a wakeup symbol [gdBit].
Remarks: This parameter maps to FlexRay Protocol 2.1 Rev. A parameter gdWakeupSymbolTxIdle.
Template Description
Number of bits used by the node to transmit the ’idle’ part of a wakeup symbol. Unit: gDbit
M2 Parameter
SystemTemplate::Fibex::Fibex4Flexray::FlexrayTopology::FlexrayCluster.wakeupTxIdle
Mapping Rule Mapping Type
1:1 mapping full
5

1411 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

System Template
AUTOSAR CP R21-11

4
Mapping Rule Mapping Type
local
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_05368]

BSW Module BSW Context

FrIf FrIf/FrIfConfig/FrIfCluster/FrIfJobList/FrIfJob
BSW Parameter BSW Type
FrIfCommunicationOperation ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
A separate operation which is part of a FlexRay Job and defines what type of action is executed.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_05369]

BSW Module BSW Context

FrIf FrIf/FrIfConfig/FrIfCluster/FrIfJobList/FrIfJob/FrIfCommunicationOperation
BSW Parameter BSW Type
FrIfCommunicationAction ECUC-ENUMERATION-PARAM-DEF
BSW Description
The action to be performed in the FlexRay Operation
Template Description

M2 Parameter

FrIf FrIf/FrIfConfig/FrIfCluster/FrIfJobList/FrIfJob
BSW Parameter BSW Type
FrIfCycle ECUC-INTEGER-PARAM-DEF
BSW Description
5

1414 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

FrIf FrIf/FrIfConfig/FrIfCluster
BSW Parameter BSW Type
5

1415 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
FrIfMainFunctionPeriod ECUC-FLOAT-PARAM-DEF
BSW Description
The execution cycle of the FrIf_MainFunction_<FrIfCluster.ShortName>() in seconds. The FrIf does not require this
information but the BSW scheduler, which invokes the cluster main functions, needs it in order to plan its tasks.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_06003]

BSW Module BSW Context

FrIf FrIf/FrIfConfig/FrIfCluster
BSW Parameter BSW Type
FrIfSafetyMargin ECUC-INTEGER-PARAM-DEF
BSW Description
Additional timespan in macroticks which takes jitter into account to be able to set the JobListPointer to the next possible job
which can be executed in case the FlexRay Job List Execution Function has be resynchronized.
Template Description
Additional timespan in macroticks which takes jitter into account to be able to set the JobListPointer to the next possible job
which can be executed in case the FlexRay Job List Execution Function has be resynchronized.
M2 Parameter
SystemTemplate::Fibex::Fibex4Flexray::FlexrayTopology::FlexrayCluster.safetyMargin
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_00004]

BSW Module BSW Context

FrIf FrIf/FrIfConfig
BSW Parameter BSW Type
FrIfFrameStructure ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
The Frame structure specifies a Construction Plan how a Frame is assembled with PDUs and their respective Update-Bits.
Template Description
Data frame which is sent over a communication medium. This element describes the pure Layout of a frame sent on a
channel.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::Frame
Mapping Rule Mapping Type
Create container for each FlexRay Frame that is transmitted or received by the regarded ECU. full
IPduToFrameMapping element in the System Template contains the construction plan.
Mapping Status ECUC Parameter ID
5

1416 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
valid [ECUC_FrIf_05370]

FrIf FrIf/FrIfConfig/FrIfPdu/FrIfPduDirection/FrIfRxPdu
BSW Parameter BSW Type
FrIfRxIndicationName ECUC-FUNCTION-NAME-DEF
BSW Description
This parameter defines the name of the <User_RxIndication>. This parameter depends on the parameter FrIfUserRx
IndicationUL. If FrIfUserRxIndicationUL equals FR_TP, FR_AR_TP, FR_NM, PDUR, FR_TSYN or XCP, the name of the
<User_RxIndication> is fixed. If FrIfUserRxIndicationUL equals CDD, the name of the <User_RxIndication> is selectable.
Template Description

M2 Parameter
5

1420 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Mapping Rule Mapping Type
local
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_00016]

BSW Module BSW Context

FrIf FrIf/FrIfConfig/FrIfPdu/FrIfPduDirection/FrIfRxPdu
BSW Parameter BSW Type
FrIfRxPduRef ECUC-REFERENCE-DEF
BSW Description
Reference to the external PDU definition.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_06073]

BSW Module BSW Context

FrIf FrIf/FrIfConfig/FrIfPdu/FrIfPduDirection/FrIfRxPdu
BSW Parameter BSW Type
FrIfUserRxIndicationUL ECUC-ENUMERATION-PARAM-DEF
BSW Description
This parameter defines the upper layer (UL) module to which the indication of the successfully received FrIfRxPdu has to be
routed via <User_RxIndication>. This <User_RxIndication> has to be invoked when the indication of the configured FrIfRx
Pdu will be received by a Rx indication event from the FR Driver module. If no upper layer (UL) module is configured, no
<User_RxIndication> has to be called in case of a Rx indication event of the FrIfRxPdu from the FR Driver module.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_00017]

BSW Module BSW Context

FrIf FrIf/FrIfConfig/FrIfPdu/FrIfPduDirection
BSW Parameter BSW Type
FrIfTxPdu ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container specifies transmission PDUs.
5

1421 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

FrIf FrIf/FrIfConfig/FrIfPdu/FrIfPduDirection/FrIfTxPdu
BSW Parameter BSW Type
FrIfImmediate ECUC-BOOLEAN-PARAM-DEF
5

1422 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

FrIf FrIf/FrIfConfig/FrIfPdu/FrIfPduDirection/FrIfTxPdu
5

1423 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

FrIf FrIf/FrIfConfig/FrIfPdu/FrIfPduDirection/FrIfTxPdu
BSW Parameter BSW Type
FrIfUserTxUL ECUC-ENUMERATION-PARAM-DEF
BSW Description
This parameter defines the upper layer (UL) module to which the trigger of the Pdu to be transmitted (via the <User_Trigger
Transmit>) or the confirmation of the successfully transmitted Pdu has to be routed (via the <User_TxConfirmation>). Please
note that handle IDs which are used in callback functions are defined by the upper layer module.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_00015]

BSW Module BSW Context

FrIf FrIf
BSW Parameter BSW Type
FrIfGeneral ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container contains the general configuration parameters of the FlexRay Interface.
Template Description
FlexRay specific attributes to the physicalCluster
M2 Parameter
SystemTemplate::Fibex::Fibex4Flexray::FlexrayTopology::FlexrayCluster
Mapping Rule Mapping Type
Container shall be created if the ECU is connected to a FlexRay Cluster. full
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_05360]

BSW Module BSW Context

FrIf FrIf/FrIfGeneral
BSW Parameter BSW Type
FrIfAbsTimerIdx ECUC-INTEGER-PARAM-DEF
BSW Description
Maximum number of supported absolute timers.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
5

1425 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

System Template
AUTOSAR CP R21-11

4
Mapping Rule Mapping Type
local
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_00002]

BSW Module BSW Context

FrIf FrIf/FrIfGeneral
BSW Parameter BSW Type
FrIfDevErrorDetect ECUC-BOOLEAN-PARAM-DEF
BSW Description
Switches the development error detection and notification on or off.
• true: detection and notification is enabled.
• false: detection and notification is disabled.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_06080]

BSW Module BSW Context

FrIf FrIf/FrIfGeneral
BSW Parameter BSW Type
FrIfDisableLPduSupport ECUC-BOOLEAN-PARAM-DEF
BSW Description
Configuration parameter to enable/disable FrIf support to disables the hardware resource of a LPdu for transmission/
reception.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_06110]

BSW Module BSW Context

FrIf FrIf/FrIfGeneral
BSW Parameter BSW Type
FrIfDisableTransceiverBranchSupport ECUC-BOOLEAN-PARAM-DEF
BSW Description
5

1427 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

FrIf FrIf/FrIfGeneral
BSW Parameter BSW Type
FrIfFreeOpBApiName ECUC-STRING-PARAM-DEF
5

1428 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

FrIf FrIf/FrIfGeneral
5

1429 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_06111]

1431 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

FrIf FrIf/FrIfGeneral
BSW Parameter BSW Type
FrIfNumClstSupported ECUC-INTEGER-PARAM-DEF
BSW Description
Maximum number of FlexRay Clusters that the FlexRay Interface supports.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_06081]

BSW Module BSW Context

FrIf FrIf/FrIfGeneral
BSW Parameter BSW Type
FrIfNumCtrlSupported ECUC-INTEGER-PARAM-DEF
BSW Description
Maximum number of FlexRay CCs that the FlexRay Interface supports
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_06082]

BSW Module BSW Context

FrIf FrIf/FrIfGeneral
BSW Parameter BSW Type
FrIfPublicCddHeaderFile ECUC-STRING-PARAM-DEF
BSW Description
Defines header files for callback functions which shall be included in case of CDDs. Range of characters is 1.. 32.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_06116]

1432 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

1433 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

FrIf FrIf/FrIfGeneral
BSW Parameter BSW Type
FrIfTxConflictNotificationName ECUC-STRING-PARAM-DEF
BSW Description
Configuration of the API name that is called in case a TxConflict has been detected.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_06122]

BSW Module BSW Context

FrIf FrIf/FrIfGeneral
BSW Parameter BSW Type
FrIfUnusedBitValue ECUC-INTEGER-PARAM-DEF
BSW Description
Set unused bits of transmitted Pdus to a defined value.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_00001]

BSW Module BSW Context

FrIf FrIf/FrIfGeneral
BSW Parameter BSW Type
FrIfVersionInfoApi ECUC-BOOLEAN-PARAM-DEF
BSW Description
Enables/disables the existence of the FrIf_GetVersionInfo() API service
true: FrIf_GetVersionInfo() API service exists false: FrIf_GetVersionInfo() API service does not exist
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrIf_06083]

1434 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

C.4.3 FrNm Mapping

BSW Module BSW Context

FrNm FrNm
BSW Parameter BSW Type
FrNmChannelConfig ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container contains the configuration parameters for all FlexRay NM channels.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrNm_00002]

BSW Module BSW Context

FrNm FrNm/FrNmChannelConfig
BSW Parameter BSW Type
FrNmChannel ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container contains the configuration parameters for a FlexRay NM Channel.
Template Description
FlexRay specific NM cluster attributes.
M2 Parameter
SystemTemplate::NetworkManagement::FlexrayNmCluster
Mapping Rule Mapping Type
Create Container for each existing FlexrayNmCluster. full
Mapping Status ECUC Parameter ID
valid [ECUC_FrNm_00006]

BSW Module BSW Context

FrNm FrNm/FrNmChannelConfig/FrNmChannel/FrNmChannelIdentifiers
BSW Parameter BSW Type
FrNmCarWakeUpBytePosition ECUC-INTEGER-PARAM-DEF
BSW Description
Specifies the Byte position of the CWU within the NM-Message.
Template Description
Specifies the bit position of the CarWakeUp within the NmPdu.
5

1436 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrNm_00013]

BSW Module BSW Context

FrNm FrNm/FrNmChannelConfig/FrNmChannel/FrNmChannelIdentifiers
BSW Parameter BSW Type
FrNmComMNetworkHandleRef ECUC-REFERENCE-DEF
BSW Description
This reference points to the unique channel defined by the ComMChannel and provides access to the unique channel index
value in ComMChannelId.
Template Description

M2 Parameter

1438 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Mapping Rule Mapping Type
local
Mapping Status ECUC Parameter ID
valid [ECUC_FrNm_00014]

BSW Module BSW Context

FrNm FrNm/FrNmChannelConfig/FrNmChannel/FrNmChannelIdentifiers
BSW Parameter BSW Type
FrNmDynamicPncToChannelMappingEnabled ECUC-BOOLEAN-PARAM-DEF
BSW Description
Channel-specific parameter to enable the dynamic PNC-to-channel-mapping feature.
False: Dynamic PNC-to-channel-mapping is disabled True: Dynamic PNC-to-channel-mapping is enabled
Template Description
Defines if this EcuInstance shall implement the dynamic PNC-to-channel-mapping functionality on this Communication
Connector and its respective PhysicalChannel.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreTopology::CommunicationConnector.dynamicPncToChannelMappingEnabled
Mapping Rule Mapping Type
1:1 mapping If M2 Parameter not defined then do not create FrNmDynamicPncToChannelMapping full
Enabled
Mapping Status ECUC Parameter ID
valid [ECUC_FrNm_00092]

BSW Module BSW Context

FrNm FrNm/FrNmChannelConfig/FrNmChannel/FrNmChannelIdentifiers
BSW Parameter BSW Type
FrNmNodeDetectionEnabled ECUC-BOOLEAN-PARAM-DEF
BSW Description
This parameter is used to enable or disable node detection support for a FrNm Channel.
Template Description
Enables the Request Repeat Message Request support. Only valid if nmNodeIdEnabled is set to true.
M2 Parameter
SystemTemplate::NetworkManagement::NmCluster.nmNodeDetectionEnabled
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_FrNm_00086]

M2 Parameter
5

1443 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

FrNm FrNm/FrNmChannelConfig/FrNmChannel/FrNmChannelIdentifiers/FrNmTxPdu
BSW Parameter BSW Type
FrNmTxConfirmationPduId ECUC-INTEGER-PARAM-DEF
BSW Description
Handle Id used by the Lower Layer when calling FrNm_TriggerTransmit() or FrNm_TxConfirmation().
Template Description

FrNm FrNm
BSW Parameter BSW Type
FrNmGlobalConfig ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container contains all global configuration parameters for the FrNm module.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrNm_00001]

1451 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

FrNm FrNm/FrNmGlobalConfig
BSW Parameter BSW Type
FrNmGlobalFeatures ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container contains module features related to the FlexRay NM functionality.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrNm_00004]

BSW Module BSW Context

FrNm FrNm/FrNmGlobalConfig/FrNmGlobalFeatures
BSW Parameter BSW Type
FrNmBusSynchronizationEnabled ECUC-BOOLEAN-PARAM-DEF
BSW Description
Pre-processor switch for enabling the bus synchronization.
Template Description
Enables bus synchronization support.
M2 Parameter
SystemTemplate::NetworkManagement::NmEcu.nmBusSynchronizationEnabled
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_FrNm_00048]

BSW Module BSW Context

FrNm FrNm/FrNmGlobalConfig/FrNmGlobalFeatures
BSW Parameter BSW Type
FrNmComUserDataSupport ECUC-BOOLEAN-PARAM-DEF
BSW Description
Preprocessor switch for enabling the Tx path of Com User Data. Use case: Setting of NMUserData via SWC.
Template Description

1452 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

1453 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
local
Mapping Status ECUC Parameter ID
valid [ECUC_FrNm_00049]

BSW Module BSW Context

FrNm FrNm/FrNmGlobalConfig/FrNmGlobalFeatures
BSW Parameter BSW Type
FrNmDynamicPncToChannelMappingSupport ECUC-BOOLEAN-PARAM-DEF
BSW Description
Precompile time switch to enable the dynamic PNC-to-channel-mapping handling.
False: Dynamic PNC-to-channel-mapping is disabled True: Dynamic PNC-to-channel-mapping is enabled
Template Description
Defines if this EcuInstance shall implement the dynamic PNC-to-channel-mapping functionality on this Communication
Connector and its respective PhysicalChannel.
M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreTopology::CommunicationConnector.dynamicPncToChannelMappingEnabled
Mapping Rule Mapping Type
If at least one dynamicPncToChannelMappingEnabled attribute is defined and if at least one full
CommunicationConnector of the EcuInstance has dynamicPncToChannelMappingEnabled set to
true, then FrNmDynamicPncToChannelMappingSupport shall be set to true. Otherwise FrNm
DynamicPncToChannelMappingSupport shall be set to false.
Mapping Status ECUC Parameter ID
valid [ECUC_FrNm_00090]

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

FrNm FrNm/FrNmGlobalConfig/FrNmGlobalFeatures
BSW Parameter BSW Type
FrNmPnEiraRxNSduRef ECUC-REFERENCE-DEF
BSW Description
Reference to a Pdu in the COM-Stack. Only one SduRef is required for FrNm because the EIRA is the aggregation over all
FlexRay Channels.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrNm_00069]

BSW Module BSW Context

FrNm FrNm/FrNmGlobalConfig/FrNmGlobalFeatures
BSW Parameter BSW Type
FrNmPnInfo ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
PN information configuration
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrNm_00061]

BSW Module BSW Context

FrNm FrNm/FrNmGlobalConfig/FrNmGlobalFeatures/FrNmPnInfo
BSW Parameter BSW Type
FrNmPnFilterMaskByte ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Filter mask byte configuration
Template Description
Bit mask for FlexRay Payload used to configure the NM filter mask for the Network Management.
M2 Parameter
SystemTemplate::Fibex::Fibex4Flexray::FlexrayTopology::FlexrayCommunicationConnector.pncFilterDataMask
Mapping Rule Mapping Type
5

1456 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

FrNm FrNm/FrNmGlobalConfig/FrNmGlobalFeatures
BSW Parameter BSW Type
FrNmPnSyncShutdownErrorReactionEnabled ECUC-BOOLEAN-PARAM-DEF
BSW Description
Pre-processor switch for enabling reaction, if a top-level PNC coordinator received a PN shutdown message on a
NM-channel which refer to a ComM channel that is actively coordinated by a PNC gateway.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrNm_00093]

BSW Module BSW Context

FrNm FrNm/FrNmGlobalConfig/FrNmGlobalFeatures
BSW Parameter BSW Type
FrNmRemoteSleepIndicationEnabled ECUC-BOOLEAN-PARAM-DEF
BSW Description
Pre-processor switch for enabling remote sleep indication.
calculationFormula = If (FrNmPassiveModeEnabled == True) then Equal(False) else Equal(False or True)
Template Description
Switch for enabling remote sleep indication support.
M2 Parameter
5

1459 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrNm_00003]

BSW Module BSW Context

FrNm FrNm/FrNmGlobalConfig/FrNmGlobalProperties
BSW Parameter BSW Type
FrNmDevErrorDetect ECUC-BOOLEAN-PARAM-DEF
BSW Description
Switches the development error detection and notification on or off.
• true: detection and notification is enabled.
• false: detection and notification is disabled.
Template Description

M2 Parameter

FrNm FrNm/FrNmGlobalConfig/FrNmGlobalProperties
BSW Parameter BSW Type
FrNmVersionInfoApi ECUC-BOOLEAN-PARAM-DEF
BSW Description
Pre-processor switch for enabling version info API support.
Template Description

M2 Parameter

1462 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Mapping Rule Mapping Type
local
Mapping Status ECUC Parameter ID
valid [ECUC_FrNm_00037]

C.4.4 FrTp Mapping

BSW Module BSW Context

FrTp FrTp
BSW Parameter BSW Type
FrTpGeneral ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container contains the general configuration parameters of the FlexRay Transport Protocol module.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrTp_00009]

BSW Module BSW Context

FrTp FrTp/FrTpGeneral
BSW Parameter BSW Type
FrTpAckRt ECUC-BOOLEAN-PARAM-DEF
BSW Description
Preprocessor switch for enabling the Acknowledgement and retry mechanisms.
True: Acknowledge and Retry is enabled False: Acknowledge and Retry is disabled
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrTp_00002]

BSW Module BSW Context

FrTp FrTp/FrTpGeneral
BSW Parameter BSW Type
FrTpChanNum ECUC-INTEGER-PARAM-DEF
5

1463 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

System Template
AUTOSAR CP R21-11

4
SystemTemplate::TransportProtocols::FlexrayTpEcu.cancellation
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_FrTp_00036]

BSW Module BSW Context

FrTp FrTp/FrTpGeneral
BSW Parameter BSW Type
FrTpUnknownMsgLength ECUC-BOOLEAN-PARAM-DEF
BSW Description
Preprocessor switch to support data transfer with unknown message length.
True: Transmission with unknown message length is enabled False: Transmission with unknown message length is disabled
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrTp_00044]

BSW Module BSW Context

FrTp FrTp/FrTpGeneral
BSW Parameter BSW Type
FrTpVersionInfoApi ECUC-BOOLEAN-PARAM-DEF
BSW Description
Preprocessor switch for enabling the Version info API.
True: Version Info API is enabled False: Version Info API is disabled
Template Description

FrTp FrTp/FrTpMultipleConfig/FrTpConnection
BSW Parameter BSW Type
FrTpConCtrlRef ECUC-REFERENCE-DEF
BSW Description
FrTpConnectionControlReference: This parameter defines a reference to a connection control container.
Template Description

FrTp FrTp/FrTpMultipleConfig/FrTpConnection/FrTpRxSdu
BSW Parameter BSW Type
FrTpRxSduId ECUC-INTEGER-PARAM-DEF
BSW Description
This unique identifier is used for change parameter request or receive cancellation from PduR to FrTp.
ImplementationType: PduIdType
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrTp_00053]

BSW Module BSW Context

FrTp FrTp/FrTpMultipleConfig/FrTpConnection/FrTpRxSdu
BSW Parameter BSW Type
FrTpRxSduRef ECUC-REFERENCE-DEF
BSW Description
Reference to a PDU in the global PDU structure.
Template Description

M2 Parameter

Mapping Rule Mapping Type

1470 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
local
Mapping Status ECUC Parameter ID
valid [ECUC_FrTp_00028]

BSW Module BSW Context

FrTp FrTp/FrTpMultipleConfig/FrTpConnection
BSW Parameter BSW Type
FrTpTxPduPoolRef ECUC-REFERENCE-DEF
BSW Description
This parameter defines a reference to a TxPduPool.
Template Description

BSW Module BSW Context

FrTp FrTp/FrTpMultipleConfig/FrTpConnection
BSW Parameter BSW Type
FrTpTxSdu ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This parameter defines the Tx Service Data Unit Identifier (Sdu Id) which uniquely identifies a data transfer (inter-module
communication) between FrTp and PDUR. This N-SDU can consume meta data items of type SOURCE_ADDRESS_16 and
TARGET_ADDRESS_16.
Template Description

M2 Parameter
SystemTemplate::TransportProtocols::FlexrayTpConnection.directTpSdu
Mapping Rule Mapping Type
Create container if an Tx Pdu is referenced by the FlexRayTpConnection full
Mapping Status ECUC Parameter ID
valid [ECUC_FrTp_00041]

BSW Module BSW Context

FrTp FrTp/FrTpMultipleConfig/FrTpConnection/FrTpTxSdu
BSW Parameter BSW Type
5

1471 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
FrTpTxSduId ECUC-INTEGER-PARAM-DEF
BSW Description
This is a unique identifier for a to be transmitted message from the PduR to the FrTp.
ImplementationType: PduIdType
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrTp_00042]

BSW Module BSW Context

FrTp FrTp/FrTpMultipleConfig/FrTpConnection/FrTpTxSdu
BSW Parameter BSW Type
FrTpTxSduRef ECUC-REFERENCE-DEF
BSW Description
Reference to a PDU in the global PDU structure.
Template Description

M2 Parameter

1473 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_FrTp_00029]

FrTp FrTp/FrTpMultipleConfig/FrTpConnectionControl
BSW Parameter BSW Type
FrTpTimeoutCr ECUC-FLOAT-PARAM-DEF
BSW Description
5

1476 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
This parameter defines the timeout value in seconds a receiver is waiting for a CF or a LF.
Template Description
This parameter defines the timeout value in seconds for waiting for a CF or FF-x (in case of retry) after receiving the last CF
or after sending an FC or AF on the receiver side. Specified in seconds.
M2 Parameter
SystemTemplate::TransportProtocols::FlexrayTpConnectionControl.timeoutCr
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_FrTp_00035]

BSW Module BSW Context

FrTp FrTp/FrTpMultipleConfig
BSW Parameter BSW Type
FrTpMaxConnectionCnt ECUC-INTEGER-PARAM-DEF
BSW Description
Maximum number of TP connections. This parameter is needed only in case of post-build loadable implementation using
static memory allocation.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrTp_00054]

BSW Module BSW Context

FrTp FrTp/FrTpMultipleConfig
BSW Parameter BSW Type
FrTpRxPduPool ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container contains all Pdus that are assigned to that Pdu Pool.
Template Description
FlexrayTpPduPool is a set of N-PDUs which are defined for FrTp sending or receiving purpose.
M2 Parameter
SystemTemplate::TransportProtocols::FlexrayTpPduPool
Mapping Rule Mapping Type
Create container if the FlexrayTpPduPool element is referenced by the FlexrayTpConnection via full
the rxPduPool or txPduPool reference. If the regarded ECU is the transmitter then the txPduPool
holds the sent NPdus and the rxPduPool holds the received NPdus. If the ECU is the receiver then
the txPduPool holds the received NPdus and the rxPduPool holds the sent NPdus.
Mapping Status ECUC Parameter ID
valid [ECUC_FrTp_00024]

1477 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

BSW Module BSW Context

FrTp FrTp/FrTpMultipleConfig/FrTpRxPduPool
BSW Parameter BSW Type
FrTpRxPdu ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
Container to hold the PDU parameters.
ImplementationType: PduInfoType
Template Description

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrTp_00040]

C.4.5 FrArTp Mapping

BSW Module BSW Context

FrArTp FrArTp
BSW Parameter BSW Type
FrArTpGeneral ECUC-PARAM-CONF-CONTAINER-DEF
BSW Description
This container contains the general configuration (parameters) of the FlexRay TP.
Template Description

M2 Parameter

FrArTp FrArTp/FrArTpGeneral
BSW Parameter BSW Type
FrArTpHaveGrpSeg ECUC-BOOLEAN-PARAM-DEF
BSW Description
Preprocessor switch for enabling segmentation of 1:n messages.
Template Description

M2 Parameter

Mapping Rule Mapping Type

1481 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
local
Mapping Status ECUC Parameter ID
valid [ECUC_FrArTp_-
00015]

BSW Module BSW Context

FrArTp FrArTp/FrArTpGeneral
BSW Parameter BSW Type
FrArTpHaveLm ECUC-BOOLEAN-PARAM-DEF
BSW Description
Preprocessor switch for enabling the mechanism for message longer than allowed by.
Template Description

M2 Parameter

Mapping Rule Mapping Type

local
Mapping Status ECUC Parameter ID
valid [ECUC_FrArTp_-
00016]

BSW Module BSW Context

FrArTp FrArTp/FrArTpGeneral
BSW Parameter BSW Type
FrArTpHaveTc ECUC-BOOLEAN-PARAM-DEF
BSW Description
Preprocessor switch for enabling Transmit Cancellation and Receive Cancellation.
Template Description

M2 Parameter

FrArTp FrArTp/FrArTpMultipleConfig
BSW Parameter BSW Type
FrArTpChannel ECUC-PARAM-CONF-CONTAINER-DEF
5

1483 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

4
BSW Description
This container contains the configuration (parameters) of one FlexRay TP channel.
Template Description
A channel is a group of connections sharing several properties.
The FlexRay AutosarTransport Layer supports several channels. These channels can work concurrently, thus each of them
requires its own state machine and management data structures and its own PDU-IDs.
M2 Parameter
SystemTemplate::TransportProtocols::FlexrayArTpChannel
Mapping Rule Mapping Type
Create container for each FlexrayArTpChannel that exists in the Ecu Extract. full
Mapping Status ECUC Parameter ID
valid [ECUC_FrArTp_-
00005]

BSW Module BSW Context

FrArTp FrArTp/FrArTpMultipleConfig/FrArTpChannel
BSW Parameter BSW Type
FrArTpAckType ECUC-ENUMERATION-PARAM-DEF
BSW Description
This parameter defines the type of acknowledgement which is used for the specific channel.
Template Description
Type of Acknowledgement.
M2 Parameter
SystemTemplate::TransportProtocols::FlexrayArTpChannel.ackType
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_FrArTp_-
00002]

BSW Module BSW Context

FrArTp FrArTp/FrArTpMultipleConfig/FrArTpChannel
BSW Parameter BSW Type
FrArTpAdrType ECUC-ENUMERATION-PARAM-DEF
BSW Description
This parameter states the addressing type this connection has. The meanings of the values are one byte and two byte.
Template Description
Adressing Type of this connection:
true: Two Bytes
false: One Byte
M2 Parameter
SystemTemplate::TransportProtocols::FlexrayArTpChannel.extendedAddressing
Mapping Rule Mapping Type
5

1484 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

System Template
AUTOSAR CP R21-11

System Template
AUTOSAR CP R21-11

4
Create container for every IPdu that is transmitted by the FrArTp and the regarded Ecu. full
Mapping Status ECUC Parameter ID
valid [ECUC_FrArTp_-
00055]

BSW Module BSW Context

BSW Module BSW Context

FrArTp FrArTp/FrArTpMultipleConfig/FrArTpChannel
BSW Parameter BSW Type
FrArTpMaxAs ECUC-INTEGER-PARAM-DEF
BSW Description
This parameter defines the maximum number of trying to send a frame when a TIMEOUT AS occurs.
Template Description
This attribute defines the maximum number of trying to send a frame when a TIMEOUT AS occurs (depending on whether
retry is configured).
M2 Parameter
SystemTemplate::TransportProtocols::FlexrayArTpChannel.maxAs
Mapping Rule Mapping Type
1:1 mapping full
Mapping Status ECUC Parameter ID
valid [ECUC_FrArTp_-
00022]

FrArTp FrArTp/FrArTpMultipleConfig/FrArTpChannel/FrArTpPdu
BSW Parameter BSW Type
FrArTpPduDirection ECUC-ENUMERATION-PARAM-DEF
BSW Description
This parameter defines the direction of the PDU.
Template Description

M2 Parameter
SystemTemplate::Fibex::FibexCore::CoreCommunication::PduTriggering.iPduPort
Mapping Rule Mapping Type
The direction of the Npdu can be derived from the triggering elements that contain references to full
IN- and OUT-Ports.
Mapping Status ECUC Parameter ID
valid [ECUC_FrArTp_-
00030]

BSW Module BSW Context

AUTOSAR CP TPS SoftwareComponentTemplate
No ratings yet
AUTOSAR CP TPS SoftwareComponentTemplate
1,228 pages
AUTOSAR TPS SoftwareComponentTemplate
No ratings yet
AUTOSAR TPS SoftwareComponentTemplate
1,127 pages
AUTOSAR SWS FlexRayARTransportLayer
No ratings yet
AUTOSAR SWS FlexRayARTransportLayer
101 pages
Autosar Sws Socketadaptor
No ratings yet
Autosar Sws Socketadaptor
157 pages
AUTOSAR SWS FlexRayInterface
No ratings yet
AUTOSAR SWS FlexRayInterface
177 pages
Autosar Sws Pdurouter
No ratings yet
Autosar Sws Pdurouter
121 pages
Autosar Sws Ipdumultiplexer
100% (1)
Autosar Sws Ipdumultiplexer
103 pages
Autosar Sws Com
No ratings yet
Autosar Sws Com
220 pages
AUTOSAR CP SWS CANNetworkManagement-pages-1
No ratings yet
AUTOSAR CP SWS CANNetworkManagement-pages-1
3 pages
IP AUTOSAR HanserAutomotive 201311 PressArticle EN
No ratings yet
IP AUTOSAR HanserAutomotive 201311 PressArticle EN
4 pages
AUTOSAR SWS EthernetDriver
No ratings yet
AUTOSAR SWS EthernetDriver
102 pages
AUTOSAR SWS FlexRayNetworkManagement
No ratings yet
AUTOSAR SWS FlexRayNetworkManagement
129 pages
AUTOSAR SWS CANNetworkManagement
No ratings yet
AUTOSAR SWS CANNetworkManagement
117 pages
AUTOSAR TPS ECUConfiguration
No ratings yet
AUTOSAR TPS ECUConfiguration
305 pages
Autosar Cp Tps Ecuconfiguration
No ratings yet
Autosar Cp Tps Ecuconfiguration
318 pages
AUTOSAR CP SWS DiagnosticCommunicationManager
No ratings yet
AUTOSAR CP SWS DiagnosticCommunicationManager
835 pages
Autosar Exp VFB
No ratings yet
Autosar Exp VFB
109 pages
AUTOSAR TPS ECUConfiguration
No ratings yet
AUTOSAR TPS ECUConfiguration
311 pages
AUTOSAR SWS EthernetStateManager
No ratings yet
AUTOSAR SWS EthernetStateManager
56 pages
AUTOSAR SWS CANInterface
No ratings yet
AUTOSAR SWS CANInterface
215 pages
AUTOSAR SWS CANInterface
No ratings yet
AUTOSAR SWS CANInterface
217 pages
Autosar Sws Diagnosticoverip
No ratings yet
Autosar Sws Diagnosticoverip
119 pages
AUTOSAR_SWS_ComStackTypes
No ratings yet
AUTOSAR_SWS_ComStackTypes
24 pages
AUTOSAR SWS CANNetworkManagement
No ratings yet
AUTOSAR SWS CANNetworkManagement
115 pages
AUTOSAR SWS EthernetTransceiverDriver
No ratings yet
AUTOSAR SWS EthernetTransceiverDriver
89 pages
AUTOSAR TPS ECUConfiguration
No ratings yet
AUTOSAR TPS ECUConfiguration
292 pages
AUTOSAR SWS CANInterface
No ratings yet
AUTOSAR SWS CANInterface
212 pages
AUTOSAR SWS DiagnosticCommunicationManager
No ratings yet
AUTOSAR SWS DiagnosticCommunicationManager
697 pages
AUTOSAR SWS CANNetworkManagement
No ratings yet
AUTOSAR SWS CANNetworkManagement
98 pages
AUTOSAR SWS CANTransportLayer
No ratings yet
AUTOSAR SWS CANTransportLayer
96 pages
AUTOSAR CP SWS TimeSyncOverEthernet
No ratings yet
AUTOSAR CP SWS TimeSyncOverEthernet
147 pages
Autosar Tps Ecuresourcetemplate
No ratings yet
Autosar Tps Ecuresourcetemplate
58 pages
Autosar Sws Com
100% (1)
Autosar Sws Com
216 pages
CAN COM Training
No ratings yet
CAN COM Training
153 pages
AUTOSAR SWS CANInterface
No ratings yet
AUTOSAR SWS CANInterface
212 pages
AUTOSAR CP EXP LayeredSoftwareArchitecture 2
No ratings yet
AUTOSAR CP EXP LayeredSoftwareArchitecture 2
183 pages
AUTOSAR SWS MCUDriver
No ratings yet
AUTOSAR SWS MCUDriver
50 pages
Comstack
No ratings yet
Comstack
51 pages
AUTOSAR SWS UDPNetworkManagement
No ratings yet
AUTOSAR SWS UDPNetworkManagement
103 pages
AUTOSAR TR ClassicPlatformReleaseOverview
No ratings yet
AUTOSAR TR ClassicPlatformReleaseOverview
42 pages
AUTOSAR_SWS_FlexRayNetworkManagement AUTOSAR
No ratings yet
AUTOSAR_SWS_FlexRayNetworkManagement AUTOSAR
121 pages
Autosar CP Sws Candriver
No ratings yet
Autosar CP Sws Candriver
131 pages
AUTOSAR SWS COMManager
No ratings yet
AUTOSAR SWS COMManager
193 pages
AUTOSAR CP RS SystemTemplate
No ratings yet
AUTOSAR CP RS SystemTemplate
44 pages
Autosar Sws Commanager
No ratings yet
Autosar Sws Commanager
128 pages
AUTOSAR CP TR BSWModuleList
No ratings yet
AUTOSAR CP TR BSWModuleList
11 pages
AUTOSAR TR ReleaseOverviewAndRevHistory
No ratings yet
AUTOSAR TR ReleaseOverviewAndRevHistory
47 pages
Autosar Sws Com
No ratings yet
Autosar Sws Com
138 pages
Autosar Sws XCP
No ratings yet
Autosar Sws XCP
66 pages
AUTOSAR SWS CommunicationStackTypes
No ratings yet
AUTOSAR SWS CommunicationStackTypes
26 pages
Autosar Sws Pdu Router
No ratings yet
Autosar Sws Pdu Router
94 pages
AUTOSAR TPS SoftwareComponentTemplate
No ratings yet
AUTOSAR TPS SoftwareComponentTemplate
1,069 pages
AUTOSAR_SWS_COMManager
No ratings yet
AUTOSAR_SWS_COMManager
192 pages
Eth Autosar
No ratings yet
Eth Autosar
61 pages
Oracle SOA Suite 11g Administrator's Handbook
From Everand
Oracle SOA Suite 11g Administrator's Handbook
Ahmed Aboulnaga
No ratings yet
AUTOSAR SWS DiagnosticCommunicationManager
No ratings yet
AUTOSAR SWS DiagnosticCommunicationManager
683 pages
Communication Gosda
No ratings yet
Communication Gosda
34 pages
AUTOSAR CP SWS CommunicationStackTypes
No ratings yet
AUTOSAR CP SWS CommunicationStackTypes
26 pages
Autosar Cp Sws Canstatemanager
No ratings yet
Autosar Cp Sws Canstatemanager
115 pages
AUTOSAR 3.2 Based Protocol Data Unit Router Module
No ratings yet
AUTOSAR 3.2 Based Protocol Data Unit Router Module
6 pages
CSC
No ratings yet
CSC
26 pages
MVS History
No ratings yet
MVS History
13 pages
System Information - Report Page
No ratings yet
System Information - Report Page
85 pages
Ka-Band MMIC High Power Amplifier (4W at 30GHz) With Record Compact Size
No ratings yet
Ka-Band MMIC High Power Amplifier (4W at 30GHz) With Record Compact Size
4 pages
202206-ECCOMAS-Oslo-Article
No ratings yet
202206-ECCOMAS-Oslo-Article
12 pages
External Devices Data International Reference Alphabet (IRA)
No ratings yet
External Devices Data International Reference Alphabet (IRA)
2 pages
Xenta 511
No ratings yet
Xenta 511
86 pages
Vsat Manual: Ri-Series Dsi-Series
No ratings yet
Vsat Manual: Ri-Series Dsi-Series
29 pages
SAM4040 Family Technical Manual V1.0
No ratings yet
SAM4040 Family Technical Manual V1.0
75 pages
Cambridge Assessment International Education: Information Technology 9626/32 May/June 2019
No ratings yet
Cambridge Assessment International Education: Information Technology 9626/32 May/June 2019
12 pages
x86 Architecture Overview
No ratings yet
x86 Architecture Overview
9 pages
GeoMax_OfficeToolsGuide_en
No ratings yet
GeoMax_OfficeToolsGuide_en
7 pages
ePMP AX 5.4.1 Release Notes
No ratings yet
ePMP AX 5.4.1 Release Notes
9 pages
Hands-On With CoAP
No ratings yet
Hands-On With CoAP
64 pages
Exception-Handling Fundamentals
No ratings yet
Exception-Handling Fundamentals
25 pages
Guide For Free and Request Passcode
No ratings yet
Guide For Free and Request Passcode
5 pages
Compiler Construction Notes
No ratings yet
Compiler Construction Notes
21 pages
Thorn CM User Manual
No ratings yet
Thorn CM User Manual
36 pages
Baver Aker CV - ENG
No ratings yet
Baver Aker CV - ENG
2 pages
Cloud Computing
100% (2)
Cloud Computing
20 pages
Untitled
No ratings yet
Untitled
37 pages
5 Theory Notes L2
No ratings yet
5 Theory Notes L2
2 pages
Installation Guide For The Suite Installer (Customer Programming Software and Radio Management)
No ratings yet
Installation Guide For The Suite Installer (Customer Programming Software and Radio Management)
7 pages
Lecture Notes DBM S
No ratings yet
Lecture Notes DBM S
11 pages
2SD1391 - Savantic, Inc Datasheet
No ratings yet
2SD1391 - Savantic, Inc Datasheet
3 pages
Exp 3 1
No ratings yet
Exp 3 1
5 pages
Cloud unit 4
No ratings yet
Cloud unit 4
14 pages
A Blueprint For SAP Deployment From HPE and Red Hat - 1617310212988001wyTR
No ratings yet
A Blueprint For SAP Deployment From HPE and Red Hat - 1617310212988001wyTR
13 pages
Apache Tomcat Linux Installation and Set
100% (1)
Apache Tomcat Linux Installation and Set
5 pages
Kafka Notes
No ratings yet
Kafka Notes
7 pages

Uploaded by

Uploaded by

System Template

Document Title System Template

Document Status published

Document Change History

1 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

• Added support for BusMirorring

2 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

3 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

• Added support for remote activation

4 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

• updated System class category

5 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

• Implemented support for LIN 2.1

6 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

• Added the boolean attribute

7 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

• Support for Signal Groups added.

8 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

9 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

10 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

11 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

3.3.4.3 FlexRay Communication Connector . . . . . . . . . 84

12 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

5.2.1.2 Mapping of Variable Data Prototypes with composite

13 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

6.7.2.3 Configuration Services . . . . . . . . . . . . . . . . . 380

14 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

6.10.3 Ethernet Destination Channel . . . . . . . . . . . . . . . . . 562

15 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

7.2.2 Support of transmission from one sender to multiple re-

16 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

10.1.2 Representation of Methods . . . . . . . . . . . . . . . . . . . 730

17 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

14.5.3 Assigning communication graphs to RTE Implementation

B Detailed Representation of InstanceRef Associations in the System Template 832

18 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

C.2.4 CanNm Mapping . . . . . . . . . . . . . . . . . . . . . . . . . 1259

19 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

C.11.2 ECU State Manager . . . . . . . . . . . . . . . . . . . . . . . 2242

20 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

D.7.1 Added Traceables in R4.2.1 . . . . . . . . . . . . . . . . . . . 2253

21 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

D.13 Constraint and Specification Item History of this document according

F Splitable Elements in the Scope of this Document 2385

G Variation Points in the Scope of this Document 2388

22 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

23 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

[18] Specification of COM Based Transformer

24 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

[36] Specification of TCP/IP Stack

25 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

CAN Controller Area Network

26 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

Table 1.1: Abbreviations used in the scope of this Document

27 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

1.2 Requirements Tracing

28 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

29 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

30 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

Table 1.2: RequirementsTracing

1.3 Requirements not fulfilled by TPS requirements

31 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

[RS_SYST_00025] The System Template shall enable the Harmonization between

32 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

1.4 Methodology for Defining Formal Template

«Text Document» +isGovernedBy UML and the Autosar

«Text Document» «Text Document»

«XML File» «XML Schema» «XML File»

Figure 1.1: Methodology to define templates in AUTOSAR

The following documents describe the various aspects of the methodology:

33 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

34 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

Complex generation step:

Figure 1.2: AUTOSAR Methodology

35 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate

AUTOSAR ECU Config Generator (per ECU)

AUTOSAR System Generator

36 of 2391 Document ID 63: AUTOSAR_TPS_SystemTemplate