Software Component Template

AUTOSAR CP Release 4.4.0

Document Title Software Component Template

Document Owner AUTOSAR
Document Responsibility AUTOSAR
Document Identification No 062

Document Status Final

Part of AUTOSAR Standard Classic Platform
Part of Standard Release 4.4.0

Document Change History

Date Release Changed by Description
• Support for optional elements in
structured data types
AUTOSAR • Improved description of service use
2018-10-31 4.4.0 Release cases
Management • minor corrections / clarifications /
editorial changes; For details please
refer to the ChangeDocumentation
AUTOSAR • minor corrections / clarifications /
2017-12-08 4.3.1 Release editorial changes; For details please
Management refer to the ChangeDocumentation
• Improved support for Unions
• Improved upstream mapping
AUTOSAR • Improved description of service use
2016-11-30 4.3.0 Release cases
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

1 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

• Efficient NV data handling

• Introduction of data transformation
AUTOSAR • Support for variable-size Arrays of
2014-10-31 4.2.1 Release arbitrary data types
Management • Support for ASIL/QM development
• Minor corrections / clarifications /
editorial changes; For details please
refer to the BWCStatement
AUTOSAR
2014-03-31 4.1.3 Release • Various fixes and clarifications
Management
AUTOSAR
2013-10-31 4.1.2 Release • Various fixes and clarifications
Management
• Introduction of PRPortPrototype
• Definition of implicit communication
behavior
• Support for the formal analysis of
resource locking
• Introduction of refined scheduling of
RunnableEntitys
• Get information about activating
RTEEvent
• Connection of Mode Managers and
AUTOSAR Mode Users with different number of
2013-03-15 4.1.1
Administration ModeDeclarations
• Support activation of
RunnableEntitys on remote
ECUs
• Support for ModeTransition
• Support for the definition of the
network representation of composite
data types
• ServiceNeeds for diagnostics over
IP
• Various fixes and clarifications

2 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

• Added CompuMethod categories

SCALE_LINEAR_AND_TEXTTABLE
and SCALE_RATIONAL_
AND_TEXTTABLE (table 5.76)
• Clarification concerning the usage of
invalid values
• Revised support for data filters
• Support for partial networking
AUTOSAR • Support for the specification of local
2011-12-22 4.0.3 connections between
Administration
software-components
• Improved description of service
needs
• Change history of constraints and
specification items
• Miscellaneous improvements and
clarifications
• “Support for Standardization” moved
to Standardization Template [1]
• Remove restriction on data type of
inter-runnable variables
AUTOSAR • Rework end-to-end communication
2011-04-15 4.0.2 protection
Administration
• Add more constraints on the usage
of the meta-model
• Various fixes and clarifications

3 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

• New requirements tracing table

• Support for fixed data exchange
• Implementation of meta-model
cleanup
• Fundamental revision of the data
type concept
• Support for variant handling
• Support for end-to-end
communication protection
AUTOSAR • Support for documentation
2009-12-18 4.0.1 • Support for stopping and restarting
Administration
of software-components
• Support for triggered events
• Support for explicit mapping of
interface elements
• Revised concept of mode
management
• Support for integrity and scaling at
ports
• Support for standardization within
AUTOSAR

AUTOSAR • Improved support for on-board

2008-08-13 3.1.1 diagnostics
Administration
• Small layout adaptations made
• Improved support for measurement
and calibration
• Improved semantics of delegation
AUTOSAR ports
2007-12-21 3.0.1 • Introduction of abstract memory
Administration
classes
• Document meta information
extended
• Small layout adaptations made

4 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

• Harmonization of the document with

other specifications (e.g. RTE)
• Introduction of a new concept to
support calibration and
measurement - harmonized with RTE
• Description of needs of the Software
AUTOSAR Component Template toward
2007-01-24 2.1.15 AUTOSAR services and of the
Administration
interaction of the Software
Component Template and services
(on XML level)
• Legal disclaimer revised
• Release notes added
• “Advice for users” added
• “Revision information” added
AUTOSAR
2006-05-16 2.0.0 Second
Administration
AUTOSAR
2005-05-31 1.0.0 Initial release
Administration

5 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

6 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

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.

7 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Table of Contents
1 Introduction 27
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.2 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.3 Organization of the Meta-Model . . . . . . . . . . . . . . . . . . . . . . 28
1.4 Structure of the Template . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.4.1 Description of Software Components on VFB Level . . . . . 30
1.4.2 Description of Software Components on RTE Level . . . . . 30
1.4.3 Descriptions of Software Components on Implementation Level 31
1.5 Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.6 Document Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
1.7 Requirements Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2 Conceptual Aspects 44
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.2 Measurement and Calibration . . . . . . . . . . . . . . . . . . . . . . . 44
2.2.1 Basic Approach of Measurement and Calibration . . . . . . . 44
2.2.2 Calibration Parameters Overview . . . . . . . . . . . . . . . . 44
2.2.3 Using Calibration Parameters . . . . . . . . . . . . . . . . . . 45
2.2.3.1 Sharing Calibration Parameters within Compositions 45
2.2.3.2 Sharing Calibration Parameters between SwCompo-
nentPrototypes of the Same SwComponentType . . 48
2.2.3.3 Providing Instance Individual Characteristic Data . . 49
2.3 Runtime and Data Consistency Aspects . . . . . . . . . . . . . . . . . 50
2.3.1 Background: the Issues . . . . . . . . . . . . . . . . . . . . . 50
2.3.1.1 Mutual Exclusion with Semaphores . . . . . . . . . . 51
2.3.1.2 Interrupt Disabling . . . . . . . . . . . . . . . . . . . 51
2.3.1.3 Priority Ceiling . . . . . . . . . . . . . . . . . . . . . 52
2.3.1.4 Implicit Communication by Means of Variable Copies 52
2.3.2 Data Consistency at Runtime . . . . . . . . . . . . . . . . . . 53
2.3.3 Modeling Aspects of Data Consistency . . . . . . . . . . . . 53
2.4 Variant Handling in the Software Component Template . . . . . . . . . 54
2.5 Communication Specification of Composition Component Types . . . . 56
2.5.1 Rationale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.6 PRPortPrototype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
2.6.1 Use Case 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
2.6.2 Use Case 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
2.6.3 Use Case 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.6.4 Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
2.7 Pretended Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
2.8 Variable-size Array Data Types . . . . . . . . . . . . . . . . . . . . . . 62
2.8.1 Overview and Use cases . . . . . . . . . . . . . . . . . . . . 62
2.8.1.1 “Old-world” dynamic-size Arrays . . . . . . . . . . . 62
2.8.1.2 “New-world” variable-size Arrays . . . . . . . . . . . 63
2.8.2 Modeling Aspects regarding Application Data Types . . . . . 66

8 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

2.8.3 Modeling Aspects regarding Implementation Data Types . . 67

2.9 Optional Elements in Structures . . . . . . . . . . . . . . . . . . . . . . 68
2.9.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3 Overview: Software Components, Ports, and Interfaces 70
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.2 Software Component . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.2.2 PortPrototype . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.2.3 AtomicSwComponentType . . . . . . . . . . . . . . . . . . . 76
3.2.4 ParameterSwComponentType . . . . . . . . . . . . . . . . . 79
3.2.5 Symbolic Name of a Software-Component . . . . . . . . . . 79
3.3 Composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.3.2 SwComponentPrototype . . . . . . . . . . . . . . . . . . . . 82
3.3.3 Connectors . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
3.3.4 Instantiation-specific RTEEvents . . . . . . . . . . . . . . . . 90
3.4 Port Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
4 Details: Software Components, Ports, and Interfaces 98
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.2 Port Interface Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.2.2 Sender Receiver Communication . . . . . . . . . . . . . . . . 99
4.2.3 Client Server Communication . . . . . . . . . . . . . . . . . . 103
4.2.3.1 Client Server Interface . . . . . . . . . . . . . . . . . 103
4.2.3.2 Error Handling in Client/Server Communication . . . 108
4.2.4 External Trigger Event Communication . . . . . . . . . . . . 110
4.2.5 Communication of Modes . . . . . . . . . . . . . . . . . . . . 113
4.2.6 Parameter Communication . . . . . . . . . . . . . . . . . . . 119
4.3 PortInterface Mapping and Data Scaling . . . . . . . . . . . . . . . . . 119
4.3.1 PortInterface Mapping . . . . . . . . . . . . . . . . . . . . . . 121
4.3.1.1 Mapping of Sender Receiver Interface, Parameter In-
terface and Non Volatile Data Interface Elements . . 123
4.3.1.2 Mapping of Client Server Interface Elements . . . . 125
4.3.1.3 Mapping of Mode Interface Elements . . . . . . . . . 129
4.3.1.4 Mapping of Trigger Interface Elements . . . . . . . . 133
4.3.1.5 Mapping of Elements of a composite Data Type . . . 134
4.3.2 Data Conversion . . . . . . . . . . . . . . . . . . . . . . . . . 141
4.3.2.1 Linear Data Scaling . . . . . . . . . . . . . . . . . . 142
4.3.2.2 Table Conversion . . . . . . . . . . . . . . . . . . . . 143
4.3.3 Relevance for Data Transformation . . . . . . . . . . . . . . . 148
4.4 Port Annotation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
4.4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
4.4.2 SenderReceiverAnnotation . . . . . . . . . . . . . . . . . . . 153
4.4.3 ClientServerAnnotation . . . . . . . . . . . . . . . . . . . . . 157
4.4.4 Annotation for the I/O Hardware Abstraction Layer . . . . . . 158

9 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4.4.5 Parameter Port Annotation . . . . . . . . . . . . . . . . . . . 160

4.4.6 Mode Port Annotation . . . . . . . . . . . . . . . . . . . . . . 161
4.4.7 Trigger Port Annotation . . . . . . . . . . . . . . . . . . . . . 162
4.4.8 Non Volatile Data Port Annotation . . . . . . . . . . . . . . . 163
4.4.9 Delegated Port Annotations . . . . . . . . . . . . . . . . . . . 164
4.4.10 General Annotation . . . . . . . . . . . . . . . . . . . . . . . 166
4.5 Communication Specification . . . . . . . . . . . . . . . . . . . . . . . 166
4.5.1 Communication Specification for Sender-Receiver Commu-
nication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
4.5.2 Communication Specification for Client-Server Communication183
4.5.3 Communication Specification for Mode Switch Communication 185
4.5.4 Communication Specification for Parameters . . . . . . . . . 188
4.5.5 Communication Specification for NV Data . . . . . . . . . . . 190
4.5.6 Configuration of Data Transformation . . . . . . . . . . . . . 193
4.6 Port Groups within Component Types . . . . . . . . . . . . . . . . . . . 199
4.7 End to End Protection . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
4.8 Partial Networking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
4.8.1 VFC Control Ports . . . . . . . . . . . . . . . . . . . . . . . . 212
4.8.2 VFC Status Ports . . . . . . . . . . . . . . . . . . . . . . . . 213
4.9 Formal Definition of implicit Communication Behavior . . . . . . . . . . 214
4.9.1 Consistency Needs on Receiver Side . . . . . . . . . . . . . 218
4.9.2 Consistency Needs on Sender Side . . . . . . . . . . . . . . 219
4.9.3 Consistency Needs for Senders and receivers of the same
Data inside on RunnableEntityGroup . . . . . . . . . . . . . 219
5 Data Description 220
5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
5.2 Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
5.2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
5.2.2 Data Type Mapping . . . . . . . . . . . . . . . . . . . . . . . 226
5.2.3 Data Categories . . . . . . . . . . . . . . . . . . . . . . . . . 230
5.2.4 Application Data Type . . . . . . . . . . . . . . . . . . . . . . 234
5.2.4.1 Application Primitive Data Types . . . . . . . . . . . 237
5.2.4.2 Application Composite Data Types . . . . . . . . . . 254
5.2.5 Implementation Data Type . . . . . . . . . . . . . . . . . . . 269
5.2.5.1 Modeling of Optional Element Structure with Imple-
mentationDataType . . . . . . . . . . . . . . . . . . . 292
5.2.6 Base Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294
5.2.7 Data Type Terminology . . . . . . . . . . . . . . . . . . . . . 300
5.2.7.1 Primitive Type . . . . . . . . . . . . . . . . . . . . . . 300
5.2.7.2 Compound Primitive Data Type . . . . . . . . . . . . 301
5.2.7.3 Integral Primitive Type . . . . . . . . . . . . . . . . . 301
5.2.7.4 Variable-Size Array Data Type . . . . . . . . . . . . . 303
5.2.7.5 Wrapped Union Data Type . . . . . . . . . . . . . . . 303
5.2.7.6 Optional Element Structure . . . . . . . . . . . . . . 306
5.3 Data Prototypes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306

10 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

5.3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306

5.3.2 Data Constraints for DataPrototypes typed by Array DataTypes313
5.3.3 Reference to Data Prototypes . . . . . . . . . . . . . . . . . 314
5.3.3.1 AUTOSAR Variable Ref . . . . . . . . . . . . . . . . 315
5.3.3.2 AUTOSAR Parameter Ref . . . . . . . . . . . . . . . 316
5.3.3.3 Modeling Approach . . . . . . . . . . . . . . . . . . . 318
5.3.3.4 Access into VariableDataPrototype typed by an Im-
plementationDataType . . . . . . . . . . . . . . . . . 320
5.3.3.5 Access into ParameterDataPrototype typed by an
ImplementationDataType . . . . . . . . . . . . . . . 323
5.4 Properties of Data Definitions . . . . . . . . . . . . . . . . . . . . . . . 325
5.4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325
5.4.2 Invalid Value . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
5.4.3 Properties for Measurement . . . . . . . . . . . . . . . . . . 345
5.4.4 Properties of Curves and Maps . . . . . . . . . . . . . . . . . 346
5.4.4.1 Specification of fix Axes . . . . . . . . . . . . . . . . 356
5.4.5 Setting an Axis Input Value . . . . . . . . . . . . . . . . . . . 361
5.4.6 Setting a Group Axis . . . . . . . . . . . . . . . . . . . . . . . 366
5.4.7 Specifying Data Dependencies . . . . . . . . . . . . . . . . . 372
5.4.8 Precedence of data properties with respect to data elements,
axis elements, computation methods, units . . . . . . . . . . 374
5.5 Elements used in Properties of Data Definitions . . . . . . . . . . . . . 380
5.5.1 Computation Methods . . . . . . . . . . . . . . . . . . . . . . 380
5.5.1.1 Category Values in the context of a CompuMethod . 391
5.5.1.2 Applicability of Attributes in the context of a Com-
puMethod . . . . . . . . . . . . . . . . . . . . . . . . 392
5.5.1.3 CompuMethod and AutosarDataType . . . . . . . . . 394
5.5.1.4 Example for Enumeration . . . . . . . . . . . . . . . 396
5.5.1.5 Example for Linear Conversion . . . . . . . . . . . . 397
5.5.1.6 Example for Linear Conversion with texttable . . . . 397
5.5.1.7 Example for conversion specified by a rational function398
5.5.1.8 Example for BITFIELD_TEXTTABLE . . . . . . . . . 399
5.5.2 Physical Units, Physical Dimensions and Unit Groups . . . . 402
5.5.3 Data Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 409
5.5.3.1 Physical Limits . . . . . . . . . . . . . . . . . . . . . 416
5.5.4 Addressing Methods . . . . . . . . . . . . . . . . . . . . . . . 416
5.5.5 Record Layouts . . . . . . . . . . . . . . . . . . . . . . . . . 425
5.5.5.1 Specifying Record Layouts . . . . . . . . . . . . . . 426
5.5.5.2 RecordLayouts and DataTypes . . . . . . . . . . . . 435
5.5.5.3 Record Layouts and Interpolation Routines . . . . . 443
5.5.6 Display Presentation . . . . . . . . . . . . . . . . . . . . . . . 445
5.6 Specification of Constant Values . . . . . . . . . . . . . . . . . . . . . 447
5.6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
5.6.2 Specification of Values based on Rules . . . . . . . . . . . . 454
5.6.2.1 Support for primitive Data Types . . . . . . . . . . . 454
5.6.2.2 Support for composite Data Types . . . . . . . . . . 461

11 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

5.6.3 Reference to Constant . . . . . . . . . . . . . . . . . . . . . 466

5.6.4 Values for Compound Primitive Data Types . . . . . . . . . . 467
5.6.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475
5.6.5.1 Example for Constant Specification for CURVE . . . 475
5.6.5.2 Example for Constant Specification for MAP . . . . . 476
5.6.5.3 Example for Constant Specification for MAP with two
STD_AXIS . . . . . . . . . . . . . . . . . . . . . . . 477
5.6.5.4 Example for Constant Specification for COM_AXIS . 478
5.7 Initial Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
5.7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 479
5.7.2 Initial Value Representation . . . . . . . . . . . . . . . . . . . 480
5.7.3 Constant Specification Mapping . . . . . . . . . . . . . . . . 481
5.7.4 Initial Values For CalibrationParameters . . . . . . . . . . . . 484
5.7.5 Initial Value for optional Element . . . . . . . . . . . . . . . . 485
5.7.5.1 Initial Value for optional ApplicationRecordElement . 485
5.7.5.2 Initial Value for optional ImplementationDataType-
Element . . . . . . . . . . . . . . . . . . . . . . . . . 486
6 Compatibility 487
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 487
6.2 Compatibility of Data Types . . . . . . . . . . . . . . . . . . . . . . . . 487
6.2.1 ApplicationDataType . . . . . . . . . . . . . . . . . . . . . . . 487
6.2.1.1 ApplicationPrimitiveDataType . . . . . . . . . . . . . 487
6.2.1.2 ApplicationCompositeDataType . . . . . . . . . . . . 488
6.2.2 ImplementationDataType . . . . . . . . . . . . . . . . . . . . 489
6.2.3 Compatibility of SwBaseType . . . . . . . . . . . . . . . . . . 491
6.2.4 Compatibility of SwDataDefProps . . . . . . . . . . . . . . . 491
6.2.4.1 Compatibility of Units . . . . . . . . . . . . . . . . . . 492
6.2.4.2 Compatibility of PhysicalDimensions . . . . . . . . . 493
6.2.4.3 Compatibility of Data Constraints . . . . . . . . . . . 494
6.2.4.4 Compatibility in case of ImplementationDataType . . 494
6.2.4.5 Compatibility of CompuMethods . . . . . . . . . . . 495
6.2.4.6 Compatibility of Record Layouts . . . . . . . . . . . . 497
6.2.5 Compatibility of ApplicationDataType and Implementation-
DataType . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 498
6.3 Compatibility of Variable Data Prototypes and Parameter Data Prototypes501
6.4 Compatibility of Sender Receiver Interfaces, Parameter Interfaces and
Non Volatile Data Interfaces . . . . . . . . . . . . . . . . . . . . . . . . 503
6.4.1 Connection of Required and Provided Port via Assem-
blySwConnector . . . . . . . . . . . . . . . . . . . . . . . . . 503
6.4.2 Connection of Inner and Outer Port via DelegationSwCon-
nector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 504
6.4.3 Connection of Required and Provided Port via PassThrough-
SwConnector . . . . . . . . . . . . . . . . . . . . . . . . . . . 505
6.4.4 Compatibility of ParameterDataPrototype and VariableDat-
aPrototype depending on PortInterface Type . . . . . . . . . 505

12 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

6.5 Compatibility of Mode Switch Interfaces . . . . . . . . . . . . . . . . . 506

6.5.1 Connection of Required and Provided Port via Assem-
blySwConnector . . . . . . . . . . . . . . . . . . . . . . . . . 507
6.5.2 Connection of Inner and Outer Port via DelegationSwCon-
nector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507
6.5.3 Connection of Outer and Outer Port via PassThroughSwCon-
nector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 508
6.6 Compatibility of Mode Declaration Group Prototypes . . . . . . . . . . 508
6.7 Compatibility of Mode Declaration Groups . . . . . . . . . . . . . . . . 509
6.8 Compatibility of Argument Prototypes . . . . . . . . . . . . . . . . . . . 510
6.9 Compatibility of Application Errors . . . . . . . . . . . . . . . . . . . . . 510
6.10 Compatibility of Client/Server Operations . . . . . . . . . . . . . . . . . 511
6.11 Compatibility of Client Server Interfaces . . . . . . . . . . . . . . . . . 511
6.11.1 Connection of Required and Provided Port via Assem-
blySwConnector . . . . . . . . . . . . . . . . . . . . . . . . . 511
6.11.2 Connection of Inner and Outer Port via DelegationSwCon-
nector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512
6.11.3 Connection of Outer and Outer Port via PassThroughSwCon-
nector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 513
6.12 Compatibility of Trigger Interfaces . . . . . . . . . . . . . . . . . . . . . 513
6.12.1 Connection of Required and Provided Port via Assem-
blySwConnector . . . . . . . . . . . . . . . . . . . . . . . . . 513
6.12.2 Connection of Inner and Outer Port via DelegationSwCon-
nector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
6.12.3 Connection of Outer and Outer Port via PassThroughSwCon-
nector . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 514
6.13 Compatibility of Trigger . . . . . . . . . . . . . . . . . . . . . . . . . . . 515
6.14 Entire Delegation of a Provided Port Prototype . . . . . . . . . . . . . . 515
6.14.1 Split and Merge of PortInterface Elements . . . . . . . . . . 516
6.15 Compatibility in Case of a Flat ECU Extract . . . . . . . . . . . . . . . 517
6.16 Compatibility Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 518
6.16.1 Compatibility on Assembly Level . . . . . . . . . . . . . . . . 518
6.16.1.1 Legal Use . . . . . . . . . . . . . . . . . . . . . . . . 518
6.16.1.2 Illegal Use . . . . . . . . . . . . . . . . . . . . . . . . 519
6.16.2 Compatibility on Delegation Level . . . . . . . . . . . . . . . 519
6.16.2.1 Legal Use . . . . . . . . . . . . . . . . . . . . . . . . 520
6.16.2.2 Illegal Use . . . . . . . . . . . . . . . . . . . . . . . . 523
7 Internal Behavior 526
7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526
7.2 Runnable Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532
7.2.1 Concurrency and Reentrancy of a RunnableEntity that can-
not be Invoked Concurrently . . . . . . . . . . . . . . . . . . 539
7.2.2 Concurrency and Reentrancy of a RunnableEntity that can
be Invoked Concurrently . . . . . . . . . . . . . . . . . . . . 540
7.2.3 Timed Activation of Runnable Entities . . . . . . . . . . . . . 541

13 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

7.2.4 Additional Remarks and Clarifications . . . . . . . . . . . . . 543

7.2.4.1 Reentrancy and Multiple Instantiation . . . . . . . . . 543
7.2.4.2 Reentrancy and “Library Functions” . . . . . . . . . . 543
7.2.4.3 Compatibility of ClientServerOperations triggering
the same RunnableEntity . . . . . . . . . . . . . . . 544
7.2.4.4 Categories of Runnable Entities . . . . . . . . . . . . 545
7.2.4.5 Arguments of a Runnable Entity . . . . . . . . . . . . 545
7.2.5 Activation Reason of a Runnable Entity . . . . . . . . . . . . 546
7.2.6 Runnable Entity for Initialization Purpose . . . . . . . . . . . 549
7.3 RTEEvent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 550
7.3.1 Defining an Event . . . . . . . . . . . . . . . . . . . . . . . . 555
7.3.2 Defining how to Respond to an Event . . . . . . . . . . . . . 558
7.4 Communication among Runnable Entities . . . . . . . . . . . . . . . . 560
7.4.1 Description Possibility 1: Exclusive Area . . . . . . . . . . . . 561
7.4.1.1 Entire Runnable Runs in the Exclusive Area . . . . . 565
7.4.1.2 Runnable would Dynamically Enter and Leave the
Exclusive Area . . . . . . . . . . . . . . . . . . . . . 565
7.4.1.3 Configuration of API Generation . . . . . . . . . . . 566
7.4.2 Description Possibility 2: Inter-Runnable Variable . . . . . . . 567
7.4.3 Inter Runnable Triggering . . . . . . . . . . . . . . . . . . . . 570
7.5 Data Access of RunnableEntities . . . . . . . . . . . . . . . . . . . . . 571
7.5.1 RunnableEntities and Sender Receiver Communication . . . 574
7.5.1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . 574
7.5.1.2 Data Access . . . . . . . . . . . . . . . . . . . . . . 575
7.5.1.3 Explicit Sending and Receiving . . . . . . . . . . . . 578
7.5.1.4 Implicit Sending and Receiving . . . . . . . . . . . . 582
7.5.1.5 DataSendCompletedEvent . . . . . . . . . . . . . . . 583
7.5.1.6 DataWriteCompletedEvent . . . . . . . . . . . . . . 583
7.5.1.7 DataReceivedEvent . . . . . . . . . . . . . . . . . . 585
7.5.1.8 DataReceiveErrorEvent . . . . . . . . . . . . . . . . 585
7.5.2 RunnableEntities and Client Server Communication . . . . . 587
7.5.2.1 Invoking an Operation . . . . . . . . . . . . . . . . . 587
7.5.2.2 Providing an Implementation of an Operation . . . . 591
7.5.2.3 Reacting on Data Transformation Errors . . . . . . . 592
7.5.3 RunnableEntities and External Trigger Event Communication 593
7.5.3.1 Trigger Source . . . . . . . . . . . . . . . . . . . . . 593
7.5.3.2 Trigger Sink . . . . . . . . . . . . . . . . . . . . . . . 595
7.5.4 RunnableEntities and Parameter Access . . . . . . . . . . . 596
7.5.4.1 InstantiationDataDefProps . . . . . . . . . . . . . . . 598
7.5.5 RunnableEntities and Mode Communication . . . . . . . . . 600
7.6 Port API Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 601
7.6.1 Enable to Take Address . . . . . . . . . . . . . . . . . . . . . 602
7.6.2 Indirect API Generation . . . . . . . . . . . . . . . . . . . . . 603
7.6.3 Port Defined Argument Value . . . . . . . . . . . . . . . . . . 603
7.6.4 Supported Features . . . . . . . . . . . . . . . . . . . . . . . 604
7.6.4.1 Buffer Locking . . . . . . . . . . . . . . . . . . . . . 605

14 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

7.7 PerInstanceMemory . . . . . . . . . . . . . . . . . . . . . . . . . . . . 606

7.7.1 PerInstanceMemory typed by “C” Data Types . . . . . . . . . 607
7.7.2 PerInstanceMemory typed by AUTOSAR Data Types . . . . 608
7.8 Static Memory and Constant Memory . . . . . . . . . . . . . . . . . . . 609
7.9 Included AUTOSAR Data Types . . . . . . . . . . . . . . . . . . . . . . 610
7.10 Included Mode Declaration Groups . . . . . . . . . . . . . . . . . . . . 611
7.11 Service Needs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613
7.11.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 613
7.11.2 Assignment of Service Needs to Ports and Data . . . . . . . 618
7.12 Variation Point Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . 627
8 Implementation 634

9 Mode Management 638

9.1 Declaration of Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 638
9.2 Modes and Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 643
9.3 Initialization / Finalization . . . . . . . . . . . . . . . . . . . . . . . . . . 648
9.4 Mode Error Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . 648
9.5 Summary Meta-Model Excerpt Related to Modes . . . . . . . . . . . . 652
10 ECU Abstraction and Complex Drivers 654
10.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 654
10.2 High Level Hardware and Software Architecture . . . . . . . . . . . . . 654
10.3 Interfaces and APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 657
10.3.1 ECU Abstraction and its AUTOSAR Interfaces . . . . . . . . 658
10.4 Sensors/Actuators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 658
10.5 I/O Hardware Abstraction . . . . . . . . . . . . . . . . . . . . . . . . . 660
10.6 Complex Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 662
11 Services 664
11.1 Overview: Generation of Service-related Model Elements . . . . . . . 664
11.2 Extending the ECU Software Composition . . . . . . . . . . . . . . . . 667
11.3 Service Software Component Type . . . . . . . . . . . . . . . . . . . . 668
11.4 Service Proxy Component Type . . . . . . . . . . . . . . . . . . . . . . 671
11.5 Non Volatile Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674
11.5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 674
11.5.2 NvBlockComponent . . . . . . . . . . . . . . . . . . . . . . . 674
11.5.3 Software-Components using NVRAM data of NvBlockCom-
ponents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 676
11.5.4 Software-Components connected to NvBlockComponents . . 679
11.5.5 NvBlockDescriptor . . . . . . . . . . . . . . . . . . . . . . . . 682
11.5.5.1 Writing Strategies . . . . . . . . . . . . . . . . . . . . 686
11.5.5.2 NvBlockNeeds . . . . . . . . . . . . . . . . . . . . . 690
11.5.5.3 RAM Block and ROM Block . . . . . . . . . . . . . . 692
11.5.5.4 NvBlockDataMapping . . . . . . . . . . . . . . . . . 693
11.5.5.5 Client Server Ports . . . . . . . . . . . . . . . . . . . 699
11.5.6 SwcInternalBehavior of an NvBlockSwComponentType . . . 701

15 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

12 Software Component Documentation 706

13 Service Dependencies and Service Use Cases 710

13.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 710
13.2 NvM Service Dependencies . . . . . . . . . . . . . . . . . . . . . . . . 710
13.2.1 Nvm Use Case: Permanent RAM Block . . . . . . . . . . . . 710
13.2.2 Nvm Use Case: Temporary RAM Block . . . . . . . . . . 712
13.2.3 Nvm Use Case: RAM Block with explicit synchronization us-
ing Mirror Interfaces . . . . . . . . . . . . . . . . . . . . . . . 713
13.2.4 NVM Use Case: Software-Components using Nv Data pro-
vided by NvBlockSwComponentType (not ServiceSwCompo-
nent of NvM) . . . . . . . . . . . . . . . . . . . . . . . . . . . 714
13.3 Watchdog Service Dependencies . . . . . . . . . . . . . . . . . . . . . 715
13.3.1 Watchdog Service use Case: Local Supervision . . . . . . . 715
13.3.2 Watchdog Service use Case: Global Supervision Status no-
tification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 718
13.3.3 Watchdog Service use Case: Control global supervision or
get global supervision status . . . . . . . . . . . . . . . . . . 718
13.4 COM Manager Service Needs . . . . . . . . . . . . . . . . . . . . . . . 719
13.4.1 ComM Use Case: read current ComM Mode . . . . . . . . . 719
13.4.2 ComM Use Case: request ComM Mode . . . . . . . . . . . . 720
13.4.3 ComM Use Case: Software-Component acts as a Mode
Manager that influences the ECU State . . . . . . . . . . . . 720
13.5 ECU State Manager Service Needs . . . . . . . . . . . . . . . . . . . . 721
13.5.1 EcuM Use Case: select Shutdown Target . . . . . . . . . . . 721
13.5.2 EcuM Use Case: select Boot Target . . . . . . . . . . . . . . 722
13.5.3 EcuM Use Case: use Alarm Clock . . . . . . . . . . . . . . . 722
13.6 BswM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 722
13.6.1 Partial Networking . . . . . . . . . . . . . . . . . . . . . . . . 723
13.6.2 Mode Manager . . . . . . . . . . . . . . . . . . . . . . . . . . 723
13.6.3 Mode User . . . . . . . . . . . . . . . . . . . . . . . . . . . . 725
13.6.4 Mode Requester . . . . . . . . . . . . . . . . . . . . . . . . . 726
13.7 Crypto Service Dependencies . . . . . . . . . . . . . . . . . . . . . . . 726
13.7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726
13.7.2 Crypto Service Use Cases . . . . . . . . . . . . . . . . . . . 728
13.7.2.1 Crypto Service Use Case: Hash calculation . . . . . 728
13.7.2.2 Crypto Service Use Case: MAC calculation . . . . . 729
13.7.2.3 Crypto Service Use Case: MAC verification . . . . . 729
13.7.2.4 Crypto Service Use Case: generation of random
numbers . . . . . . . . . . . . . . . . . . . . . . . . . 730
13.7.2.5 Crypto Service Use Case: Encryption with Authenti-
cated Encryption with Associated Data (AEAD) . . . 731
13.7.2.6 Crypto Service Use Case: Decryption with Authenti-
cated Encryption with Associated Data (AEAD) . . . 731
13.7.2.7 Crypto Service Use Case: encryption . . . . . . . . 732
13.7.2.8 Crypto Service Use Case: decryption . . . . . . . . 732

16 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

13.7.2.9 Crypto Service Use Case: signature generation . . . 733

13.7.2.10 Crypto Service Use Case: signature verification . . . 734
13.7.2.11 Crypto Service Use Case: usage of key management 734
13.7.3 Crypto Service Job Use Cases . . . . . . . . . . . . . . . . . 735
13.7.3.1 Crypto Service Use Case: usage of job API to set
key valid . . . . . . . . . . . . . . . . . . . . . . . . . 735
13.7.3.2 Crypto Service Use Case: usage of job API to create
a random seed . . . . . . . . . . . . . . . . . . . . . 735
13.7.3.3 Crypto Service Use Case: usage of job API to gen-
erate a key . . . . . . . . . . . . . . . . . . . . . . . 736
13.7.3.4 Crypto Service Use Case: usage of job API to derive
a key . . . . . . . . . . . . . . . . . . . . . . . . . . . 736
13.7.3.5 Crypto Service Use Case: usage of job API to exe-
cute calculation of the public value for key exchange 737
13.7.3.6 Crypto Service Use Case: usage of job API to exe-
cute calculation of shared secret for key exchange . 738
13.7.3.7 Crypto Service Use Case: usage of job API to exe-
cute certificate parsing . . . . . . . . . . . . . . . . . 738
13.7.3.8 Crypto Service Use Case: usage of job API to exe-
cute certificate verification . . . . . . . . . . . . . . . 739
13.8 Diagnostic Service Dependency . . . . . . . . . . . . . . . . . . . . . . 739
13.8.1 Development Approach . . . . . . . . . . . . . . . . . . . . . 740
13.8.2 Function Inhibition Needs . . . . . . . . . . . . . . . . . . . . 741
13.8.2.1 Function Inhibition Manager Service use Case: read
function permission . . . . . . . . . . . . . . . . . . . 743
13.8.2.2 Function Inhibition Manager Use Case: react on sup-
pressed or unavailable events . . . . . . . . . . . . . 743
13.8.3 Diagnostic Event Needs . . . . . . . . . . . . . . . . . . . . . 744
13.8.3.1 Dem Service Use Case: diagnostic monitor, de-
bouncing by Dem . . . . . . . . . . . . . . . . . . . 754
13.8.3.2 Dem Service Use Case: diagnostic monitor, de-
bouncing by SWC . . . . . . . . . . . . . . . . . . . 755
13.8.3.3 Dem Service Use Case: software-component pro-
vides information about operation cycles . . . . . . 755
13.8.3.4 Dem Service Use Case: software-component en-
ables reporting of DTCs in general . . . . . . . . . . 756
13.8.3.5 Dem Service Use Case: software-component en-
ables storage of subsequent DTCs . . . . . . . . . . 756
13.8.3.6 Dem Service Use Case: retrieve information of the
lamp status . . . . . . . . . . . . . . . . . . . . . . . 757
13.8.3.7 Dem Service Use Case: DEM provides information
that the fault storage overflows . . . . . . . . . . . . 758
13.8.3.8 Dem Service Use Case: software-component sup-
presses the storage of DTCs . . . . . . . . . . . . . 758
13.8.3.9 Dem Service Use Case: software-component in-
forms that the PTO is active . . . . . . . . . . . . . . 759

17 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

13.8.3.10 Dem Service Use Case: software-component needs

information about any DTC status change . . . . . . 759
13.8.3.11 Dem Service Use Case: call operation if the data of
a given diagnostic event changes (I) . . . . . . . . . 760
13.8.3.12 Dem Service Use Case: call operation if the data or
status of any diagnostic event changes (II) . . . . . . 761
13.8.3.13 Dem Service Use Case: software-component pro-
vides data for diagnostic purposes . . . . . . . . . . 761
13.8.3.14 Dem Service Use Case: software-component gets
information about a specific DTC . . . . . . . . . . . 762
13.8.3.15 Dem Service Use Case: Software-Component wants
to be triggered on Monitor Status Changes . . . . . 763
13.8.3.16 Dem Service Use Case: write parameter identifier by
software-component . . . . . . . . . . . . . . . . . . 763
13.8.3.17 Dem Service Use Case: read parameter identifier by
software-component . . . . . . . . . . . . . . . . . . 764
13.8.3.18 Dem Service Use Case: diagnostic monitor provides
monitor data, debouncing by Dem . . . . . . . . . . 764
13.8.3.19 Dem Service Use Case: diagnostic monitor provides
monitor data, debouncing by software-component . . 765
13.8.4 Diagnostic Communication Needs . . . . . . . . . . . . . . . 766
13.8.4.1 Dcm Service Use Case: read/write current values by
Client Server Interface . . . . . . . . . . . . . . . . . 770
13.8.4.2 Dcm Service Use Case: read/write current values of
specific DID by Client Server Interface . . . . . . . . 771
13.8.4.3 Dcm Service Use Case: read/write current values by
Sender Receiver Interface . . . . . . . . . . . . . . . 771
13.8.4.4 Dcm Service Use Case: start/stop or request routine
results . . . . . . . . . . . . . . . . . . . . . . . . . . 772
13.8.4.5 Dcm Service Use Case: IO control by Client Server
Interface . . . . . . . . . . . . . . . . . . . . . . . . . 773
13.8.4.6 Dcm Service Use Case: IO control by Sender Re-
ceiver Interface . . . . . . . . . . . . . . . . . . . . . 773
13.8.4.7 Dcm Service Use Case: Access to protocol, session
and security information . . . . . . . . . . . . . . . . 776
13.8.4.8 Dcm Service Use Case: Verify the access to security
level . . . . . . . . . . . . . . . . . . . . . . . . . . . 776
13.8.4.9 Dcm Service Use Case: multiple testers access one
ECU . . . . . . . . . . . . . . . . . . . . . . . . . . . 777
13.8.4.10 Dcm Service Use Case: Service Request Notification 777
13.8.4.11 Dcm Service Use Case: read/write and IOCtrl cur-
rent values by Client Server Interface . . . . . . . . . 778
13.8.4.12 Dcm Service Use Case: A software-component acts
as a "file server" to a diagnostic tester . . . . . . . . 779
13.8.5 OBD related Needs . . . . . . . . . . . . . . . . . . . . . . . 780

18 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

13.8.5.1 Dem Service Use Case: In-Use-Monitor Perfor-

mance Ratio calculation . . . . . . . . . . . . . . . . 783
13.8.5.2 Dcm Service Use Case: read parameter identifier via
diagnostic services by Client Server Interface . . . . 784
13.8.5.3 Dcm Service Use Case: read parameter identifier via
diagnostic services by Sender Receiver Interface . . 784
13.8.5.4 Dcm Service Use Case: Request vehicle information 785
13.8.5.5 Dem Service Use Case: Read DTR data from SW-C
for OBD Service $06 . . . . . . . . . . . . . . . . . . 786
13.8.5.6 Dcm Service Use Case: request control of on-board
system, test or component . . . . . . . . . . . . . . . 787
13.8.5.7 Dem Service Use Case: In-Use-Monitoring Perfor-
mance Ratio Denominator interface . . . . . . . . . 787
13.8.6 Diagnostics over IP . . . . . . . . . . . . . . . . . . . . . . . 788
13.8.6.1 DoIP Service Use Case: GID synchronization can
be necessary if the ECU is DoIP Gid synchronization
master . . . . . . . . . . . . . . . . . . . . . . . . . . 791
13.8.6.2 DoIP Service Use Case: Vehicle information is
broadcast or can be requested by the tester . . . . . 792
13.8.6.3 DoIP Service Use Case: Tester could also request
the power status with respect to diagnostics . . . . . 792
13.8.6.4 DoIP Service Use Case: Routing activation mech-
anism is used which can lead to additional impact
regarding authentication or confirmation . . . . . . . 793
13.8.6.5 DoIP Service Use Case: a DoIP entity needs to be
informed when an external tester is attached or acti-
vated. . . . . . . . . . . . . . . . . . . . . . . . . . . 793
13.8.6.6 Service Use Case: Set and reset Warning Indicator
Request bit . . . . . . . . . . . . . . . . . . . . . . . 794
13.8.6.7 DoIP Service Use Case: Atomic Software-
Component provides the further action byte to
the DoIP Service Component . . . . . . . . . . . . . 795
13.8.7 Miscellaneous Diagnostic Service Use-Cases . . . . . . . . 796
13.8.7.1 Dcm Service Use Case: DiagnosticSessionControl . 796
13.8.7.2 Dcm Service Use Case: EcuReset . . . . . . . . . . 796
13.8.7.3 Dcm Service Use Case: EcuReset ModeRapidPow-
erShutDown . . . . . . . . . . . . . . . . . . . . . . . 797
13.8.7.4 Dcm Service Use Case: CommunicationControl . . . 797
13.8.7.5 Dcm Service Use Case: ControlDTCSetting . . . . . 798
13.8.7.6 Dcm Service Use Case: Response On Event via di-
agnostic services . . . . . . . . . . . . . . . . . . . . 798
13.8.7.7 Dcm Service Use Case: SecurityAccess . . . . . . . 799
13.8.7.8 Service Use Case: Atomic Software-Component im-
plements a Hardware Shutdown . . . . . . . . . . . 800
13.8.7.9 Service Use Case: Upload and download of data . . 800
13.9 Diagnostic Log and Trace Dependency . . . . . . . . . . . . . . . . . . 801

19 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

13.9.1 Dlt use Case:Application software component transmits de-

bug information . . . . . . . . . . . . . . . . . . . . . . . . . 802
13.10 Synchronized Time-Base Manager Dependency . . . . . . . . . . . . . 802
13.10.1 StbM Use Case: start timer and potentially get notified about
its expiration . . . . . . . . . . . . . . . . . . . . . . . . . . . 803
13.10.2 StbM Use Case: Software-Components wants to get notifi-
cations of status changes . . . . . . . . . . . . . . . . . . . . 804
13.10.3 StbM Use Case: Process time snapshot obtained from global
time slave for diagnostics purposes . . . . . . . . . . . . . . 805
13.10.4 StbM Use Case: Software-component represents a global
time master . . . . . . . . . . . . . . . . . . . . . . . . . . . . 805
13.10.5 StbM Use Case: Software-component represents a global
time slave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 806
13.11 Secure On-Board Communication . . . . . . . . . . . . . . . . . . . . . 807
13.11.1 SecOc Use Case: obtain the verification status of secure
communication . . . . . . . . . . . . . . . . . . . . . . . . . . 807
13.11.2 SecOc Use Case: software component retires from secure
communication for a given period . . . . . . . . . . . . . . . 808
13.11.3 SecOc Use Case: deliver freshness to SecOC I . . . . . . . 808
13.11.4 SecOc Use Case: deliver freshness to SecOC II . . . . . . . 809
13.11.5 SecOc Use Case: deliver freshness to SecOC III . . . . . . . 809
13.11.6 SecOc Use Case: enable the sending of Pdus even if com-
putation of the MAC is not possible . . . . . . . . . . . . . . . 810
13.12 J1939 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . 810
13.12.1 J1939RM Use Case: AtomicSwComponentType sends re-
quests to the bus . . . . . . . . . . . . . . . . . . . . . . . . . 811
13.12.2 J1939RM Use Case: AtomicSwComponentType accepts re-
quests from the bus . . . . . . . . . . . . . . . . . . . . . . . 811
13.13 Error Tracer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 812
13.13.1 Error Tracer Use Case: Default Error Tracer Service use
Case: report failure . . . . . . . . . . . . . . . . . . . . . . . 814
13.14 Vehicle-2-X Facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . 814
13.14.1 V2xFac Use Case: Application software component provides
Vehicle specific data to the V2X-Stack for CAM transmission 815
13.14.2 V2xFac Use Case: V2xFac notifies application software com-
ponent about received messages . . . . . . . . . . . . . . . 815
13.14.3 V2xFac Use Case: Application software component triggers
transmission of DENM message . . . . . . . . . . . . . . . . 816
13.14.4 V2xFac Use Case: Application software component pro-
cesses the MAP (topology) Extended Message . . . . . . . . 817
13.14.5 V2xFac Use Case: Application software component pro-
cesses Infrastructure to Vehicle Information Message . . . . 817
13.14.6 V2xFac Use Case: Application software component pro-
cesses Signal Phase And Timing Extended Message . . . . 818
13.15 Vehicle-2-X Management . . . . . . . . . . . . . . . . . . . . . . . . . 818

20 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

13.15.1V2xM Use Case: Application software component provides

Vehicle specific data to the V2X-Stack for Position and Time
information . . . . . . . . . . . . . . . . . . . . . . . . . . . . 819
13.15.2 V2xM Use Case: Application software component needs
V2X specific data from the V2X Manager . . . . . . . . . . . 820
13.15.3 V2xM Use Case: Application software component has soft-
control over Pseudonym-Change within V2X Manager . . . . 820
13.15.4 V2xM Use Case: Application software component has the
ability to do Verification-on-Demand . . . . . . . . . . . . . . 821
13.15.5 V2xM Use Case: Application software component do loca-
tion based calculations . . . . . . . . . . . . . . . . . . . . . 821
13.16 Hardware Test Manager . . . . . . . . . . . . . . . . . . . . . . . . . . 822
13.16.1 HtssM Service Use Case: Query results of hardware tests . 823
14 Rapid Prototyping Scenarios 824
14.1 Definition of Rapid Prototyping Scenario . . . . . . . . . . . . . . . . . 824
14.2 Usage of RptContainers on M1 . . . . . . . . . . . . . . . . . . . . . . 828
14.3 Usage of atpSplitable for RptContainers on M1 . . . . . . . . . . . . . 829
14.4 Modifications of the Meta-Model for supporting the RPT scenario . . . 829
14.5 Extended Buffer Access Method . . . . . . . . . . . . . . . . . . . . . 832
14.5.1 RP Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . 833
14.5.2 Service Points . . . . . . . . . . . . . . . . . . . . . . . . . . 837
14.5.2.1 Service Functions . . . . . . . . . . . . . . . . . . . 837
A Glossary 840

B Supported Special Use Cases 844

B.1 Asymmetric Data Transformation between a Software-Component and
a Complex Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844
B.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 844
B.1.2 Modeling Aspects . . . . . . . . . . . . . . . . . . . . . . . . 845
C History of Constraints and Specification Items 847
C.1 Constraint History of this Document according to AUTOSAR R4.0.1 . . 847
C.1.1 Changed Constraints in R4.0.1 . . . . . . . . . . . . . . . . . 847
C.1.2 Added Constraints in R4.0.1 . . . . . . . . . . . . . . . . . . 847
C.1.3 Deleted Constraints . . . . . . . . . . . . . . . . . . . . . . . 852
C.2 Constraint History of this Document according to AUTOSAR R4.0.2 . . 853
C.2.1 Changed Constraints in R4.0.2 . . . . . . . . . . . . . . . . . 853
C.2.2 Added Constraints in R4.0.2 . . . . . . . . . . . . . . . . . . 853
C.2.3 Deleted Constraints in R4.0.2 . . . . . . . . . . . . . . . . . . 854
C.3 Constraint History of this Document according to AUTOSAR R4.0.3 . . 854
C.3.1 Changed Constraints in R4.0.3 . . . . . . . . . . . . . . . . . 854
C.3.2 Added Constraints in R4.0.3 . . . . . . . . . . . . . . . . . . 855
C.3.3 Added Specification Items in R4.0.3 . . . . . . . . . . . . . . 857
C.3.4 Deleted Constraints in R4.0.3 . . . . . . . . . . . . . . . . . . 873
C.3.5 Deleted Specification Items . . . . . . . . . . . . . . . . . . . 874

21 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

C.4 Constraint History of this Document according to AUTOSAR R4.1.1 . . 874

C.4.1 Changed Constraints in R4.1.1 . . . . . . . . . . . . . . . . . 874
C.4.2 Added Constraints in R4.1.1 . . . . . . . . . . . . . . . . . . 875
C.4.3 Changed Specification Items in R4.1.1 . . . . . . . . . . . . 879
C.4.4 Added Specification Items in R4.1.1 . . . . . . . . . . . . . . 879
C.4.5 Deleted Constraints in R4.1.1 . . . . . . . . . . . . . . . . . . 882
C.4.6 Deleted Specification Items in R4.1.1 . . . . . . . . . . . . . 883
C.5 Constraint History of this Document according to AUTOSAR R4.1.2 . . 883
C.5.1 Changed Constraints in R4.1.2 . . . . . . . . . . . . . . . . . 883
C.5.2 Added Constraints in R4.1.2 . . . . . . . . . . . . . . . . . . 883
C.5.3 Changed Specification Items in R4.1.2 . . . . . . . . . . . . 884
C.5.4 Added Specification Items in R4.1.2 . . . . . . . . . . . . . . 885
C.5.5 Deleted Constraints in R4.1.2 . . . . . . . . . . . . . . . . . . 885
C.5.6 Deleted Specification Items in R4.1.2 . . . . . . . . . . . . . 886
C.6 Constraint History of this Document according to AUTOSAR R4.1.3 . . 886
C.6.1 Added Traceables in R4.1.3 . . . . . . . . . . . . . . . . . . . 886
C.6.2 Changed Traceables in R4.1.3 . . . . . . . . . . . . . . . . . 886
C.6.3 Deleted Traceables in R4.1.3 . . . . . . . . . . . . . . . . . . 886
C.6.4 Added Constraints in R4.1.3 . . . . . . . . . . . . . . . . . . 887
C.6.5 Changed Constraints in R4.1.3 . . . . . . . . . . . . . . . . . 887
C.6.6 Deleted Constraints in R4.1.3 . . . . . . . . . . . . . . . . . . 887
C.7 Constraint History of this Document according to AUTOSAR R4.2.1 . . 887
C.7.1 Added Traceables in R4.2.1 . . . . . . . . . . . . . . . . . . . 887
C.7.2 Changed Traceables in R4.2.1 . . . . . . . . . . . . . . . . . 890
C.7.3 Deleted Traceables in R4.2.1 . . . . . . . . . . . . . . . . . . 891
C.7.4 Added Constraints in R4.2.1 . . . . . . . . . . . . . . . . . . 891
C.7.5 Changed Constraints in R4.2.1 . . . . . . . . . . . . . . . . . 892
C.7.6 Deleted Constraints in R4.2.1 . . . . . . . . . . . . . . . . . . 893
C.8 Constraint History of this Document according to AUTOSAR R4.2.2 . . 893
C.8.1 Added Traceables in R4.2.2 . . . . . . . . . . . . . . . . . . . 893
C.8.2 Changed Traceables in R4.2.2 . . . . . . . . . . . . . . . . . 894
C.8.3 Deleted Traceables in R4.2.2 . . . . . . . . . . . . . . . . . . 895
C.8.4 Added Constraints in R4.2.2 . . . . . . . . . . . . . . . . . . 895
C.8.5 Changed Constraints in R4.2.2 . . . . . . . . . . . . . . . . . 896
C.8.6 Deleted Constraints in R4.2.2 . . . . . . . . . . . . . . . . . . 897
C.9 Constraint History of this Document according to AUTOSAR R4.3.0 . . 897
C.9.1 Added Traceables in R4.3.0 . . . . . . . . . . . . . . . . . . . 897
C.9.2 Changed Traceables in R4.3.0 . . . . . . . . . . . . . . . . . 900
C.9.3 Deleted Traceables in R4.3.0 . . . . . . . . . . . . . . . . . . 901
C.9.4 Added Constraints in R4.3.0 . . . . . . . . . . . . . . . . . . 902
C.9.5 Changed Constraints in R4.3.0 . . . . . . . . . . . . . . . . . 904
C.9.6 Deleted Constraints in R4.3.0 . . . . . . . . . . . . . . . . . . 905
C.10 Constraint History of this Document according to AUTOSAR R4.3.1 . . 905
C.10.1 Added Traceables in 4.3.1 . . . . . . . . . . . . . . . . . . . . 905
C.10.2 Changed Traceables in 4.3.1 . . . . . . . . . . . . . . . . . . 906
C.10.3 Deleted Traceables in 4.3.1 . . . . . . . . . . . . . . . . . . . 906

22 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

C.10.4 Added Constraints in 4.3.1 . . . . . . . . . . . . . . . . . . . 907

C.10.5 Changed Constraints in 4.3.1 . . . . . . . . . . . . . . . . . . 907
C.10.6 Deleted Constraints in 4.3.1 . . . . . . . . . . . . . . . . . . 908
C.11 Constraint History of this Document according to AUTOSAR R4.4.0 . . 908
C.11.1 Added Traceables in 4.4.0 . . . . . . . . . . . . . . . . . . . . 908
C.11.2 Changed Traceables in 4.4.0 . . . . . . . . . . . . . . . . . . 910
C.11.3 Deleted Traceables in 4.4.0 . . . . . . . . . . . . . . . . . . . 912
C.11.4 Added Constraints in 4.4.0 . . . . . . . . . . . . . . . . . . . 912
C.11.5 Changed Constraints in 4.4.0 . . . . . . . . . . . . . . . . . . 913
C.11.6 Deleted Constraints in 4.4.0 . . . . . . . . . . . . . . . . . . 914
D Modeling of InstanceRef 915
D.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 915
D.2 Modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 916
D.2.1 Components and Compositions . . . . . . . . . . . . . . . . 916
D.2.2 Definition of implicit Communication Behavior . . . . . . . . . 935
D.2.3 Internal Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 945
E Examples 954
E.1 Examples for the Definition of variable-size Arrays . . . . . . . . . . . . 954
F Mentioned Class Tables 958

G Upstream Mapping 994

G.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 994
G.2 NvM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 994
G.3 Com . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1002
G.4 WdgM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1017
G.5 Dcm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1018
G.6 Dem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1045
G.7 BswM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1051
G.8 MemMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1056
G.9 RTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1057
G.10 ECUC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1062
G.11 OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1063
H Splitable Elements in the Scope of this Document 1065

I Variation Points in the Scope of this Document 1067

23 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

References
[1] Standardization Template
AUTOSAR_TPS_StandardizationTemplate
[2] Specification of RTE Software
AUTOSAR_SWS_RTE
[3] Virtual Functional Bus
AUTOSAR_EXP_VFB
[4] Methodology
AUTOSAR_TR_Methodology
[5] Layered Software Architecture
AUTOSAR_EXP_LayeredSoftwareArchitecture
[6] Basic Software Module Description Template
AUTOSAR_TPS_BSWModuleDescriptionTemplate
[7] Specification of Timing Extensions
AUTOSAR_TPS_TimingExtensions
[8] Requirements on Timing Extensions
AUTOSAR_RS_TimingExtensions
[9] Specification of ECU Resource Template
AUTOSAR_TPS_ECUResourceTemplate
[10] System Template
AUTOSAR_TPS_SystemTemplate
[11] Generic Structure Template
AUTOSAR_TPS_GenericStructureTemplate
[12] Requirements on Software Component Template
AUTOSAR_RS_SoftwareComponentTemplate
[13] Supplementary material of general blueprints for AUTOSAR
AUTOSAR_TR_GeneralBlueprintsSupplement
[14] Specification of Basic Software Mode Manager
AUTOSAR_SWS_BSWModeManager
[15] Information technology – Universal Coded Character Set (UCS)
http://www.iso.org
[16] Specification of Manifest
AUTOSAR_TPS_ManifestSpecification
[17] Specification of I/O Hardware Abstraction
AUTOSAR_SWS_IOHardwareAbstraction

24 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[18] ISO 17356-4: Road vehicles – Open interface for embedded automotive applica-
tions – Part 4: OSEK/VDX Communication (COM)
[19] Specification of SW-C End-to-End Communication Protection Library
AUTOSAR_SWS_E2ELibrary
[20] Specification of Communication Manager
AUTOSAR_SWS_COMManager
[21] Specification of Communication
AUTOSAR_SWS_COM
[22] Specification of Platform Types
AUTOSAR_SWS_PlatformTypes
[23] ISO/IEC 9899:1990
http://www.iso.org
[24] ASAM MCD 2MC ASAP2 Interface Specification
http://www.asam.net
ASAP2-V1.51.pdf
[25] ASAM MCD 2 Harmonized Data Objects Version 1.1
harmonized-data-objects-V1.1.pdf
[26] Collection of blueprints for AUTOSAR M1 models
AUTOSAR_MOD_GeneralBlueprints
[27] ISO 26262 (Part 1-10) – Road vehicles – Functional Safety, First edition
http://www.iso.org
[28] ASAM AE Calibration Data Format V2.0.0
http://www.asam.net
ASAM-AE-CDF-V2_0_0-Users-Guide.pdf
[29] Specification of Operating System
AUTOSAR_SWS_OS
[30] ISO 17356-3: Road vehicles – Open interface for embedded automotive applica-
tions – Part 3: OSEK/VDX Operating System (OS)
[31] Specification of ECU Configuration Parameters (XML)
AUTOSAR_MOD_ECUConfigurationParameters
[32] Glossary
AUTOSAR_TR_Glossary
[33] Specification of NVRAM Manager
AUTOSAR_SWS_NVRAMManager
[34] ASAM AE Functional Specification Exchange Format V1.0.0
http://www.asam.net
AE-FSX_V1.0.0.pdf

25 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[35] Specification of Watchdog Manager

AUTOSAR_SWS_WatchdogManager
[36] Specification of ECU State Manager
AUTOSAR_SWS_ECUStateManager
[37] Diagnostic Extract Template
AUTOSAR_TPS_DiagnosticExtractTemplate
[38] Specification of Function Inhibition Manager
AUTOSAR_SWS_FunctionInhibitionManager
[39] Specification of Diagnostic Event Manager
AUTOSAR_SWS_DiagnosticEventManager
[40] Specification of Diagnostic Communication Manager
AUTOSAR_SWS_DiagnosticCommunicationManager
[41] Road vehicles – Diagnostic communication over Internet Protocol (DoIP)
http://www.iso.org
[42] Specification of Diagnostic Log and Trace
AUTOSAR_SWS_DiagnosticLogAndTrace
[43] Specification of Synchronized Time-Base Manager
AUTOSAR_SWS_SynchronizedTimeBaseManager
[44] Specification of Secure Onboard Communication
AUTOSAR_SWS_SecureOnboardCommunication
[45] Specification of a Request Manager for SAE J1939
AUTOSAR_SWS_SAEJ1939RequestManager
[46] Specification of Default Error Tracer
AUTOSAR_SWS_DefaultErrorTracer
[47] Specification of Vehicle-2-X Facilities
AUTOSAR_SWS_V2XFacilities
[48] Specification of Vehicle-2-X Management
AUTOSAR_SWS_V2XManagement
[49] Software Process Engineering Meta-Model Specification
http://www.omg.org/spec/SPEM/2.0/
[50] Specification of SOME/IP Transformer
AUTOSAR_SWS_SOMEIPTransformer

26 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

1 Introduction

1.1 Overview
This document contains the specification of the AUTOSAR Software-Component
Template. Actually, it has been created as a supplement to the formal definition of
the Software-Component Template by means of the AUTOSAR meta-model. In
other words, this document in addition to the formal specification provides introductory
description and rationale for the part of the AUTOSAR meta-model relevant for the
definition of software-components.
In this context, the term software-component refers to a formally described piece of
software existing that needs the AUTOSAR RTE [2] for execution.
Please note that the general ideas behind the semantics of application software-
components have been described in the specification of the Virtual Functional
Bus [3]. The latter, however, represents conceptual work that strongly influences but
does not totally govern the formal definition of software-components.
Note further that this document does not provide any “best practice” recommendations
of software-component modeling nor does it require or enforce a certain methodol-
ogy. Note however, that the methodology aspect is covered by the specification of the
AUTOSAR methodology [4].
Although it is beyond any doubt reasonable to use a suitable AUTOSAR Authoring Tool
for dealing with AUTOSAR software-components, this specification does not make any
assumptions nor does it give recommendations regarding the tooling.

1.2 Scope
As already mentioned in chapter 1.1, the Scope of this document is the description of
AUTOSAR software-components. This work covers the following three aspects:
• A general description of SwComponentTypes using PortPrototypes and
PortInterfaces, i.e. this document defines the SwComponentType as an en-
tity which can be described through PortPrototypes which provide or require
PortInterfaces.
• A description of CompositionSwComponentTypes which are sub-systems
consisting out of connected instances of software-components, i.e. software-
components may be defined in the form of hierarchical subsystems which in turn
consist of software-components again. The description of such hierarchical struc-
tures is in scope of this document.
• A description of AtomicSwComponentType which is implemented as a piece of
software that can be mapped to an AUTOSAR ECU.
An AtomicSwComponentType therefore shows up in the ECU Software Archi-

27 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

tecture depicted in Figure 1.1. In this figure, the green (vertically striped) and
blue (diagonally striped) borders show the aspects that are described by the
Software-Component Template.

Figure 1.1: Scope of this document in the ECU SW Architecture [5]

Aspects of AUTOSAR Basic Software not relevant for the RTE are out of scope; these
are covered by the Basic Software Module Description Template [6].
Also, the document does not cover aspects of timing analysis with respect to the ex-
ecution of AUTOSAR software-components. This issue is explained in the Speci-
fication of Timing Extensions [7] as well as the corresponding requirements
specification [8].

1.3 Organization of the Meta-Model

Figure 1.2 sketches the overall structure of the meta-model which formally defines
the vocabulary required to describe AUTOSAR software-components. As the dia-
gram points out, other template specifications (e.g. ECU Resource Template [9]
and System Template [10]) also use the same modeling approach in order to define
an overall consistent model of AUTOSAR software description.
The dashed arrows in the diagram describe dependencies in terms of import-
relationships between the packages within the meta-model. For example, the package

28 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

SWComponentTemplate imports meta-classes defined in the packages Generic-

Structure [11] and ECUResourceTemplate [9].
Please note that this specification document will (with some well-defined exceptions)
mostly discuss meta-model elements defined in the package SWComponentTem-
plate.

AutosarTopLevelStructure      CommonStructure


   
    
    
    
 

SWComponentTemplate EcuResourceTemplate

AdaptivePlatform

SystemTemplate

DiagnosticExtract

ECUCDescriptionTemplate

ECUCParameterDefTemplate

BswModuleTemplate

StandardizationTemplate GenericStructure
     FeatureModelTemplate

   
   
  

Figure 1.2: Structure of the meta-model

For clarification, please note that the package GenericStructure contains some
fundamental infrastructure meta-classes and common patterns that are described
in [11]. As these are used by all other template specification the dependency asso-
ciations are not depicted in the diagram for the sake of clarity.

29 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

1.4 Structure of the Template

AUTOSAR software components are described on three distinctive levels, as shown in
Figure 1.3.
AtomicSwComponentType

     
 

«atpVariation,atpSplitable»

+internalBehavior 0..1

SwcInternalBehavior
      

+behavior 1

SwcImplementation

  

Figure 1.3: The description of a software component is done on three levels

1.4.1 Description of Software Components on VFB Level

The highest (most abstract) description level is the Virtual Functional Bus [3].
In this document SwComponentTypes are described with the means of DataTypes,
PortInterfaces, PortPrototypes, and connections between them. At this level,
the fundamental communication properties of components and their communication
relationships among each other are expressed.
In the diagram depicted in Figure 1.3, this aspect is expressed by means of the de-
scription of AtomicSwComponentType1 .

1.4.2 Description of Software Components on RTE Level

The middle level allows for behavior description of a given AtomicSwCompo-

nentType. This so-called SwcInternalBehavior is expressed according to
AUTOSAR RTE concepts, e.g. RTEEvents and in terms of schedulable units, so-called
RunnableEntitys.
1
To avoid clutter and require additional up-front information about the meta model, Composition-
SwComponentTypes have not been added to the diagram.

30 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

For instance, for a ClientServerOperation defined in the scope of a particular

ClientServerInterface on the VFB, the behavior specifies which RunnableEn-
tity is activated as a consequence of the invocation of the specific ClientServer-
Operation.
As sketched by Figure 1.3, there may be zero or one SwcInternalBehaviors ag-
gregated by a given AtomicSwComponentType. In response to the existence of the
stereotype atpSplitable at the aggregation it is possible to distribute the ag-
gregation over several physical files.

1.4.3 Descriptions of Software Components on Implementation Level

The lowest level of description specifies the implementation (i.e. in terms of the
AUTOSAR meta-model: the SwcImplementation) of a given SwcInternalBe-
havior description. More precisely, the RunnableEntitys of such a behavior are
mapped to code (source code or object code).
There may be different SwcImplementations that reference a specific SwcInter-
nalBehavior description, e.g. in different programming languages, or with differently
optimized code.
Please note that Implementation has been described in previous versions of this
document. In response to the evolution of the AUTOSAR concept the description of the
Implementation aspect has been moved to the “CommonStructure” (see Figure 1.2)
because it is also used for creating the Basic Software Module Description
Template [6].
However, the SwcImplementation still remains in the scope of this document as it
exclusively covers aspects of software-components rather than basic software mod-
ules.

1.5 Abbreviations
The following table contains a list of abbreviations used in the scope of this document
along with the spelled-out meaning of each of the abbreviations.
Abbreviation Meaning
API Application Programming Interface
BOM Byte Order Mark
CAN Controller Area Network
CSE Codes for Scaling Units
DCM Diagnostics Communication Manager
5

31 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4
Abbreviation Meaning
DCY Driving Cycle
DEM Diagnostics Event Manager
DID Diagnostic Identifier
DTC Diagnostic Trouble Code
DoIp Diagnostics over IP
ECU Electrical Control Unit
EPROM Erasable Programmable Read-Only Memory
EEPROM Electrically Erasable Programmable Read-Only Memory
FID Function Identifier
GID Group Identifier
ID Identifier
IO Input/Output
IP Internet Protocol
IUMPR In-Use Monitor Performance Ratio
ISO International Standardization Organization
MAC Message Authentication Code
MCAL Micro-Controller Abstraction
LIN Local Interconnect Network
MCD Measurement, Calibration, Diagnostics
NM Network Management
NV Non-Volatile
OBD On-Board Diagnostic
OEM Original Equipment Manufacturer
OS Operating System
PDU Protocol Data Unit
PID Parameter Identifier
PTO Power Take Off
RA Routing Activation
RAM Random Access Memory
ROM Read-Only Memory
RPT Rapid Prototyping
RTE Runtime Environment
SWC Software Component
TID Test Identifier
UDS Unified Diagnostic Services
UML Unified Modeling Language
VFB Virtual Functional Bus
WWH-OBD World-Wide Harmonized On-Board Diagnostics
XML Extensible Markup Language
XSD XML Schema Definition

Table 1.1: Abbreviations used in the scope of this Document

32 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

1.6 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:
Class AUTOSAR
Package M2::AUTOSARTemplates::AutosarTopLevelStructure
Note Root element of an AUTOSAR description, also the root element in corresponding XML documents.
Tags: xml.globalElement=true
Base ARObject
Attribute Type Mul. Kind Note
adminData AdminData 0..1 aggr This represents the administrative data of an Autosar file.
Tags: xml.sequenceOffset=10
arPackage ARPackage * aggr This is the top level package in an AUTOSAR model.
Stereotypes: atpSplitable; atpVariation
Tags: atp.Splitkey=shortName, variationPoint.shortLabel
vh.latestBindingTime=blueprintDerivationTime
xml.sequenceOffset=30
fileInfo FileInfoComment 0..1 aggr This represents a possibility to provide a structured
Comment comment in an AUTOSAR file.
Stereotypes: atpStructuredComment
Tags: xml.roleElement=true
xml.sequenceOffset=-10
xml.typeElement=false
introduction DocumentationBlock 0..1 aggr This represents an introduction on the Autosar file. It is
intended for example to rpresent disclaimers and legal
notes.
Tags: xml.sequenceOffset=20

Table 1.2: AUTOSAR

The first rows in the table have the following meaning:

Class: The name of the class as defined in the UML model.

33 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

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

1.7 Requirements Tracing

Requirements against this document are exclusively stated in the corresponding re-
quirements document [12].
The following table references the requirements specified in [12] and provides informa-
tion about individual specification items that fulfill a given requirement.
Requirement Description Satisfied by

34 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[RS_SWCT_00010] AUTOSAR shall support inter- [TPS_SWCT_01025] [TPS_SWCT_01026]

and intra-ECU-communication [TPS_SWCT_01027] [TPS_SWCT_01069]
mechanisms with high [TPS_SWCT_01070] [TPS_SWCT_01111]
reliability [TPS_SWCT_01516] [TPS_SWCT_01573]
[RS_SWCT_00020] AUTOSAR shall provide open [TPS_SWCT_01002]
and standardized software
interfaces for intra-ECU and
inter-ECU communication
[RS_SWCT_00030] AUTOSAR shall provide [TPS_SWCT_01002]
complete interfaces to
application software and basic
software modules
[RS_SWCT_00070] AUTOSAR shall provide an [TPS_SWCT_01030] [TPS_SWCT_01097]
abstraction of the application [TPS_SWCT_01098]
software from hardware
[RS_SWCT_00080] AUTOSAR shall provide an [TPS_SWCT_01025] [TPS_SWCT_01026]
independence of application [TPS_SWCT_01027] [TPS_SWCT_01069]
software from in-vehicle [TPS_SWCT_01070] [TPS_SWCT_01516]
communication technologies
[RS_SWCT_00090] AUTOSAR should provide an [TPS_SWCT_01030] [TPS_SWCT_01097]
independence of application [TPS_SWCT_01098]
software from operating
systems
[RS_SWCT_00110] AUTOSAR shall provide a [TPS_SWCT_01025] [TPS_SWCT_01026]
functional interface view of [TPS_SWCT_01027] [TPS_SWCT_01069]
the entire system [TPS_SWCT_01070] [TPS_SWCT_01516]
[RS_SWCT_00120] AUTOSAR shall provide [TPS_SWCT_01031] [TPS_SWCT_01049]
protection/unlock [TPS_SWCT_01050] [TPS_SWCT_01051]
mechanisms for software [TPS_SWCT_01052] [TPS_SWCT_01053]
through appropriate services [TPS_SWCT_01054] [TPS_SWCT_01055]
in the infrastructure [TPS_SWCT_01321] [TPS_SWCT_01592]
[TPS_SWCT_01713] [TPS_SWCT_01714]
[RS_SWCT_00150] AUTOSAR shall provide [TPS_SWCT_01002]
means to protect
SW-Components from
malicious SW-Components
[RS_SWCT_00160] AUTOSAR shall provide [TPS_SWCT_01002]
means to achieve
compositionality
[RS_SWCT_00170] AUTOSAR shall provide [TPS_SWCT_01028] [TPS_SWCT_01029]
diagnostics means during [TPS_SWCT_01129] [TPS_SWCT_01132]
runtime, for production and [TPS_SWCT_01134] [TPS_SWCT_01135]
services purposes [TPS_SWCT_01136] [TPS_SWCT_01137]
[TPS_SWCT_01138] [TPS_SWCT_01139]
[TPS_SWCT_01140] [TPS_SWCT_01425]
[TPS_SWCT_01426] [TPS_SWCT_01427]
[TPS_SWCT_01453] [TPS_SWCT_01582]
[TPS_SWCT_01591] [TPS_SWCT_01627]
[TPS_SWCT_01628] [TPS_SWCT_01629]
[TPS_SWCT_01630] [TPS_SWCT_01631]
[TPS_SWCT_01632] [TPS_SWCT_01633]

35 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[TPS_SWCT_01634] [TPS_SWCT_01639]
[TPS_SWCT_01640] [TPS_SWCT_01654]
[TPS_SWCT_01655] [TPS_SWCT_01656]
[TPS_SWCT_01657] [TPS_SWCT_01690]
[TPS_SWCT_01691] [TPS_SWCT_01697]
[TPS_SWCT_01698] [TPS_SWCT_01706]
[TPS_SWCT_01707] [TPS_SWCT_01708]
[TPS_SWCT_01709] [TPS_SWCT_01711]
[TPS_SWCT_01712] [TPS_SWCT_01715]
[TPS_SWCT_01739] [TPS_SWCT_01765]
[TPS_SWCT_01766] [TPS_SWCT_01767]
[TPS_SWCT_01789] [TPS_SWCT_01790]
[TPS_SWCT_01791] [TPS_SWCT_02002]
[TPS_SWCT_02003] [TPS_SWCT_02004]
[TPS_SWCT_02005] [TPS_SWCT_02007]
[TPS_SWCT_02008] [TPS_SWCT_02009]
[TPS_SWCT_02010] [TPS_SWCT_02011]
[TPS_SWCT_02012] [TPS_SWCT_02013]
[TPS_SWCT_02014] [TPS_SWCT_02015]
[TPS_SWCT_02016] [TPS_SWCT_02505]
[RS_SWCT_00190] AUTOSAR shall support [TPS_SWCT_01032] [TPS_SWCT_01033]
hierarchical design methods [TPS_SWCT_01034] [TPS_SWCT_01035]
[TPS_SWCT_01036] [TPS_SWCT_01037]
[TPS_SWCT_01697] [TPS_SWCT_01698]
[RS_SWCT_00200] Definitions of relations [TPS_SWCT_01002] [TPS_SWCT_01322]
between SW components are [TPS_SWCT_01323] [TPS_SWCT_01325]
exhaustive and formal [TPS_SWCT_01326] [TPS_SWCT_01328]
[TPS_SWCT_01329] [TPS_SWCT_01330]
[TPS_SWCT_01331] [TPS_SWCT_01333]
[TPS_SWCT_01334] [TPS_SWCT_01335]
[TPS_SWCT_01336] [TPS_SWCT_01337]
[TPS_SWCT_01338] [TPS_SWCT_01339]
[TPS_SWCT_01340] [TPS_SWCT_01341]
[TPS_SWCT_01342] [TPS_SWCT_01343]
[TPS_SWCT_01344] [TPS_SWCT_01345]
[TPS_SWCT_01346] [TPS_SWCT_01347]
[TPS_SWCT_01348] [TPS_SWCT_01349]
[TPS_SWCT_01350] [TPS_SWCT_01351]
[TPS_SWCT_01352] [TPS_SWCT_01353]
[TPS_SWCT_01557] [TPS_SWCT_01558]
[TPS_SWCT_01567] [TPS_SWCT_01663]
[RS_SWCT_00210] SW components are [TPS_SWCT_01002]
protected from illegal access
[RS_SWCT_00220] Management of vehicle [TPS_SWCT_01038] [TPS_SWCT_01039]
diversity is supported by [TPS_SWCT_01040] [TPS_SWCT_01041]
AUTOSAR [TPS_SWCT_01042] [TPS_SWCT_01447]
[RS_SWCT_00230] The Software Component [TPS_SWCT_01635]
Template shall provide the
ability to define naming
conventions for public
symbols
[RS_SWCT_02000] AUTOSAR shall support a [TPS_SWCT_01032] [TPS_SWCT_01033]
top-down hierarchical design [TPS_SWCT_01034] [TPS_SWCT_01035]
[TPS_SWCT_01036] [TPS_SWCT_01037]

36 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[RS_SWCT_02010] Interfaces of atomic [TPS_SWCT_01002]

software-components shall be
supported
[RS_SWCT_02020] Bottom-up design of [TPS_SWCT_01032] [TPS_SWCT_01033]
CompositionTypes shall be [TPS_SWCT_01034] [TPS_SWCT_01035]
supported [TPS_SWCT_01036] [TPS_SWCT_01037]
[RS_SWCT_02030] Specification of [TPS_SWCT_01002] [TPS_SWCT_01025]
Communications shall be [TPS_SWCT_01026] [TPS_SWCT_01027]
supported [TPS_SWCT_01516]
[RS_SWCT_02060] Interaction with basic software [TPS_SWCT_01043] [TPS_SWCT_01044]
shall be considered [TPS_SWCT_01045] [TPS_SWCT_01046]
[TPS_SWCT_01693]
[RS_SWCT_02080] Designing a Sensor Actuator [TPS_SWCT_01047] [TPS_SWCT_01048]
Component shall be
supported
[RS_SWCT_02090] Data-consistency for [TPS_SWCT_01031] [TPS_SWCT_01049]
communication among [TPS_SWCT_01050] [TPS_SWCT_01051]
RunnableEntities shall be [TPS_SWCT_01052] [TPS_SWCT_01053]
supported [TPS_SWCT_01054] [TPS_SWCT_01055]
[TPS_SWCT_01637] [TPS_SWCT_01713]
[TPS_SWCT_01714]
[RS_SWCT_02100] Definition of physical units [TPS_SWCT_01056] [TPS_SWCT_01057]
shall be supported [TPS_SWCT_01058] [TPS_SWCT_01059]
[TPS_SWCT_01060] [TPS_SWCT_01061]
[TPS_SWCT_01068] [TPS_SWCT_01736]
[TPS_SWCT_01737]
[RS_SWCT_02110] Definition of comments shall [TPS_SWCT_01062]
be supported
[RS_SWCT_03000] The SW-Component template [TPS_SWCT_01032] [TPS_SWCT_01033]
shall support compositions [TPS_SWCT_01034] [TPS_SWCT_01035]
[TPS_SWCT_01036] [TPS_SWCT_01037]
[RS_SWCT_03010] The SW-Component template [TPS_SWCT_01025] [TPS_SWCT_01026]
shall support interfaces [TPS_SWCT_01069] [TPS_SWCT_01070]
[TPS_SWCT_01516]
[RS_SWCT_03040] The SW-Component template [TPS_SWCT_01075] [TPS_SWCT_01108]
shall support description of
the behavior
[RS_SWCT_03045] The SW-Component template [TPS_SWCT_01469]
shall allow enabling of
RTE-Feature to get the
activating RTE-Event of
Runnable Entity
[RS_SWCT_03046] The SW-Component template [TPS_SWCT_02507]
shall support instance specific
RTE-Events
[RS_SWCT_03050] The SW-Component template [TPS_SWCT_01030] [TPS_SWCT_01097]
shall support the definition of [TPS_SWCT_01098]
schedulability
[RS_SWCT_03055] The SW-Component template [TPS_SWCT_01457] [TPS_SWCT_01458]
shall support optional [TPS_SWCT_01459] [TPS_SWCT_01460]
configuration of ExclusiveArea
usage within RunnableEntities

37 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[RS_SWCT_03065] The SW-Component template [TPS_SWCT_01466] [TPS_SWCT_01470]

shall support the definition of [TPS_SWCT_01471] [TPS_SWCT_01472]
implicit communication [TPS_SWCT_01473] [TPS_SWCT_01475]
behavior [TPS_SWCT_01476] [TPS_SWCT_01479]
[TPS_SWCT_01481] [TPS_SWCT_01482]
[TPS_SWCT_01509] [TPS_SWCT_01625]
[RS_SWCT_03090] The SW-Component template [TPS_SWCT_01047] [TPS_SWCT_01048]
shall support the definition of
needed and usable sensors
and actuators
[RS_SWCT_03100] The SW-Component template [TPS_SWCT_01038] [TPS_SWCT_01040]
shall support variant handling [TPS_SWCT_01041] [TPS_SWCT_01042]
[TPS_SWCT_01370] [TPS_SWCT_01371]
[TPS_SWCT_01372] [TPS_SWCT_01373]
[TPS_SWCT_01448]
[RS_SWCT_03110] The SW-Component template [TPS_SWCT_01071] [TPS_SWCT_01190]
shall support modes [TPS_SWCT_01376] [TPS_SWCT_01377]
[TPS_SWCT_01378] [TPS_SWCT_01379]
[TPS_SWCT_01380] [TPS_SWCT_01381]
[TPS_SWCT_01382] [TPS_SWCT_01383]
[TPS_SWCT_01384] [TPS_SWCT_01385]
[TPS_SWCT_01388] [TPS_SWCT_01511]
[TPS_SWCT_01512] [TPS_SWCT_01513]
[TPS_SWCT_01530] [TPS_SWCT_01531]
[TPS_SWCT_01532] [TPS_SWCT_01533]
[TPS_SWCT_01534] [TPS_SWCT_01535]
[TPS_SWCT_01536] [TPS_SWCT_01541]
[TPS_SWCT_01542] [TPS_SWCT_01552]
[TPS_SWCT_01553] [TPS_SWCT_01554]
[TPS_SWCT_01555] [TPS_SWCT_01581]
[TPS_SWCT_01664]
[RS_SWCT_03115] The SW-Component template [TPS_SWCT_01464] [TPS_SWCT_01465]
shall support mapping of [TPS_SWCT_01545]
mode declarations
[RS_SWCT_03120] The SW-Component template [TPS_SWCT_01077]
shall support dependency on
modes
[RS_SWCT_03130] The SW-Component template [TPS_SWCT_01079] [TPS_SWCT_01080]
shall support connections [TPS_SWCT_01081] [TPS_SWCT_01082]
between PortInterfaces [TPS_SWCT_01083] [TPS_SWCT_01084]
[TPS_SWCT_01113] [TPS_SWCT_01573]
[RS_SWCT_03135] The SW-Component template [TPS_SWCT_01023] [TPS_SWCT_01024]
shall support record type [TPS_SWCT_01551]
subsetting
[RS_SWCT_03136] The SW-Component template [TPS_SWCT_01195]
shall support record type
subsetting with primitive types
[RS_SWCT_03140] The SW-Component template [TPS_SWCT_01038]
shall support conditional
existence of PortPrototypes

38 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[RS_SWCT_03141] The SW-Component template [TPS_SWCT_01106]

shall support the conditional
existence of data element
prototypes, operation
prototypes, parameter
prototypes in an interface
[RS_SWCT_03142] The SW-Component template [TPS_SWCT_01038]
shall support the conditional
existence of Component
Prototypes
[RS_SWCT_03143] The SW-Component template [TPS_SWCT_01040]
shall support the conditional
existence of Connector
Prototypes
[RS_SWCT_03144] The SW-Component template [TPS_SWCT_01076] [TPS_SWCT_01078]
shall support a configurable [TPS_SWCT_01752]
size of arrays
[RS_SWCT_03148] Attributes swMinAxisPoints [TPS_SWCT_01107] [TPS_SWCT_01181]
and swMaxAxisPoints shall be
adjustable by an System
Constant Definition
[RS_SWCT_03149] The SW-Component template [TPS_SWCT_01085]
shall support the conditional
existence of RunnableEntitys
[RS_SWCT_03150] The SW-Component template [TPS_SWCT_01085]
shall support the conditional
existence of RTEEvents
[RS_SWCT_03151] The SW-Component template [TPS_SWCT_01085]
shall support the conditional
existence of InterRunnable
Variables
[RS_SWCT_03152] The SW-Component template [TPS_SWCT_01130]
shall support the conditional
accessibility for measurement
[RS_SWCT_03153] The SW-Component template [TPS_SWCT_01085]
shall support the conditional
existence of parameter
prototypes
[RS_SWCT_03154] The SW-Component template [TPS_SWCT_01038]
shall support conditional ports
for software components
[RS_SWCT_03155] The SW-Component template [TPS_SWCT_01099] [TPS_SWCT_01100]
shall support interfaces with [TPS_SWCT_01101] [TPS_SWCT_01102]
different resolutions [TPS_SWCT_01103] [TPS_SWCT_01104]
[TPS_SWCT_01105]
[RS_SWCT_03170] The SW-Component template [TPS_SWCT_01102] [TPS_SWCT_01103]
shall support fixed data [TPS_SWCT_01104]
exchange
[RS_SWCT_03175] The SW-Component template [TPS_SWCT_01177] [TPS_SWCT_01178]
shall support the definition of [TPS_SWCT_01188]
calibration datasets
[RS_SWCT_03180] The SW-Component template [TPS_SWCT_01076] [TPS_SWCT_01673]
shall support SAE J1939 [TPS_SWCT_01674] [TPS_SWCT_01752]
Protocol Features

39 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[RS_SWCT_03181] The SW-Component template [TPS_SWCT_01076] [TPS_SWCT_01127]

shall support arrays of [TPS_SWCT_01495] [TPS_SWCT_01601]
variable number of elements [TPS_SWCT_01602] [TPS_SWCT_01604]
within the maximum size [TPS_SWCT_01605] [TPS_SWCT_01606]
[TPS_SWCT_01607] [TPS_SWCT_01608]
[TPS_SWCT_01610] [TPS_SWCT_01612]
[TPS_SWCT_01613] [TPS_SWCT_01614]
[TPS_SWCT_01615] [TPS_SWCT_01617]
[TPS_SWCT_01618] [TPS_SWCT_01619]
[TPS_SWCT_01620] [TPS_SWCT_01621]
[TPS_SWCT_01622] [TPS_SWCT_01623]
[TPS_SWCT_01636] [TPS_SWCT_01641]
[TPS_SWCT_01642] [TPS_SWCT_01644]
[TPS_SWCT_01645] [TPS_SWCT_01647]
[TPS_SWCT_01648] [TPS_SWCT_01649]
[TPS_SWCT_01650] [TPS_SWCT_01752]
[RS_SWCT_03182] The SW-Component template [TPS_SWCT_01127]
shall support byte arrays of
variable number of elements
[RS_SWCT_03190] The SW-Component template [TPS_SWCT_01028] [TPS_SWCT_01029]
shall support the ability to [TPS_SWCT_01129] [TPS_SWCT_01132]
publish/specify the diagnostic [TPS_SWCT_01134] [TPS_SWCT_01135]
capabilities and its resources [TPS_SWCT_01136] [TPS_SWCT_01137]
of an SWC [TPS_SWCT_01138] [TPS_SWCT_01139]
[TPS_SWCT_01140] [TPS_SWCT_01425]
[TPS_SWCT_01426] [TPS_SWCT_01427]
[TPS_SWCT_01453] [TPS_SWCT_01537]
[TPS_SWCT_01538] [TPS_SWCT_01539]
[TPS_SWCT_01540] [TPS_SWCT_01544]
[TPS_SWCT_01546] [TPS_SWCT_01547]
[TPS_SWCT_01577] [TPS_SWCT_01578]
[TPS_SWCT_01582] [TPS_SWCT_01591]
[TPS_SWCT_01627] [TPS_SWCT_01628]
[TPS_SWCT_01629] [TPS_SWCT_01630]
[TPS_SWCT_01631] [TPS_SWCT_01632]
[TPS_SWCT_01633] [TPS_SWCT_01634]
[TPS_SWCT_01639] [TPS_SWCT_01640]
[TPS_SWCT_01654] [TPS_SWCT_01655]
[TPS_SWCT_01656] [TPS_SWCT_01657]
[TPS_SWCT_01680] [TPS_SWCT_01690]
[TPS_SWCT_01691] [TPS_SWCT_01706]
[TPS_SWCT_01707] [TPS_SWCT_01708]
[TPS_SWCT_01709] [TPS_SWCT_01711]
[TPS_SWCT_01712] [TPS_SWCT_01715]
[TPS_SWCT_01739] [TPS_SWCT_01746]
[TPS_SWCT_01765] [TPS_SWCT_01766]
[TPS_SWCT_01767] [TPS_SWCT_01769]
[TPS_SWCT_01789] [TPS_SWCT_01790]
[TPS_SWCT_01791] [TPS_SWCT_02002]
[TPS_SWCT_02003] [TPS_SWCT_02004]
[TPS_SWCT_02005] [TPS_SWCT_02007]
[TPS_SWCT_02008] [TPS_SWCT_02009]
[TPS_SWCT_02010] [TPS_SWCT_02011]
[TPS_SWCT_02012] [TPS_SWCT_02013]
[TPS_SWCT_02014] [TPS_SWCT_02015]

40 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[TPS_SWCT_02016] [TPS_SWCT_02505]
[RS_SWCT_03200] The SW-Component template [TPS_SWCT_01008] [TPS_SWCT_01009]
shall support vehicle and [TPS_SWCT_01010] [TPS_SWCT_01011]
application mode [TPS_SWCT_01016] [TPS_SWCT_01017]
management [TPS_SWCT_01018] [TPS_SWCT_01019]
[TPS_SWCT_01020] [TPS_SWCT_01021]
[TPS_SWCT_01063] [TPS_SWCT_01064]
[TPS_SWCT_01065] [TPS_SWCT_01066]
[TPS_SWCT_01067] [TPS_SWCT_01071]
[TPS_SWCT_01126] [TPS_SWCT_01450]
[TPS_SWCT_01451] [TPS_SWCT_01552]
[TPS_SWCT_01553] [TPS_SWCT_01554]
[TPS_SWCT_01572] [TPS_SWCT_01581]
[TPS_SWCT_01664]
[RS_SWCT_03201] The SW-Component template [TPS_SWCT_01063] [TPS_SWCT_01064]
shall support Portgroups [TPS_SWCT_01065] [TPS_SWCT_01066]
[TPS_SWCT_01096] [TPS_SWCT_01126]
[TPS_SWCT_01169] [TPS_SWCT_01173]
[TPS_SWCT_01174]
[RS_SWCT_03202] The SW-Component template [TPS_SWCT_01086] [TPS_SWCT_01201]
shall support enabling SWCs [TPS_SWCT_01353] [TPS_SWCT_01554]
to request dedicated modes [TPS_SWCT_01572]
[RS_SWCT_03203] The SW-Component template [TPS_SWCT_01086] [TPS_SWCT_01087]
shall support propagation of [TPS_SWCT_01200] [TPS_SWCT_01201]
mode information [TPS_SWCT_01202] [TPS_SWCT_01552]
[TPS_SWCT_01553] [TPS_SWCT_01566]
[TPS_SWCT_01664]
[RS_SWCT_03210] The SW-Component template [TPS_SWCT_01023] [TPS_SWCT_01024]
shall support integrity and [TPS_SWCT_01099] [TPS_SWCT_01100]
scaling at ports [TPS_SWCT_01101] [TPS_SWCT_01102]
[TPS_SWCT_01103] [TPS_SWCT_01104]
[TPS_SWCT_01105] [TPS_SWCT_01158]
[TPS_SWCT_01159] [TPS_SWCT_01160]
[TPS_SWCT_01161] [TPS_SWCT_01162]
[TPS_SWCT_01163] [TPS_SWCT_01164]
[TPS_SWCT_01165] [TPS_SWCT_01166]
[TPS_SWCT_01167] [TPS_SWCT_01168]
[TPS_SWCT_01449] [TPS_SWCT_01543]
[TPS_SWCT_01549] [TPS_SWCT_01550]
[TPS_SWCT_01551] [TPS_SWCT_01560]
[TPS_SWCT_01561] [TPS_SWCT_01583]
[TPS_SWCT_01768]
[RS_SWCT_03215] The SW-Component template [TPS_SWCT_01072] [TPS_SWCT_01073]
shall define the need to add [TPS_SWCT_01074] [TPS_SWCT_01189]
application data type on top of [TPS_SWCT_01229] [TPS_SWCT_01231]
implementation data type [TPS_SWCT_01235] [TPS_SWCT_01236]

41 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[RS_SWCT_03216] The SW-Component template [TPS_SWCT_01072] [TPS_SWCT_01073]

shall support application data [TPS_SWCT_01179] [TPS_SWCT_01180]
type [TPS_SWCT_01181] [TPS_SWCT_01183]
[TPS_SWCT_01184] [TPS_SWCT_01185]
[TPS_SWCT_01189] [TPS_SWCT_01191]
[TPS_SWCT_01229] [TPS_SWCT_01230]
[TPS_SWCT_01231] [TPS_SWCT_01235]
[TPS_SWCT_01236] [TPS_SWCT_01237]
[TPS_SWCT_01240] [TPS_SWCT_01241]
[TPS_SWCT_01242] [TPS_SWCT_01243]
[TPS_SWCT_01249] [TPS_SWCT_01256]
[TPS_SWCT_01486]
[RS_SWCT_03217] The SW-Component template [TPS_SWCT_01072] [TPS_SWCT_01074]
shall support implementation [TPS_SWCT_01183] [TPS_SWCT_01184]
data type [TPS_SWCT_01189] [TPS_SWCT_01191]
[TPS_SWCT_01229] [TPS_SWCT_01231]
[TPS_SWCT_01232] [TPS_SWCT_01233]
[TPS_SWCT_01235] [TPS_SWCT_01236]
[TPS_SWCT_01237] [TPS_SWCT_01248]
[TPS_SWCT_01250] [TPS_SWCT_01251]
[TPS_SWCT_01252] [TPS_SWCT_01253]
[TPS_SWCT_01254] [TPS_SWCT_01255]
[TPS_SWCT_01257] [TPS_SWCT_01258]
[TPS_SWCT_01259] [TPS_SWCT_01700]
[TPS_SWCT_01701] [TPS_SWCT_01702]
[RS_SWCT_03218] The SW-Component template [TPS_SWCT_01477]
shall support data types for
primitive data mapping
[RS_SWCT_03220] The SW-Component template [TPS_SWCT_01088] [TPS_SWCT_01568]
shall allow communication
attributes on compositions
[RS_SWCT_03221] The SW-Component template [TPS_SWCT_01222] [TPS_SWCT_01594]
shall allow port specific [TPS_SWCT_01595] [TPS_SWCT_01596]
configuration of data [TPS_SWCT_01597] [TPS_SWCT_01598]
transformation properties [TPS_SWCT_01599] [TPS_SWCT_01600]
[RS_SWCT_03222] The SW-Component template [TPS_SWCT_01616] [TPS_SWCT_01624]
shall support error notification [TPS_SWCT_01626]
for transformed data
communication
[RS_SWCT_03225] The SW-Component template [TPS_SWCT_01141] [TPS_SWCT_01142]
shall support an enhanced [TPS_SWCT_01143] [TPS_SWCT_01227]
non-volatile (NV) memory [TPS_SWCT_01228] [TPS_SWCT_01584]
interface [TPS_SWCT_01585] [TPS_SWCT_01586]
[TPS_SWCT_01587] [TPS_SWCT_01588]
[TPS_SWCT_01589] [TPS_SWCT_01590]
[TPS_SWCT_01662] [TPS_SWCT_01665]
[TPS_SWCT_01666] [TPS_SWCT_01675]
[TPS_SWCT_01754] [TPS_SWCT_01755]
[TPS_SWCT_02501] [TPS_SWCT_02502]
[TPS_SWCT_02503] [TPS_SWCT_02504]
[RS_SWCT_03230] The SW-Component template [TPS_SWCT_01062] [TPS_SWCT_01699]
shall support documentation
of M1 artifacts

42 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[RS_SWCT_03240] The SW-Component template [TPS_SWCT_01089] [TPS_SWCT_01090]

shall support end-to-end [TPS_SWCT_01091] [TPS_SWCT_01092]
communication protection [TPS_SWCT_01093] [TPS_SWCT_01094]
[TPS_SWCT_01095] [TPS_SWCT_01508]
[TPS_SWCT_01529]
[RS_SWCT_03241] The SW-Component template [TPS_SWCT_01169] [TPS_SWCT_01170]
shall support partial [TPS_SWCT_01171] [TPS_SWCT_01172]
networking [TPS_SWCT_01173] [TPS_SWCT_01174]
[TPS_SWCT_01175]
[RS_SWCT_03250] The SW-Component template [TPS_SWCT_01112] [TPS_SWCT_01113]
shall support bidirectional [TPS_SWCT_01454] [TPS_SWCT_01455]
communication [TPS_SWCT_01514] [TPS_SWCT_01573]
[RS_SWCT_03260] The SW-Component template [TPS_SWCT_01484] [TPS_SWCT_01485]
shall support rule-based [TPS_SWCT_01493] [TPS_SWCT_01494]
initialization of arrays [TPS_SWCT_01495] [TPS_SWCT_01528]
[TPS_SWCT_01609] [TPS_SWCT_01692]
[RS_SWCT_03270] The SW-Component template [TPS_SWCT_02507]
shall support overriding the
activation period time on
instance level
[RS_SWCT_03280] The SW-Component template [TPS_SWCT_01719] [TPS_SWCT_01720]
shall support the description [TPS_SWCT_01721] [TPS_SWCT_01722]
of bypass points and bypass [TPS_SWCT_01723] [TPS_SWCT_01724]
scenarios [TPS_SWCT_02046] [TPS_SWCT_02047]
[TPS_SWCT_02048] [TPS_SWCT_02049]
[TPS_SWCT_02050] [TPS_SWCT_02051]
[TPS_SWCT_02052]
[RS_SWCT_03281] The SW-Component template [TPS_SWCT_02047]
shall support post-build
hooking tools for rapid
prototyping
[RS_SWCT_03282] The SW-Component template [TPS_SWCT_02046] [TPS_SWCT_02047]
shall support the description
of service points and rapid
prototyping scenarios
[RS_SWCT_03290] The SW-Component template [TPS_SWCT_01525]
shall support the initialization
of runnables without usage of
mode management
[RS_SWCT_03310] The SW-Component template [TPS_SWCT_01537] [TPS_SWCT_01538]
shall support Diagnostics over [TPS_SWCT_01539] [TPS_SWCT_01544]
IP [TPS_SWCT_01546] [TPS_SWCT_01547]
[TPS_SWCT_01746]
[RS_SWCT_03320] The SW-Component template [TPS_SWCT_01771] [TPS_SWCT_01772]
shall support the definition of [TPS_SWCT_01773] [TPS_SWCT_01774]
optional elements for [TPS_SWCT_01775] [TPS_SWCT_01785]
communication [TPS_SWCT_01786]

Table 1.3: RequirementsTracing

43 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

2 Conceptual Aspects

2.1 Introduction
For the sake of a compact description of relevant meta-model elements the discussion
and explanation of conceptual aspects has been concentrated in this chapter.
Reading this chapter is not a pre-requisite for understanding the subsequent chapters.
It just provides a central place for the detailed description of conceptual aspects used
in various other chapters of this document.
The actual explanation of the concept of a software-component starts in chapter 3.

2.2 Measurement and Calibration

2.2.1 Basic Approach of Measurement and Calibration

While performing the calibration process using a MCD tool (Measurement, Calibration,
and Diagnostic) the calibration engineer needs to have a specific insight to the data
within the CPU at runtime.
This insight is provided by access to ECU internal variables (also called measure-
ments) as well as calibration parameters (sometimes also called characteristic value).
For more details, please refer to [TPS_SWCT_01418]
The description of measurement variables and calibration parameters is basically the
same. In AUTOSAR both appear finally as DataPrototypes.

2.2.2 Calibration Parameters Overview

A Calibration Parameter is a parameter which characterizes the dynamics of a control

algorithm. From a software implementation point of view, it is a variable with only
read-access during the normal operation of an ECU. Characteristics are specialized
DataPrototype entities in terms of its associated type but are used in a similar way.
[TPS_SWCT_01418] Ways to define a calibration parameter d This means that Cal-
ibration Parameters can be defined
• individually for a SwComponentPrototype in the SwcInternalBehavior of
a SwComponentType via an aggregation of an ParameterDataPrototype in
the role of perInstanceParameter (similar to PerInstanceMemory).
• sharing between all SwComponentPrototypes of the same SwComponent-
Type in its SwcInternalBehavior via an aggregation of an ParameterDat-
aPrototype in the role of sharedParameter or constantMemory.

44 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

• for several SwComponentPrototypes (using the port-/interface-concept with

ParameterInterfaces).
c()
Please note:
• The definition of perInstanceParameter is further described in chap-
ter 2.2.3.3.
• Chapter 2.2.3.2 provides more information about the definition of sharedPa-
rameter or constantMemory.
• For more information regarding the definition of ParameterInterface, please
refer to chapter 2.2.3.1.

Curve Map Axis

Figure 2.1: Some Categories of calibration parameters

Note: the structure of various calibration objects is visualized in [13].

2.2.3 Using Calibration Parameters

As mentioned above, a ParameterDataPrototype can be used in the context of

SwcInternalBehavior as well as in the context of PortPrototypes.

2.2.3.1 Sharing Calibration Parameters within Compositions

To provide calibration parameters for being visible in other SwComponentTypes, a

dedicated ParameterSwComponentType (see Figure 3.4) that inherits from SwCom-
ponentType has to be used as a SwComponentPrototype within a Composition-
SwComponentType.

45 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Class ParameterSwComponentType
Package M2::AUTOSARTemplates::SWComponentTemplate::Components
Note The ParameterSwComponentType defines parameters and characteristic values accessible via provided
Ports. The provided values are the same for all connected SwComponentPrototypes
Tags: atp.recommendedPackage=SwComponentTypes
Base ARElement, ARObject, AtpBlueprint, AtpBlueprintable, AtpClassifier , AtpType, CollectableElement,
Identifiable, MultilanguageReferrable, PackageableElement, Referrable, SwComponentType
Attribute Type Mul. Kind Note
constant ConstantSpecification * ref Reference to the ConstanSpecificationMapping to be
Mapping MappingSet applied for the particular ParameterSwComponentType
Stereotypes: atpSplitable
Tags: atp.Splitkey=constantMapping
dataType DataTypeMappingSet * ref Reference to the DataTypeMapping to be applied for the
Mapping particular ParameterSwComponentType
Stereotypes: atpSplitable
Tags: atp.Splitkey=dataTypeMapping
instantiation InstantiationDataDef * aggr The purpose of this is that within the context of a given
DataDefProps Props SwComponentType some data def properties of individual
instantiations can be modified.
The aggregation of InstantiationDataDefProps is subject
to variability with the purpose to support the conditional
existence of PortPrototypes
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime

Table 2.1: ParameterSwComponentType

[TPS_SWCT_01420] SwComponentType requiring access to shared calibration

parameters needs RPortPrototype typed by a ParameterInterface d Every
SwComponentType requiring access to shared calibration parameters will have an
RPortPrototype typed by a ParameterInterface. The definition of this shared
calibration access in the context of a CompositionSwComponentType will be defined
by creating a SwConnector between the relevant SwComponentPrototypes. c()
Class ParameterInterface
Package M2::AUTOSARTemplates::SWComponentTemplate::PortInterface
Note A parameter interface declares a number of parameter and characteristic values to be exchanged
between parameter components and software components.
Tags: atp.recommendedPackage=PortInterfaces
Base ARElement, ARObject, AtpBlueprint, AtpBlueprintable, AtpClassifier , AtpType, CollectableElement,
DataInterface, Identifiable, MultilanguageReferrable, PackageableElement, PortInterface, Referrable
Attribute Type Mul. Kind Note
parameter ParameterData 1..* aggr The ParameterDataPrototype of this ParameterInterface.
Prototype

Table 2.2: ParameterInterface

[TPS_SWCT_01421] ParameterInterface is not restricted to parameters which

can actually can be calibrated d Note that a ParameterInterface is not restricted
to parameters which can actually can be calibrated. It can be used whenever there
shall be no write access to the data during normal operation of the software, i.e. only
constant data are visible over the interface. c()

46 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

The compatibility rules for ParameterInterfaces are described in chapter 6.4; the
compatibility rules for ParameterDataPrototypes are described in chapter 6.4.4.
[TPS_SWCT_01422] Delegation of PortPrototypes typed by a Parameter-
Interface d Access to shared calibration parameters can be provided and re-
quired even over CompositionSwComponentTypes using DelegationSwConnec-
tors and AssemblySwConnectors.
This means that each access to calibration parameters between SwComponentPro-
totypes is explicitly visible. If a SwConnector spans after the mapping of SwCom-
ponentPrototypes over two different ECUs the system generation process has to
ensure the proper allocation of the ParameterDataPrototype while the calibration
system has to cope with setting the parameter synchronously on the affected ECUs. c
()

47 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

AtpBlueprintable
AtpPrototype
PortPrototype

AbstractProvidedPortPrototype AbstractRequiredPortPrototype

PPortPrototype RPortPrototype

«isOfType»
«isOfType»
1 1
{redefines {redefines
+providedInterface atpType} +requiredInterface atpType}
ARElement
AtpBlueprint
AtpBlueprintable
AtpType
PortInterface

+ isService: Boolean
+ serviceKind: ServiceProviderEnum [0..1]

AtpPrototype
DataInterface
DataPrototype

ParameterInterface AutosarDataPrototype

+parameter 1..* +/swDataDefProps 0..1

ParameterDataPrototype «atpVariation»
SwDataDefProps

Figure 2.2: ParameterInterface

2.2.3.2 Sharing Calibration Parameters between SwComponentPrototypes of

the Same SwComponentType

To share calibration parameters between several SwComponentPrototypes of the

same SwComponentType, a ParameterDataPrototype is attached to an SwcIn-
ternalBehavior in sharedParameter role (see [TPS_SWCT_01418]).

48 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

When the SwcInternalBehavior is aggregated by an AtomicSwComponentType

the actual calibration parameters of the ParameterDataPrototype is the same for
all SwComponentPrototypes.
[TPS_SWCT_01423] ParameterDataPrototype aggregated in the role con-
stantMemory d Additionally, it is possible to describe the implementation of shared
characteristic values via a ParameterDataPrototype which is attached to an
SwcInternalBehavior in the role constantMemory.
In contrast to the ParameterDataPrototype in sharedParameter role this kind
of memory is not instantiated by the RTE. This supports more efficient implementa-
tions (especially for software components provided as object code) by avoidance of
the additional indirection caused by the RTE’s component data structure. c()
Further on this kind of memory reduces the dependencies of the software-component’s
implementation to generated RTE code which is appreciated for safety related function-
alities.
Nevertheless the information about these characteristic values has to be taken into
account for the A2L file generation.
A typical example for this kind of sharing code between instances is dealing with two
lambda sensors in multiple cylinder-bank engines, where (at least) two SwComponent-
Prototypes for each lambda sensor will use the very same Calibration Parameters.

2.2.3.3 Providing Instance Individual Characteristic Data

[TPS_SWCT_01424] ParameterDataPrototype aggregated in the role perIn-

stanceParameter d To provide instance individual calibration parameters a Param-
eterDataPrototype is owned by a SwcInternalBehavior in perInstancePa-
rameter role.
When the SwcInternalBehavior is attached to an AtomicSwComponentType, the
actual calibration values are specific for each SwComponentPrototype. c()

49 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

AutosarDataPrototype

AtpStructureElement
ParameterDataPrototype
InternalBehavior +constantMemory

«atpVariation,atpSplitable» 0..*

SwcInternalBehavior +perInstanceParameter

+ handleTerminationAndRestart: HandleTerminationAndRestartEnum «atpVariation,atpSplitable» *

+ supportsMultipleInstantiation: Boolean
+sharedParameter

«atpVariation,atpSplitable» *

AtpPrototype
DataPrototype

+localParameter 0..1 +autosarParameter 0..1

«atpVariation,atpSplitable» «instanceRef»

AutosarParameterRef

  
   
 

+accessedParameter 1
+runnable 0..*

AtpStructureElement
ExecutableEntity
AbstractAccessPoint
RunnableEntity
+parameterAccess AtpStructureElement
+ canBeInvokedConcurrently: Boolean Identifiable
+ symbol: CIdentifier «atpVariation,atpSplitable» 0..* ParameterAccess

Figure 2.3: ParameterDataPrototypes in internal behavior

2.3 Runtime and Data Consistency Aspects

2.3.1 Background: the Issues

This section gives some background information and lists possible strategies concern-
ing the implementation of the RunnableEntitys and the RTE with respect to efficient
communication between the RunnableEntitys.
The communication among RunnableEntitys can very efficiently be implemented
by means of “sharing memory”1 .
1
Please note that the term “sharing memory” can be interpreted on different levels. It is e.g. in the C
language possible to use variables with external linkage (a.k.a. “global variables”, although this term is
not officially defined by the C language) for the purpose of inter-Runnable communication.

50 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

This is technically feasible because it is always guaranteed that the RunnableEn-

titys within an AtomicSwComponentType are always gathered at a specific pro-
cessing unit (in other words: distribution is not an option).
Note that the purpose of communication among the RunnableEntitys is to establish
a data flow scheme. The latter is a very popular pattern in the application of control
theory to automotive embedded systems. So if “global variables” are used for estab-
lishing internal communication among RunnableEntitys they acquire the semantics
of so called state-messages.
Nevertheless, directly sharing memory between RunnableEntitys requires a seri-
ous problem to be solved: the guarantee of data consistency among communicating
RunnableEntitys. The RunnableEntitys will indeed be mapped to tasks so that
one RunnableEntity of an AtomicSwComponentType may be preempted by a dif-
ferent RunnableEntity of the same AtomicSwComponentType.
Please note that a purist approach to achieving data consistency not only applies to
single accesses of concurrently accessed variables. Rather, it would not be permitted
that the value of a concurrently accessed variable (with state-message semantics) is
unintentionally changed during the run-time of a RunnableEntity.
The following paragraphs describe some common strategies that can be used to en-
sure the required data-consistency. We do not attempt to describe the pros or cons of
these approaches.

2.3.1.1 Mutual Exclusion with Semaphores

Multi-threaded operating systems provide mutexes (mutual exclusion semaphores) that

protect access to an exclusive resource that is used from within several tasks.
The RTE could use these OS-provided mutexes to make sure that the RunnableEn-
titys sharing a memory-space would never run concurrently. The RTE would make
sure the task running the RunnableEntity has taken an appropriate mutex before
accessing the memory shared between the RunnableEntitys.

2.3.1.2 Interrupt Disabling

Another alternative would be the disabling of interrupts during the run-time of

RunnableEntitys or at least for a period in time identical to the interval from the
first to the last usage of a concurrently accessed variable in a RunnableEntity. This
approach could lead to seriously non-deterministic execution timing.

51 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

2.3.1.3 Priority Ceiling

Priority ceiling allows for a non-blocking protection of shared resources. Provided that
the priority scheme is static, the AUTOSAR OS is capable of temporarily raising the
priority of a task that attempts to access a shared resource to the highest priority of all
tasks that would ever attempt to access the resource.
By this means is technically impossible that a task in temporary possession of a re-
source is ever preempted by a task that attempts to access the resource as well.

2.3.1.4 Implicit Communication by Means of Variable Copies

Another alternative is the usage of copies of concurrently accessed variables with state
message semantics. Note that this approach directly corresponds to the semantics of
“implicit” sender-receiver communication (see 7.5.1.2).
This means in particular that for a concurrently used variable a copy is created on
which a RunnableEntity entity can work without any danger of data inconsistency.
This concept requires additional code to write the value of the concurrently accessed
variable to the copy before the RunnableEntity that accesses the variable is exe-
cuted. The value of the copy shall be written back to the concurrently accessed variable
after the RunnableEntity has been terminated.
This concept is sketched in Figure 2.4. Since it would be too expensive and error-prone
to manually care about the copy routines it would be a good idea to leave the creation
of the additional code to a suitable code generator.

Figure 2.4: Generation of copy routines around RunnableEntitys

The additional copy routines as sketched in Figure 2.4 already protect the particular
RunnableEntitys from unintended changes of concurrently accessed variables. It
would, however, be possible to further optimize the process by reducing the additional
code at the beginning and end of each task (see Figure 2.5).

52 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

2.3.2 Data Consistency at Runtime

In addition, copy routines will only be inserted where appropriate, e.g. a copy routine
for writing the value of a copy back to the concurrently accessed variable will only be
inserted if the RunnableEntity has write access to the concurrently used variable.
Please note that the copy routines have to temporarily make sure that the copy process
is not interrupted in order to be capable of consistently copying the values from and to
the concurrently accessed variable.
These periods, however, are supposed to be very short compared with the overall
run-time consumption of the RunnableEntity and thus would not have a significant
impact on the runtime behavior.

Figure 2.5: Optimized insertion of copy routines

Further optimization criteria can be applied, for example: it would be perfectly safe
to avoid the creation of copies for RunnableEntitys that are scheduled in the task
with the highest priority of all tasks that (via contained RunnableEntitys) access a
certain concurrently accessed variable.
In order to keep the application code free of any dependencies from the code gener-
ation, access to concurrently accessed variables will be guarded by macros that are
later resolved by the code generator.
The presence of the guard macros directly supports the reuse on the level of source
code. The reuse on the level of object code is only possible if the scheduling scenario
(in terms of the assignment of RunnableEntitys to priority levels) does not change.
This concept can only be implemented properly with the aid of a code generator if the
variables in question can be identified. In other words: the description of an Atomic-
SwComponentType has to expose all concurrently accessed variables to the outside
world.

2.3.3 Modeling Aspects of Data Consistency

The intrinsic meaning of the terms “explicit communication” and “implicit communica-
tion” is explained in section 7.5.1.1. It would be fair to say that the distinction between

53 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

implicit and explicit communication establishes a usage pattern in the application do-
main, i.e. in the world of the developer of AUTOSAR software-components and their
implementation.
There is another facet to this subject, however, namely the question how this pattern is
implemented in the meta-model. With respect to the application of the pattern for port-
based communication the details can be found in section 7.5.1.2, more specifically in
section 7.5.1.3. The consideration of the internal communication based on so-called
“inter-runnable variables” is described in section 7.4.2.
By reading the respective text sections it becomes apparent that the two applications
of the pattern are modeled differently. The port-based communication uses the Vari-
ableAccess to formalize different roles of accessing communication elements. Some
of the roles used for this purpose imply explicit communication (e.g. dataSendPoint)
and some represent implicit communication (e.g. dataWriteAccess).
The important thing about using the VariableAccess, however, is that the modeling
of communication roles is abstracted from the actual communication elements and
represents a uniform (meaning: it can refer to the target directly or by a so-called
InstanceRef) modeling approach that is applied for all use cases2 .
Admittedly, this is handled in a different way for the internal communication. Here,
the additional layer of abstraction is not used (although it would have been techni-
cally feasible to do so) with respect to the clear separation of “inter-runnable variables
with implicit behavior” and “inter-runnable variables with explicit behavior” in the RTE.
The implementation of different communication roles (i.e. implicit vs. explicit) is done
by directly aggregating VariableDataPrototype in the roles explicitInter-
RunnableVariable and implicitInterRunnableVariable.
On the other hand, access to internal communication never requires the usage of an
InstanceRef and therefore the abstraction might be considered unnecessary over-
head that blows up the M1 model.

2.4 Variant Handling in the Software Component Template

The Software Component Template supports the creation of Variants in a subset
of its model elements. The full list of model elements that support variation can be
found in the appendix.
[TPS_SWCT_01038] Support for Variant Handling in the in Software Com-
ponent Template d The Variant Handling support in the in Software Com-
ponent Template is mainly driven by the purpose to describe a variable system on
Virtual Functional Bus[3] level by varying
• the existence of SwComponentPrototypes
2
On a related note, even for non-communication related data access the same pattern applies imple-
mented by ParameterAccess

54 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

• the existence of SwConnectors

• the existence of Chapters of SwComponentDocumentation
• the existence of PortPrototypes
c(RS_SWCT_00220, RS_SWCT_03100, RS_SWCT_03140, RS_SWCT_03142,
RS_SWCT_03154)
[TPS_SWCT_01039] Purpose of variant handling d This supports adjusting the num-
ber and kind of software-component instances as well as their interconnection in a
particular system variant. c(RS_SWCT_00220)
[TPS_SWCT_01447] Applicable binding times for model elements in the scope of
the Software Component Template d The first three cases are supporting Post-
Build binding. For the existence of PortPrototypes only preCompileTime is sup-
ported as latest Binding Time. c(RS_SWCT_00220)
[TPS_SWCT_01040] SwConnector exists depending on a PostBuild condition
d A SwConnector which exists depending on a PostBuild condition has an impact
on the behavior of API function calls that apply on a PortPrototype to which the
SwConnector is attached. If the SwConnector does not exist the behavior of the RTE
API functions need to take this into account. This means that the RTE implementation
of this PortPrototype resembles the behavior of an unconnected PortPrototype.
c(RS_SWCT_00220, RS_SWCT_03100, RS_SWCT_03143)
Please find more details in the specification of the RTE [2].
[TPS_SWCT_01041] API functions of not existing SwConnector are still part of
the software-component’s implementation d If SwConnectors do not exist the cor-
responding API functions are still part of the software-component’s implementation.
It is not possible to remove the API functions in a PostBuild step. Therefore the lat-
est reasonable Binding Time for the conditional existence of a PortPrototype is
preCompileTime. c(RS_SWCT_00220, RS_SWCT_03100)
[TPS_SWCT_01085] Variation on the behavior level d In addition to variation of the
VFB-related model elements, the description of variant software-component implemen-
tations is supported. Please note that this requires a broad support of variability in the
Internal Behavior.
The identified main use case are
• the existence of RunnableEntitys
• the existence of RTEEvents
• the existence of VariableDataPrototypes in the roles implicitInter-
RunnableVariable and explicitInterRunnableVariable
• the existence of ParameterDataPrototypes in the roles perInstancePa-
rameter, sharedParameter, and constantMemory
c(RS_SWCT_03149, RS_SWCT_03150, RS_SWCT_03151, RS_SWCT_03153)

55 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

For the same reason that applies on the existence of PortPrototype the latest
Binding Time of these kinds of variability is preCompileTime.
In the meta-model, 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 information, for example the latest binding
time.
[TPS_SWCT_01042] Four types of locations in the meta-model which may exhibit
variability d There are four types of locations in the meta-model which may exhibit
variability:
• Aggregations
• Associations
• Attribute Values
• Classes providing property sets
c(RS_SWCT_00220, RS_SWCT_03100)
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 [11].

2.5 Communication Specification of Composition Component

Types
[TPS_SWCT_01088] ComSpecs defined by CompositionSwComponentTypes d It
shall be possible to attach ComSpecs to PortPrototypes owned by Composition-
SwComponentTypes. c(RS_SWCT_03220)

2.5.1 Rationale

ComSpecs attached to a PortPrototype owned by an AtomicSwComponentType

have a direct impact on the generation of the RTE. The RTE Generator, on the other
hand, does not consider the existence of CompositionSwComponentTypes.
Nevertheless, there are some cases where the definition of a ComSpec attached to a
PortPrototype owned by a CompositionSwComponentType does make sense.
That is, in case an OEM wants to submit the definition of a CompositionSwCompo-
nentType to a supplier for adding more details and implementing the behavior the
OEM might want to point out that from the OEM’s point of view sender initValues
and receiver initValues apply for the elements of PortInterfaces used to type
the delegation PortPrototypes.

56 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

The idea is that the supplier takes over the initValues attached to the delegation
PortPrototypes and copies them to the PortPrototypes owned by SwCompo-
nentPrototypes of the CompositionSwComponentType.
[TPS_SWCT_01568] Consideration of RPortComSpec or PPortComSpec depend-
ing on the ownership d The RTE Generator shall take the attributes of the RPortCom-
Spec or PPortComSpec of the PortPrototypes owned by AtomicSwComponent-
Types or ParameterSwComponentType and ignore the attributes of the RPortCom-
Spec or PPortComSpec attached to PortPrototypes owned by Composition-
SwComponentType. c(RS_SWCT_03220)
Therefore, the initValues of the delegation PortPrototype would be taken as
mere templates for the detailing of PortPrototypes connected to the delegation
PortPrototypes.
It is not required that the initValues of delegated PortPrototype and a Port-
Prototype connected by means of a DelegationSwConnector match.
Although this would certainly make sense in many cases it is eventually still left to the
supplier to decide on the specific initValues applicable inside the Composition-
SwComponentType.
On the other hand, a requirement that the initValues defined on the surface of Com-
positionSwComponentType and the inside of the CompositionSwComponent-
Type shall be consistent in any case might effectively prevent the reuse of existing
AtomicSwComponentTypes.
Please note that the ability to define a ComSpec in the context of a Composition-
SwComponentType implies that it shall be possible to define mappings of Applica-
tionDataTypes used in a PortInterface to their corresponding Implementa-
tionDataTypes.
For this purpose the CompositionSwComponentType owns a DataTypeMap-
pingSet in the role dataTypeMapping and a ConstantSpecificationMap-
pingSet in the role constantValueMapping.
SwComponentType
CompositionSwComponentType

«atpSplitable» «atpSplitable»

+dataTypeMapping 0..* +constantValueMapping 0..*

ARElement ARElement
AtpBlueprint ConstantSpecificationMappingSet
AtpBlueprintable
DataTypeMappingSet

Figure 2.6: Specification of data type mapping for CompositionSwComponentType

57 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

2.6 PRPortPrototype
In some cases SwComponentTypes need to read and write the same piece of data.
One of the most prominent examples for this use case is the NvBlockSwComponent-
Type that factually ready and writes blocks of NvRAM.
Without the ability to combine read and write semantics in a kind of PortPrototype
that supports both read and write semantics work-arounds have to be implemented
that come with a certain footprint on memory and processing time.

2.6.1 Use Case 1

Without the ability to define a combined read and write semantics the definition of an
RPortPrototype and a PPortPrototype is required for reading and writing the
applicable data.

Figure 2.7: Use Case 1 for the existence of PRPortPrototype

Technically, this read and write access is related to the same data item in an NVRAM
Block. This requires a consistent connection of the PortPrototypes between
an NvBlockSwComponentType and ApplicationSwComponentType as well as a
consistent mapping of the corresponding RPortPrototype and a PPortPrototype
of the NvBlockSwComponentType and the related element of the ramBlock.

2.6.2 Use Case 2

It may happen that a SwComponentType need to consume the same data that it pro-
duces. If the only way to achieve this was the connection of a PPortPrototype to an
RPortPrototype of the same SwComponentType then the creator of the SwCom-
ponentType cannot enforce this connection as it is created on a higher level of ab-
straction in the context of a CompositionSwComponentType.

58 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

In other words, it is impossible to fully specify the semantics of the otherwise self-
contained SwComponentType.

Figure 2.8: Use Case 2 for the existence of PRPortPrototype

This means that only in the in best case one buffer for the data is needed. But depend-
ing on the mapping RunnableEntitys to OS tasks additional buffers may need to be
allocated by the RTE to fully implement the implicit communication pattern.
As an alternative, the ApplicationSwComponentType could utilize inter-runnable
variables but unfortunately this inhibits any optimization in the RTE and will consume
additional RAM. In contrast to the previous approach at least two buffers are needed.

2.6.3 Use Case 3

In this scenario, several ApplicationSwComponentTypes are iterating over the

same large set of data. This means each ApplicationSwComponentType imple-
ments one out of many steps of a complex data processing algorithm applied to the
same piece of data.

59 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Figure 2.9: Use Case 3 for the existence of PRPortPrototype

For example, this scenario may apply for video signal processing in camera applica-
tions. Typically, such applications will not be distributed over several ECUs.
It is clear that in this case the allocation of several buffers in the RTE is required to im-
plement the individual connections between the ApplicationSwComponentTypes.
In most cases, the processing has to be executed at a certain point in time in a dedi-
cated order.

2.6.4 Solution

The solution to the above-mentioned use cases is the ability to define a PortProto-
type that can read and write the same piece of data. This solves both the described
problem of resource consumption as well as the problem of having to define multiple
PortPrototypes as outlets for same piece of data item.
The technical details of the definition of PRPortPrototype are explained in chap-
ters 3.2.2 and 4.2.1.

2.7 Pretended Networking

[TPS_SWCT_01510] The role of pretended networking d Pretended networking is
a feature to reduce energy consumption of an ECU by switching the ECU in a mode
called Pretended Networking. In this mode the communication on communication
networks is reduced and the ECU can go into power saving modes.

60 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

When communication via communication networks is required the mode Pretended

Networking shall be left by request of a mode change to Normal Mode. c()
[TPS_SWCT_01511] Configuration option is encoded into ModeDeclaration d
The identification of different configuration options for Pretended Networking shall
be encoded into the definition of dedicated ModeDeclarations inside a ModeDec-
larationGroup. c(RS_SWCT_03110)
For example, assume that an implementation of pretended networking supports three
configuration options:
• PRETENDED_NW_MODE_OFF
• PRETENDED_NW_MODE_ONE
• PRETENDED_NW_MODE_TWO
In this example case, a ModeDeclarationGroup consisting of three ModeDecla-
rations shall be defined where each ModeDeclaration shall represent one of the
above-mentioned configuration options. The shortNames of the ModeDeclaration
shall be taken from the above-mentioned list.
[TPS_SWCT_01512] Request change of Pretended Networking mode d A
SwComponentType that needs to be able to request a change in the operating mode
of Pretended Networking shall provide a PPortPrototype typed by a Sender-
ReceiverInterface (see [TPS_SWCT_01086]) for requesting a change (towards
the BswM [14]) of the Pretended Networking mode.
It is out of the scope of this document to define the particular properties of the applica-
ble SenderReceiverInterface. The details of this specificSenderReceiverIn-
terface can be found in the specification of the BswM [14]. c(RS_SWCT_03110)
More details about how a mode change is requested can be found in section 9.
[TPS_SWCT_01513] React on the change of Pretended Networking mode d A
SwComponentType that needs to be able to react on a change in the operating mode
of Pretended Networking shall provide an RPortPrototype typed by a Mod-
eSwitchInterface (see [TPS_SWCT_01087]) for reacting on a change (initiated by
the BswM [14]) of the Pretended Networking mode.
It is out of the scope of this document to define the particular properties of the appli-
cable ModeSwitchInterface. The details of this specific ModeSwitchInterface
can be found in the specification of the BswM [14]. c(RS_SWCT_03110)

61 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

2.8 Variable-size Array Data Types

2.8.1 Overview and Use cases

AUTOSAR supports the definition of array data types where the size of the actual
payload varies at run-time. As far as the configuration is concerned, it is possible to
specify a maximum number of array elements that shall not be exceeded at run-time.
In order to properly understand the approach, it is necessary to understand that the
support for Variable-Size Array Data Types has been introduced in two waves
that each had a different motivation.

2.8.1.1 “Old-world” dynamic-size Arrays

In the first wave, the support for Variable-Size Array Data Types was limited
to data types that basically boil down to an array where the base type is an unsigned
integer data type with a length of exactly one byte.
The main use cases for this scenario are derived from diagnostics requirements as
well as support for the J1939 communication protocol.
In both cases the actual length of a Variable-Size Array Data Type could be
determined from the context, i.e. either by the diagnostic basic-software module or by
the implementation of the J1939 TP.
For the lack of a better terminology, this specification distinguishes between “old-world”
dynamic-size arrays and “new-world” Variable-Size Array Data Types. It will
be necessary to clearly define the characteristics that allow for an disambiguation be-
tween the “old-world” dynamic-size arrays and “new-world” Variable-Size Array
Data Types.
[TPS_SWCT_01641] Definition of an “old-world” dynamic-size array data type by
means of an ApplicationArrayDataType d An ApplicationArrayDataType
that doesn’t define attribute dynamicArraySizeProfile and that aggregates an
ApplicationArrayElement where attribute arraySizeSemantics exists and is
set to the value variableSize shall be considered an “old-world” dynamic-size array
data type. c(RS_SWCT_03181)
Please note that [TPS_SWCT_01641] can’t go any deeper into the specifics of the
given data type because it is intentionally focused on ApplicationDataTypes.
There are use cases where the distinction between “old-world” dynamic-size arrays and
“new-world” Variable-Size Array Data Types must be done in the absence of
a corresponding ImplementationDataType.
In general, the disambiguation becomes multi-faceted (but not necessarily easier)
if the definition of a corresponding ImplementationDataType is available (see
[TPS_SWCT_01642]).

62 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[TPS_SWCT_01642] Definition of an “old-world” dynamic-size array data type by

means of an ImplementationDataType d An ImplementationDataType that
(after all type references are resolved) fulfills all of the following conditions shall be
considered an “old-world” dynamic-size array data type:
• The value of attribute category is set to ARRAY
• The ImplementationDataType doesn’t define the attribute dynamicArray-
SizeProfile
• The ImplementationDataType aggregates a subElement where
– attribute arraySizeSemantics exists and is set to the value variable-
Size
– attribute arraySizeHandling does not exist
• The ImplementationDataType.swDataDefProps.baseType exists and the
attribute
– baseTypeEncoding exists and is set to the value NONE
– baseTypeSize exists and is set to the value 8
c(RS_SWCT_03181)
By and large, the defining characteristics for “old-world” dynamic-size arrays is the
absence of a definition of the attribute ApplicationArrayDataType.dynamicAr-
raySizeProfile or ImplementationDataType.dynamicArraySizeProfile.
By regulation of [constr_1387], “old-world” dynamic-size arrays are not supported for
transmission by means of a data transformer. The only supported kind of Variable-
Size Array Data Type that can be transmitted using a data transformer is the
“new-world” variable-size arrays.

2.8.1.2 “New-world” variable-size Arrays

In contrast to this, the second wave of support for Variable-Size Array Data
Types was motivated by the application software layer itself.
Here, the situation is entirely different because the actual size cannot be determined
by any context software module. The application itself is responsible for maintaining
the proper length of a Variable-Size Array Data Type at run-time.
As a consequence, the specification of the actual array size at run-time needs to be re-
flected by the structure of the data types used for hosting the Variable-Size Array
Data Type.
[TPS_SWCT_01644] Definition of a “new-world” variable-size array data type by
means of an ApplicationArrayDataType d An ApplicationArrayDataType

63 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

that fulfills all of the following conditions shall be considered an “new-world” dynamic-
size array data type.
• The ApplicationArrayDataType defines attribute ApplicationArray-
DataType.dynamicArraySizeProfile.
• ApplicationArrayDataType aggregates an ApplicationArrayElement
that defines attribute ApplicationArrayElement.arraySizeHandling.
c(RS_SWCT_03181)
[TPS_SWCT_01645] Definition of a “new-world” variable-size array data type by
means of an ImplementationDataType d An ImplementationDataType that
fulfills all of the following conditions shall be considered an “new-world” dynamic-size
array data type.
• The ImplementationDataType defines attribute Implementation-
DataType.dynamicArraySizeProfile.
• ImplementationDataType aggregates an ImplementationDataType-
Element that defines attribute ImplementationDataTypeElement.array-
SizeHandling.
c(RS_SWCT_03181)
In contrast to the first use case described above, the application-motivated Variable-
Size Array Data Type cannot be limited in terms of the base type of the array data
type, i.e. limiting the underlying data type to an unsigned integer data type with a length
of exactly one byte is not an option.
On top of that, several possible structures of Variable-Size Array Data Types
have been required. This aspect is depicted in Figure 2.10.
[TPS_SWCT_01636] Definition of profiles for the definition of Variable-Size
Array Data Types d The possible variants for Variable-Size Array Data
Types are:
Linear The data type of the elements of the Variable-Size Array Data Type
itself does not consist of a Variable-Size Array Data Type.
This case corresponds to the possible value VSA_LINEAR of attribute dynami-
cArraySizeProfile.
Square The data type of the elements of the Variable-Size Array Data Type
itself consists of Variable-Size Array Data Types where the maximum
number of elements in all “second order” arrays is identical to the maximum
number of elements in the “first order” array.
This case corresponds to the possible value VSA_SQUARE of attribute dynami-
cArraySizeProfile.
Rectangular The data type of the elements of the Variable-Size Array Data
Type itself consists of Variable-Size Array Data Types data types where

64 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

the maximum number of elements in “second order” arrays is identical but this
value is typically not identical3 to the maximum number of elements in the “first
order” array.
This case corresponds to the possible value VSA_RECTANGULAR of attribute dy-
namicArraySizeProfile.
Fully Flexible The data type of the elements of the Variable-Size Array Data
Type itself consists of Variable-Size Array Data Types where the maxi-
mum number of elements in “second order” arrays is not necessarily identical
with each other and (obviously) not necessarily identical to the maximum num-
ber of elements in the “first order” array.
This case corresponds to the possible value VSA_FULLY_FLEXIBLE of attribute
dynamicArraySizeProfile.
c(RS_SWCT_03181)
The described cases directly correspond to the portrayal of different kinds of variable-
size arrays in Figure 2.10:
• The value VSA_LINEAR corresponds to the tag (a).
• The value VSA_SQUARE corresponds to the tag (b).
• The value VSA_RECTANGULAR corresponds to the tag ca).
• The value VSA_FULLY_FLEXIBLE corresponds to the tag (d).

(a) (b) (c) (d)

Figure 2.10: Structural variety of array data types with variable size

Please note that the leaf elements in a Variable-Size Array Data Type doesn’t
have to be primitive data types. As mentioned before, it is possible to define multiple-
dimension Variable-Size Array Data Types.
The “terminal” elements can be recognized as such in that they don’t establish further
Variable-Size Array Data Types.
3
If it was, the case boils down to the rectangular scenario tagged (b).

65 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Please note further that the modeling of Variable-Size Array Data Types is a
complex step governed by a collection of rules and constraints.
It is the expressed intent of this specification to keep the complexity of the rule set as
low as possible while still providing the user with a powerful modeling framework.
The major consequence of this conclusion is to keep the modeling as straightforward
as possible; in other words: intentionally cut away certain modeling variants for which
acceptable workarounds within the modeling framework itself exist.
One concrete example for such a restriction is that for ImplementationDataTypes,
Variable-Size Array Data Types can only be defined on the level of an Au-
tosarDataType.
It is intentionally not supported to define a Variable-Size Array Data Type on
the level of an ImplementationDataTypeElement because the intended seman-
tics can be realized by assigning the value TYPE_REFERENCE to the Implemen-
tationDataTypeElement.category and then let it reference to another Imple-
mentationDataType that in turn implements the Variable-Size Array Data
Type.

2.8.2 Modeling Aspects regarding Application Data Types

In the context of the AUTOSAR layered data type concept, the level of Application-
DataTypes is not concerned about the structure of how the Variable-Size Array
Data Types.
In other words, aspects of the implementation of this kind of data type is intentionally
abstracted as much as possible in order to support the idea behind the definition of
ApplicationDataTypes as a concept that is independent from an implementation
to the applicable degree.
Consequently, the support for Variable-Size Array Data Types on the level of
ApplicationDataTypes requires the addition of a couple of additional attributes.
Details can be found in chapter 5.2.4.2.
If a Variable-Size Array Data Type is modeled on the level of Application-
DataType it is necessary to also provide a companion ImplementationDataType
as well as a DataTypeMap that refers to both the ApplicationDataType and the
ImplementationDataType.
The contrary is not applicable, i.e. it is possible to define a Variable-Size Array
Data Type with only an ImplementationDataType, see [TPS_SWCT_01622].

66 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

2.8.3 Modeling Aspects regarding Implementation Data Types

On the other hand, the data type used for the actual hosting of the Variable-
Size Array Data Type corresponds directly to the level of the Implementation-
DataType.
Here, it is possible to define how an ImplementationDataType can be used to
define a Variable-Size Array Data Type.
The definition of ImplementationDataType in the AUTOSAR meta-model comes
with a certain level of generic nature the support for Variable-Size Array Data
Types on this level comes as a mixture of dedicated attributes in the meta-model and
a set of recipes how to support different use cases of Variable-Size Array Data
Types.
This means that the definition of ImplementationDataTypes for the purpose of
creating Variable-Size Array Data Types only has a chance to take off if the
structure of these data types is replicated in different implementations of AUTOSAR
software.
Therefore, AUTOSAR defines a common way of how ImplementationDataTypes
for the purpose of creating Variable-Size Array Data Types shall be defined
such that the ImplementationDataType shall be of category STRUCTURE with
the following sub-elements:
1. A numerical value that determines the actual size. This element shall be called
the Size Indicator throughout this document.
2. An array of the base-type of the Variable-Size Array Data Type that im-
plements the payload of the Variable-Size Array Data Type. The dimen-
sion of the array shall be defined such that the intended maximum number of
elements fits in.
A Size Indicator of a Variable-Size Array Data Type holds the number of
valid elements of the array. This information is necessary for the RTE to handle the
array efficiently.
On the sender-side this indicator is actively updated by the software-component which
is the only instance that knows how many elements of the array are valid.
So the number of valid elements and the Size Indicator have to be kept consistent
by the application. When the software-component sends the data over the RTE the
RTE hands the data over to the transformer.
The transformer may evaluate the Size Indicator (depends on the transformer)
and only work on the valid array elements. The output of the transformer can vary in
length and only contain necessary data. Therefore it can be more resource saving.
On the receiver side, the last transformer in the execution order restores the data ele-
ments of the array and the value of the Size Indicator. This output is handed over

67 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

by the RTE to the software-component. The application now is aware of the number of
valid elements in the array.
The details of how ImplementationDataTypes need to be modeled for the imple-
mentation of Variable-Size Array Data Types can be found in chapter 5.2.5
and a couple of examples is available in the appendix E.1.

2.9 Optional Elements in Structures

2.9.1 Background

The AUTOSAR classic platform supports the usage of a TLV4 data encoding on the
SOME/IP transport layer. TLV is typically used where at least a part of the transmitted
data is only optionally existing and filled with meaningful values.
In other words: an optional part of a data structure may exist and carry meaningful val-
ues in one instance of data transmission and be completely missing in another instance
of the data transmission.
The receiving software needs to be able to identify whether the optional part exists and
read its value accordingly.
The receiving software also needs to be able to still execute in a meaningful way if
the optional part of such a data structure does not exist in the specific communication
instance.
Consequently, it is necessary to be able to precisely identify the parts of a data struc-
ture that may become optional for specific instances of data transmission.
In terms of the AUTOSAR meta-model, the identification could - in principle - be at-
tached at various levels of abstraction:
AutosarDataType In this case the optionality that is only needed for communication
purposes would still be existing in all other usages of data types. This seems
unbalanced.
Admittedly, the definition of different optionality configurations for the same data
type may lead to the existence of a bunch of structurally identical data types that
only vary in terms of optionality. The existence of variation points may help to
mitigate this effect, though.
PortInterface In this case the optionality is defined where it is actually required.
However, different optionality could - in principle - be defined for DataProto-
types typed by the same AutosarDataType.
This would lead to an increased effort for the definition of C data types in the
context of the same PortInterface.
4
This abbreviation stands for tag-length-value

68 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Additional constraints have been identified in the context of the definition of RTE
APIs of the AUTOSAR classic platform that finally render this option as not viable.
ComSpec In this case (for more information please refer to section 4.5) the definition
of optionality would even be more specific in comparison to the definition of op-
tionality on the level of PortInterfaces.
On top of that, the task to define optionality in the vast majority of cases is done by
an OEM, whereas the model definition on the level of ComSpec requires the exis-
tence of SwComponentTypes and this definition is in many cases in the domain
of a supplier.
As a result of this consideration, AUTOSAR has opted for implementation of the con-
cept of defining the optionality on the level of the AutosarDataType.

69 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

3 Overview: Software Components, Ports, and

Interfaces

3.1 Introduction
The detailed introduction of all aspects of the Software Component Template in
one move is considered too complex. This chapter therefore provides an overview
of the main conceptual aspects of software components, ports and interfaces. The
overview will then be broken down into further details in chapter 4.
One of the goals of the AUTOSAR concept is the support of re-usability on the level of
application software. In other words: it should be possible to re-use existing artifacts to
create further model elements instead of being forced to create every single modeling
detail from scratch. One of the consequences of this approach is the application of the
so-called type-prototype pattern [11].
Among other things, this concept allows for creating hierarchical structures of software-
components with arbitrary complexity. However, the creation of hierarchical structures
itself does not have an impact on the run-time behavior of the overall system. The
actual behavior is completely defined within the individual software-components.
This conclusion is backed by the understanding that software-components are devel-
oped against the so-called Virtual Functional Bus (VFB), an abstract communication
channel without direct dependency on ECUs and communication buses. The VFB does
not provide any means for expressing a hierarchy of software-components.
Of course, the usage of the VFB has further consequences on the design of software-
components which shall not directly call the operating system or the communication
hardware. As a result, software-components can be deployed to actual ECUs at a
rather late stage in the development process.
In order to make the description more precise, the following text preferably uses accu-
rate meta-model terms instead of the rather vague terminology of “composition” and
“software-component”.

3.2 Software Component

3.2.1 Overview

Application software within AUTOSAR is organized in self-contained units called Atom-

icSwComponentTypes. Such AtomicSwComponentTypes encapsulate the imple-
mentation of their functionality and behavior and merely expose well-defined connec-
tion points, called PortPrototypes, to the outside world.

70 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Figure 3.1: Graphical representation of software-components in AUTOSAR

The graphical appearance of AUTOSAR software-components according to [3] is de-

picted in Figure 3.1.
Class SwComponentType (abstract)
Package M2::AUTOSARTemplates::SWComponentTemplate::Components
Note Base class for AUTOSAR software components.
Base ARElement, ARObject, AtpBlueprint, AtpBlueprintable, AtpClassifier , AtpType, CollectableElement,
Identifiable, MultilanguageReferrable, PackageableElement, Referrable
Subclasses AtomicSwComponentType, CompositionSwComponentType, ParameterSwComponentType
Attribute Type Mul. Kind Note
consistency ConsistencyNeeds * aggr This represents the collection of ConsistencyNeeds
Needs owned by the enclosing SwComponentType.
Stereotypes: atpSplitable; atpVariation
Tags: atp.Splitkey=shortName, variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
port PortPrototype * aggr The PortPrototypes through which this SwComponent
Type can communicate.
The aggregation of PortPrototype is subject to variability
with the purpose to support the conditional existence of
PortPrototypes.
Stereotypes: atpSplitable; atpVariation
Tags: atp.Splitkey=shortName, variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
portGroup PortGroup * aggr A port group being part of this component.
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime
swComponent SwComponent 0..1 aggr This adds a documentation to the SwComponentType.
Documentation Documentation
Stereotypes: atpSplitable; atpVariation
Tags: atp.Splitkey=swComponentDocumentation,
variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
xml.sequenceOffset=-10
5

71 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4
Class SwComponentType (abstract)
unitGroup UnitGroup * ref This allows for the specification of which UnitGroups are
relevant in the context of referencing SwComponentType.

Table 3.1: SwComponentType

3.2.2 PortPrototype

Please note that PortPrototypes of a SwComponentType are supposed to be used

for attaching SwConnectors that establish an actual connection between SwCompo-
nentPrototypes (see chapter 3.3).
[TPS_SWCT_01002] SwComponentTypes may only interact by means of their
PortPrototypes d AtomicSwComponentTypes (and also the more general
SwComponentTypes may only interact by means of their PortPrototypes). Hidden
communication dependencies that are not expressed by means of PortPrototypes
are strictly forbidden. c(RS_SWCT_00020, RS_SWCT_00030, RS_SWCT_00150,
RS_SWCT_00160, RS_SWCT_00200, RS_SWCT_00210, RS_SWCT_02010,
RS_SWCT_02030)
Therefore, software-components are in theory exchangeable as long as they imple-
ment the same functionality and provide the same public communication interface to
the remaining system.
Class PortPrototype (abstract)
Package M2::AUTOSARTemplates::SWComponentTemplate::Components
Note Base class for the ports of an AUTOSAR software component.
The aggregation of PortPrototypes is subject to variability with the purpose to support the conditional
existence of ports.
Base ARObject, AtpBlueprintable, AtpFeature, AtpPrototype, Identifiable, MultilanguageReferrable, Referrable
Subclasses AbstractProvidedPortPrototype, AbstractRequiredPortPrototype
Attribute Type Mul. Kind Note
clientServer ClientServerAnnotation * aggr Annotation of this PortPrototype with respect to
Annotation client/server communication.
delegatedPort DelegatedPort 0..1 aggr Annotations on this delegated port.
Annotation Annotation
ioHwAbstraction IoHwAbstractionServer * aggr Annotations on this IO Hardware Abstraction port.
Server Annotation
Annotation
modePort ModePortAnnotation * aggr Annotations on this mode port.
Annotation
nvDataPort NvDataPortAnnotation * aggr Annotations on this non voilatile data port.
Annotation
parameterPort ParameterPort * aggr Annotations on this parameter port.
Annotation Annotation
senderReceiver SenderReceiver * aggr Collection of annotations of this ports sender/receiver
Annotation Annotation communication.
5

72 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4
Class PortPrototype (abstract)
triggerPort TriggerPortAnnotation * aggr Annotations on this trigger port.
Annotation
Table 3.2: PortPrototype

AtpBlueprintable
AtpPrototype
PortPrototype

AbstractProvidedPortPrototype AbstractRequiredPortPrototype

PPortPrototype PRPortPrototype RPortPrototype

Figure 3.2: Overview of PortPrototype

[TPS_SWCT_01111] PortPrototypes need an additional model artifact, the

PortInterface d Please note that PortPrototypes actually need an additional
model artifact, the PortInterface, for fully describing the details of the PortPro-
totype. c(RS_SWCT_00010)
The concept of the PortInterface as another means for establishing a high degree
of re-usability is described in chapter 3.4.
[TPS_SWCT_01112] Semantics of PortPrototypes d PortPrototypes can have
the following semantics:
• A require-port (in technical terms: RPortPrototype) requires certain services
or data.
• A provide-port (or PPortPrototype) on the other hand provides services or
data.
• A provide-require-port (or PRPortPrototype) combines the ability to provide
and require services or data in one entity.
c(RS_SWCT_03250)
The semantics of PortPrototype is also depicted in Figure 3.2,
[TPS_SWCT_01573] A PRPortPrototype is never considered unconnected
d A PRPortPrototype is never considered unconnected, even if there are no

73 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

SwConnectors actually referring to it. c(RS_SWCT_00010, RS_SWCT_03250,

RS_SWCT_03130)
Please note that [TPS_SWCT_01573] represents the immediate consequence of the
semantics defined in [TPS_SWCT_01112].
[TPS_SWCT_01113] Connecting two PortPrototypes d Two SwComponentPro-
totypes are eventually connected by hooking up a PPortPrototype or PRPort-
Prototype of one SwComponentPrototype to a compatible RPortPrototype or
PRPortPrototype of the other SwComponentPrototypes. c(RS_SWCT_03130,
RS_SWCT_03250)
Please find more information concerning the definition of “compatibility” in section 6.
Class AbstractRequiredPortPrototype (abstract)
Package M2::AUTOSARTemplates::SWComponentTemplate::Components
Note This abstract class provides the ability to become a required PortPrototype.
Base ARObject, AtpBlueprintable, AtpFeature, AtpPrototype, Identifiable, MultilanguageReferrable, Port
Prototype, Referrable
Subclasses PRPortPrototype, RPortPrototype
Attribute Type Mul. Kind Note
requiredCom RPortComSpec * aggr Required communication attributes, one for each
Spec interface element.

Table 3.3: AbstractRequiredPortPrototype

Class AbstractProvidedPortPrototype (abstract)

Package M2::AUTOSARTemplates::SWComponentTemplate::Components
Note This abstract class provides the ability to become a provided PortPrototype.
Base ARObject, AtpBlueprintable, AtpFeature, AtpPrototype, Identifiable, MultilanguageReferrable, Port
Prototype, Referrable
Subclasses PPortPrototype, PRPortPrototype
Attribute Type Mul. Kind Note
providedCom PPortComSpec * aggr Provided communication attributes per interface element
Spec (data element or operation).

Table 3.4: AbstractProvidedPortPrototype

Class RPortPrototype
Package M2::AUTOSARTemplates::SWComponentTemplate::Components
Note Component port requiring a certain port interface.
Base ARObject, AbstractRequiredPortPrototype, AtpBlueprintable, AtpFeature, AtpPrototype, Identifiable,
MultilanguageReferrable, PortPrototype, Referrable
Attribute Type Mul. Kind Note
required PortInterface 1 tref The interface that this port requires, i.e. the port depends
Interface on another port providing the specified interface.
Stereotypes: isOfType

Table 3.5: RPortPrototype

74 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Class PPortPrototype
Package M2::AUTOSARTemplates::SWComponentTemplate::Components
Note Component port providing a certain port interface.
Base ARObject, AbstractProvidedPortPrototype, AtpBlueprintable, AtpFeature, AtpPrototype, Identifiable,
MultilanguageReferrable, PortPrototype, Referrable
Attribute Type Mul. Kind Note
provided PortInterface 1 tref The interface that this port provides.
Interface
Stereotypes: isOfType

Table 3.6: PPortPrototype

Class PRPortPrototype
Package M2::AUTOSARTemplates::SWComponentTemplate::Components
Note This kind of PortPrototype can take the role of both a required and a provided PortPrototype.
Base ARObject, AbstractProvidedPortPrototype, AbstractRequiredPortPrototype, AtpBlueprintable, Atp
Feature, AtpPrototype, Identifiable, MultilanguageReferrable, PortPrototype, Referrable
Attribute Type Mul. Kind Note
provided PortInterface 1 tref This represents the PortInterface used to type the PRPort
Required Prototype
Interface
Stereotypes: isOfType

Table 3.7: PRPortPrototype

75 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

ARElement
AtpBlueprint AtpBlueprintable
AtpBlueprintable +port AtpPrototype
AtpType PortPrototype
«atpVariation,atpSplitable» 0..*
SwComponentType

  
   
 

AbstractRequiredPortPrototype AbstractProvidedPortPrototype

RPortPrototype PRPortPrototype PPortPrototype

«isOfType» «isOfType» «isOfType»

1 1 1
{redefines {redefines {redefines
+requiredInterface atpType} +providedRequiredInterface atpType} +providedInterface atpType}
ARElement
AtpBlueprint
AtpBlueprintable
AtpType
PortInterface

+ isService: Boolean
+ serviceKind: ServiceProviderEnum [0..1]

Figure 3.3: Components and Ports

[TPS_SWCT_01096] PortGroup d PortPrototypes can be logically grouped into

PortGroups. This mechanism is used for implementing mode management features.
c(RS_SWCT_03201)
Further explanations about the semantics of meta-class PortGroup can be found in
chapter 4.6.

3.2.3 AtomicSwComponentType

[TPS_SWCT_01108] Added value of an AtomicSwComponentType d As mentioned

before, the term AtomicSwComponentType is a specific form of the general concept
of the SwComponentType. The added value of an AtomicSwComponentType is that
it can aggregate an InternalBehavior c(RS_SWCT_03040)
More information regarding the semantics of InternalBehavior can be found in
chapter 7.
[TPS_SWCT_01109] Adding the SwcInternalBehavior in a later process step
d The aggregation of SwcInternalBehavior is stereotyped atpSplitable to

76 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

allow for adding the SwcInternalBehavior in a later process step. In other words,
it is possible to completely develop the VFB view of a software-component and later
add more details like InternalBehavior. c()
Class AtomicSwComponentType (abstract)
Package M2::AUTOSARTemplates::SWComponentTemplate::Components
Note An atomic software component is atomic in the sense that it cannot be further decomposed and
distributed across multiple ECUs.
Base ARElement, ARObject, AtpBlueprint, AtpBlueprintable, AtpClassifier , AtpType, CollectableElement,
Identifiable, MultilanguageReferrable, PackageableElement, Referrable, SwComponentType
Subclasses ApplicationSwComponentType, ComplexDeviceDriverSwComponentType, EcuAbstractionSwComponent
Type, NvBlockSwComponentType, SensorActuatorSwComponentType, ServiceProxySwComponent
Type, ServiceSwComponentType
Attribute Type Mul. Kind Note
internalBehavior SwcInternalBehavior 0..1 aggr The SwcInternalBehaviors owned by an AtomicSw
ComponentType can be located in a different physical file.
Therefore the aggregation is «atpSplitable».
Stereotypes: atpSplitable; atpVariation
Tags: atp.Splitkey=internalBehavior, variationPoint.short
Label
vh.latestBindingTime=preCompileTime
symbolProps SymbolProps 0..1 aggr This represents the SymbolProps for the AtomicSw
ComponentType.
Stereotypes: atpSplitable
Tags: atp.Splitkey=shortName

Table 3.8: AtomicSwComponentType

There are several specialized SwComponentTypes to describe specific software-

components used in the different parts of the AUTOSAR Layered Architecture [5]. Fur-
ther details are mentioned in chapter 10 and 11.

77 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

ARElement AtpPrototype
AtpBlueprint SwComponentPrototype
AtpBlueprintable +type
AtpType
1 «isOfType»
SwComponentType {redefines
atpType}

   +component 0..*
   
 «atpVariation,atpSplitable»

AtomicSwComponentType ParameterSwComponentType CompositionSwComponentType

ApplicationSwComponentType NvBlockSwComponentType ComplexDeviceDriverSwComponentType ServiceSwComponentType

EcuAbstractionSwComponentType SensorActuatorSwComponentType ServiceProxySwComponentType

Figure 3.4: Overview of Component Types

The ApplicationSwComponentType is a specialization of AtomicSwComponent-

Type for representing hardware-independent application software. The Parameter-
SwComponentType is a specialization of SwComponentType that can - in contrast to
AtomicSwComponentType - not aggregate SwcInternalBehavior.
The purpose of the NvBlockSwComponentType is described in detail in sec-
tion 11.5.2. The ServiceSwComponentType is described in section 11.3. Further on,
the EcuAbstractionSwComponentType and the ComplexDeviceDriverSwCom-
ponentType are discussed in detail in section 10.
A description of the ServiceProxySwComponentType can be found in section 11.4
while the SensorActuatorSwComponentType is described in section 10.4.
Class ApplicationSwComponentType
Package M2::AUTOSARTemplates::SWComponentTemplate::Components
Note The ApplicationSwComponentType is used to represent the application software.
Tags: atp.recommendedPackage=SwComponentTypes
Base ARElement, ARObject, AtomicSwComponentType, AtpBlueprint, AtpBlueprintable, AtpClassifier , Atp
Type, CollectableElement, Identifiable, MultilanguageReferrable, PackageableElement, Referrable, Sw
ComponentType
Attribute Type Mul. Kind Note
– – – – –
Table 3.9: ApplicationSwComponentType

78 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

3.2.4 ParameterSwComponentType

[constr_1092] ParameterSwComponentType d A ParameterSwComponentType

shall never aggregate a SwcInternalBehavior and also owns exclusively PPort-
Prototypes of type ParameterInterface. c()
However, a ParameterSwComponentType shall have the ability to aggregate In-
stantiationDataDefProps. By this means it is possible to define role-specific
data properties of elements of composite data types used for the definition of calibra-
tion parameters in the scope of a ParameterSwComponentType.
For more information about this aspect please refer to section 7.5.4.
SwComponentType
ParameterSwComponentType

  
   
«atpSplitable» «atpVariation»   «atpSplitable»

+dataTypeMapping 0..* +instantiationDataDefProps 0..* +constantMapping 0..*

ARElement ARElement
InstantiationDataDefProps
AtpBlueprint ConstantSpecificationMappingSet
AtpBlueprintable
DataTypeMappingSet

Figure 3.5: Details of ParameterSwComponentType

3.2.5 Symbolic Name of a Software-Component

Please note that an AtomicSwComponentType manifests itself in the source code of

an RTE into which an instance of the AtomicSwComponentType is deployed. This
implies potential naming conflicts if instances of AtomicSwComponentType that have
identical shortNames are deployed into a specific RTE.
[TPS_SWCT_01110] Symbolic name of a software-component d To mitigate this
potential hazard it is possible to provide the AtomicSwComponentType along with
an accompanying symbolic name that can be used for resolving the name clash. The
symbolic name is provided by means of the attribute symbol of the meta-class Sym-
bolProps owned by AtomicSwComponentType in the role symbolProps. c()
Please note that more information about the symbolic name provided by means of the
attribute symbol of the meta-class SymbolProps owned by AtomicSwComponent-
Type in the role symbolProps can be found in Figure 3.6.
For more detailed information about how SymbolProps can be used to mitigate name
clashes occurring during the integration of software-components on an AUTOSAR
ECU, please refer to [4].

79 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[TPS_SWCT_01000] Usage of attribute symbol of the symbolProps d In par-

ticular, the RTE generator shall take over the value of the attribute symbol of
the symbolProps owned by a given AtomicSwComponentType. If and only if
symbolProps is not defined the RTE generator shall take the shortName of the
AtomicSwComponentType. For the generation of symbols for RunnableEntitys
[TPS_SWCT_01001] shall be observed. c()
[TPS_SWCT_01001] Prefix symbols generated for the RunnableEntity d If and
only if the attribute symbol of a symbolProps owned by an AtomicSwComponent-
Type exists, its value shall also be taken for prefixing the symbols generated for the
RunnableEntitys owned by the AtomicSwComponentType. c()
Note: if symbolProps is not defined the behavior of the RTE generator is fully back-
wards compatible, i.e. existing implementations of RunnableEntitys do not have to
be touched in order to conform with this version of the AUTOSAR standard.
This is a further measure to mitigate the risk of potential name clashes in the RTE
code.
[TPS_SWCT_01635] Naming conventions may support the effectiveness of Sym-
bolProps d Of course, there is a residual risk that even in the presence of Symbol-
Props name clashes may occur.
Therefore, the definition of naming conventions may facilitate the avoidance of name
clashes to the further degree. c(RS_SWCT_00230)
Referrable
ImplementationProps

+ symbol: CIdentifier

SwComponentType SymbolProps
AtomicSwComponentType +symbolProps

«atpSplitable» 0..1

ApplicationSwComponentType NvBlockSwComponentType ComplexDeviceDriverSwComponentType ServiceSwComponentType

EcuAbstractionSwComponentType SensorActuatorSwComponentType ServiceProxySwComponentType

Figure 3.6: Overview of AtomicSwComponentType

80 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

3.3 Composition

3.3.1 Overview

[TPS_SWCT_01032] CompositionSwComponentType d The purpose of an

AUTOSAR CompositionSwComponentType is to allow the encapsulation of spe-
cific functionality by aggregating existing software-components. c(RS_SWCT_00190,
RS_SWCT_02000, RS_SWCT_02020, RS_SWCT_03000)
[TPS_SWCT_01033] Nested definition of CompositionSwComponentTypes d
Since a CompositionSwComponentType is also a SwComponentType, it again may
be aggregated in further CompositionSwComponentTypes. c(RS_SWCT_00190,
RS_SWCT_02000, RS_SWCT_02020, RS_SWCT_03000)
This recursive relation is formally expressed in Figure 3.7.
It is important to understand that while compositions allow for (sub-) system abstrac-
tion, they are solely an architectural element for the implementation of model scalabil-
ity. They simply group existing software-components and thereby take away complexity
when viewing or designing logical software architecture.
ARElement AtpPrototype
AtpBlueprint SwComponentPrototype
AtpBlueprintable +type
AtpType «isOfType»
1
SwComponentType {redefines
atpType}

+component 0..*

CompositionSwComponentType

«atpVariation,atpSplitable»

  
    

Figure 3.7: The recursive relation of software-components and compositions

Therefore, the definition of CompositionSwComponentTypes has no effect on how

software-components interact with the Virtual Functional Bus (VFB). Composition-
SwComponentTypes do not add any new functionality to what is already provided by
the software-components they aggregate.
[TPS_SWCT_01034] CompositionSwComponentTypes do not have any bi-
nary footprint d As the main consequence, CompositionSwComponentTypes
do not have any binary footprint in the ECU software. c(RS_SWCT_00190,
RS_SWCT_02000, RS_SWCT_02020, RS_SWCT_03000)

81 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

3.3.2 SwComponentPrototype

[TPS_SWCT_01035] CompositionSwComponentType aggregates SwCompo-

nentPrototypes d In terms of the AUTOSAR meta-model, a composition of software-
components realized by the meta-class CompositionSwComponentType aggre-
gates SwComponentPrototypes which in turn are typed by a SwComponentType. c
(RS_SWCT_00190, RS_SWCT_02000, RS_SWCT_02020, RS_SWCT_03000)
Please note that a CompositionSwComponentType is also a SwComponentType.
Class CompositionSwComponentType
Package M2::AUTOSARTemplates::SWComponentTemplate::Composition
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 Mul. 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 SwComponentPrototypes is
resolved post-build the deselected SwComponent
Prototypes are still contained in the ECUs build but the
instances are inactive in 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=shortName, variationPoint.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=shortName, variationPoint.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
5

82 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4
Class CompositionSwComponentType
dataType DataTypeMappingSet * ref Reference to the DataTypeMapping to be applied for the
Mapping used ApplicationDataTypes in PortInterfaces.
Background: when developing subsystems it may happen
that ApplicationDataTypes are used on the surface of
CompositionSwComponentTypes. In this case it would be
reasonable to be able to also provide the intended
mapping to the ImplementationDataTypes. However, this
mapping shall be informal and not technically binding for
the implementers 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=shortLabel, variationPoint.shortLabel
vh.latestBindingTime=codeGenerationTime

Table 3.10: 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 Mul. Kind Note
type SwComponentType 1 tref Type of the instance.
Stereotypes: isOfType

Table 3.11: SwComponentPrototype

83 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

ARElement AtpBlueprintable
AtpBlueprint +port AtpPrototype
AtpBlueprintable PortPrototype
AtpType «atpVariation,atpSplitable» 0..*
SwComponentType

  
     

AtpStructureElement
+portGroup Identifiable
«atpVariation» 0..* PortGroup

  
     

AtpStructureElement
CompositionSwComponentType
+connector SwConnector

«atpVariation,atpSplitable» *

  
    

AtpPrototype
+component SwComponentPrototype

«atpVariation,atpSplitable» 0..*

  
    

InstantiationRTEEventProps
+instantiationRTEEventProps
+ shortLabel: Identifier
«atpVariation,atpSplitable» 0..*

  
      

Figure 3.8: Composition and the meta-classes aggregated

[TPS_SWCT_01036] SwComponentPrototype implements a specific role d

Therefore, a SwComponentPrototype implements the usage of a SwComponent-
Type in a specific role. c(RS_SWCT_00190, RS_SWCT_02000, RS_SWCT_02020,
RS_SWCT_03000)
[TPS_SWCT_01037] arbitrary numbers of SwComponentPrototypes can be cre-
ated d In general, arbitrary numbers of SwComponentPrototypes that refer to spe-
cific SwComponentTypes can be created. c(RS_SWCT_00190, RS_SWCT_02000,
RS_SWCT_02020, RS_SWCT_03000)
Example: a SwComponentPrototype “LeftDoorControl” fulfills the role of implement-
ing the SwComponentType “DoorControl” for the left door of a vehicle while the
SwComponentPrototype “RightDoorControl” fulfills the role of the SwComponent-
Type “DoorControl” for the right door.

84 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[TPS_SWCT_01080] Delegation ports d Note that being a SwComponentType,

a CompositionSwComponentType also exposes PortPrototypes to the out-
side world. However, the PortPrototypes are only delegated and do not play
the same role as PortPrototypes attached to AtomicSwComponentTypes. c
(RS_SWCT_03130)
[TPS_SWCT_01081] Implications of being a delegation port d Being a PortPro-
totype attached to a CompositionSwComponentType has the following implica-
tions:
• The delegation has to follow the rules for basic compatibility.
• By creating PortPrototypes on the surface of a specific Composition-
SwComponentType it is explicitly decided whether or not the contents of an “in-
ner” port contained in the CompositionSwComponentType is exposed to the
outside world.
c(RS_SWCT_03130)
Please note that the rules for compatibility are described in chapter 6.
Please note further that the semantics of the delegation of PortPrototypes are sim-
ilar to encapsulation mechanisms like public and private members in object-oriented
programming languages.
One implication of the concept of CompositionSwComponentType is that the appli-
cation software of an entire vehicle eventually is represented by one Composition-
SwComponentType. This so-called top-level composition has a special role in the
context of the AUTOSAR System Template [10].
However, please note that a top-level composition might have (unconnected) Port-
Prototypes in order to allow for reuse as part of another system.
[constr_1035] Recursive definition of CompositionSwComponentType d The re-
cursive definition of a CompositionSwComponentType that eventually contains
a SwComponentPrototype typed by the same CompositionSwComponentType
shall not be feasible. c()

3.3.3 Connectors

[TPS_SWCT_01079] SwConnector d Note that CompositionSwComponentType

also aggregates the abstract meta-class SwConnector for connecting the contained
SwComponentPrototypes among each other. c(RS_SWCT_03130)
More information can be found in Figure 3.8.
CompositionSwComponentTypes contain two kinds of SwConnectors:

85 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

• [TPS_SWCT_01082] AssemblySwConnector d AssemblySwConnectors in-

terconnect PortPrototypes of SwComponentPrototypes that are part of the
CompositionSwComponentType. c(RS_SWCT_03130)
• [TPS_SWCT_01083] DelegationSwConnector d DelegationSwConnec-
tors connect from “inner” PortPrototypes to delegated “outer” PortProto-
types. c(RS_SWCT_03130)
[TPS_SWCT_01084] Outer PortPrototype is referenced by multiple Del-
egationSwConnectors d In the case that an outer PortPrototype is refer-
enced by multiple DelegationSwConnectors the semantic is the multiplica-
tion of the AssemblySwConnectors referencing the outer PortPrototypes.c
(RS_SWCT_03130)
[constr_1086] SwConnector between two specific PortPrototypes d Each pair
of PortPrototypes can only be connected by one and only one SwConnector. c()
In other words, it is not supported to create two different SwConnectors that connect
the same pair of PortPrototypes.
[TPS_SWCT_01638] Existence of SwConnector between two PRPortProto-
types d [constr_1086] applies also in the case that two PRPortPrototypes are con-
nected with each other. In particular, the roles
• AssemblySwConnector.requester
• AssemblySwConnector.provider
• PassThroughSwConnector.providedOuterPort
• PassThroughSwConnector.requiredOuterPort
do not establish a direction in this case. c()
For clarification, [TPS_SWCT_01638] means that the SwConnector represents the
ability for bi-directional communication between the two PRPortPrototypes.
[constr_1087] AssemblySwConnector inside CompositionSwComponentType d
An AssemblySwConnector can only connect PortPrototypes of SwComponent-
Prototypes that are owned by the same CompositionSwComponentType c()
[constr_1088] DelegationSwConnector inside CompositionSwComponent-
Type d A DelegationSwConnector can only connect a PortPrototype of a
SwComponentPrototype that is owned by the same CompositionSwComponent-
Type that also owns the connected delegation PortPrototype. c()
In the context of attaching a DelegationSwConnector to an inner PRPortProto-
type there is some ambiguity to be considered. In particular, from the formal point of
view it would be feasible to use either a PPortInCompositionInstanceRef or a
RPortInCompositionInstanceRef.

86 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

The ability to use one or the other meta-class arbitrarily is considered confusing. There-
fore, [TPS_SWCT_01515] has been defined to remove the unnecessary degree of
freedom.
[TPS_SWCT_01515] PPortInCompositionInstanceRef shall be used for at-
taching DelegationSwConnector to an inner PRPortPrototype d For the im-
plementation of the attachment of a DelegationSwConnector to an inner PRPort-
Prototype the meta-class PPortInCompositionInstanceRef shall be used. c
()
[constr_1100] Unconnected RPortPrototype typed by a DataInterface d For
any element in an unconnected RPortPrototype typed by a DataInterface there
shall be a requiredComSpec that defines an initValue. c()
Class SwConnector (abstract)
Package M2::AUTOSARTemplates::SWComponentTemplate::Composition
Note The base class for connectors between ports. Connectors have to be identifiable to allow references from
the system constraint template.
Base ARObject, AtpClassifier , AtpFeature, AtpStructureElement, Identifiable, MultilanguageReferrable,
Referrable
Subclasses AssemblySwConnector, DelegationSwConnector, PassThroughSwConnector
Attribute Type Mul. Kind Note
mapping PortInterfaceMapping 0..1 ref Reference to a PortInterfaceMapping specifying the
mapping of unequal named PortInterface elements of the
two different PortInterfaces typing the two PortPrototypes
which are referenced by the ConnectorPrototype.

Table 3.12: SwConnector

Class AssemblySwConnector
Package M2::AUTOSARTemplates::SWComponentTemplate::Composition
Note AssemblySwConnectors are exclusively used to connect SwComponentPrototypes in the context of a
CompositionSwComponentType.
Base ARObject, AtpClassifier , AtpFeature, AtpStructureElement, Identifiable, MultilanguageReferrable,
Referrable, SwConnector
Attribute Type Mul. Kind Note
provider AbstractProvidedPort 0..1 iref Instance of providing port.
Prototype
requester AbstractRequiredPort 0..1 iref Instance of requiring port.
Prototype

Table 3.13: AssemblySwConnector

Class DelegationSwConnector
Package M2::AUTOSARTemplates::SWComponentTemplate::Composition
Note A delegation connector delegates one inner PortPrototype (a port of a component that is used inside the
composition) to a outer PortPrototype of compatible type that belongs directly to the composition (a port
that is owned by the composition).
5

87 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4
Class DelegationSwConnector
Base ARObject, AtpClassifier , AtpFeature, AtpStructureElement, Identifiable, MultilanguageReferrable,
Referrable, SwConnector
Attribute Type Mul. Kind Note
innerPort PortPrototype 1 iref The port that belongs to the ComponentPrototype in the
composition
Tags: xml.typeElement=true
outerPort PortPrototype 1 ref The port that is located on the outside of the Composition
Type

Table 3.14: DelegationSwConnector

One specific use case for the application of SwConnectors is exemplified by the fig-
ures 3.9 and 3.11. A specific CompositionSwComponentType exists in two variants
where one (more complex) variant foresees the existence of a SwComponentPro-
totype inside the CompositionSwComponentType (depicted by 3.9) and the other
(because it is implementing a simpler semantics) does not need the SwComponent-
Prototype.

Composition SW Component

Application SW Component

RTO Trigger

RunA1

Figure 3.9: Use case for PassThroughSwConnector (I)

Class PassThroughSwConnector
Package M2::AUTOSARTemplates::SWComponentTemplate::Composition
Note This kind of SwConnector can be used inside a CompositionSwComponentType to connect two
delegation PortPrototypes.
Base ARObject, AtpClassifier , AtpFeature, AtpStructureElement, Identifiable, MultilanguageReferrable,
Referrable, SwConnector
Attribute Type Mul. Kind Note
providedOuter AbstractProvidedPort 1 ref This represents the provided outer delegation Port
Port Prototype Prototype of the PassThroughSwConnector.
requiredOuter AbstractRequiredPort 1 ref This represents the required outer delegation Port
Port Prototype Prototype of the PassThroughSwConnector.

Table 3.15: PassThroughSwConnector

88 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

AtpStructureElement
SwConnector

AssemblySwConnector PassThroughSwConnector DelegationSwConnector

«instanceRef» «instanceRef»

+provider 0..1 +providedOuterPort 1 +outerPort 1 +innerPort 1

AtpBlueprintable
«instanceRef» AbstractProvidedPortPrototype
AtpPrototype
PortPrototype

+requester 0..1 +requiredOuterPort 1

AbstractRequiredPortPrototype

Figure 3.10: Connectors

Without the ability to define a PassThroughSwConnector the second variant could

only be implemented by defining a dummy SwComponentPrototype inside the
CompositionSwComponentType. However, the dummy SwComponentPrototype
would need to define RunnableEntitys that are created for the sole purpose of being
able to shovel the data from (e.g. for sender-receiver communication) RPortProto-
types to PPortPrototypes.
This would not only be cumbersome it would also obviously require additional re-
sources (memory and code) at run-time. Plus, the existence of addition RunnableEn-
titys also unnecessarily increases the propagation delay of information flowing
around inside the ECU.

Composition SW Component

Application SW Component

PortInterfaceMapping

Figure 3.11: Use case for PassThroughSwConnector (II)

89 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[TPS_SWCT_01507] The role of PassThroughSwConnector d PassThrough-

SwConnector can be taken to connect PortPrototypes owned by the same Com-
positionSwComponentType. In other words, PassThroughSwConnector creates
a bypass inside a CompositionSwComponentType form the requiredOuterPort
to the the providedOuterPort (or vice versa) without involving SwComponentPro-
totypes. c()
[constr_1252] Creation of a loop involving a PassThroughSwConnector is not
allowed d A PassThroughSwConnector is not allowed if the required outer Port-
Prototype is directly or indirectly connected to the provided outer PortPrototype
without the placement of a SwComponentPrototype typed by an AtomicSwCompo-
nentType in the chain of SwConnectors. c()
In other words, according to [constr_1252] it is not allowed to create a “infinite loop” by
means of a PassThroughSwConnector and at least one AssemblySwConnector
that connects the requiredOuterPort to the providedOuterPort.

3.3.4 Instantiation-specific RTEEvents

[TPS_SWCT_02507] Instantiation-specific RTEEvents d It is possible to specify

instantiation specific properties of an RTEEvent by applying InstantiationR-
TEEventProps in the role instantiationRTEEventProps.
This allows to use the same ApplicationSwComponentType in different timing sce-
narios. Even if the scheduling is an issue of the SwcInternalBehavior, the instance
specific definition of timing needs to be specified on the level of a Composition-
SwComponentType. c(RS_SWCT_03046, RS_SWCT_03270)
As an example for [TPS_SWCT_02507], please consider a software-component that
implements a closed-loop control algorithm.
This software-component can potentially be deployed to “slow” and “fast” control sce-
narios. As the actual time-base of the control algorithm is derived from the scheduling
implemented in the RTE it obviously facilitates the overall design if the timing can be
defined on “instance” level.

90 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

ARElement
AtpBlueprint
AtpBlueprintable
AtpType
SwComponentType

AtomicSwComponentType CompositionSwComponentType

  
   
  
«atpVariation,atpSplitable» «atpVariation,atpSplitable»

+internalBehavior 0..1 +instantiationRTEEventProps 0..*

InternalBehavior
InstantiationRTEEventProps
SwcInternalBehavior
+ shortLabel: Identifier
+ handleTerminationAndRestart: HandleTerminationAndRestartEnum
+ supportsMultipleInstantiation: Boolean

  
   
«atpVariation,atpSplitable» «atpVariation,atpSplitable»
 

+runnable 0..* +event *

AtpStructureElement AbstractEvent
ExecutableEntity +startOnEvent AtpStructureElement
RunnableEntity RTEEvent «instanceRef»
0..1
+ canBeInvokedConcurrently: Boolean
+ symbol: CIdentifier
+refinedEvent

+waitPoint *

Identifiable
WaitPoint +trigger

+ timeout: TimeValue 1

TimingEvent InstantiationTimingEventProps

+ offset: TimeValue [0..1] + period: TimeValue

+ period: TimeValue

Figure 3.12: Instantiation specific Properties of RTEEvents

Class InstantiationRTEEventProps (abstract)

Package M2::AUTOSARTemplates::SWComponentTemplate::Composition
Note This meta class represents the ability to refine the properties of RTEEvents for particular instances of a
software component.
Base ARObject
Subclasses InstantiationTimingEventProps
Attribute Type Mul. Kind Note
refinedEvent RTEEvent 1 iref This instance ref denotes the Timing Event for which the
period shall be refined on an instance level.
shortLabel Identifier 1 attr The main purpose of the shortLabel is to contribute to the
splitkey of aggregations that are «atpSplitable».

Table 3.16: InstantiationRTEEventProps

91 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[constr_1233] InstantiationTimingEventProps shall only reference

TimingEvent d An InstantiationTimingEventProps shall only reference
TimingEvent in the role refinedEvent. A reference to other kinds of RTEEvents
is not supported. c()

3.4 Port Interface

[TPS_SWCT_01025] The role of PortPrototypes in the AUTOSAR architecture
d A PortPrototype mainly contributes the functionality of being a connection point
to the AUTOSAR concept.
The details, i.e. with respect to what kind of information is actually transported between
two PortPrototypes is defined by the PortInterface. c(RS_SWCT_00010,
RS_SWCT_00080, RS_SWCT_00110, RS_SWCT_02030, RS_SWCT_03010)
[TPS_SWCT_01026] The role of PortInterfaces in the AUTOSAR architec-
ture d PortInterfaces are used to support a design-by-contract work-flow, i.e.
a PortInterface provides means to formally verify structural and dynamic com-
patibility between software-components. c(RS_SWCT_00010, RS_SWCT_00080,
RS_SWCT_00110, RS_SWCT_02030, RS_SWCT_03010)
In other words: PortInterfaces (see Figure 3.14) represent a pivotal point in the
AUTOSAR concept.
Please note that a PortInterface creates a name space for the information con-
tained. This allows for defining the details of a specific PortInterface without hav-
ing to care for possible side-effects on other PortInterfaces. Again, this property
of the AUTOSAR concept directly supports re-usability.
[TPS_SWCT_01027] Different flavors of PortInterfaces d Within the AUTOSAR
concept, different flavors of PortInterfaces are defined:
• SenderReceiverInterface
• NvDataInterface
• ParameterInterface
• ModeSwitchInterface
• ClientServerInterface
• TriggerInterface
c(RS_SWCT_00010, RS_SWCT_00080, RS_SWCT_00110, RS_SWCT_02030)
[TPS_SWCT_01069] DataInterface is defined as abstract base class d
Please note that the conceptual relationship of SenderReceiverInterface, Nv-
DataInterface, and ParameterInterface is expressed by the definition of
the abstract base class DataInterface. c(RS_SWCT_00010, RS_SWCT_00080,
RS_SWCT_00110, RS_SWCT_03010)

92 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

ARElement
AtpBlueprint
AtpBlueprintable
AtpType
PortInterface

+ isService: Boolean
+ serviceKind: ServiceProviderEnum [0..1]

DataInterface

ParameterInterface NvDataInterface SenderReceiverInterface

Figure 3.13: DataInterface as an abstract base class

Please find more details about the specialization of the PortInterface concept in
chapter 4.2.3 and 4.2.2.
Class PortInterface (abstract)
Package M2::AUTOSARTemplates::SWComponentTemplate::PortInterface
Note Abstract base class for an interface that is either provided or required by a port of a software component.
Base ARElement, ARObject, AtpBlueprint, AtpBlueprintable, AtpClassifier , AtpType, CollectableElement,
Identifiable, MultilanguageReferrable, PackageableElement, Referrable
Subclasses ClientServerInterface, DataInterface, ModeSwitchInterface, TriggerInterface
Attribute Type Mul. Kind Note
isService Boolean 1 attr This flag is set if the PortInterface is to be used for
communication between an
• ApplicationSwComponentType or
• ServiceProxySwComponentType or
• SensorActuatorSwComponentType or
• ComplexDeviceDriverSwComponentType
• ServiceSwComponentType
• EcuAbstractionSwComponentType
and a ServiceSwComponentType (namely an
AUTOSAR Service) located on the same ECU.
Otherwise the flag is not set.
serviceKind ServiceProviderEnum 0..1 attr This attribute provides further details about the nature of
the applied service.

Table 3.17: PortInterface

93 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Class DataInterface (abstract)

Package M2::AUTOSARTemplates::SWComponentTemplate::PortInterface
Note The purpose of this meta-class is to act as an abstract base class for subclasses that share the
semantics of being concerned about data (as opposed to e.g. operations).
Base ARElement, ARObject, AtpBlueprint, AtpBlueprintable, AtpClassifier , AtpType, CollectableElement,
Identifiable, MultilanguageReferrable, PackageableElement, PortInterface, Referrable
Subclasses NvDataInterface, ParameterInterface, SenderReceiverInterface
Attribute Type Mul. Kind Note
– – – – –
Table 3.18: DataInterface

[TPS_SWCT_01070] PortInterface acts as a type for a PortPrototype d From

an abstract point of view, a PortInterface acts as a type for a PortProto-
type. This means in particular that several PortPrototypes can be typed by the
same PortInterface. c(RS_SWCT_00010, RS_SWCT_00080, RS_SWCT_00110,
RS_SWCT_03010)
Of course, this aspect facilitates the creation of valid connections between software-
components dramatically. By using a specific PortInterface for typing particular
PortPrototypes the latter are eligible for being connected to each other by definition.

94 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

ARElement
AtpBlueprint ImplementationProps
AtpBlueprintable SymbolProps
AtpType
PortInterface

ModeSwitchInterface TriggerInterface ClientServerInterface

«atpVariation»

+modeGroup 1 +trigger 1..* +operation 1..*

AtpPrototype AtpStructureElement AtpStructureElement

ModeDeclarationGroupPrototype Identifiable Identifiable
  
Trigger ClientServerOperation    
  

DataInterface «atpVariation»
*
+argument {ordered}
AutosarDataPrototype
ArgumentDataPrototype

ParameterInterface SenderReceiverInterface NvDataInterface

+parameter 1..* +dataElement 1..* +nvData 1..*

AutosarDataPrototype AutosarDataPrototype
ParameterDataPrototype VariableDataPrototype

Figure 3.14: PortInterfaces in the AUTOSAR meta-model

However, the creation of a valid connection does not need to be based on the usage of
identical PortInterfaces. It is also possible to use different, but compatible Port-
Interfaces. The details about compatibility of PortInterfaces are described in
chapter 6.
[constr_1036] Connect kinds of PortInterfaces d It shall not be possible to con-
nect PortPrototypes typed by PortInterfaces of different kinds. Subclasses of
DataInterface make an exception from this rule and can be used for creating con-
nections to each other. c()
For clarification, a connection between a PortPrototype typed by a Sender-
ReceiverInterface and a PortPrototype typed by a ClientServerInter-
face shall not be possible. However, the creation of a connection between a Port-
Prototype typed by a SenderReceiverInterface and a PortPrototype typed
by a ParameterInterface is supported.

95 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[constr_1137] Applicability of ParameterInterface d A PPortPrototype typed

by a ParameterInterface can only be owned by a ParameterSwComponent-
Type. c()
Please note that PortInterfaces also play an important role in the context of defin-
ing so-called AUTOSAR services. In particular, by means of the attribute isService
a PortInterface can define whether or not it is supposed to be used in the context
of an AUTOSAR service and in addition to this it may define (by means of the attribute
serviceKind) what kind of service is intended.
ARElement «enumeration»
AtpBlueprint ServiceProviderEnum
AtpBlueprintable
AtpType basicSoftwareModeManager
PortInterface comManager
cryptoServiceManager
+ isService: Boolean diagnosticCommunicationManager
+ serviceKind: ServiceProviderEnum [0..1] diagnosticEventManager
diagnosticLogAndTrace
ecuManager
functionInhibitionManager
nonVolatileRamManager
syncBaseTimeManager
watchDogManager
anyStandardized
vendorSpecific
operatingSystem
defaultErrorTracer
secureOnBoardCommunication
j1939RequestManager

Figure 3.15: PortInterfaces and AUTOSAR services

The information contained in serviceKind can be used in various ways. The primary
intent is to distinguish between the usage of standardized AUTOSAR services from
the usage of a vendor-specific service. This information may have an impact on the
development- and build process of software-components that use the PortInter-
face.
In addition, it is also possible to use the information contained in serviceKind for
filtering the presentation of an AUTOSAR model in an AUTOSAR authoring tool and
e.g. display the nature of the service PortPrototypes independently of the content
of the corresponding PortInterface.
[TPS_SWCT_01003] Inconsistencies regarding the value of serviceKind and
the actual implementation of the PortInterface d In case of inconsistencies
between the value of serviceKind and the actual implementation of the PortIn-
terface the implementation of the PortInterface wins over the value of attribute
PortInterface.serviceKind (which, for the intended purpose shall be considered
an annotation rather than a semantically binding information). c()
[TPS_SWCT_01004] Default value if serviceKind is not defined d if the attribute
serviceKind is not defined in the context of a specific PortInterface the default
value anyStandardized shall be assumed. c()
[constr_1174] PortInterfaces used in the context of CompositionSwCompo-
nentTypes cannot refer to AUTOSAR services d CompositionSwComponent-
Types shall not own PortPrototypes typed by PortInterfaces where the at-
tribute isService is set to true. c()

96 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Enumeration ServiceProviderEnum
Package M2::AUTOSARTemplates::CommonStructure::ServiceNeeds
Note This represents a list of possible service providers
Literal Description
anyStandardized This value means that the specific nature is either unknown or it is not important for the given
purpose. This is also the default value for any attribute of type ServiceProviderEnum
Tags: atp.EnumerationValue=0
basicSoftwareMode The service relates to the Basic Software Mode Manager (BswM)
Manager
Tags: atp.EnumerationValue=1
comManager The service relates to the COM Manager (ComM).
Tags: atp.EnumerationValue=2
cryptoService The service relates to the Crypto Service Manager (CsM).
Manager
Tags: atp.EnumerationValue=3
defaultErrorTracer The service relates to the Default Error Tracer (DET)
Tags: atp.EnumerationValue=4
diagnostic The service relates to the Diagnostic Communication Manager (DCM).
Communication
Tags: atp.EnumerationValue=6
Manager
diagnosticEvent The service relates to the Diagnostic Event Manager (DEM).
Manager
Tags: atp.EnumerationValue=7
diagnosticLogAnd The service relates to the Diagnostic Log and Trace (DLT).
Trace
Tags: atp.EnumerationValue=8
ecuManager The service relates to the ECU Manager (EcuM).
Tags: atp.EnumerationValue=9
functionInhibition The service relates to the Function Inhibition Manager (FIM).
Manager
Tags: atp.EnumerationValue=10
j1939Request The service relates to the J1939Rm.
Manager
Tags: atp.EnumerationValue=11
nonVolatileRam The service relates to the Non-Volatile RAM Manager (NvM).
Manager
Tags: atp.EnumerationValue=12
operatingSystem The service relates to the Operating System (OS).
Tags: atp.EnumerationValue=13
secureOnBoard The service relates to the SecOc module.
Communication
Tags: atp.EnumerationValue=14
syncBaseTime The service relates to the Sync Time Base Manager (StbM).
Manager
Tags: atp.EnumerationValue=15
vendorSpecific This value denotes a vendor-specific service.
Tags: atp.EnumerationValue=16
watchDogManager The service relates to the Watchdog Manager (WdgM).
Tags: atp.EnumerationValue=17

Table 3.19: ServiceProviderEnum

Please find more details about the relation of PortInterfaces to AUTOSAR services
in chapter 11.

97 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4 Details: Software Components, Ports, and

Interfaces

4.1 Introduction
The specification of the Virtual Functional Bus (VFB) [3] explains the main commu-
nication paradigms for communication among software-components: client/server for
operation-based communication, and sender/receiver for data-based communication.
The nature of the two communication paradigms is quite different, and so is the mod-
eling of SenderReceiverInterfaces and ClientServerInterfaces and their
related meta-classes.
[TPS_SWCT_01516] PortInterface describes the static structure of informa-
tion interchange d PortInterfaces are limited to the description of the static
structure of the exchanged information; the dynamic attributes relevant for commu-
nication are attached to PortPrototypes. c(RS_SWCT_00010, RS_SWCT_00080,
RS_SWCT_00110, RS_SWCT_02030, RS_SWCT_03010)
Please note that the dynamic attributes relevant for communication are described in
chapter 4.5.

4.2 Port Interface Details

4.2.1 Introduction

The usage of value encodings (for more information please refer to section 5.2.6) is
limited within the context of PortInterfaces.
[constr_1045] Supported value encodings for SwBaseType in the context of
PortInterfaces d The supported value encodings for the usage within a Port-
Interface are:
• 2C: Two’s complement
• IEEE754: floating point numbers
• ISO-8859-1: single-byte coded character
• ISO-8859-2: single-byte coded character
• WINDOWS-1252: single-byte coded character
• UTF-8: UCS Transformation Format 8
• UTF-16: Character encoding for Unicode code points based on 16 bit code
units [15]
• UCS-2: Universal Character Set 2

98 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

• NONE: Unsigned Integer

• BOOLEAN: This represents an integer to be interpreted as boolean.
c()
[constr_1046] Applicability of [constr_1045] d [constr_1045] applies only if the
value of the attribute isService is set to false. c()
[constr_1295] PortInterfaces and category DATA_REFERENCE d A DataPro-
totype defined in the context of a PortInterface used by an Application-
SwComponentType or SensorActuatorSwComponentType that is (after potential
indirections via TYPE_REFERENCE are resolved) either typed by or mapped to an Im-
plementationDataType of category DATA_REFERENCE shall only be used if ei-
ther the provider or the requester of the information represents a ServiceSwCompo-
nentType, a ComplexDeviceDriverSwComponentType, a ParameterSwCom-
ponentType, or an NvBlockSwComponentType, or the EcuAbstractionSwCom-
ponentType. c()
Note: [constr_1295] corresponds to [SWS_RTE_07670].

4.2.2 Sender Receiver Communication

[TPS_SWCT_01114] SenderReceiverInterface d SenderReceiverInter-

faces allow for the specification of the typically asynchronous communication pattern
where a sender provides data that is required by one or more receivers.
While the actual communication takes place via the respective PortPrototypes, a
SenderReceiverInterface allows for formally describing what kind of information
is sent and received. c()
Class SenderReceiverInterface
Package M2::AUTOSARTemplates::SWComponentTemplate::PortInterface
Note A sender/receiver interface declares a number of data elements to be sent and received.
Tags: atp.recommendedPackage=PortInterfaces
Base ARElement, ARObject, AtpBlueprint, AtpBlueprintable, AtpClassifier , AtpType, CollectableElement,
DataInterface, Identifiable, MultilanguageReferrable, PackageableElement, PortInterface, Referrable
Attribute Type Mul. Kind Note
dataElement VariableDataPrototype 1..* aggr The data elements of this SenderReceiverInterface.
invalidation InvalidationPolicy * aggr InvalidationPolicy for a particular dataElement
Policy

Table 4.1: SenderReceiverInterface

99 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Class InvalidationPolicy
Package M2::AUTOSARTemplates::SWComponentTemplate::PortInterface
Note Specifies whether the component can actively invalidate a particular dataElement.
If no invalidationPolicy points to a dataElement this is considered to yield the identical result as if the
handleInvalid attribute was set to dontInvalidate.
Base ARObject
Attribute Type Mul. Kind Note
dataElement VariableDataPrototype 1 ref Reference to the dataElement for which the Invalidation
Policy applies.
handleInvalid HandleInvalidEnum 0..1 attr This attribute controls how invalidation is applied to the
dataElement.
Table 4.2: InvalidationPolicy

Enumeration HandleInvalidEnum
Package M2::AUTOSARTemplates::SWComponentTemplate::Communication
Note Strategies of handling the reception of invalidValue.
Literal Description
dontInvalidate Invalidation is switched off.
Tags: atp.EnumerationValue=0
external Replace a received invalidValue. The replacement value is sourced from the externalReplacement.
Replacement
Tags: atp.EnumerationValue=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.EnumerationValue=2
replace Replace a received invalidValue. The replacement value is specified by the initValue.
Tags: atp.EnumerationValue=3

Table 4.3: HandleInvalidEnum

A SenderReceiverInterface focuses on the description of information items rep-

resented by VariableDataPrototypes (see section 5.3).
A VariableDataPrototype aggregated in the role of dataElement represents
an atomic1 piece of information transmitted among PortPrototypes typed by a
SenderReceiverInterface.
[TPS_SWCT_01115] invalidationPolicy d An invalidationPolicy specifies
whether the sending component can actively invalidate a particular dataElement and
which strategy of handling the reception of invalidValue on the receiver side shall
be implemented. c()
Further information about the related concept of an invalidValue is provided in
chapter 5.4.2
1
Note that the term “atomic” does not have any implication on the implementation on a concrete
computing platform

100 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

ARElement
AtpBlueprint
AtpBlueprintable
AtpType
PortInterface

+ isService: Boolean
+ serviceKind: ServiceProviderEnum [0..1]

DataPrototype
DataInterface
AutosarDataPrototype

SenderReceiverInterface VariableDataPrototype
+dataElement

1..*

+invalidationPolicy 0..*

InvalidationPolicy
+dataElement
+ handleInvalid: HandleInvalidEnum [0..1]
1

«enumeration»
HandleInvalidEnum

keep
replace
dontInvalidate
externalReplacement

Figure 4.1: dataElements of a SenderReceiverInterface

Note that a SenderReceiverInterface provides a name space for the definition

of VariableDataPrototypes. In terms of the AUTOSAR meta-model this aspect
is indicated by the inheritance relation to DataPrototype (which in turn inherits from
Identifiable). Please find more information on the creation of name spaces in [11].
[TPS_SWCT_01116] swImplPolicy d The swImplPolicy indicates the way how
a VariableDataPrototype shall be processed at the receiver’s side. If set to
queued the semantics is that the corresponding VariableDataPrototype needs
to be added to a queue (or in other words: a FIFO data structure) from which it is later
consumed by the actual receiver software-component. c()
Please note that the swImplPolicy is described in section 5.4.
[constr_1200] Queued communication is not applicable for dataElements
owned by PRPortPrototype d The swImplPolicy shall not be set to queued for
any dataElement owned by a PRPortPrototype. c()
[TPS_SWCT_01176] last-is-best semantics for sender-receiver communication d
If swImplPolicy is set to any other valid value of SwImplPolicyEnum then last is
best semantics applies. c()

101 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Please note that the definition of VariableDataPrototype may possibly come very
close to the reader’s idea of a signal. However, different kinds of signals have a specific
meaning in the AUTOSAR concept, especially in the context of the AUTOSAR System
Template [10].
[TPS_SWCT_01117] Communication patterns for sender-receiver communica-
tion d PortPrototypes typed by a SenderReceiverInterface may be connected
to establish a 1:n (i.e. one sender, multiple receivers) communication relationship. It
is also possible to establish a n:1 (i.e. many senders, one receiver) communication
pattern. c()
[constr_1033] Communication scenarios for sender/receiver communication d
For sender/receiver communication, it is not allowed to create a communication sce-
nario where n sender are connected to m receivers where m and n are both greater
than 1. c()
Factually, [constr_1033] is not applicable to a scenario where several PRPortPro-
totypes are connected by a chain of AssemblySwConnectors or PassThrough-
SwConnectors.
[constr_1202] Supported connections by AssemblySwConnector for PortPro-
totypes typed by a SenderReceiverInterface or NvDataInterface d For
the modeling of AssemblySwConnectors between PortPrototypes typed by a
SenderReceiverInterface or NvDataInterface, only the connections docu-
mented in Table 4.4 are supported by AUTOSAR. c()
RPortPrototype PPortPrototype PRPortPrototype
RPortPrototype No Yes Yes
PPortPrototype Yes No Yes
PRPortPrototype Yes Yes Yes
Table 4.4: Supported connections for PortPrototypes typed by a Sender-
ReceiverInterface or NvDataInterface

[constr_1203] Supported connections by DelegationSwConnector for Port-

Prototypes typed by a SenderReceiverInterface or NvDataInterface d For
the modeling of DelegationSwConnectors between PortPrototypes typed by a
SenderReceiverInterface or NvDataInterface, only the connections docu-
mented in Table 4.5 are supported by AUTOSAR. c()
innerPort outerPort
RPortPrototype PPortPrototype PRPortPrototype
RPortPrototype Yes No Yes
PPortPrototype No Yes Yes
PRPortPrototype Yes Yes Yes
Table 4.5: Supported connections for PortPrototypes typed by a Sender-
ReceiverInterface or NvDataInterface

102 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4.2.3 Client Server Communication

The underlying semantics of a client/server communication is that a client may initiate

the execution of an operation by a server that supports the operation.
The server executes the operation and, when completed, it provides the client with the
result (synchronous operation call) or else the client checks for the completion of the
operation by itself (asynchronous operation call).
[constr_1037] Client shall not be connected to multiple servers d A client shall not
be connected to multiple servers such that an operation call would be handled by more
than one server. c()

4.2.3.1 Client Server Interface

A ClientServerInterface, to some extent, is a counterpart to the Sender-

ReceiverInterface2 .
Instead of defining pieces of information to be transferred among software-
components, a ClientServerInterface defines a collection of ClientServer-
Operations.
Class ClientServerInterface
Package M2::AUTOSARTemplates::SWComponentTemplate::PortInterface
Note A client/server interface declares a number of operations that can be invoked on a server by a client.
Tags: atp.recommendedPackage=PortInterfaces
Base ARElement, ARObject, AtpBlueprint, AtpBlueprintable, AtpClassifier , AtpType, CollectableElement,
Identifiable, MultilanguageReferrable, PackageableElement, PortInterface, Referrable
Attribute Type Mul. Kind Note
operation ClientServerOperation 1..* aggr ClientServerOperation(s) of this ClientServerInterface.
Stereotypes: atpVariation
Tags: vh.latestBindingTime=blueprintDerivationTime
possibleError ApplicationError * aggr Application errors that are defined as part of this interface.

Table 4.6: ClientServerInterface

2
However, different connection patterns apply, see [constr_1037]

103 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

ARElement
AtpBlueprint
AtpBlueprintable
AtpType
PortInterface

+ isService: Boolean
+ serviceKind: ServiceProviderEnum [0..1]

ClientServerInterface

«atpVariation»

+operation 1..*

AtpStructureElement DataPrototype
Identifiable AutosarDataPrototype
ClientServerOperation

  
   
   «atpVariation»
+argument * {ordered}

ArgumentDataPrototype

«enumeration» + direction: ArgumentDirectionEnum «isOfType»

ArgumentDirectionEnum + serverArgumentImplPolicy: ServerArgumentImplPolicyEnum [0..1]

in
out
inout
1
+type {redefines atpType}
«enumeration»
ServerArgumentImplPolicyEnum ARElement
AtpType
useArgumentType AutosarDataType
useVoid

Figure 4.2: ClientServerOperations of a ClientServerInterface

[TPS_SWCT_01118] ClientServerInterface d A ClientServerInterface is

composed of ClientServerOperations, i.e. a ClientServerOperation cannot
be reused in the context of a different ClientServerInterface c()
[TPS_SWCT_01106] ClientServerOperation d A ClientServerOperation
consists of 0..* ArgumentDataPrototypes. The latter may be
• passed to the operation (i.e. the direction is “in”)
• passed to and returned from the operation (i.e. the direction is “inout”)
• returned from the operation (i.e. the direction is “out”)
The aggregation represents a variation point. c(RS_SWCT_03141)

104 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Class ClientServerOperation
Package M2::AUTOSARTemplates::SWComponentTemplate::PortInterface
Note An operation declared within the scope of a client/server interface.
Base ARObject, AtpClassifier , AtpFeature, AtpStructureElement, Identifiable, MultilanguageReferrable,
Referrable
Attribute Type Mul. Kind Note
argument (or- ArgumentDataPrototype * aggr An argument of this ClientServerOperation
dered)
Stereotypes: atpVariation
Tags: vh.latestBindingTime=blueprintDerivationTime
possibleError ApplicationError * ref Possible errors that may by raised by the referring
operation.

Table 4.7: ClientServerOperation

Class ArgumentDataPrototype
Package M2::AUTOSARTemplates::SWComponentTemplate::PortInterface
Note An argument of an operation, much like a data element, but also carries direction information and is
owned by a particular ClientServerOperation.
Base ARObject, AtpFeature, AtpPrototype, AutosarDataPrototype, DataPrototype, Identifiable, Multilanguage
Referrable, Referrable
Attribute Type Mul. Kind Note
direction ArgumentDirection 1 attr This attribute specifies the direction of the argument
Enum prototype.
serverArgument ServerArgumentImpl 0..1 attr This defines how the argument type of the servers
ImplPolicy PolicyEnum RunnableEntity is implemented.
If the attribute is not defined this has the same semantics
as if the attribute is set to the value useArgumentType for
primitive arguments and structures.

Table 4.8: ArgumentDataPrototype

[TPS_SWCT_01119] Direction of ArgumentDataPrototypes d To cover these

cases, ArgumentDataPrototype defines an attribute direction, possible values
are in (pass to operation), out (return from operation), and inout (pass to and return
from operation). c()
In many common programming languages (like C), an operation is yet another data
type. This makes it for example possible to pass a reference to an operation as an
argument to another operation.
This is not allowed in the AUTOSAR concept.
[TPS_SWCT_01517] ClientServerOperation cannot be passed as a reference
d It is not possible to pass a reference to a ClientServerOperation as an Argu-
mentDataPrototype in another ClientServerOperation. c()
Essentially, all ArgumentDataPrototypes in a ClientServerOperation can be
passed (conceptually) by value (from the client to the server and/or from the server to
the client depending on the direction of the ArgumentDataPrototype).

105 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[TPS_SWCT_01120] Client needs to provide ArgumentDataPrototypes d When

the client invokes an operation, it needs to provide a value for each ArgumentDat-
aPrototype that is of direction in or inout. c()
[TPS_SWCT_01121] Pass correct data type d The value passed to an Argument-
DataPrototype of direction in or inout needs to be of the corresponding
Datatype. c()
[TPS_SWCT_01122] Synchronous call of ClientServerOperation d In the case
of synchronous operation call, the client expects to receive a response to the invocation
of the operation.
As part of the response, it receives a value (of the correct AutosarDataType) for
each ArgumentDataPrototype that is of direction out or inout. c()
Enumeration ArgumentDirectionEnum
Package M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::PrimitiveTypes
Note Use cases:
• Arguments in ClientServerOperation can have different directions that need to be formally
indicated because they have an impact on how the function signature looks like eventually.
• Arguments in BswModuleEntry already determine a function signature, but the direction is
used to specify the semantics, especially of pointer arguments.
Literal Description
in The argument value is passed to the callee.
Tags: atp.EnumerationValue=0
inout The argument value is passed to the callee but also passed back from the callee to the caller.
Tags: atp.EnumerationValue=1
out The argument value is passed from the callee to the caller.
Tags: atp.EnumerationValue=2

Table 4.9: ArgumentDirectionEnum

Each ClientServerOperation provides a name space for its ArgumentDataPro-

totypes and therefore has a unique identifier which identifies the operation within the
corresponding ClientServerInterface.
The ClientServerOperations have no ordering within a ClientServerInter-
face (there is no such thing as the “first” operation)3 .
[TPS_SWCT_01123] No default values for ArgumentDataPrototypes d It is not
possible to define default values for ArgumentDataPrototypes defined in the con-
text of a ClientServerOperation. Default values might lead to complicated map-
pings to programming languages. c()
3
In different parts of the definition of a ClientServerInterface, a “calling-order” of the
ClientServerOperations might be prescribed: the client might be required to use the
ClientServerOperations in a certain logical ordering.
However, this ordering has nothing to do with the order in which the ClientServerOperations are
listed in the definition of a ClientServerInterface

106 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[TPS_SWCT_01124] Definition of ArgumentDataPrototypes within the context

of a ClientServerOperation is ordered d In contrast to the unordered relation-
ship of ClientServerInterface to ClientServerOperation, the definition of
ArgumentDataPrototypes within the context of a ClientServerOperation is
ordered, i.e. a ClientServerOperation may have a first argument4 . c()
Please note that ArgumentDataPrototype inherits from AutosarDataPrototype
and therefore has a reference to a concrete AutosarDataType.
The RTE Generator uses the referred AutosarDataTypes to determine the data
types of the arguments depending on the value of the attribute ArgumentDataPro-
totype.serverArgumentImplPolicy.
Enumeration ServerArgumentImplPolicyEnum
Package M2::AUTOSARTemplates::SWComponentTemplate::PortInterface
Note This defines how the argument type of the servers RunnableEntity is implemented.
Literal Description
useArgumentType The argument type of the RunnableEntity is derived from the AutosarDataType of the Argument
Prototype.
Tags: atp.EnumerationValue=0
useVoid The argument type of the RunnableEntity is void.
Tags: atp.EnumerationValue=2

Table 4.10: ServerArgumentImplPolicyEnum

[constr_1286] serverArgumentImplPolicy and ArgumentDataPrototype

typed by primitive data types d The value of the attribute ArgumentDataProto-
type.serverArgumentImplPolicy shall not be set to useVoid for an Argument-
DataPrototype of direction in that is typed by an AutosarDataType that boils
down to a primitive C data type (see [TPS_SWCT_01565]). c()
Please note that the server RunnableEntity needs information about the currently
used array length respectively structure size by usage of additionally arguments passed
by the Client or via PortDefinedArgumentValue.
Note further that a ClientServerInterface does not define any timing information
(how quickly the client expects a response of the server). It does not define how the
threading works (if the client for example blocks until the response comes back from
the server).
4
Giving the ArgumentDataPrototypes of a ClientServerOperation both an ordering and a
unique identifier might seem redundant.
For example, in the operation “foo(a, b, c)”, we can refer to the “second argument” or to “the argument
named b”. In many common programming languages (like C or Java), only the ordering is actually used
by the client during the invocation of the server (the client invokes the operation as “foo(1,2,3)” not as
“foo(a=1,c=3,b=2)”.
In addition, the names of the arguments represent an arbitrary choice made when implementing of the
invocation. In C, only the data types and ordering of the arguments constitute the signature, not the
names of the arguments.

107 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

It also does not define explicitly how information is passed between an implementation
of the client and the server and the underlying RTE (for example: through “pointers” or
“by value”).
[constr_1204] Supported connections by AssemblySwConnector for Port-
Prototypes typed by a ClientServerInterface, ModeSwitchInterface,
or TriggerInterface d For the modeling of AssemblySwConnectors between
PortPrototypes typed by a ClientServerInterface, ModeSwitchInter-
face, or TriggerInterface, only the connections documented in Table 4.11 are
supported by AUTOSAR. c()
RPortPrototype PPortPrototype PRPortPrototype
RPortPrototype No Yes Yes
PPortPrototype Yes No No
PRPortPrototype Yes No No
Table 4.11: Supported connections for PortPrototypes typed by a
ClientServerInterface, ModeSwitchInterface, or TriggerInterface

[constr_1205] Supported connections by DelegationSwConnector for Port-

Prototypes typed by a ClientServerInterface, ModeSwitchInterface, or
TriggerInterface d For the modeling of DelegationSwConnectors between
PortPrototypes typed by a ClientServerInterface, ModeSwitchInter-
face, or TriggerInterface, only the connections documented in Table 4.12 are
supported by AUTOSAR. c()
innerPort outerPort
RPortPrototype PPortPrototype PRPortPrototype
RPortPrototype Yes No No
PPortPrototype No Yes No
PRPortPrototype No Yes No
Table 4.12: Supported connections for PortPrototypes typed by a
ClientServerInterface, ModeSwitchInterface, or TriggerInterface

4.2.3.2 Error Handling in Client/Server Communication

This section describes the handling of errors occurring either within an application
software-component or during the communication across the VFB [3]. Errors that are
created and consumed by basic software modules are not in the scope of this docu-
ment and therefore will not be discussed.
Therefore, errors in the scope of this document are divided into two simple classes:
• infrastructure errors and
• application errors.

108 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

A software-component implementation uses RTE API methods to communicate with

other software-components. During this communication certain errors can occur as a
result of infrastructure faults, like a bus is not working, or an expected data value was
not arriving in time.
These errors are listed in the RTE specification [2], as they are an inherent feature
of the infrastructure provided by the VFB. Software-components will therefore typically
not raise infrastructure errors on their own.
Instead, the AUTOSAR basic software and the RTE will determine infrastructure faults
and communicate the corresponding error codes to the relevant software-components.
PortInterface
ClientServerInterface

  
   
«atpVariation»   

+operation 1..* +possibleError 0..*

AtpStructureElement Identifiable
Identifiable +possibleError ApplicationError
ClientServerOperation
0..* + errorCode: Integer

Figure 4.3: Application error meta-model

[TPS_SWCT_01491] AUTOSAR system does not need to explicitly describe in-

frastructure errors d As the fixed set of infrastructure errors is defined as an implicit
part of the VFB, a developer of an AUTOSAR system does not need to explicitly de-
scribe these.
It is assumed that these might occur at run-time and application developers should take
measures to handle them. c()
Application errors, on the other hand, are specific to the functionality or information that
is described in form of a PortInterface. It is not possible to define such errors up
front, instead they are defined at design time of a certain PortInterface.
In principle, such ApplicationErrors could be part of all kinds of PortInter-
faces.
[constr_1102] ApplicationError in the scope of one SwComponentType d If
a SwComponentType has PortPrototypes typed by different ClientServerIn-
terfaces with equal shortName and ApplicationErrors defined then the follow-
ing condition applies: ApplicationErrors with the same shortName shall have
identical values of errorCodes. c()
Rationale for the existence of [constr_1102]: the RTE generator creates symbols for
the error codes in which the shortName of the ClientServerInterface and the
shortName of the ApplicationError occur.

109 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[constr_1108] Value of ApplicationError.errorCode d The value of Applica-

tionError.errorCode shall not exceed the closed interval 1 .. 63. The following
exception applies: only in case possibleError is supposed to represent E_OK the
value 0 shall be allowed. c()
By [constr_1108] it is possible to ensure that only the six least significant bits of a return
value shall be used for indicating an application error.
Class ApplicationError
Package M2::AUTOSARTemplates::SWComponentTemplate::PortInterface
Note This is a user-defined error that is associated with an element of an AUTOSAR interface. It is specific for
the particular functionality or service provided by the AUTOSAR software component.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mul. Kind Note
errorCode Integer 1 attr The RTE generator is forced to assign this value to the
corresponding error symbol. Note that for error codes
certain ranges are predefined (see RTE specification).

Table 4.13: ApplicationError

Consequently, ClientServerOperations may be associated with a number of Ap-

plicationErrors they possibly raise. These errors are defined as part of the
ClientServerInterface.
[constr_1038] Reference to ApplicationError d A possibleError referenced
by a ClientServerOperation shall be owned by the PortInterface that also
owns the ClientServerOperation. c()
Please note that the meta-class ApplicationError is also used on the AUTOSAR
adaptive platform (see [16]) and therefore [constr_1038] cannot be more specific about
the nature of the enclosing PortInterface.

4.2.4 External Trigger Event Communication

[TPS_SWCT_01196] Semantics of an external trigger event communication d The

underlying semantics of an external trigger event communication is that a trigger source
may initiate the execution of RunnableEntitys in the connected trigger sinks. Typi-
cally (but not necessarily) these RunnableEntitys are executed in a sequential or-
der. c()
[TPS_SWCT_01197] TriggerInterface d The TriggerInterface defines a set
of Trigger to be communicated between software-components. The Trigger repre-
sents a special kind of events at which occurrence the trigger sinks shall react in a
particular manner. c()

110 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Class TriggerInterface
Package M2::AUTOSARTemplates::SWComponentTemplate::PortInterface
Note A trigger interface declares a number of triggers that can be sent by an trigger source.
Tags: atp.recommendedPackage=PortInterfaces
Base ARElement, ARObject, AtpBlueprint, AtpBlueprintable, AtpClassifier , AtpType, CollectableElement,
Identifiable, MultilanguageReferrable, PackageableElement, PortInterface, Referrable
Attribute Type Mul. Kind Note
trigger Trigger 1..* aggr The Trigger of this trigger interface.

Table 4.14: TriggerInterface

Class Trigger
Package M2::AUTOSARTemplates::CommonStructure::TriggerDeclaration
Note A trigger which is provided (i.e. released) or required (i.e. used to activate something) in the given
context.
Base ARObject, AtpClassifier , AtpFeature, AtpStructureElement, Identifiable, MultilanguageReferrable,
Referrable
Attribute Type Mul. Kind Note
swImplPolicy SwImplPolicyEnum 0..1 attr This attribute, when set to value queued, allows for a
queued processing of Triggers.
triggerPeriod MultidimensionalTime 0..1 aggr Optional definition of a period in case of a periodically
(time or angle) driven external trigger.

Table 4.15: Trigger

Class MultidimensionalTime
Package M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::MultidimensionalTime
Note This is used to specify a multidimensional time value based on ASAM CSE codes. It is specified by a
code which defined the basis of the time and a scaling factor which finally determines the time value.
If for example the cseCode is 100 and the cseCodeFactor is 360, it represents 360 angular degrees.
If the cseCode is 0 and the cseCodeFactor is 50 it represents 50 microseconds.
Base ARObject
Attribute Type Mul. Kind Note
cseCode CseCodeType 1 attr Specifies the time base by means of CSE codes.
cseCodeFactor Integer 1 attr The scaling factor for the time value based on the
specified CSE code.

Table 4.16: MultidimensionalTime

111 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

ARElement
AtpBlueprint
AtpBlueprintable
AtpType
PortInterface

+ isService: Boolean
+ serviceKind: ServiceProviderEnum [0..1]

TriggerInterface

+trigger 1..*

AtpStructureElement
Identifiable
Trigger

+ swImplPolicy: SwImplPolicyEnum [0..1]

+triggerPeriod 0..1

MultidimensionalTime

+ cseCode: CseCodeType
+ cseCodeFactor: Integer

Figure 4.4: Trigger of a TriggerInterface

As illustrated in Figure 4.4, a TriggerInterface is composed of Trigger.

[TPS_SWCT_01198] Period for periodic triggering d A Trigger can optionally de-
fine a period for periodic triggering. It is expressed via the meta-class Multidimen-
sionalTime in terms of time or angle. Note that the main use case for this is to
specify the properties if the trigger is coming from the Basic Software e.g. from a
Complex Driver, it is not used as an input for the RTE generator. c()
Apart from this, a TriggerInterface does not define any timing information (e.g.
how quickly the source expects a reaction of the sinks). This is property of the timing
information in the templates.
[constr_1104] Trigger sink and trigger source d An RPortPrototype typed by
a TriggerInterface shall not be referenced by more than one SwConnectors
that are in turn referencing PPortPrototypes typed by TriggerInterfaces that
contain Triggers with the same shortName. c()
[constr_1104] boils down to the requirement that trigger communication shall not be
implemented in a n:1 scenario.
To be clear, the n:1 scenario is not supported for trigger communication because there
is no active use case for it. Support would require the implementation of queue man-
agement for Trigger communication.
[TPS_SWCT_01199] Queued processing of Triggers d It may happen that at least
tentatively a Trigger source fires Triggers faster than they can be processed on

112 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

the side of the Trigger sink. To support this use case it is possible to process trigger
event communication in a queued manner.
In this case the Triggers are added to a queue from where the foremost trigger is
dequeued and processed when the processing of the current Trigger is done. Please
note that the queue size is not subject to definition in the scope of this document. The
actual queue size is defined during the process of RTE configuration.
The specification of whether or not a Trigger is subject to queued processing is
controlled by the attribute Trigger.swImplPolicy. c()
[constr_1169] Allowed values for Trigger.swImplPolicy d The only allowed val-
ues for the attribute Trigger.swImplPolicy are either STANDARD (in which case the
Trigger processing does not use a queue) or QUEUED (in which case the processing
of Triggers positively uses a queue). c()
Please note that the value of Trigger.swImplPolicy is not the final word on the
implementation of a queue for the specific Trigger. The integrator still has the power
to overrule the application software developer’s verdict if applicable.
For more information regarding the ability to connect different kinds of PortProto-
types typed by a TriggerInterface to each others please refer to [constr_1204]
and [constr_1205].

4.2.5 Communication of Modes

There are two distinctive use cases for the communication of modes via ports:
1. An actual mode transition can be communicated from a mode manager compo-
nent to its client components to enforce a mode switch.
2. A request for a mode transition can be communicated from any component to a
mode manager.
[TPS_SWCT_01087] Propagation of mode information d For communicating a
mode switch (i.e. the first use case), the Software-Component Template describes
the concept of the communication of ModeDeclarationGroupPrototypes simi-
lar to the communication of VariableDataPrototypes but is uses a special type
of PortInterface: the collections of ModeDeclarations that are required or
provided by a SwComponentType are defined by means of ModeSwitchInter-
faces used to type the PortPrototypes owned by the SwComponentType. c
(RS_SWCT_03203)
This aspect is depicted in Figure 4.5.
Due to the strong interaction with the RTE for handling the mode switches, this first use
case does not allow communication across ECU boundaries:
[constr_4000] Local communication of mode switches d Ports with ModeSwitch-
Interfaces cannot be connected across ECU boundaries. c()

113 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[constr_2049] Different ModeDeclarationGroups shall have different short-

Names. d A software component is not allowed to type multiple PortPrototypes
with ModeSwitchInterfaces where the contained ModeDeclarationGroupPro-
totypes are referencing ModeDeclarationGroups with identical shortNames but
different ModeDeclarations. c()
Obviously, the rationale for [constr_2049] is to avoid conflicts in generated RTE files.
For instance:
Two ModeDeclarationGroups with identical shortName “Foo” are defined.
ModeDeclarationGroup “Foo”
contains the ModeDeclarations “X”, “Y”, “Z”
ModeDeclarationGroup “Foo*”
contains the ModeDeclarations “W”, “X”, “Y”, “Z”
In this case a software component is only allowed to use either “Foo” or “Foo*”
Class ModeSwitchInterface
Package M2::AUTOSARTemplates::SWComponentTemplate::PortInterface
Note A mode switch interface declares a ModeDeclarationGroupPrototype to be sent and received.
Tags: atp.recommendedPackage=PortInterfaces
Base ARElement, ARObject, AtpBlueprint, AtpBlueprintable, AtpClassifier , AtpType, CollectableElement,
Identifiable, MultilanguageReferrable, PackageableElement, PortInterface, Referrable
Attribute Type Mul. Kind Note
modeGroup ModeDeclarationGroup 1 aggr The ModeDeclarationGroupPrototype of this mode
Prototype interface.

Table 4.17: ModeSwitchInterface

Class ModeDeclarationGroupPrototype
Package M2::AUTOSARTemplates::CommonStructure::ModeDeclaration
Note The ModeDeclarationGroupPrototype specifies a set of Modes (ModeDeclarationGroup) which is
provided or required in the given context.
Tags: atp.ManifestKind=ExecutionManifest,MachineManifest
Base ARObject, AtpFeature, AtpPrototype, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mul. Kind Note
swCalibration SwCalibrationAccess 0..1 attr This allows for specifying whether or not the enclosing
Access Enum ModeDeclarationGroupPrototype can be measured at
run-time.
type ModeDeclarationGroup 1 tref The "collection of ModeDeclarations" ( = ModeDeclaration
Group) supported by a component
Stereotypes: isOfType

Table 4.18: ModeDeclarationGroupPrototype

Please note that by aggregating SwCalibrationAccessEnum in the role swCal-

ibrationAccess a ModeDeclarationGroupPrototype gains the ability to be-
come measurable. This implies the following constraint:

114 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[constr_1172] Allowed values of SwCalibrationAccessEnum for ModeDecla-

rationGroupPrototype d The only allowed values of swCalibrationAccess ag-
gregated by ModeDeclarationGroupPrototype are notAccessible and read-
Only. c()
[TPS_SWCT_01566] Define literals for an MCD system in the context of a
FlatInstanceDescriptor d If ModeDeclarationGroupPrototype.swCali-
brationAccess is set to readOnly a referenced FlatInstanceDescriptor.sw-
DataDefProps may in turn refer to a CompuMethod that defines the particular literals
used in the MCD system for displaying values of the the measured ModeDeclara-
tionGroupPrototypes. c(RS_SWCT_03203)
The existence of this use case is the reason for putting “AI” at the intersection of com-
puMethod and FlatInstanceDescriptor.
Another possible scenario (that does not necessarily have to be related to ModeDec-
larationGroupPrototypes but to the definition of literals for MCD systems in gen-
eral) is that a FlatInstanceDescriptor does not exist (e.g. because the affected
piece of data exists in the basic software) but still it would be good to have the ability
to define particular literals for displaying values in an MCD system.
This case can be supported by the AUTOSAR standard as well by putting “AI” at the
intersection of compuMethod and McDataInstance in table 5.39.
[TPS_SWCT_01200] ModeDeclarationGroupPrototype per ModeSwitchIn-
terface d The multiplicity of the aggregation of ModeDeclarationGroupProto-
type to ModeSwitchInterface is pragmatically limited to 1. c(RS_SWCT_03203)
Admittedly, there would be no technical restriction to support a 0..* multiplicity but on
the other hand it does not seem as if any reasonable use case for such a scenario
exists.
If somehow a SwComponentType would have to consider two or even more Mod-
eDeclarationGroupPrototypes it is very likely that these would be part of different
ModeSwitchInterfaces.
The containment of a ModeDeclarationGroupPrototype in a ModeSwitchIn-
terface allows for explicitly defining SwConnectors which communicate between
SwComponentPrototypes and to define service interfaces for communication with
ServiceSwComponentTypes. Due to the compatibility rules of PortInterfaces
(see chapter 6) each SwComponentType can rely on the availability of required mode
activations.

115 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

PortInterface
ModeSwitchInterface

+modeGroup 1

AtpPrototype
ModeDeclarationGroupPrototype

+ swCalibrationAccess: SwCalibrationAccessEnum [0..1]

  
   
  

«isOfType»
1
+type {redefines atpType}
ARElement AtpStructureElement
AtpBlueprint +modeDeclaration Identifiable
AtpBlueprintable «atpVariation» 1..* ModeDeclaration
AtpType
ModeDeclarationGroup + value: PositiveInteger [0..1]

+ onTransitionValue: PositiveInteger [0..1]

+initialMode
1

Figure 4.5: Mode Switch Interface

Please note that each SwComponentType can define (via their PortPrototypes
and ModeSwitchInterfaces) a list of required and provided ModeDeclara-
tionGroupPrototypes.
[TPS_SWCT_01201] CompositionSwComponentType requires and provides the
modes that are required or provided by its contained SwComponentPrototypes
d Eventually, a CompositionSwComponentType requires and provides the modes
that are required or provided by its contained SwComponentPrototypes. The dele-
gation of these modes from SwComponentPrototypes to the enclosing Composi-
tionSwComponentType is explicitly described by DelegationSwConnectors. c
(RS_SWCT_03202, RS_SWCT_03203)
The formal description of a software-component does not make any assumptions about
the semantics of the required and provided ModeDeclarationGroupPrototypes.
It just requires and provides the ModeDeclarationGroupPrototypes by name. For
more information about mode declaration refer to section 9.1.
[TPS_SWCT_01086] Request mode change d The ability to request a mode (i.e.
the second use case) is modeled on the VFB via a SenderReceiverInterface
and for the RTE it is like a usual communication, that means the connector can also
cross ECU boundaries and the communicated dataElements have to be based on
AutosarDataTypes. c(RS_SWCT_03202, RS_SWCT_03203)
However, for semantic consistency with the first use case, a communicated mode re-
quest shall also be mapped to a corresponding ModeDeclarationGroup. This can
be defined by a mapping class as shown in figure 4.6.
The ImplementationDataType mapped to a certain ModeDeclarationGroup
can then be used in a PortInterface to represent a ModeDeclaration of the
associated ModeDeclarationGroup as a numerical value:

116 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[constr_4002] Unambiguous mapping of modes to data types d Within one

DataTypeMappingSet, a ModeDeclarationGroup shall not be mapped to differ-
ent ImplementationDataTypes. c()
ARElement ARElement
AtpBlueprint AtpBlueprint
AtpBlueprintable AtpBlueprintable
PortInterfaceMappingSet DataTypeMappingSet

  
«atpVariation»    
  
+portInterfaceMapping 1..* 0..* +modeRequestTypeMap

AtpBlueprint AbstractImplementationDataType
ModeRequestTypeMap
AtpBlueprintable ImplementationDataType
Identifiable
PortInterfaceMapping + dynamicArraySizeProfile: String [0..1]
+ isStructWithOptionalElement: Boolean [0..1]
+ typeEmitter: NameToken [0..1]

ARElement
AtpBlueprint
AtpBlueprintable
ModeInterfaceMapping AtpType
+modeGroup 1 ModeDeclarationGroup

+ onTransitionValue: PositiveInteger [0..1]

+type 1
{redefines
atpType}

«isOfType»
+modeMapping 1

ModeDeclarationGroupPrototypeMapping +firstModeGroup AtpPrototype

1 ModeDeclarationGroupPrototype
+secondModeGroup
+ swCalibrationAccess: SwCalibrationAccessEnum [0..1]
1

Figure 4.6: Mapping of modes to data types

Class ModeRequestTypeMap
Package M2::AUTOSARTemplates::CommonStructure::ModeDeclaration
Note Specifies a mapping between a ModeDeclarationGroup and an ImplementationDataType. This
ImplementationDataType shall be used to implement the ModeDeclarationGroup.
Base ARObject
Attribute Type Mul. Kind Note
implementation AbstractImplementation 1 ref This is the corresponding AbstractImplementationData
DataType DataType Type. It shall be modeled along the idea of an "unsigned
integer-like" data type.
modeGroup ModeDeclarationGroup 1 ref This is the corresponding ModeDeclarationGroup.

Table 4.19: ModeRequestTypeMap

[constr_1166] Restrictions of ModeRequestTypeMap d For every ModeDeclara-

tionGroup referenced by a ModeDeclarationGroupPrototype used in a Port-
Prototype typed by a ModeSwitchInterface a ModeRequestTypeMap shall ex-
ist that points to the ModeDeclarationGroup and also to an eligible Implementa-
tionDataType.

117 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

The ModeRequestTypeMap shall be aggregated by a DataTypeMappingSet which

is referenced from the SwcInternalBehavior that is owned by the Application-
SwComponentType that also owns the PortPrototype. c()
ARElement AtpStructureElement
AtpBlueprint InternalBehavior
AtpBlueprintable +dataTypeMapping
DataTypeMappingSet
0..*«atpSplitable»

+modeRequestTypeMap 0..*

ARElement
ModeRequestTypeMap SwcInternalBehavior
AtpBlueprint
AtpBlueprintable
AtpType
SwComponentType

+internalBehavior 0..1
«atpVariation,atpSplitable»

  
   
«atpVariation,atpSplitable»  

+modeGroup 1 +port 0..*

ARElement AbstractImplementationDataType AtpBlueprintable

AtomicSwComponentType
AtpBlueprint ImplementationDataType AtpPrototype
AtpBlueprintable PortPrototype
AtpType
ModeDeclarationGroup

+type 1
{redefines
atpType}
ARElement AbstractProvidedPortPrototype
AtpBlueprint +providedInterface PPortPrototype
AtpBlueprintable
1 «isOfType»
AtpType
{redefines atpType}
PortInterface

AbstractProvidedPortPrototype
+providedRequiredInterface AbstractRequiredPortPrototype

1 «isOfType» PRPortPrototype
{redefines atpType}

AbstractRequiredPortPrototype
«isOfType» +requiredInterface
RPortPrototype
1 «isOfType»
{redefines atpType}

ModeSwitchInterface

+modeGroup 1

AtpPrototype ModeDeclarationGroupPrototypeMapping
+firstModeGroup
ModeDeclarationGroupPrototype
1

+secondModeGroup

Figure 4.7: Big picture of mode declaration mapping

[constr_1167] ImplementationDataTypes used as ModeRequestTypeMap.im-

plementationDataType d The ImplementationDataType referenced by a

118 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

ModeRequestTypeMap shall either be of category VALUE or of category

TYPE_REFERENCE that in turn references an ImplementationDataType of cat-
egory VALUE.
The baseType referenced by the ImplementationDataType shall have set the
value of the attribute BaseTypeDirectDefinition.baseTypeEncoding to NONE.
c()
[TPS_SWCT_01202] ApplicationDataType defines a subset of the values used
in the ModeDeclarationGroup d Please note that the corresponding Appli-
cationDataType is defining a subset of the values used in the ModeDeclara-
tionGroup and the used labels may differ from the names used for the ModeDec-
larations.
It is in the responsibility of a system designer to maintain the data types and ModeDec-
larationGroups according to the functional needs.
For example, a ModeRequester may only request a subset of the available Modes (via
SenderReceiverInterface or ClientServerInterface). The ModeManager
may additionally decide to indicate failure. c(RS_SWCT_03203)
For more information regarding the ability to connect different kinds of PortProto-
types typed by a ModeSwitchInterface to each other please refer to [constr_1204]
and [constr_1205].

4.2.6 Parameter Communication

Of course, the “communication” of ParameterDataPrototypes as part of a Param-

eterInterface does not establish an actual transmission of data.
The term is used in a conceptual meaning; and the existence of something like a
ParameterInterface is justified by the mere idea of unifying the exposure of cali-
bration parameters at the surface of a software-component on the same formal level
as the exposure of other pieces of data, i.e. by means of a PortPrototype typed by
a PortInterface.
[constr_1312] PortPrototypes typed by a ParameterInterface d PortPro-
totypes typed by a ParameterInterface can either be PPortPrototypes or
RPortPrototypes. The usage of PRPortPrototypes that are typed by a Param-
eterInterface is not supported. c()

4.3 PortInterface Mapping and Data Scaling

In former versions of this specification, the requirements on PortInterfaces to
match each other could lead to situations where PortInterfaces that were “prac-
tically” compatible would nevertheless be rejected because of formal reasons (e.g.
shortNames of dataElements do not match).

119 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

In order to also support scenarios where the developer of a CompositionSwCom-

ponentType needs to connect PortPrototypes that would match to each others
but don’t fulfill formal requirements the concept of “port interface mapping” has been
introduced.
[TPS_SWCT_01158] Cases for PortInterfaceMapping d In general, the existence
of a PortInterfaceMapping is suitable in the following cases:
1. Two PortPrototypes shall be connected and the PortInterface elements
are compatible except the unequal shortNames. This requires a pure logical
mapping of the PortInterface elements.
2. PortInterface elements are logically equivalent but the range and resolution
is differently. This requires a data conversion respectively a re-scaling of the
provided data and arguments to the required data and arguments range and
resolution.
3. invalidationPolicy of PortInterface elements is different. This might re-
quire the implementation of different invalidation handling strategies for the same
dataElement in parallel on the same ECU.
4. Two PortPrototypes shall be connected and the PortInterface elements
shall be converted using the AUTOSAR data transformer approach.
c(RS_SWCT_03210)
More information about the AUTOSAR data transformer approach can be found in
section 4.3.3.
Typically the mapping of such PortInterface is agreed once between the different
component vendors and system designer in the early phase of a project.
[TPS_SWCT_01159] Mapping is described separately from the SwConnector as
reusable ARElement d The mapping is described separately from the SwConnec-
tor as reusable ARElement. A set of PortInterfaceMappings is grouped in a
PortInterfaceMappingSet. c(RS_SWCT_03210)
[TPS_SWCT_01543] PortInterfaceMapping overrides all other compatibility
rules d The existence of a PortInterfaceMapping overrides all other compatibility
rules given that the following statements are fulfilled:
• [constr_1071] applies also for the application of a PortInterfaceMapping.
• [constr_1268] applies also for the application of a PortInterfaceMapping.
• [constr_1269] applies also for the application of a PortInterfaceMapping.
• [constr_1270] applies also for the application of a PortInterfaceMapping.
• A structural difference between mapped DataPrototypes can be mitigated by
means of a SubElementMapping. This includes the case that a “structure” data
type is mapped to an “array” data type and vice versa. [TPS_SWCT_01195] is
also applicable.

120 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

When using a PortInterfaceMapping, the developer of a software-component

needs to properly understand the consequences in terms of model semantics. c
(RS_SWCT_03210)
Please note that [TPS_SWCT_01543] does not require a tool implementation to ignore
and let go unreported deviations of all other compatibility rules in the presence of a
PortInterfaceMapping.
If this is considered helpful, the tool may still issue warnings with respect to compatibil-
ity rules defined in section 6 but this is not mandated by the AUTOSAR standard. The
tool, however, shall not report errors in this case.
Class PortInterfaceMappingSet
Package M2::AUTOSARTemplates::SWComponentTemplate::PortInterface
Note Specifies a set of (one or more) PortInterfaceMappings.
Tags: atp.recommendedPackage=PortInterfaceMappingSets
Base ARElement, ARObject, AtpBlueprint, AtpBlueprintable, CollectableElement, Identifiable, Multilanguage
Referrable, PackageableElement, Referrable
Attribute Type Mul. Kind Note
portInterface PortInterfaceMapping 1..* aggr Specifies one PortInterfaceMapping to support the
Mapping connection of Ports typed by two different PortInterfaces
with PortInterface elements having unequal names and/or
unequal semantic (resolution or range).
Stereotypes: atpVariation
Tags: vh.latestBindingTime=blueprintDerivationTime

Table 4.20: PortInterfaceMappingSet

Class PortInterfaceMapping (abstract)

Package M2::AUTOSARTemplates::SWComponentTemplate::PortInterface
Note Specifies one PortInterfaceMapping to support the connection of Ports typed by two different Port
Interfaces with PortInterface elements having unequal names and/or unequal semantic (resolution or
range).
Base ARObject, AtpBlueprint, AtpBlueprintable, Identifiable, MultilanguageReferrable, Referrable
Subclasses ClientServerInterfaceMapping, ModeInterfaceMapping, TriggerInterfaceMapping, VariableAndParameter
InterfaceMapping
Attribute Type Mul. Kind Note
– – – – –
Table 4.21: PortInterfaceMapping

4.3.1 PortInterface Mapping

By default, the shortNames of PortInterface elements are used to identify the

matching element pairs of connected PortPrototypes. In case of non-matching
shortNames (this might be due to distributed development, off-the-shelves develop-
ment, or reuse of software-components) it is required to explicitly specify which ele-
ments of PortInterfaces shall correlate to each other.
This definition is provided with PortInterfaceMappings.

121 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[TPS_SWCT_01099] PortInterfaceMapping d Each PortInterfaceMapping

describes the mapping of the PortInterface elements of exactly two PortInter-
faces. c(RS_SWCT_03155, RS_SWCT_03210)
To apply the PortInterfaceMapping a SwConnector has to reference a PortIn-
terfaceMapping.
[constr_1151] Applicability of PortInterfaceMapping d A PortInter-
faceMapping is only applicable and valid for a SwConnector if the two PortProto-
types which are referenced by the SwConnector are typed by the same two Port-
Interfaces which are mapped by the PortInterfaceMapping. c()
[TPS_SWCT_01100] Precedence of PortInterfaceMapping d The mapping via
PortInterfaceMapping has a higher precedence than the mapping by equal
shortNames as defined in compatibility rules.
If a connector has an associated PortInterfaceMapping this mapping shall
be strictly binding with respect to the number of mapped data elements. c
(RS_SWCT_03155, RS_SWCT_03210)
Please note that the compatibility rules are described in chapter 6.
[TPS_SWCT_01101] Unmapped elements of PortInterfaces d Unmapped
PortInterface elements will not be connected by the referencing SwConnector.
c(RS_SWCT_03155, RS_SWCT_03210)
[constr_1583] PortInterfaceMapping for DataPrototype typed by Compound
Primitive Data Type d There is one very limited use case to apply PortIn-
terfaceMapping for a DataPrototype typed by a Compound Primitive Data
Type: adjustment of the shortName of the DataPrototype. Everything else is not
supported. c()
ARElement
AtpBlueprint
AtpBlueprintable
PortInterfaceMappingSet

  
«atpVariation»       

+portInterfaceMapping 1..*

AtpBlueprint AtpStructureElement
AtpBlueprintable +mapping SwConnector
Identifiable
0..1
PortInterfaceMapping

VariableAndParameterInterfaceMapping ClientServerInterfaceMapping ModeInterfaceMapping TriggerInterfaceMapping

Figure 4.8: Relevant meta-classes for PortInterface element mapping

122 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4.3.1.1 Mapping of Sender Receiver Interface, Parameter Interface and Non

Volatile Data Interface Elements

[TPS_SWCT_01102] VariableAndParameterInterfaceMapping d The Vari-

ableAndParameterInterfaceMapping defines the correlation of VariableDat-
aPrototypes and ParameterDataPrototypes defined in the context of DataIn-
terfaces, i.e. SenderReceiverInterface, NvDataInterface, or Parameter-
Interface. c(RS_SWCT_03155, RS_SWCT_03210, RS_SWCT_03170)
[constr_1159] Consistency of VariableAndParameterInterfaceMapping with
respect to the referenced DataInterfaces d Within one VariableAndParame-
terInterfaceMapping all firstDataPrototypes shall belong to one and only
one DataInterface and all secondDataPrototypes shall belong to one other and
only one other DataInterface. c()
[TPS_SWCT_01103] Mapping between different kinds of PortInterfaces d
Thereby it is possible to describe the mapping between different kinds of PortInter-
faces for instance a ParameterInterface and SenderReceiverInterface. c
(RS_SWCT_03155, RS_SWCT_03210, RS_SWCT_03170)
[TPS_SWCT_01104] Possible mappings are restricted by the swImplPolicy
d Nevertheless, the possible mappings of VariableDataPrototypes and Pa-
rameterDataPrototypes are restricted by the swImplPolicy attribute. c
(RS_SWCT_03155, RS_SWCT_03210, RS_SWCT_03170)
For more explanation of [TPS_SWCT_01104], please refer to [constr_1071].
[constr_1039] Relevance of swImplPolicy d It is not possible to define a mapping
between an element where the swImplPolicy is set to queued and an other element
where the swImplPolicy is set differently. c()
This is required to fulfill the compatibility rules defined in table 6.1.
[constr_1635]{DRAFT} Relevance of attribute isOptional d If a SubEle-
mentMapping is defined for the elements of a structured data type then the attribute
isOptional5 shall either not exist for the firstElement and secondElement or it
shall have the identical value for the firstElement and secondElement. c()
[constr_1040] Conversion of SenderReceiverInterfaces d The conversion of el-
ements of SenderReceiverInterfaces is possible if one of the following conditions
applies:
• The AutosarDataTypes of the referred DataPrototypes are compatible.
• A conversion of the data is available.
• A DataPrototypeMapping.firstToSecondDataTransformation is de-
fined.
5
this is valid for both ApplicationRecordElement as well as ImplementationDataTypeEle-
ment

123 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

c()
The compatibility of AutosarDataTypes is described in section 6.2. A description of the
conversion of data can be found in section 4.3.2.
PortInterfaceMapping
VariableAndParameterInterfaceMapping

+dataMapping 1..*
TextTableMapping
DataPrototypeMapping
+ identicalMapping: Boolean
+textTableMapping
+ mappingDirection: MappingDirectionEnum
0..2 «atpVariation»
+ bitfieldTextTableMaskFirst: PositiveInteger [0..1]
+ bitfieldTextTableMaskSecond: PositiveInteger [0..1]

+firstDataPrototype 1 +secondDataPrototype 1

DataPrototype
AutosarDataPrototype

VariableDataPrototype ParameterDataPrototype

+dataElement 1..* +nvData 1..* +parameter 1..*

DataInterface DataInterface DataInterface

SenderReceiverInterface NvDataInterface ParameterInterface

Figure 4.9: Mapping of Sender Receiver Interface, Parameter Interface and Non Volatile
Data Interface elements

Class VariableAndParameterInterfaceMapping
Package M2::AUTOSARTemplates::SWComponentTemplate::PortInterface
Note Defines the mapping of VariableDataPrototypes or ParameterDataPrototypes in context of two different
SenderReceiverInterfaces, NvDataInterfaces or ParameterInterfaces.
Base ARObject, AtpBlueprint, AtpBlueprintable, Identifiable, MultilanguageReferrable, PortInterfaceMapping,
Referrable
Attribute Type Mul. Kind Note
dataMapping DataPrototypeMapping 1..* aggr Defines the mapping of two particular VariableData
Prototypes or ParameterDataPrototypes with unequal
names and/or unequal semantic (resolution or range) in
context of two different SenderReceiverInterfaces, Nv
DataInterfaces or ParameterInterfaces
Table 4.22: VariableAndParameterInterfaceMapping

124 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Class DataPrototypeMapping
Package M2::AUTOSARTemplates::SWComponentTemplate::PortInterface
Note Defines the mapping of two particular VariableDataPrototypes, ParameterDataPrototypes or Argument
DataPrototypes with unequal names and/or unequal semantic (resolution or range) in context of two
different SenderReceiverInterface, NvDataInterface or ParameterInterface or Operations.
If the semantic is unequal following rules apply:
The textTableMapping is only applicable if the referred DataPrototypes are typed by AutosarDataType
referring to CompuMethods of category TEXTTABLE, SCALE_LINEAR_AND_TEXTTABLE or
BITFIELD_TEXTTABLE.
In the case that the DataPrototypes are typed by AutosarDataType either referring to CompuMethods of
category LINEAR, IDENTICAL or referring to no CompuMethod (which is similar as IDENTICAL) the
linear conversion factor is calculated out of the factorSiToUnit and offsetSiToUnit attributes of the referred
Units and the CompuRationalCoeffs of a compuInternalToPhys of the referred CompuMethods.
Base ARObject
Attribute Type Mul. Kind Note
firstData AutosarDataPrototype 1 ref First to be mapped DataPrototype in context of a Sender
Prototype ReceiverInterface, NvDataInterface, ParameterInterface
or Operation.
firstToSecond DataTransformation 0..1 ref This reference defines the need to execute the Data
Data Transformation <Mip>_<transformerId> functions of the
Transformation transformation chain when communicating from the Data
PrototypeMapping.firstDataPrototype to the Data
PrototypeMapping.secondDataPrototype.
This reference also specifies the reverse Data
Transformation <Mip>_Inv_<transformerId> functions of
the transformation chain (i.e. from the DataPrototype
Mapping.secondDataPrototype to the DataPrototype
Mapping.firstDataPrototype) if the referenced Data
Transformation is symmetric, i.e. attribute Data
Transformation.dataTransformationKind is set to
symmetric.
secondData AutosarDataPrototype 1 ref Second to be mapped DataPrototype in context of a
Prototype SenderReceiverInterface, NvDataInterface, Parameter
Interface or Operation.
secondToFirst DataTransformation 0..1 ref This defines the need to execute the reverse Data
Data Transformation <Mip>_Inv_<transformerId> functions of
Transformation the transformation chain when communicating from the
DataPrototypeMapping.secondDataPrototype to the Data
PrototypeMapping.firstDataPrototype.
subElement SubElementMapping * aggr This represents the owned SubelementMapping.
Mapping
textTable TextTableMapping 0..2 aggr Applied TextTableMapping(s)
Mapping

Table 4.23: DataPrototypeMapping

4.3.1.2 Mapping of Client Server Interface Elements

[TPS_SWCT_01105] ClientServerInterfaceMapping d The ClientServer-

InterfaceMapping defines the correlation of ClientServerOperations de-
fined in the context of two ClientServerInterfaces. c(RS_SWCT_03155,
RS_SWCT_03210)
[constr_1237] Scope of mapped ClientServerOperations in the context of a
ClientServerOperationMapping d All ClientServerOperations referenced

125 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

by a ClientServerOperationMapping in the role firstOperation shall belong

to exactly one ClientServerInterface.
All ClientServerOperations referenced by a ClientServerOperation-
Mapping in the role secondOperation shall belong to exactly one other
ClientServerInterface. c()
[constr_1238] Scope of mapped ApplicationErrors in the context of a
ClientServerOperationMapping d All ApplicationErrors referenced by a
ClientServerApplicationErrorMapping in the role firstApplication-
Error shall belong to exactly one ClientServerInterface.
All ApplicationErrors referenced by a ClientServerApplicationErrorMap-
ping in the role secondApplicationError shall belong to exactly one other
ClientServerInterface. c()
[constr_1041] Conversion of ClientServerInterfaces d Either the Autosar-
DataTypes of the referred ArgumentDataPrototypes are compatible or a conver-
sion of the data is available. c()
The compatibility of AutosarDataTypes is described in section 6.2. A description of the
conversion of data can be found in section 4.3.2.
[constr_1240] Consistency of ArgumentDataPrototypes within the context of
a ClientServerOperationMapping d Unless a ClientServerOperationMap-
ping.firstToSecondDataTransformation exists, for each argument owned by
a ClientServerOperationMapping.firstOperation and ClientServerOp-
erationMapping.secondOperation a reference in the role ClientServerOp-
erationMapping.argumentMapping.firstDataPrototype or ClientServer-
OperationMapping.argumentMapping.secondDataPrototype shall exist orig-
inated by one of the ClientServerOperationMapping.argumentMappings
owned by the mentioned ClientServerOperationMapping. c()
[constr_1268] ArgumentDataPrototype.direction shall be preserved in a
ClientServerOperationMapping d Within the context of a ClientServerOper-
ationMapping, the value of the argument ArgumentDataPrototype.direction
of two mapped ArgumentDataPrototype shall be identical. c()
[constr_1269] Number of arguments shall be preserved in a ClientServerOp-
erationMapping d Within the context of a ClientServerOperationMapping, the
number of arguments of firstOperation and secondOperation shall be identi-
cal. c()
[constr_1270] ArgumentDataPrototype shall be mapped only once in a
ClientServerOperationMapping d Within the context of a ClientServerOp-
erationMapping, each argument shall only be referenced once in the role first-
DataPrototype or secondDataPrototype. c()
[constr_1469] Applicability of constraints depending on the existence of a data
transformation d [constr_1269], [constr_1270], [constr_1268], and [constr_1240] shall
not apply under the following conditions:

126 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

• A reference from the respective ClientServerOperationMapping to a

DataTransformation in the role firstToSecondDataTransformation
exists.
• The value of the attribute dataTransformationKind of the referenced
DataTransformation is set to DataTransformationKindEnum.asymmet-
ricFromByteArray or DataTransformationKindEnum.asymmetricTo-
ByteArray.
c()
PortInterfaceMapping PortInterface
ClientServerInterfaceMapping ClientServerInterface

  
    «atpVariation»
  
+operationMapping 1..* +operation 1..*

+firstOperation AtpStructureElement
ClientServerOperationMapping
Identifiable
1 ClientServerOperation
+secondOperation

0..1 +firstToSecondDataTransformation

Identifiable
Transformer::DataTransformation

+ dataTransformationKind: DataTransformationKindEnum [0..1]

+ executeDespiteDataUnavailability: Boolean

+errorMapping 0..* +possibleError 0..* +possibleError 0..*

+firstApplicationError Identifiable
ClientServerApplicationErrorMapping
1 ApplicationError
+secondApplicationError + errorCode: Integer

Figure 4.10: Mapping of ClientServerInterface elements and mapping of arguments

127 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

PortInterface
ClientServerInterface

«atpVariation»
+operation 1..*

+firstOperation AtpStructureElement
ClientServerOperationMapping
Identifiable
  
1 ClientServerOperation    
+secondOperation   

«atpVariation»
*
+argument {ordered}

ArgumentDataPrototype

+argumentMapping 0..*

+firstDataPrototype DataPrototype
DataPrototypeMapping
AutosarDataPrototype
1
+secondDataPrototype

+textTableMapping 0..2

TextTableMapping

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

Figure 4.11: Mapping of ArgumentDataPrototypes

Class ClientServerInterfaceMapping
Package M2::AUTOSARTemplates::SWComponentTemplate::PortInterface
Note Defines the mapping of ClientServerOperations in context of two different ClientServerInterfaces.
Base ARObject, AtpBlueprint, AtpBlueprintable, Identifiable, MultilanguageReferrable, PortInterfaceMapping,
Referrable
Attribute Type Mul. Kind Note
errorMapping ClientServerApplication * aggr Map two different ApplicationErrors defined in the context
ErrorMapping of two different ClientServerInterfaces.
operation ClientServerOperation 1..* aggr Mapping of two ClientServerOperations in two different
Mapping Mapping ClientServerInterfaces

Table 4.24: ClientServerInterfaceMapping

128 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Class ClientServerOperationMapping
Package M2::AUTOSARTemplates::SWComponentTemplate::PortInterface
Note Defines the mapping of two particular ClientServerOperations in context of two different ClientServer
Interfaces.
Base ARObject
Attribute Type Mul. Kind Note
argument DataPrototypeMapping * aggr Defines the mapping of two particular ArgumentData
Mapping Prototypes with unequal names or unequal semantic
(resolution or range) in context of Operations.
firstOperation ClientServerOperation 1 ref First to-be-mapped ClientServerOperation of a Client
ServerInterface.
firstToSecond DataTransformation 0..1 ref This reference indicates that a DataTransformation is
Data intended in the context of the ClientServerOperation
Transformation Mapping.
second ClientServerOperation 1 ref Second to-be-mapped ClientServerOperation of a Client
Operation ServerInterface.

Table 4.25: ClientServerOperationMapping

Class ClientServerApplicationErrorMapping
Package M2::AUTOSARTemplates::SWComponentTemplate::PortInterface
Note This meta-class represents the ability to map ApplicationErrors onto each other.
Base ARObject
Attribute Type Mul. Kind Note
firstApplication ApplicationError 1 ref This represents the first ApplicationError in the context of
Error the ClientServerApplicationErrorMapping.
second ApplicationError 1 ref This represents the second ApplicationError in the
ApplicationError context of the ClientServerApplicationErrorMapping.

Table 4.26: ClientServerApplicationErrorMapping

4.3.1.3 Mapping of Mode Interface Elements

[TPS_SWCT_01160] ModeInterfaceMapping d The ModeInterfaceMapping

defines the correlation of ModeDeclarationGroupPrototypes defined in the con-
text of ModeSwitchInterfaces. c(RS_SWCT_03210)
[TPS_SWCT_01167] Validity of ModeInterfaceMapping d The mapping of Mod-
eDeclarationGroupPrototypes is only valid if these are typed by (read “refer to”)
compatible ModeDeclarationGroups. c(RS_SWCT_03210)
The compatibility of ModeDeclarationGroups is described in chapter 6.7.

129 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Class ModeInterfaceMapping
Package M2::AUTOSARTemplates::SWComponentTemplate::PortInterface
Note Defines the mapping of ModeDeclarationGroupPrototypes in context of two different ModeInterfaces.
Base ARObject, AtpBlueprint, AtpBlueprintable, Identifiable, MultilanguageReferrable, PortInterfaceMapping,
Referrable
Attribute Type Mul. Kind Note
modeMapping ModeDeclarationGroup 1 aggr Mapping of two ModeDeclarationGroupPrototypes in two
PrototypeMapping different ModeInterfaces

Table 4.27: ModeInterfaceMapping

Class ModeDeclarationGroupPrototypeMapping
Package M2::AUTOSARTemplates::CommonStructure::ModeDeclaration
Note Defines the mapping of two particular ModeDeclarationGroupPrototypes (in the given context) that are
unequally named and/or require a reference to a ModeDeclarationMappingSet in order to become
compatible by definition of ModeDeclarationMappings.
Base ARObject
Attribute Type Mul. Kind Note
firstModeGroup ModeDeclarationGroup 1 ref ModeDeclarationGroupPrototype to be mapped.
Prototype
mode ModeDeclaration 0..1 ref This represents the available mappings of Mode
Declaration MappingSet Declarations in the context ot this ModeDeclarationGroup
MappingSet Prototype.
secondMode ModeDeclarationGroup 1 ref ModeDeclarationGroupPrototype to be mapped.
Group Prototype

Table 4.28: ModeDeclarationGroupPrototypeMapping

[TPS_SWCT_01449] Semantics of a ModeDeclarationGroupPrototypeMap-

ping d A ModeDeclarationGroupPrototypeMapping shall be used to identify
two ModeDeclarationGroups that afterwards shall be considered compatible. This
also applies if the two ModeDeclarationGroups deviate with respect to the con-
tained modeTransitions. c(RS_SWCT_03210)

130 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

PortInterfaceMapping PortInterface
ModeInterfaceMapping ModeSwitchInterface

+modeMapping 1 +modeGroup 1
+secondModeGroup AtpPrototype
ModeDeclarationGroupPrototypeMapping
1 ModeDeclarationGroupPrototype
+firstModeGroup + swCalibrationAccess: SwCalibrationAccessEnum [0..1]
1

«isOfType»

1
+modeDeclarationMappingSet 0..1 +type {redefines atpType}
ARElement ARElement
AtpType AtpBlueprint
ModeDeclarationMappingSet AtpBlueprintable
AtpType
ModeDeclarationGroup

+ onTransitionValue: PositiveInteger [0..1]

  
   
   «atpVariation»

+modeDeclarationMapping 1..* +modeDeclaration 1..* +initialMode 1

+firstMode
AtpStructureElement AtpStructureElement
Identifiable 1..* Identifiable
ModeDeclarationMapping +secondMode ModeDeclaration

1 + value: PositiveInteger [0..1]

Figure 4.12: Mapping of ModeSwitchInterface elements

[constr_1246] Consistency of firstMode and secondMode in the scope of one

ModeDeclarationMappingSet d Within the scope of one ModeDeclaration-
MappingSet, all firstModes shall belong to one and only one ModeDeclara-
tionGroup and all secondModes shall belong to one and only one other ModeDec-
larationGroup c()
[constr_1247] Consistency of ModeDeclarationMappingSet with respect to
the referenced firstModeGroup and secondModeGroup d If a ModeDec-
larationGroupPrototypeMapping.modeDeclarationMappingSet exists, the
ModeDeclarationGroup owning the modeDeclarations referenced in the role
firstMode shall be the type of the ModeDeclarationGroupPrototypeMap-
ping.firstModeGroup and the ModeDeclarationGroup owning the modeDec-
larations referenced in the role secondMode shall be the type of the ModeDec-
larationGroupPrototypeMapping.secondModeGroup. c()
[TPS_SWCT_01462] ModeDeclarationMapping defines the explicit correlation
of ModeDeclarations d The meta-class ModeDeclarationMapping defines the
explicit correlation of ModeDeclarations defined in the context of two ModeDecla-
rationGroups. c()
[TPS_SWCT_01463] ModeDeclarationGroupPrototypeMapping.modeDecla-
rationMappingSet defines the applicable set of ModeDeclarationMappings

131 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

d The attribute ModeDeclarationGroupPrototypeMapping.modeDeclaration-

MappingSet defines the applicable set of ModeDeclarationMappings for the
connection of ModeDeclarationGroupPrototypes typed by ModeDeclara-
tionGroups with differently named ModeDeclarations and/or with a different num-
ber of ModeDeclarations. c()
Class ModeDeclarationMappingSet
Package M2::AUTOSARTemplates::SWComponentTemplate::PortInterface
Note This meta-class implements a container for ModeDeclarationGroupMappings
Tags: atp.recommendedPackage=PortInterfaceMappingSets
Base ARElement, ARObject, AtpClassifier , AtpType, CollectableElement, Identifiable, Multilanguage
Referrable, PackageableElement, Referrable
Attribute Type Mul. Kind Note
mode ModeDeclaration 1..* aggr This represents the collection of ModeDeclaration
Declaration Mapping Mappings owned by the enclosing ModeDeclaration
Mapping MappingSet.

Table 4.29: ModeDeclarationMappingSet

Class ModeDeclarationMapping
Package M2::AUTOSARTemplates::SWComponentTemplate::PortInterface
Note This meta-class implements a concrete mapping of two ModeDeclarations.
Base ARObject, AtpClassifier , AtpFeature, AtpStructureElement, Identifiable, MultilanguageReferrable,
Referrable
Attribute Type Mul. Kind Note
firstMode ModeDeclaration 1..* ref This represents the first ModeDeclaration of the Mode
DeclarationMapping. This reference has the multiplicity 1
.. * to support use cases where e.g. one mode of the
mode user is mapped to several modes of the mode
manager.
secondMode ModeDeclaration 1 ref This represents the second ModeDeclaration of the Mode
DeclarationMapping.

Table 4.30: ModeDeclarationMapping

[TPS_SWCT_01464] ModeDeclaration of a mode user is mapped to exactly one

ModeDeclaration of a mode manager d The mode that corresponds to the Mod-
eDeclaration of the Mode User is entered or exited when the mode of the mode
manager that corresponds to the mapped (i.e. referenced by the same ModeDecla-
rationMapping) ModeDeclaration of the mode manager is entered or exited. c
(RS_SWCT_03115)
[TPS_SWCT_01465] ModeDeclaration of a mode user is mapped to several
ModeDeclarations of a mode manager d The mode that corresponds to the
mapped ModeDeclaration of the mode user is entered when any of the modes of the
Mode Manager that correspond to ModeDeclarations referenced by the applicable
ModeDeclarationMapping is entered.

132 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

The mode that corresponds to the mapped ModeDeclaration of the mode user is
exited when any of the modes of the Mode Manager that correspond to ModeDec-
larations referenced by the applicable ModeDeclarationMapping is exited if the
new mode is not mapped to related mode of the mode user. c(RS_SWCT_03115)
Please note if one ModeDeclaration of a mode user is mapped to several Mod-
eDeclarations of a mode manager by means of several ModeDeclarationMap-
pings the intended semantics is defined in a way that the individual mode transitions
of the mode manager are representing “exit” and “enter” events for the Mode User. In
other words, the individual transitions are recognizable by the mode user.
If one ModeDeclaration of a mode user is (by utilizing the multiplicity of the role
firstMode) mapped to several ModeDeclarations of a mode manager in the con-
text of a single ModeDeclarationMapping the semantics is defined in a way that
the individual mode transitions of the Mode Manager are not recognizable to the Mode
User.
[constr_1209] Mapping of ModeDeclarations of mode user to ModeDeclara-
tion of mode manager d A configuration that maps several ModeDeclarations
representing modes of a mode user to one ModeDeclaration representing a mode
of a mode manager shall be rejected. c()
[constr_1210] Mapping of ModeDeclarations of mode user to all ModeDecla-
rations of mode manager d If a ModeDeclarationMapping exists that references
a ModeDeclaration representing a mode of the mode manager then ModeDecla-
rationMappings shall exist that map all modes of the mode manager to modes of
the mode user. c()
Please note that [constr_1210] prevents the existence of configurations where the
mode user is not in a defined mode when no transition is ongoing.
[TPS_SWCT_01545] ModeDeclaration of a mode user that is not mapped to a
ModeDeclaration of a mode manager d A ModeDeclaration of a mode user that
is not mapped to a ModeDeclaration of a mode manager represents a valid model.
In this case the related mode is never entered nor exit during runtime of the ECU. c
(RS_SWCT_03115)

4.3.1.4 Mapping of Trigger Interface Elements

[TPS_SWCT_01161] TriggerInterfaceMapping d The TriggerInter-

faceMapping defines the correlation of Triggers defined in the context Trigger-
Interfaces. c(RS_SWCT_03210)

133 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Class TriggerInterfaceMapping
Package M2::AUTOSARTemplates::SWComponentTemplate::PortInterface
Note Defines the mapping of unequal named Triggers in context of two different TriggerInterfaces.
Base ARObject, AtpBlueprint, AtpBlueprintable, Identifiable, MultilanguageReferrable, PortInterfaceMapping,
Referrable
Attribute Type Mul. Kind Note
triggerMapping TriggerMapping 1..* aggr Mapping of two Trigger in two different TriggerInterface

Table 4.31: TriggerInterfaceMapping

Class TriggerMapping
Package M2::AUTOSARTemplates::CommonStructure::TriggerDeclaration
Note Defines the mapping of two particular unequally named Triggers in the given context.
Base ARObject
Attribute Type Mul. Kind Note
firstTrigger Trigger 1 ref A Trigger to be mapped.
secondTrigger Trigger 1 ref A Trigger to be mapped.

Table 4.32: TriggerMapping

PortInterfaceMapping PortInterface
TriggerInterfaceMapping TriggerInterface

+triggerMapping 1..* +trigger 1..*

+firstTrigger AtpStructureElement
TriggerMapping
Identifiable
1
Trigger
+secondTrigger
+ swImplPolicy: SwImplPolicyEnum [0..1]
1

Figure 4.13: Mapping of TriggerInterface elements

4.3.1.5 Mapping of Elements of a composite Data Type

The mapping of elements of PortInterfaces is not limited to mapping entire Dat-

aPrototypes onto each others.
[TPS_SWCT_01023] Mapping of elements of composite data types d For appli-
cations of DataInterfaces it is also possible to formally describe the mapping of
elements of ApplicationCompositeDataTypes or ImplementationDataTypes
of category STRUCTURE or ARRAY onto each others. c(RS_SWCT_03210,
RS_SWCT_03135)
This ability can be used if e.g. dataElements on the sender and receiver side are
typed by different ApplicationRecordDataTypes.

134 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

In this case the mapping of elements of ApplicationCompositeDataTypes or Im-

plementationDataTypes of category STRUCTURE or ARRAY onto each others al-
lows for the definition of specific pairs of elements that fulfill the compatibility rules.
[TPS_SWCT_01551] Mapping of elements on the sender side to elements on the
receiver side d Unless the attribute swImplPolicy is set to queued, it is not required
that all elements on the sender side need to be mapped to elements on the receiver
side to achieve compatibility. c(RS_SWCT_03210, RS_SWCT_03135)
The details regarding the compatibility rules are explained in chapter 6.3.
[constr_1279] Unmapped elements of ApplicationCompositeDataTypes or
ImplementationDataTypes and the attribute swImplPolicy d If the attribute
swImplPolicy is set to queued it is not allowed to have unmapped elements of Ap-
plicationCompositeDataTypes or ImplementationDataTypes of category
STRUCTURE or ARRAY on the receiver side. c()
[constr_1280] Unmapped dataElement on the receiver side shall have an init-
Value d If elements of ApplicationCompositeDataTypes or Implementation-
DataTypes of category STRUCTURE or ARRAY are not considered in a SubEle-
mentMapping then the enclosing dataElement shall have an initValue if the
NonqueuedReceiverComSpec is aggregated by an AbstractRequiredPortPro-
totype. c()

135 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

DataPrototypeMapping TextTableMapping «enumeration»

+textTableMapping MappingDirectionEnum
+ identicalMapping: Boolean
0..2 + mappingDirection: MappingDirectionEnum bidirectional
firstToSecond
«atpVariation»
secondToFirst
+ bitfieldTextTableMaskFirst: PositiveInteger [0..1]
+ bitfieldTextTableMaskSecond: PositiveInteger [0..1]

+textTableMapping 0..2

+subElementMapping 0..*

SubElementMapping

  
   
 
«atpVariation» «atpVariation»

+firstElement 0..1 +secondElement 0..1

SubElementRef

ApplicationCompositeDataTypeSubElementRef ImplementationDataTypeSubElementRef

«instanceRef» «instanceRef» «instanceRef»

+applicationCompositeElement 1 +parameterImplementationDataTypeElement 0..1 +implementationDataTypeElement 0..1

DataPrototype AbstractImplementationDataTypeElement
ApplicationCompositeElementDataPrototype ImplementationDataTypeElement

+ arraySizeHandling: ArraySizeHandlingEnum [0..1]

+ arraySizeSemantics: ArraySizeSemanticsEnum [0..1]
+ isOptional: Boolean [0..1]
«atpVariation»
+ arraySize: PositiveInteger [0..1]

+subElement 0..*
{ordered}

«atpVariation»

  
   
 

Figure 4.14: Mapping of elements of composite data types

[TPS_SWCT_01024] Combination of ApplicationCompositeDataType and

nested ImplementationDataType d The mapping of elements of Application-
CompositeDataTypes or ImplementationDataTypes of category STRUCTURE
or ARRAY works for both ApplicationCompositeDataType and nested Imple-
mentationDataTypes and even for combinations of them, i.e. one PortIn-
terface may use an ApplicationCompositeDataType while the other Port-
Interface uses a nested ImplementationDataType. c(RS_SWCT_03210,
RS_SWCT_03135)

136 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[TPS_SWCT_01195] Mapping of composite element to primitive DataPrototype

d It is also possible to map an element of a composite data type on the provided side to
a primitive DataPrototype on the required side. For this purpose the multiplicity of
the firstElement shall be set to 1 and the multiplicity of the secondElement shall
be set to 0. c(RS_SWCT_03136)
In general, the multiplicity of the firstElement can technically also be set to 0 but
this case is reserved for future use.
[constr_1190] Only one mapping for composite to primitive use case d In the case
described by [TPS_SWCT_01195] only one subElementMapping shall exist at the
enclosing DataPrototypeMapping. c()
[constr_1300] Primitive DataPrototype on the provider side shall not be
mapped to element of a composite data type on the requester side d The usage of
DataPrototypeMapping or SubElementMapping does not support the following
configuration:
• The AutosarDataPrototype referenced on the provider/client side is typed by
an ApplicationPrimitiveDataType of category VALUE or Implemen-
tationDataType of category VALUE or category TYPE_REFERENCE that
eventually resolves to category VALUE.
• The DataPrototypeMapping aggregates a subElementMapping that refers
to a ImplementationDataTypeElement or ApplicationCompositeEle-
mentDataPrototype on the requester/server side.
c()
[constr_1611] Existence of ImplementationDataTypeSubElementRef.imple-
mentationDataTypeElement as opposed to ImplementationDataType-
SubElementRef.parameterImplementationDataTypeElement d For any given
ImplementationDataTypeSubElementRef, either the aggregation
• ImplementationDataTypeSubElementRef.implementationDataType-
Element or
• ImplementationDataTypeSubElementRef.parameterImplementa-
tionDataTypeElement
shall exist. c()
In other words, the ImplementationDataTypeSubElementRef shall either refer
to the nested hierarchy inside a VariableDataPrototype or a ParameterDat-
aPrototype.

137 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Class SubElementMapping
Package M2::AUTOSARTemplates::SWComponentTemplate::PortInterface
Note This meta-class allows for the definition of mappings of elements of a composite data type.
Base ARObject
Attribute Type Mul. Kind Note
firstElement SubElementRef 0..1 aggr This represents the first element referenced in the scope
of the mapping.
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime
secondElement SubElementRef 0..1 aggr This represents the second element referenced in the
scope of the mapping.
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime
textTable TextTableMapping 0..2 aggr This allows for the text-table translation of individual
Mapping elements of a composite data type.

Table 4.33: SubElementMapping

Class SubElementRef (abstract)

Package M2::AUTOSARTemplates::SWComponentTemplate::PortInterface
Note This meta-class provides the ability to reference elements of composite data type.
Base ARObject
Subclasses ApplicationCompositeDataTypeSubElementRef, ImplementationDataTypeSubElementRef
Attribute Type Mul. Kind Note
– – – – –
Table 4.34: SubElementRef

Class ImplementationDataTypeSubElementRef
Package M2::AUTOSARTemplates::SWComponentTemplate::PortInterface
Note This meta-class represents the specialization of SubElementMapping with respect to Implementation
DataTypes.
Base ARObject, SubElementRef
Attribute Type Mul. Kind Note
implementation ArVariableIn 0..1 aggr This represents the referenced implementationDataType
DataType ImplementationData Element.
Element InstanceRef
parameter ArParameterIn 0..1 aggr This represents the referenced ImplementationDataType
Implementation ImplementationData Element.
DataType InstanceRef
Element
Table 4.35: ImplementationDataTypeSubElementRef

138 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Class ApplicationCompositeDataTypeSubElementRef
Package M2::AUTOSARTemplates::SWComponentTemplate::PortInterface
Note This meta-class represents the specialization of SubElementMapping with respect to Application
CompositeDataTypes.
Base ARObject, SubElementRef
Attribute Type Mul. Kind Note
application ApplicationComposite 1 iref This represents the referenced ApplicationComposite
Composite ElementDataPrototype DataPrototype.
Element
Table 4.36: ApplicationCompositeDataTypeSubElementRef

SubElementRef

PortInterface
ApplicationCompositeDataTypeSubElementRef
DataInterface

+base 1
{redefines
atpBase}
«atpDerived»

1 +applicationCompositeElement
AtpPrototype AtpInstanceRef
DataPrototype ApplicationCompositeElementInPortInterfaceInstanceRef

«instanceRef»

1 0..*
{redefines {subsets
+applicationCompositeElement 1 +targetDataPrototype atpTarget} +contextDataPrototype atpContextElement}

ApplicationCompositeElementDataPrototype

AutosarDataPrototype
+rootDataPrototype

1
{subsets
atpContextElement}

Figure 4.15: Implementation of the InstanceRef for the mapping of elements of compos-
ite application data types

[constr_1184] Consistency of rootDataPrototype and base in the context of

ApplicationCompositeElementInPortInterfaceInstanceRef d The root-
DataPrototype referenced by ApplicationCompositeElementInPortInter-
faceInstanceRef shall be owned by the applicable subclass of DataInterface
referenced in the role base.

139 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

This implies that the rootDataPrototype shall be a ParameterDataPrototype if

the base is a ParameterInterface. Otherwise the rootDataPrototype shall be
a VariableDataPrototype. c()
[constr_1185] Consistency of data types in the context of ApplicationCompos-
iteElementInPortInterfaceInstanceRef d The definition of attributes con-
textDataPrototype and targetDataPrototype shall (via the type-prototype pat-
tern) be enclosed in the context of the definition of the data type used to type root-
DataPrototype. c()
In other words, it shall be possible to reach contextDataPrototype and target-
DataPrototype by means of the type-prototype chain created by the definition of the
data type used to type rootDataPrototype. And, as implied by the definition of the
InstanceRef, the contextDataPrototypes shall enclose each others and, eventu-
ally, the targetDataPrototype.
SubElementRef
ImplementationDataTypeSubElementRef

«instanceRef»

0..1 +implementationDataTypeElement +implementationDataTypeElement 0..1

AbstractImplementationDataTypeElement
+contextDataPrototype ArVariableInImplementationDataInstanceRef
ImplementationDataTypeElement
0..*
+ arraySizeHandling: ArraySizeHandlingEnum [0..1] {ordered}
+ arraySizeSemantics: ArraySizeSemanticsEnum [0..1]
+ isOptional: Boolean [0..1] +targetDataPrototype
«atpVariation»
+ arraySize: PositiveInteger [0..1] 1

0..* +subElement +subElement 0..*

{ordered} {ordered}

ARElement
AtpType
«atpVariation»
AutosarDataType

+type 1
«atpVariation» {redefines atpType}

«isOfType»

DataPrototype
AutosarDataPrototype

  
   
 

+rootVariableDataPrototype 0..1

AbstractImplementationDataType
VariableDataPrototype
ImplementationDataType

+ dynamicArraySizeProfile: String [0..1]

+ isStructWithOptionalElement: Boolean [0..1]
+ typeEmitter: NameToken [0..1]

Figure 4.16: Implementation of the InstanceRef for the mapping of elements of a Vari-
ableDataPrototype typed by a composite implementation data type

140 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[constr_1186] Consistency of data types in the context of ArVariableInImple-

mentationDataInstanceRef d The definition of attributes contextDataProto-
type and targetDataPrototype shall be enclosed in the context of the definition
of the data type used to type rootVariableDataPrototype. c()
SubElementRef
ImplementationDataTypeSubElementRef

«instanceRef»

+parameterImplementationDataTypeElement 0..1 +parameterImplementationDataTypeElement 0..1

AbstractImplementationDataTypeElement
+contextDataPrototype ArParameterInImplementationDataInstanceRef
ImplementationDataTypeElement
0..*
+ arraySizeHandling: ArraySizeHandlingEnum [0..1] {ordered}
+ arraySizeSemantics: ArraySizeSemanticsEnum [0..1]
+ isOptional: Boolean [0..1]
+targetDataPrototype
«atpVariation»
+ arraySize: PositiveInteger [0..1] 1

+subElement 0..* {ordered} +subElement 0..*

{ordered}

ARElement
AtpType
«atpVariation» AutosarDataType

+type 1
{redefines atpType}

«isOfType»
«atpVariation»

DataPrototype
AutosarDataPrototype

  
   
 

+rootParameterDataPrototype 0..1

AbstractImplementationDataType
ParameterDataPrototype
ImplementationDataType

+ dynamicArraySizeProfile: String [0..1]

+ isStructWithOptionalElement: Boolean [0..1]
+ typeEmitter: NameToken [0..1]

Figure 4.17: Implementation of the InstanceRef for the mapping of elements of a Param-
eterDataPrototype typed by a composite implementation data type

[constr_1518] Consistency of data types in the context of ArParameterInIm-

plementationDataInstanceRef d The definition of attributes contextDataPro-
totype and targetDataPrototype shall be enclosed in the context of the definition
of the data type used to type rootParameterDataPrototype. c()

4.3.2 Data Conversion

[TPS_SWCT_01560] Supported categorys of CompuMethods for data conver-

sion d Data conversion shall be supported for AutosarDataTypes that refer to Com-
puMethods of category

141 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

• LINEAR,
• IDENTICAL,
• SCALE_LINEAR_AND_TEXTTABLE,
• TEXTTABLE,
• BITFIELD_TEXTTABLE, and
• RAT_FUNC - as long as the semantics of the latter comes down to a reciprocal
linear data scaling.
c(RS_SWCT_03210)
[TPS_SWCT_01561] Application of data conversion to composite Autosar-
DataTypes d Data conversion is also applicable for composite AutosarDataTypes.
The actual conversion, however, shall be individually applied to each leaf element of a
given composite AutosarDataType. c(RS_SWCT_03210)

4.3.2.1 Linear Data Scaling

A Linear Data Scaling can be defined under following preconditions:

[TPS_SWCT_01549] Definition of linear data scaling d The term Linear Scaling
is defined as follows:
1. Regarding the existence of CompuMethods one of the following cases shall ap-
ply:
(a) The involved AutosarDataTypes refer to CompuMethods of category
IDENTICAL, LINEAR, or RAT_FUNC.
(b) If one side (sender or receiver) does not refer a CompuMethod then a “de-
fault” CompuMethod of category IDENTICAL shall be assumed.
2. Regarding the existence of Units one of the following cases shall apply:
(a) The CompuMethods refer either to compatible Units or to Units that in
turn refer to compatible definitions of PhysicalDimension.
(b) Units and PhysicalDimensions do partially not exist on one side:
• If one side (sender or receiver) does not refer to a Unit, then an “imag-
inary” Unit with the properties defined in [TPS_SWCT_01492] shall be
assumed.
• if the PhysicalDimension is only defined on one side (sender or re-
ceiver) then it shall be considered as default for the other side.
3. Both CompuMethods fulfill the following condition:
N0 ∗phys0 +N1 ∗phys1 +N2 ∗phys2 +...+Ni ∗physi
Int = D 0 1 2 i with
0 ∗phys +D1 ∗phys +D2 ∗phys +...+Di ∗phys

142 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

• N2 =N3 =...=Ni =0
• D1 =D2 =...=Di =0
• N1 6=0
• D0 6=0
The coefficient N0 represents the offset and can take any value.
c(RS_SWCT_03210)
[TPS_SWCT_01550] Definition of reciprocal linear data scaling d The term Re-
ciprocal Linear Scaling is defined as follows:
1. The involved AutosarDataTypes refer to CompuMethods of category
RAT_FUNC.
2. The CompuMethods refer either to compatible Units or to Units that in turn
refer to compatible definitions of PhysicalDimension.
3. Both CompuMethods fulfill the following condition:
N0 ∗phys0 +N1 ∗phys1 +N2 ∗phys2 +...+Ni ∗physi
Int = D 0 1 2 i with
0 ∗phys +D1 ∗phys +D2 ∗phys +...+Di ∗phys

• N1 =N2 =...=Ni =0
• D2 =D3 =...=Di =0
• N0 6=0
• D1 6=0
The coefficient D0 represents the (reciprocal) offset and can take any value.
c(RS_SWCT_03210)
[TPS_SWCT_01168] Linear conversion factor can be calculated d In such cases
a linear conversion factor can be calculated out of the factorSiToUnit and off-
setSiToUnit attributes of the referred Units and the CompuRationalCoeffs of a
compuInternalToPhys/compuPhysToInternal of the referred CompuMethods. c
(RS_SWCT_03210)

4.3.2.2 Table Conversion

[TPS_SWCT_01162] Existence of TextTableMapping d A TextTableMapping

can be defined if the AutosarDataTypes refer to CompuMethods of cate-
gory TEXTTABLE, SCALE_LINEAR_AND_TEXTTABLE, and BITFIELD_TEXTTABLE.
c(RS_SWCT_03210)
Please note that the use case behind the appearance of BITFIELD_TEXTTABLE in
[TPS_SWCT_01162] is the fact that BSW modules such as the Dem need to put data
into the NVRAM that has the nature of single bits embedded into a composite data type.

143 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

The TextTableMapping is defined as a table based conversion.

[TPS_SWCT_01163] Conversion from firstValue to secondValue d A first-
Value of a valuePair is converted into the secondValue in case of a data flow from
the firstDataPrototype to the secondDataPrototype. c(RS_SWCT_03210)
[TPS_SWCT_01164] Conversion from secondValue to firstValue d In case of a
data flow from the secondDataPrototype to firstDataPrototype the second-
Value is substituted by the firstValue. c(RS_SWCT_03210)
[TPS_SWCT_01165] Invertible mapping d If the mappingDirection attribute is set
to bidirectional then the TextTableMapping has to be invertible. This requires
that the list of all firstValues and the list of all secondValues do not contain iden-
tical values inside a list. c(RS_SWCT_03210)
[TPS_SWCT_01166] Non-invertible mapping d For non-invertible TextTableMap-
ping, a dedicated TextTableMapping for each direction can be defined. c
(RS_SWCT_03210)
[constr_1303] Applicability of TextTableMapping depending on the value of
CompuMethod.category d If a DataPrototypeMapping aggregates a Text-
TableMapping then only certain combinations of the value of the applicable Com-
puMethod.category are supported:
• category of firstDataPrototype: TEXTTABLE,
category of secondDataPrototype: TEXTTABLE
• category of firstDataPrototype: SCALE_LINEAR_AND_TEXTTABLE,
category of secondDataPrototype: TEXTTABLE
• category of firstDataPrototype: TEXTTABLE,
category of secondDataPrototype: SCALE_LINEAR_AND_TEXTTABLE
• category of firstDataPrototype: BITFIELD_TEXTTABLE,
category of secondDataPrototype: TEXTTABLE
• category of firstDataPrototype: TEXTTABLE,
category of secondDataPrototype: BITFIELD_TEXTTABLE
• category of firstDataPrototype: BITFIELD_TEXTTABLE,
category of secondDataPrototype: BITFIELD_TEXTTABLE
c()
To some extent, bitfields can be regarded as a hybrid between a primitive and a struc-
tured data type:
• On the one hand, a bitfield is defined in the context of a primitive Implementa-
tionDataType.
• On the other hand, by means of the definition of a mask, it is possible to define
isolated parts within the primitive ImplementationDataType that potentially

144 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

can be totally independent from each other with respect to the semantics of the
data that match the mask.
In other words, the existence of semantically independent and potentially isolated parts
within the primitive ImplementationDataType creates a similar characteristic as
if the definitions of the isolated parts were created by means of defining primitive Im-
plementationDataTypeElements within the context of a composite Implemen-
tationDataType.
And because it is possible to regard the “mission statement” of a DataPrototype
that refers to a CompuMethod of category BITFIELD_TEXTTABLE as to mimic the
semantics of a structured data type it is also possible to apply some of the rules that
are already in place for structured data types in this specific case as well.
This conclusion, in combination with the existence of [TPS_SWCT_01551], sets the
stage for [TPS_SWCT_01583].
[TPS_SWCT_01583] Completeness of TextTableMapping is not a requirement
d If a DataPrototypeMapping contains one or more TextTableMapping(s) where
the DataPrototype on the sender side refers to a CompuMethod of category
BITFIELD_TEXTTABLE it is not required that for each possible value and each possi-
ble bit mask on the sender side corresponding values on the receiver side are specified.
c(RS_SWCT_03210)
With respect to [TPS_SWCT_01583] it is still important to observe that within a single
mask all values on the sender side shall have a mapping to the receiver side.
Otherwise the RTE generator would not be able to create mapping code that unam-
biguously takes care of mapping the correct values onto each other.
[constr_1313] Completeness of TextTableMapping for the values of a given bit
mask on the sender side d If a DataPrototypeMapping contains one or more
TextTableMapping(s) where the DataPrototype on the sender side refers to a
CompuMethod of category BITFIELD_TEXTTABLE then all DataPrototypeMap-
ping.textTableMapping shall aggregate a collection of TextTableMapping.val-
uePair where each possible value of the sender bit mask6 is represented by
exactly one TextTableValuePair.firstValue ([TPS_SWCT_01163]) or Text-
TableValuePair.secondValue ([TPS_SWCT_01164]). c()
[constr_1304] Existence of attribute bitfieldTextTableMaskFirst d The at-
tribute bitfieldTextTableMaskFirst shall be defined only if the firstDat-
aPrototype of a DataPrototypeMapping refers to a CompuMethod that has the
value of category set to BITFIELD_TEXTTABLE. c()
6
Depending on the applicable case this means either bitfieldTextTableMaskFirst (ap-
plies if [TPS_SWCT_01163] is in place) or bitfieldTextTableMaskSecond for the case of
[TPS_SWCT_01164].

145 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[constr_1305] Existence of attribute bitfieldTextTableMaskSecond d The at-

tribute bitfieldTextTableMaskSecond shall be defined only if the secondDat-
aPrototype of a DataPrototypeMapping refers to a CompuMethod that has the
value of category set to BITFIELD_TEXTTABLE. c()
[constr_1306] Limitation of TextTableMapping for CompuMethods that have
the value of category set to BITFIELD_TEXTTABLE d For any TextTableMap-
ping where both firstDataPrototype and secondDataPrototype refer to Com-
puMethods that have the value of category set to BITFIELD_TEXTTABLE and
where the attribute TextTableMapping.valuePair exists the value of attribute
TextTableMapping.identicalMapping shall be set to false. c()
[constr_1307] Consistency of values and masks in TextTableMapping d
If a TextTableMapping element defines bit masks as bitfieldTextTable-
MaskFirst or bitfieldTextTableMaskSecond then all contained Text-
TableMapping.valuePair.firstValues as well as all TextTableMapping.val-
uePair.secondValues shall not specify a value that would be ruled out when - de-
pending on the given value of TextTableMapping.mappingDirection - the rele-
vant bit mask is applied. c()
Example for [constr_1307]: For a bit mask 0b00001000 only the corresponding values
8 and 0 are allowed.
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 Mul. 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 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 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 4.37: TextTableMapping

146 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Enumeration MappingDirectionEnum
Package M2::AUTOSARTemplates::SWComponentTemplate::PortInterface
Note Specifies the conversion direction for which the mapping is applicable.
Literal Description
bidirectional The TextTableMapping is applicable in both directions.
Tags: atp.EnumerationValue=0
firstToSecond The TextTableMapping is applicable in the direction from firstDataPrototype / firstOperationArgument
referring into the PortInterface of the PPortPrototype to secondDataPrototype / secondOperation
Argument referring into the PortInterface of the RPortPrototype.
Tags: atp.EnumerationValue=1
secondToFirst The TextTableMapping is applicable in the direction from secondDataPrototype / secondOperation
Argument referring into the PortInterface of the PPortPrototype to firstDataPrototype / firstOperation
Argument referring into the PortInterface of the RPortPrototype.
Tags: atp.EnumerationValue=2

Table 4.38: MappingDirectionEnum

Class TextTableValuePair
Package M2::AUTOSARTemplates::SWComponentTemplate::PortInterface
Note Defines a pair of text values which are translated into each other.
Base ARObject
Attribute Type Mul. Kind Note
firstValue Numerical 1 attr Value of first DataPrototype provided similar to a
numerical ValueSpecification which is intended to be
assigned to a Primitive data element.
Note that the numerical value is a variant, it can be
computed by a formula.
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime
secondValue Numerical 1 attr Value of second DataPrototype provided similar to a
numerical ValueSpecification which is intended to be
assigned to a Primitive data element.
Note that the numerical value is a variant, it can be
computed by a formula.
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime

Table 4.39: TextTableValuePair

147 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

+firstDataPrototype DataPrototype
DataPrototypeMapping
AutosarDataPrototype
1
+secondDataPrototype

+textTableMapping 0..2

TextTableMapping «enumeration»
MappingDirectionEnum
+ identicalMapping: Boolean
+ mappingDirection: MappingDirectionEnum bidirectional
firstToSecond
«atpVariation»
secondToFirst
+ bitfieldTextTableMaskFirst: PositiveInteger [0..1]
+ bitfieldTextTableMaskSecond: PositiveInteger [0..1]

+valuePair 0..*

TextTableValuePair

«atpVariation»
+ firstValue: Numerical
+ secondValue: Numerical

Figure 4.18: Mapping of DataPrototypes that eventually refer to CompuMethods of cat-

egory TEXTTABLE, SCALE_LINEAR_AND_TEXTTABLE, and BITFIELD_TEXTTABLE

4.3.3 Relevance for Data Transformation

One (prominent) use-case for item 4 in [TPS_SWCT_01158] is the interaction between

the NvBlockSwComponentType and the AUTOSAR Dcm.
Specifically, the RTE will call a data transformer to convert the uint8-array representa-
tion of the diagnostic data available from a PortPrototype owned by the Dcm Ser-
viceSwComponentType to a VariableDataPrototype owned by a PortProto-
type of NvBlockSwComponentType.
For the configuration of this purpose, the applicable DataPrototypeMapping refers
to a DataTransformation in the role firstToSecondDataTransformation and
- for the case of two connected PortPrototypes that use asymmetric data transfor-
mation - secondToFirstDataTransformation (see Figure 4.19).
Identifiable
DataPrototypeMapping
+firstToSecondDataTransformation DataTransformation
0..1 + dataTransformationKind: DataTransformationKindEnum [0..1]
+ executeDespiteDataUnavailability: Boolean
+secondToFirstDataTransformation

0..1

Figure 4.19: Configuration of Ecu-internal data transformation

Note that for this specific interaction between an ApplicationSwComponentType

and a ServiceSwComponentType [TPS_SWCT_01579] applies which defines that
attribute isService shall be set to false for the dataElements in PortPrototypes
typed by a SenderReceiverInterface.

148 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[TPS_SWCT_01768] Semantics of DataPrototypeMapping.secondToFirst-

DataTransformation d For symmetric data transformations (i.e. the value of at-
tribute DataTransformation.dataTransformationKind is set to DataTrans-
formationKindEnum.symmetric) it is sufficient to specify the reference first-
ToSecondDataTransformation.
There are, however, use cases for asymmetric data transformations between two con-
nected PRPortPrototypes and in this case it is necessary to specify each direction
separately.
For this purpose, the reference secondToFirstDataTransformation exists in ad-
dition to firstToSecondDataTransformation. c(RS_SWCT_03210)
Figure 4.20 describes the most prominent use case for the necessity to specify both
firstToSecondDataTransformation and secondToFirstDataTransforma-
tion.

TransformationTechnology DataTransformation
protocol=SomeIp transformerChain dataTransformationKind=
asymmetricToByteArray

transformerChain firstToSecondDataTransformation

DataTransformation
dataTransformationKind=
secondToFirstDataTransformation
asymmetricFromByteArray
VariableAndParameterMapping

DataPrototypeMapping

SwComponentPrototype typed by
NvBlockSwComponentType SwComponentPrototype typed by
ServiceSwComponentType (Dcm)

NvDataInterface

nvData AssemblySwConnector SenderReceiverInterface

RecordElement 1 dataElement
PRPortPrototype
RecordElement 2 Byte-Array
PRPortPrototype
RecordElement 3

RecordElement 4

Figure 4.20: Use case for the existence of asymmetric data transformation in both direc-
tions

An SwComponentPrototype typed by NvBlockSwComponentType exposes a PR-

PortPrototype that is connected to another PRPortPrototype attached to an
SwComponentPrototype that represents the Dcm service software-component.

149 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

The PRPortPrototype on the side of the NvBlockSwComponentType in typed by

an NvDataInterface that in turn aggregates a single nvData. The data type used
to define the nvData is a structured data type.
The service software-component representing the Dcm, however, is not capable of
dealing with structured data types. It can only handle primitive types and arrays of
primitive types, e.g. bytes.
Therefore, the existence of (asymmetric) data transformers is conveniently utilized to
serialize the content of the structured data type into a linear array and vice versa.
To expressly define this intended semantics, the DataPrototypeMapping defines
two references:
• firstToSecondDataTransformation that refers to a DataTransforma-
tion where attribute dataTransformationKind is set to the value asymmet-
ricToByteArray. This reference represents the direction from the NvBlock-
SwComponentType to the Dcm.
• secondToFirstDataTransformation that refers to a DataTransforma-
tion where attribute dataTransformationKind is set to the value asym-
metricFromByteArray. This reference represents the direction from the Dcm
to the NvBlockSwComponentType.
This approach to modeling is formalized in [constr_1631] and [constr_1632].
[constr_1631] Applicability of DataPrototypeMapping.secondToFirstData-
Transformation d The reference to DataTransformation in the role DataPro-
totypeMapping.secondToFirstDataTransformation shall only exist if refer-
ence DataPrototypeMapping.firstToSecondDataTransformation exists and
refers to a DataTransformation where attribute dataTransformationKind ex-
ists and is not set to the value symmetric. c()
[constr_1632] Restriction for firstToSecondDataTransformation and sec-
ondToFirstDataTransformation d If both the reference firstToSecondData-
Transformation and the reference secondToFirstDataTransformation exist
in the context of the same DataPrototypeMapping then
• the firstToSecondDataTransformation shall refer to a DataTransfor-
mation with attribute dataTransformationKind set to asymmetricTo-
ByteArray and
• the secondToFirstDataTransformation shall refer to a DataTransfor-
mation with attribute dataTransformationKind set to asymmetricFrom-
ByteArray.
c()

150 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

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 Mul. 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 4.40: DataTransformation

Enumeration DataTransformationKindEnum
Package M2::AUTOSARTemplates::SystemTemplate::Transformer
Note This enumeration contributes to the definition of the scope of the DataTransformation.
Literal Description
asymmetricFrom The DataTransformation shall only be applied to the receiving end only, i.e. transform from byte array
ByteArray to data type.
Tags: atp.EnumerationValue=0
asymmetricToByte The DataTransformation shall be applied to the sending end only, i.e. from data type to byte array.
Array
Tags: atp.EnumerationValue=1
symmetric The DataTransformation shall be applied at both the sending and the receiving end of the
communication.
Tags: atp.EnumerationValue=2

Table 4.41: DataTransformationKindEnum

4.4 Port Annotation

4.4.1 Introduction

[TPS_SWCT_01203] PortPrototype may own port annotations d In addition to

the formal specification required to implement the communication via ports, a Port-
Prototype may own so-called port annotations.
They do not directly influence the signature of calls via this PortPrototype, but con-
tain further information that may be useful for the application developers of the compo-
nents on both sides of the connection. c()
A summary of port-level annotations can be found in Figure 4.21.
[TPS_SWCT_01204] GeneralAnnotation d Beside formally specified attributes it is
also possible to place textual information as provided in GeneralAnnotation. c()

151 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

ARElement
AtpBlueprint
AtpBlueprintable
AtpType
SwComponentType

  
   
 
«atpVariation,atpSplitable»
+port 0..*

AtpBlueprintable GeneralAnnotation
AtpPrototype SenderReceiverAnnotation
PortPrototype +senderReceiverAnnotation
constraints
0..* {"port's interface is a SenderReceiverInterface"}

GeneralAnnotation
DelegatedPortAnnotation
+delegatedPortAnnotation
constraints
0..1
{aggregating PortPrototype is a port of a CompositionSwComponentType (DelegatedPort)}

GeneralAnnotation
+failureMonitoring IoHwAbstractionServerAnnotation

0..1 constraints
{"port's interface is a client/server interface using the operations GET and SET"}
+ioHwAbstractionServerAnnotation

0..*

GeneralAnnotation
ParameterPortAnnotation
+parameterPortAnnotation
constraints
0..*
{"The corresponding port interface shall be a ParameterInterface."}

GeneralAnnotation
ModePortAnnotation
+modePortAnnotation
constraints
0..* {"The corresponding port interface shall be a ModeInterface."}

GeneralAnnotation
NvDataPortAnnotation
+nvDataPortAnnotation constraints
{"The corresponding port interface shall be a NvDataInterface."}
0..*

GeneralAnnotation
TriggerPortAnnotation
+triggerPortAnnotation
constraints
0..*
{"The corresponding port interface shall be a TriggerInterface."}

GeneralAnnotation
ClientServerAnnotation
+clientServerAnnotation
constraints
0..* {"The corresponding PortInterface shall be a ClientServerInterface."}

Figure 4.21: Application Level Port Annotations Overview

152 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4.4.2 SenderReceiverAnnotation

Embedded automotive software is used to implement open-loop and closed-loop

control-algorithms. Therefore, a software-component description has to accommodate
typical control engineering description means which have only indirect influence of the
embedded software itself.
These annotations provide the (function-) developer with a direct indication whether
a certain software-component is appropriate for the control-algorithm to be designed.
A typical annotation is the signal quality which is characterized by several properties.
Each of the property is an annotation in its own.
[TPS_SWCT_01205] Typical annotations for sender/receiver communication d
Typical annotations for sender/receiver communication are:
• Signal Age: this attribute expresses that the associated software-component will
only work correctly given that the propagation of the signal from a sensor to a
consumer can be finished within a particular time-limit. Of course, this cannot be
identified on component or role level, but has to take into account the instance
view as well as the actual ECU- and bus-scheduling.
• Raw: a raw signal is typically taken directly from the basic software modules
of the ECU abstraction layer. In particular, no sensor software-component has
filtered its original value. A dataElement in an RPortPrototype of a SwCom-
ponentType using this annotation indicates to the control engineer (who devel-
ops a control-algorithm for this component) that the signal has to be filtered (This
relationship applies for SenderReceiverInterfaces).
• Filtered: this attribute indicates that a raw signal has been manipulated by some
application software-components by using a certain filter.
• Computed: this attribute indicates that this signal is not measured directly but
calculated from tentatively several other measured or calculated signals. In a
vehicle, there might be alternative signals to be used from other components
having a better quality, e.g. a raw signal.
• Min: this annotation indicates that the signal carries a minimum value. If, for
example, a reference value computed in the software-component is below that
value some dedicated actions (e.g. failure-mode) might have to be taken.
• Max: this annotation indicates that the signal carries a maximum value. If, for
example, a reference value computed in the software-component is above that
value some dedicated actions (e.g. failure-mode) might have to be taken.
In the meta-model this aspect is implemented by the abstract meta-class Sender-
ReceiverAnnotation which represents the base class of both SenderAnnota-
tion and ReceiverAnnotation. c()
The relationship of abstract abstract meta-class SenderReceiverAnnotation to
SenderAnnotation and ReceiverAnnotationis depicted in Figure 4.22.

153 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Class SenderReceiverAnnotation (abstract)

Package M2::AUTOSARTemplates::SWComponentTemplate::ApplicationAttributes
Note Annotation of the data elements in a port that realizes a sender/receiver interface.
Base ARObject, GeneralAnnotation
Subclasses ReceiverAnnotation, SenderAnnotation
Attribute Type Mul. Kind Note
computed Boolean 1 attr Flag whether this data element was not measured directly
but instead was calculated from possibly several other
measured or calculated values.
dataElement VariableDataPrototype 1 ref The instance of VariableDataPrototype annotated.
limitKind DataLimitKindEnum 1 attr This min or max has not to be mismatched with the min-
and max for data-value in a compu-method. For example,
this annotation
shows when the result of the calculation performed in a
RunnableEntity owned by one AtomicSwComponentType
is transmitted to another AtomicSwComponentType
whose RunnableEntity will use this value as a limit, e.g.
the max.power which can be used by that
software-component, or the current min. slip.
processingKind ProcessingKindEnum 1 attr This attribute controls how data is processed according to
the possible values of ProcessingKindEnum.

Table 4.42: SenderReceiverAnnotation

Class SenderAnnotation
Package M2::AUTOSARTemplates::SWComponentTemplate::ApplicationAttributes
Note Annotation of a sender port, specifying properties of data elements that don’t affect communication or
generation of the RTE.
Base ARObject, GeneralAnnotation, SenderReceiverAnnotation
Attribute Type Mul. Kind Note
– – – – –
Table 4.43: SenderAnnotation

Class ReceiverAnnotation
Package M2::AUTOSARTemplates::SWComponentTemplate::ApplicationAttributes
Note Annotation of a receiver port, specifying properties of data elements that don’t affect communication or
generation of the RTE. The given attributes are requirements on the required data.
Base ARObject, GeneralAnnotation, SenderReceiverAnnotation
Attribute Type Mul. Kind Note
signalAge MultidimensionalTime 1 aggr The maximum allowed age of the signal since it was
originally read by a sensor. This is a requirement
specified on the receiver side.

Table 4.44: ReceiverAnnotation

154 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Enumeration ProcessingKindEnum
Package M2::AUTOSARTemplates::SWComponentTemplate::ApplicationAttributes
Note Kind of processing which has been applied to a data element.
Literal Description
filtered Indicates that a raw signal has been manipulated by some application software components by using
filters.
Tags: atp.EnumerationValue=0
none Indicates that none of the other option apply.
Tags: atp.EnumerationValue=1
raw Specifies that a signal is taken directly from the basic software modules, i.e. from the ECU abstraction
layer. It indicates to a developer that the control algorithm in the software has to provide filters.
Tags: atp.EnumerationValue=2

Table 4.45: ProcessingKindEnum

Enumeration DataLimitKindEnum
Package M2::AUTOSARTemplates::SWComponentTemplate::ApplicationAttributes
Note Indicates whether the data element carries a minimum or maximum value, thereby limiting the current
range of another value.
Literal Description
max Limitation to maximum value
Tags: atp.EnumerationValue=0
min Limitation to minimum value
Tags: atp.EnumerationValue=1
none No limitation applicable
Tags: atp.EnumerationValue=2

Table 4.46: DataLimitKindEnum

[TPS_SWCT_01206] Min and Max annotations are valid for a certain amount of
time d The Min and Max annotations are valid for a certain amount of time. The value
is likely to change to another valid value while the ECU is running. E.g. the maximal
torque which can be requested from an engine is a typical use-case. c()
This value might vary depending on e.g. the status of the climate control system.
Therefore, these annotations shall not be mismatched with the min and max attributes
of CompuMethods.

155 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

AtpBlueprintable
AtpPrototype
PortPrototype

+senderReceiverAnnotation 0..*
GeneralAnnotation
SenderReceiverAnnotation

+ computed: Boolean +dataElement AutosarDataPrototype

+ limitKind: DataLimitKindEnum VariableDataPrototype
+ processingKind: ProcessingKindEnum 1

constraints
{"port's interface is a SenderReceiverInterface"}

«enumeration» «enumeration»
ProcessingKindEnum DataLimitKindEnum
SenderAnnotation ReceiverAnnotation
none none
raw min
filtered max

+signalAge 1

MultidimensionalTime

+ cseCode: CseCodeType
+ cseCodeFactor: Integer

Figure 4.22: SenderReceiverAnnotation

The application level port annotations for sender/receiver communication have to be

associated to each dataElement in a PortPrototype, e.g. there might be a “raw”
dataElement and a “filtered” dataElement in the same PortPrototype!
[TPS_SWCT_01207] VariableDataPrototypes use the same application-level
SenderReceiverAnnotation d Furthermore, if two VariableDataPrototypes
use the same application-level SenderReceiverAnnotation, a reference from the
annotation to the VariableDataPrototypes will be established by an appropriate
tool. c()
[TPS_SWCT_01208] Grouping for SenderReceiverAnnotation d The Sender-
ReceiverAnnotation for sender/receiver communication are grouped into
• processing type, indicating to some extend the direct quality of the signal,
• computed, which is just a flag or,
• limit type, showing the component expects an actual limit.
In the case of an RPortPrototype, the signal age of the value, carried by the asso-
ciated SwConnector, can be specified. Each of these groups can be interpreted as a
property of the signal-quality. c()
For more information about meta-class SenderReceiverAnnotation please refer
to Figure 4.22.

156 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[constr_4004] Context of SenderReceiverAnnotation d A SenderReceiver-

Annotation shall only be aggregated by a PortPrototype typed by a Sender-
ReceiverInterface. c()

4.4.3 ClientServerAnnotation

[TPS_SWCT_01209] ClientServerAnnotation d The ClientServerAnnota-

tion can be used to provide more information with respect to the ClientServerOp-
eration of the PortPrototype. c()
Class ClientServerAnnotation
Package M2::AUTOSARTemplates::SWComponentTemplate::ApplicationAttributes
Note Annotation to a port regarding a certain Operation.
Base ARObject, GeneralAnnotation
Attribute Type Mul. Kind Note
operation ClientServerOperation 1 ref This represents the ClientServerOperation that the Client
ServerAnnotation corresponds to.

Table 4.47: ClientServerAnnotation

The main use-case is to allow define additional information related to the

ClientServerOperation.
AtpBlueprintable
AtpPrototype
PortPrototype

+clientServerAnnotation 0..*

GeneralAnnotation
ClientServerAnnotation

+operation 1

AtpStructureElement
Identifiable
ClientServerOperation

Figure 4.23: ClientServerAnnotation

[constr_4005] Context of ClientServerAnnotation d A ClientServerAnno-

tation shall only be aggregated by a PortPrototype typed by a ClientServer-
Interface. c()

157 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4.4.4 Annotation for the I/O Hardware Abstraction Layer

Within the ECU-Abstraction Layer there are ECU-signals defined. These signals rep-
resent the electrical signals as they arrive in the micro-controller peripheral and are
fetched from the registers via the MCAL.
Access to the I/O Hardware Abstraction Layer is done via service interfaces, i.e. the I/O
Hardware Abstraction Layer provides GET- and SET-operations at the specified service
ports of a SensorActuatorSwComponentType.
[TPS_SWCT_01524] Usage of IoHwAbstractionServerAnnotation d IoHwAb-
stractionServerAnnotation can be used for all kinds of PortInterfaces ex-
cept NvDataInterface. c()
AtpBlueprintable AtpStructureElement DataInterface
AtpPrototype Identifiable SenderReceiverInterface
PortPrototype ClientServerOperation

0..1 +failureMonitoring

«atpVariation»

*
+argument {ordered}
+ioHwAbstractionServerAnnotation
0..*
  
AutosarDataPrototype
   
GeneralAnnotation ArgumentDataPrototype   
IoHwAbstractionServerAnnotation +argument

+ bswResolution: Float 0..1

+ filteringDebouncing: FilterDebouncingEnum
+ pulseTest: PulseTestEnum +dataElement 1..*

AutosarDataPrototype
+dataElement
VariableDataPrototype
0..1

AtpStructureElement
+trigger
Identifiable
Trigger
0..1
+ swImplPolicy: SwImplPolicyEnum [0..1]

+age 0..1

MultidimensionalTime +triggerPeriod

+ cseCode: CseCodeType 0..1

+ cseCodeFactor: Integer
+trigger 1..*

«enumeration» «enumeration» PortInterface

FilterDebouncingEnum PulseTestEnum TriggerInterface

rawData disable
debounceData enable
waitTimeDate

Figure 4.24: IoHwAbstractionServerAnnotation

158 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Class IoHwAbstractionServerAnnotation
Package M2::AUTOSARTemplates::SWComponentTemplate::ApplicationAttributes
Note The IoHwAbstractionServerAnnotation will only be used from a sensor- or an actuator component while
interacting with the IoHwAbstraction layer.
Note that the "server" in the name of this meta-class is not meant to restrict the usage to ClientServer
Interfaces.
Base ARObject, GeneralAnnotation
Attribute Type Mul. Kind Note
age MultidimensionalTime 0..1 aggr In case of a SET operation, the age will be interpreted as
Delay while in a GET operation (input) it specifies the
Lifetime of the signal within the IoHwAbstraction Layer
Tags: xml.sequenceOffset=10
argument ArgumentDataPrototype 0..1 ref Reference to the corresponding ArgumentDataPrototype.
Tags: xml.sequenceOffset=20
bswResolution Float 1 attr This value is determined by an appropriate combination
of the range, the unit as well as the data-elements type,
i.e. (ecuSignalRange.upperLimit-ecuSignalRange.lower
Limit) / (2d̂atatypelength - 1)
Tags: xml.sequenceOffset=30
dataElement VariableDataPrototype 0..1 ref Reference to the corresponding VariableDataPrototype.
Tags: xml.sequenceOffset=40
failure PortPrototype 0..1 ref This is only applicable in SET operations. If it is enabled,
Monitoring the IoHwAbstraction layer will monitor the result of the
operation and issue an diagnostic signal. This means
especially, that an additional client-server port has to be
created. Tools can use this information to cross-check
whether for each data-element in a SET operation with
FailureMonitoring enabled an additional port is created
The referenced port monitors a failure in the to be
monitored VariableDataPrototype of the IoHwAbstraction
layer. The referenced port has to be another port of the
same Actuator or Sensor Component.
Tags: xml.sequenceOffset=50
filtering FilterDebouncingEnum 1 attr This attribute is used to indicate what kind of
Debouncing filtering/debouncing has been put to the signal in the Io
HwAbstraction layer.
rawData means that no modification of the signal has
been applied. This is the default value
debounceData means that the signal is a mean value
waitTimeData means that the signal is delivered by a
GET operation after a certain amount of time
Tags: xml.sequenceOffset=60
pulseTest PulseTestEnum 1 attr This attribute indicates to the connected SensorActuator
SwComponentType whether the VariableDataPrototype
can be used to generate pulse test sequences using the
IoHwAbstraction layer
Tags: xml.sequenceOffset=70
trigger Trigger 0..1 ref Reference to the corresponding Trigger.
Tags: xml.sequenceOffset=80

Table 4.48: IoHwAbstractionServerAnnotation

159 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Enumeration FilterDebouncingEnum
Package M2::AUTOSARTemplates::SWComponentTemplate::ApplicationAttributes
Note This enumeration defines possible values for the filter debouncing strategy.
Literal Description
debounceData The signal is a
mean value
Tags: atp.EnumerationValue=0
rawData Means that no modification of the
signal has been applied. This is the default
value
Tags: atp.EnumerationValue=1
waitTimeDate The signal is delivered by a GET operation after a certain amount of time
Tags: atp.EnumerationValue=2

Table 4.49: FilterDebouncingEnum

Enumeration PulseTestEnum
Package M2::AUTOSARTemplates::SWComponentTemplate::ApplicationAttributes
Note This element indicates to the connected Actuator Software component whether the data-element can
be used to generate pulse test sequences using the IoHwAbstraction layer
Literal Description
disable Disables the pulse test
Tags: atp.EnumerationValue=0
enable Enables the pulse test
Tags: atp.EnumerationValue=1

Table 4.50: PulseTestEnum

[TPS_SWCT_01211] Assign several annotations to ArgumentDataPrototype d

The ClientServerOperations provide an ArgumentDataPrototype where sev-
eral annotations can be assigned to. c()
They are depicted in the IoHwAbstractionServerAnnotation meta-class in Fig-
ure 4.24.
A detailed description of the attributes can be found in the IoHwAbstraction Layer soft-
ware specification document [17]. For example, the signal age has a very dedicated
meaning in this particular interface with respect to a register whereas the signal age in
the SenderReceiverAnnotation is more generic. Especially, there is no relation-
ship with the micro-controller peripherals.

4.4.5 Parameter Port Annotation

[TPS_SWCT_01212] ParameterPortAnnotation d The ParameterPortAnno-

tation can be used to provide more information with respect to calibration parameter
prototypes of the PortPrototype. The data provided at the PortPrototype is
calibration parameters. The ParameterPortAnnotation provides a reference to a
particular ParameterDataPrototype. c()

160 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Class ParameterPortAnnotation
Package M2::AUTOSARTemplates::SWComponentTemplate::ApplicationAttributes
Note Annotation to a port used for calibration regarding a certain ParameterDataPrototype.
Base ARObject, GeneralAnnotation
Attribute Type Mul. Kind Note
parameter ParameterData 1 ref The instance of annotated ParameterDataPrototype.
Prototype

Table 4.51: ParameterPortAnnotation

The main use-case is to allow easy access to the information which calibration param-
eters influence the data on the PortPrototype.
AtpBlueprintable
AtpPrototype
PortPrototype

+parameterPortAnnotation 0..*

GeneralAnnotation
ParameterPortAnnotation

constraints
{"The corresponding port interface shall be a ParameterInterface."}

+parameter 1

AutosarDataPrototype
ParameterDataPrototype

Figure 4.25: ParameterPortAnnotation

[constr_4006] Context of ParameterPortAnnotation d A ParameterPortAn-

notation shall only be aggregated by a PPortPrototype owned by a Parame-
terSwComponentType. c()

4.4.6 Mode Port Annotation

[TPS_SWCT_01213] ModePortAnnotation d The ModePortAnnotation can be

used to provide more information with respect to the mode declaration group prototype
of the PortPrototype. c()

161 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Class ModePortAnnotation
Package M2::AUTOSARTemplates::SWComponentTemplate::ApplicationAttributes
Note Annotation to a port used for calibration regarding a certain ModeDeclarationGroupPrototype.
Base ARObject, GeneralAnnotation
Attribute Type Mul. Kind Note
modeGroup ModeDeclarationGroup 1 ref The instance of annotated ModeDeclarationGroup
Prototype Prototype.

Table 4.52: ModePortAnnotation

The main use-case is to allow for the definition of additional information related to the
mode declaration group prototype.
AtpBlueprintable
AtpPrototype
PortPrototype

+modePortAnnotation 0..*
GeneralAnnotation
ModePortAnnotation

+modeGroup 1

AtpPrototype
ModeDeclarationGroupPrototype

+ swCalibrationAccess: SwCalibrationAccessEnum [0..1]

Figure 4.26: ModePortAnnotation

[constr_4007] Context of ModePortAnnotation d A ModePortAnnotation shall

only be aggregated by a PortPrototype typed by a ModeSwitchInterface. c()

4.4.7 Trigger Port Annotation

[TPS_SWCT_01214] TriggerPortAnnotation d The TriggerPortAnnotation

can be used to provide more information with respect to the trigger of the PortPro-
totype. c()

162 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Class TriggerPortAnnotation
Package M2::AUTOSARTemplates::SWComponentTemplate::ApplicationAttributes
Note Annotation to a port used for calibration regarding a certain Trigger.
Base ARObject, GeneralAnnotation
Attribute Type Mul. Kind Note
trigger Trigger 1 ref The instance of annotated trigger.

Table 4.53: TriggerPortAnnotation

The main use-case is to allow define additional information related to the trigger.
AtpBlueprintable
AtpPrototype
PortPrototype

+triggerPortAnnotation 0..*

GeneralAnnotation
TriggerPortAnnotation

+trigger 1

AtpStructureElement
Identifiable
Trigger

+ swImplPolicy: SwImplPolicyEnum [0..1]

Figure 4.27: TriggerPortAnnotation

[constr_4008] Context of TriggerPortAnnotation d A TriggerPortAnnota-

tion shall only be aggregated by a PortPrototype typed by a TriggerInter-
face. c()

4.4.8 Non Volatile Data Port Annotation

[TPS_SWCT_01215] NvDataPortAnnotation d The NvDataPortAnnotation

can be used to provide more information with respect to the non volatile data of the
PortPrototype. c()
Class NvDataPortAnnotation
Package M2::AUTOSARTemplates::SWComponentTemplate::ApplicationAttributes
Note Annotation to a port regarding a certain VariableDataPrototype.
Base ARObject, GeneralAnnotation
5

163 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4
Class NvDataPortAnnotation
Attribute Type Mul. Kind Note
variable VariableDataPrototype 1 ref The instance of nv data annotated.

Table 4.54: NvDataPortAnnotation

The main use-case is to allow define additional information related to the non volatile
data elements.
AtpBlueprintable
AtpPrototype
PortPrototype

+nvDataPortAnnotation 0..*

GeneralAnnotation
NvDataPortAnnotation

+variable 1

AutosarDataPrototype
VariableDataPrototype

Figure 4.28: NvDataPortAnnotation

[constr_4009] Context of NvDataPortAnnotation d An NvDataPortAnnota-

tion shall only be aggregated by a PortPrototype typed by an NvDataInter-
face. c()

4.4.9 Delegated Port Annotations

[TPS_SWCT_01216] DelegatedPortAnnotation d The DelegatedPortAnno-

tation is used to define the Signal Fan In or Signal Fan Out inside the Composi-
tionSwComponentType.
This information is used to pre-define and pre-check resulting communication patterns
in the VFB (1:n, n:1, 1:1) if empty CompositionSwComponentTypes are used as
interface definition for sub-systems.
The DelegatedPortAnnotation guides either the system designer in connecting
the empty CompositionSwComponentType or the sub-system designer in applying
communication pattern (1:n, n:1, 1:1) inside of the CompositionSwComponentType.
c()

164 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Class DelegatedPortAnnotation
Package M2::AUTOSARTemplates::SWComponentTemplate::ApplicationAttributes
Note Annotation to a "delegated port" to specify the Signal Fan In or Signal Fan Out inside the CompositionSw
ComponentType.
Base ARObject, GeneralAnnotation
Attribute Type Mul. Kind Note
signalFan SignalFanEnum 0..1 attr Specifies the Signal Fan In or Signal Fan Out inside the
Composition Type.

Table 4.55: DelegatedPortAnnotation

Enumeration SignalFanEnum
Package M2::AUTOSARTemplates::SWComponentTemplate::ApplicationAttributes
Note Signal Fan inside the Composition Component Type.
Literal Description
nfold The connections internally in the CompositionSwComponentType via DelegationSwConnectors and
AssemblySwConnectors are defined in a way that at least one data element present in the S/R
interface or one ClientServerOperation in the C/S interface of the outer PortPrototype is involved in a
1:n or n:1 communication pattern.
Tags: atp.EnumerationValue=0
single The connections internally in the CompositionSwComponentType via DelegationSwConnectors and
AssemblySwConnectors are defined in a way that each VariableDataPrototype present in the S/R
interface or ClientServerOperation in the C/S interface of the outer PortPrototype is involved in a 1:1
communication pattern only.
Tags: atp.EnumerationValue=1

Table 4.56: SignalFanEnum

[TPS_SWCT_01217] Semantics of DelegatedPortAnnotation.signalFan d

The attribute values have following definition:
• single: the internal connections in the CompositionSwComponentType via
DelegationSwConnectors and AssemblySwConnectors are defined in a
way that each dataElement present in the SenderReceiverInterfaces or
operation in the ClientServerInterfaces of the outer PortPrototype
is involved in a 1:1 communication pattern only.
• nfold: The internal connections in the CompositionSwComponentType via
DelegationSwConnectors and AssemblySwConnectors are defined in a
way that at least one dataElement present in the SenderReceiverInter-
faces or one operation in the ClientServerInterfaces of the outer
PortPrototype is involved in a 1:n or n:1 communication pattern.
c()
[constr_4010] Context of DelegatedPortAnnotation d A DelegatedPortAn-
notation shall only be aggregated by a PortPrototype aggregated by a Compo-
sitionSwComponentType. c()

165 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4.4.10 General Annotation

Besides formally specified attributes it is also possible to place textual information as

provided in the abstract GeneralAnnotation (see Figure 4.29 for an overview).
GeneralAnnotation

+ annotationOrigin: String

+annotationText 1 +label 0..1

«atpMixed» MultilanguageLongName
DocumentationBlock

Figure 4.29: textual information in annotations

Class GeneralAnnotation (abstract)

Package M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::GeneralAnnotation
Note This class represents textual comments (called annotations) which relate to the object in which it is
aggregated. These annotations are intended for use during the development process for transferring
information from one step of the development process to the next one.
The approach is similar to the "yellow pads" ...
This abstract class can be specialized in order to add some further formal properties.
Base ARObject
Subclasses Annotation, ClientServerAnnotation, DelegatedPortAnnotation, IoHwAbstractionServerAnnotation, Mode
PortAnnotation, NvDataPortAnnotation, ParameterPortAnnotation, SenderReceiverAnnotation, Trigger
PortAnnotation
Attribute Type Mul. Kind Note
annotation String 1 attr This attribute identifies the origin of the annotation. It is an
Origin arbitrary string since it can be an individual’s name as well
as the name of a tool or even the name of a process step.
Tags: xml.sequenceOffset=30
annotationText DocumentationBlock 1 aggr This is the text of the annotation.
Tags: xml.sequenceOffset=40
label MultilanguageLong 0..1 aggr This is the headline for the annotation.
Name
Tags: xml.sequenceOffset=20

Table 4.57: GeneralAnnotation

4.5 Communication Specification

[TPS_SWCT_01218] Big picture of ComSpec d The highest level of description of
information exchanged between components in an AUTOSAR system is the Port-
Interfaces, as shown in earlier sections. Such PortInterface however, only
describes structure and does not include information about whether communication
needs to be done reliably, or whether an initial value exists in case the real data is not
yet available.

166 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

This information is role-specific, i.e. it shall be applied on the level of PortPrototypes

rather than PortInterfaces. Therefore, most communication-relevant attributes are
related to the PortPrototypes of an SwComponentType.
The communication attributes are organized in a so-called communication specifica-
tion (in terms of the meta-model: ComSpec) classes. c()
Note that the communication specification is optional, i.e. its existence is not required in
any case. Figures 4.30 and 4.31 provide an overview of communication specifications.
The derived meta-classes are explained in the following sub-chapters.
PortPrototype
AbstractRequiredPortPrototype

AbstractProvidedPortPrototype
RPortPrototype
PRPortPrototype

+requiredComSpec 0..*

RPortComSpec

ClientComSpec ModeSwitchReceiverComSpec NvRequireComSpec ParameterRequireComSpec ReceiverComSpec

Figure 4.30: Overview of communication attributes of RPortPrototype

167 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

PortPrototype
AbstractProvidedPortPrototype

AbstractRequiredPortPrototype
PPortPrototype
PRPortPrototype

+providedComSpec 0..*

PPortComSpec

ModeSwitchSenderComSpec ParameterProvideComSpec SenderComSpec

Figure 4.31: Overview of communication attributes of PPortPrototype

As explained before, ComSpec meta-classes which are required on the level of a

SwComponentType are attached to the PortPrototype declarations which in turn
are part of the definition of a SwComponentType. Nevertheless, the usage of Com-
Specs is not restricted to the PortPrototypes of AtomicSwComponentTypes (for
more details please refer to section 2.5).
Sections 7.5.1 and 7.5.2 then explain the sender-receiver and client-server communi-
cation patterns with respect to the RTE, the RTE events and the corresponding com-
munication attributes.
Several ComSpecs allow to define initValues in relation to the associated Dat-
aPrototype. For further details about the representation of initValues please refer
to section 5.7.2.
Furthermore, semantic constraints apply such that specific subclasses of ComSpec
can only be owned by PortPrototypes typed by the corresponding kind of PortIn-
terface.
[constr_1290] Limitation on the number of PPortComSpecs in the context of one
PPortPrototype d Within the context of one PPortPrototype there can only be
one PPortComSpec that references a given dataElement or operation. c()
In other words, it is not allowed that two or more PPortComSpec exist in the context of
a one PPortPrototype that refer to the same dataElement or operation.
[constr_1291] Limitation on the number of RPortComSpecs in the context of one
PPortPrototype d Within the context of one RPortPrototype, there can only be
one RPortComSpec that references a given dataElement or operation. c()

168 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

In other words, it is not allowed that two or more RPortComSpec exist in the context of
a one RPortPrototype that refer to the same dataElement or operation.
[TPS_SWCT_01454] PRPortPrototype can own both RPortComSpecs and
PPortComSpecs d In contrast to PPortPrototype and RPortPrototype, PR-
PortPrototype can own both RPortComSpecs and PPortComSpecs at the same
time. c(RS_SWCT_03250)
Nevertheless, the following restriction applies:
[constr_1292] Limitation on the number of RPortComSpecs/PPortComSpecs in
the context of one PRPortPrototype d Within the context of one PRPortProto-
type, there can only be one RPortComSpec and one PPortComSpec that references
a given dataElement or operation. c()
In other words, it is not allowed that two or more PPortComSpec exist in the context of
a one PRPortPrototype that refer to the same dataElement or operation. In the
same manner, it is not allowed that two or more RPortComSpec exist in the context of
one PRPortPrototype that refer to the same dataElement or operation.
The rationale for the existence of [constr_1290], [constr_1291], and [constr_1292] is
that the AUTOSAR communication layer needs an unambiguous specification of the
communication behavior. The existence of redundant RPortComSpecs/PPortCom-
Specs may easily be contradicting each other and this would inhibit the creation of a
valid configuration for the AUTOSAR Com.
Class PPortComSpec (abstract)
Package M2::AUTOSARTemplates::SWComponentTemplate::Communication
Note Communication attributes of a provided PortPrototype. This class will contain attributes that are valid for
all kinds of provide ports, independent of client-server or sender-receiver communication patterns.
Base ARObject
Subclasses ModeSwitchSenderComSpec, NvProvideComSpec, ParameterProvideComSpec, SenderComSpec,
ServerComSpec
Attribute Type Mul. Kind Note
– – – – –
Table 4.58: PPortComSpec

Class RPortComSpec (abstract)

Package M2::AUTOSARTemplates::SWComponentTemplate::Communication
Note Communication attributes of a required PortPrototype. This class will contain attributes that are valid for
all kinds of require-ports, independent of client-server or sender-receiver communication patterns.
Base ARObject
Subclasses ClientComSpec, ModeSwitchReceiverComSpec, NvRequireComSpec, ParameterRequireComSpec,
ReceiverComSpec
Attribute Type Mul. Kind Note
– – – – –
Table 4.59: RPortComSpec

169 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[constr_1043] PortInterface vs. ComSpec d The allowed combinations of a spe-

cific kind of PortInterface and a kind of ComSpec are documented in Table 4.60. c
()
PortInterface ComSpec
SenderReceiverInterface SenderComSpec, ReceiverComSpec
ClientServerInterface ClientComSpec, ServerComSpec
ModeSwitchInterface ModeSwitchSenderComSpec, ModeSwitchReceiverComSpec
ParameterInterface ParameterProvideComSpec, ParameterRequireComSpec
NvDataInterface NvRequireComSpec, NvProvideComSpec

Table 4.60: PortInterface vs. ComSpec

As explained in section 2.5, there are cases where PortPrototypes owned by a

CompositionSwComponentType could have initValues.
Therefore, it is possible that PortPrototypes owned by CompositionSwCompo-
nentTypes can have ComSpecs. It is not required that the ComSpecs defined on the
composition level match the ComSpecs defined inside the CompositionSwCompo-
nentType.
If consistency would be required this constraint might be a major obstacle for integrat-
ing existing AtomicSwComponentTypes into a CompositionSwComponentType
that has PortPrototypes with ComSpecs.

4.5.1 Communication Specification for Sender-Receiver Communication

Communication specification applies in different ways to specific kinds of communi-

cation. Figure 4.32 shows the meta-model of the communication attributes relevant
sender-receiver communication at an RPortPrototype.
[TPS_SWCT_01455] Duplicate existence of initValue in the context of a PR-
PortPrototype d If an initValue is defined in a NonqueuedReceiverComSpec
owned by a PRPortPrototype its value shall be ignored. c(RS_SWCT_03250)

170 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

DataPrototype
ApplicationCompositeElementDataPrototype

+leafElement 1

«instanceRef»

PortPrototype
CompositeNetworkRepresentation
AbstractRequiredPortPrototype

0..* +compositeNetworkRepresentation

+requiredComSpec 0..* +networkRepresentation 1

«atpVariation» Describable
RPortComSpec
SwDataDefProps TransformationComSpecProps

+networkRepresentation 0..1 0..* +transformationComSpecProps

AbstractAccessPoint
ReceiverComSpec
AtpStructureElement +replaceWith
Identifiable + handleOutOfRange: HandleOutOfRangeEnum
VariableAccess 0..1 + handleOutOfRangeStatus: HandleOutOfRangeStatusEnum [0..1]
+ maxNoNewOrRepeatedData: PositiveInteger [0..1]
+ scope: VariableAccessScopeEnum [0..1] + syncCounterInit: PositiveInteger [0..1]
«atpVariation»
+ maxDeltaCounterInit: PositiveInteger [0..1]
DataPrototype + usesEndToEndProtection: Boolean [0..1]
+dataElement
AutosarDataPrototype
0..1

VariableDataPrototype NonqueuedReceiverComSpec QueuedReceiverComSpec

+ aliveTimeout: TimeValue + queueLength: PositiveInteger

+ enableUpdate: Boolean
+ handleDataStatus: Boolean [0..1]
+ handleNeverReceived: Boolean
+ handleTimeoutType: HandleTimeoutEnum

«enumeration»
HandleOutOfRangeEnum
+initValue 0..1 +timeoutSubstitutionValue 0..1 +filter 0..1
none
ignore
ValueSpecification DataFilter
saturate
default + shortLabel: Identifier [0..1] + dataFilterType: DataFilterTypeEnum
invalid + mask: UnlimitedInteger [0..1]
externalReplacement + max: UnlimitedInteger [0..1]
+ min: UnlimitedInteger [0..1]
+ offset: PositiveInteger [0..1]
+ period: PositiveInteger [0..1]
«enumeration» + x: UnlimitedInteger [0..1]
«enumeration»
HandleTimeoutEnum HandleOutOfRangeStatusEnum
replace silent
none indicate
replaceByTimeoutSubstitutionValue

Figure 4.32: Communication attributes of RPortPrototype with respect to sender-

receiver communication.

[TPS_SWCT_01219] ComSpec for queued and non-queued sender-receiver com-

munication d Sender-receiver communication might be queued or non-queued. This

171 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

aspect is primarily reflected in the value of dataElement.swDataDefProps.swIm-

plPolicy. If the value of this attribute is set to queued then QueuedSender-
ComSpec and/or QueuedReceiverComSpec shall be defined. In all other applica-
ble cases NonqueuedSenderComSpec or NonqueuedReceiverComSpec shall be
used. Thus, the constraints [constr_1129], [constr_1130], [constr_1131], and [con-
str_1132] shall apply.
While in the case of queued communication the queueLength attribute remains the
only information item the non-queued case foresees several attributes for controlling
communication behavior. c()
Class ReceiverComSpec (abstract)
Package M2::AUTOSARTemplates::SWComponentTemplate::Communication
Note Receiver-specific communication attributes (RPortPrototype typed by SenderReceiverInterface).
Base ARObject, RPortComSpec
Subclasses NonqueuedReceiverComSpec, QueuedReceiverComSpec
Attribute Type Mul. Kind Note
composite CompositeNetwork * aggr This represents a CompositeNetworkRepresentation
Network Representation defined in the context of a ReceiverComSpec. The
Representation purpose of this aggregation is to be able to specify the
network representation of leaf elements of Application
CompositeDataTypes.
dataElement AutosarDataPrototype 0..1 ref Data element these attributes belong to.
handleOutOf HandleOutOfRange 1 attr This attribute controls how values that are out of the
Range Enum specified range are handled according to the values of
HandleOutOfRangeEnum.
handleOutOf HandleOutOfRange 0..1 attr Control the way how return values are created in case of
RangeStatus StatusEnum an out-of-range situation.
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.
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime
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.
network SwDataDefProps 0..1 aggr A networkRepresentation is used to define how the data
Representation Element is mapped to a communication bus.
replaceWith VariableAccess 0..1 aggr This aggregation is used to identify the AutosarData
Prototype to be taken for sourcing an external
replacement in the out-of-range handling.
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.
5

172 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4
Class ReceiverComSpec (abstract)
transformation TransformationCom * aggr This references the TransformationComSpecProps which
ComSpecProps SpecProps define port-specific configuration for data transformation.
usesEndToEnd Boolean 0..1 attr This indicates whether the corresponding dataElement
Protection shall be transmitted using end-to-end protection.
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime

Table 4.61: ReceiverComSpec

Class NonqueuedReceiverComSpec
Package M2::AUTOSARTemplates::SWComponentTemplate::Communication
Note Communication attributes specific to non-queued receiving.
Base ARObject, RPortComSpec, ReceiverComSpec
Attribute Type Mul. Kind Note
aliveTimeout TimeValue 1 attr 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.
enableUpdate Boolean 1 attr This attribute controls whether application code is entitled
to check whether the value of the corresponding Variable
DataPrototype has been updated.
filter DataFilter 0..1 aggr The applicable filter algorithm for filtering the value of the
corresponding dataElement.
handleData Boolean 0..1 attr If this attribute is set to true than the Rte_IStatus API shall
Status exist. If the attribute does not exist or is set to false then
the Rte_IStatus API may still exist in response to the
existence of further conditions.
handleNever Boolean 1 attr This attribute specifies whether for the corresponding
Received VariableDataPrototype the "never received" flag is
available. If yes, the RTE is supposed to assume that
initially the VariableDataPrototype has not been received
before.
After the first reception of the corresponding VariableData
Prototype the flag is cleared.
• If the value of this attribute is set to "true" the flag
is required.
• If set to "false", the RTE shall not support the
"never received" functionality for the
corresponding VariableDataPrototype.
handleTimeout HandleTimeoutEnum 1 attr This attribute controls the behavior with respect to the
Type handling of timeouts.
initValue ValueSpecification 0..1 aggr Initial value to be used in case the sending component is
not yet initialized. If the sender also specifies an initial
value the receiver’s value will be used.
timeout ValueSpecification 0..1 aggr This attribute represents the substitution value applicable
Substitution in the case of a timeout.
Value
Table 4.62: NonqueuedReceiverComSpec

173 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Class QueuedReceiverComSpec
Package M2::AUTOSARTemplates::SWComponentTemplate::Communication
Note Communication attributes specific to queued receiving.
Base ARObject, RPortComSpec, ReceiverComSpec
Attribute Type Mul. Kind Note
queueLength PositiveInteger 1 attr Length of queue for received events.

Table 4.63: QueuedReceiverComSpec

Enumeration HandleTimeoutEnum
Package M2::AUTOSARTemplates::SWComponentTemplate::Communication
Note Strategies of handling a reception timeout violation.
Literal Description
none If set to none no replacement shall take place.
Tags: atp.EnumerationValue=0
replace If set to replace, the replacement value shall be the ComInitValue.
Tags: atp.EnumerationValue=1
replaceByTimeout If set to replace, the replacement value shall be the timeout substitution value.
SubstitutionValue
Tags: atp.EnumerationValue=2

Table 4.64: HandleTimeoutEnum

Primitive TimeValue
Package M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::PrimitiveTypes
Note This primitive type is taken for expressing time values. The numerical value is supposed to be interpreted
in the physical unit second.
Tags: xml.xsd.customType=TIME-VALUE
xml.xsd.type=double

Table 4.65: TimeValue

[constr_1538] Restriction for ReceiverComSpec.dataElement d The reference

ReceiverComSpec.dataElement shall not refer to an ArgumentDataPrototype
or ParameterDataPrototype. c()
[constr_1103] NonqueuedReceiverComSpec and enableUpdate d A Nonqueue-
dReceiverComSpec that has attribute enableUpdate set to true may not refer-
ence a dataElement that in turn is referenced by a VariableAccess in the role
dataReadAccess. c()
In general, it is considered beneficial for software-components to define initValues
for all the dataElements received by RPortPrototypes.
These initValues are required by the RTE for several functionalities, e.g.:
• Providing a default value for not yet received dataElements (see
[TPS_SWCT_01220]).
• Providing default values in case of unconnected RPortPrototypes (see [con-
str_1100]).

174 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

• Partial mapping of composite data (see [constr_1280])

Therefore, the availability of initValue increases the flexibility of the usage of the
software-component in different scenarios.
On the other hand, there are also use cases where initValues are not mandatory,
i.e. the DataPrototype remains intentionally uninitialized. This is expressed by ap-
plying a SwAddrMethod where the sectionInitializationPolicy is set to NO-
INIT) or when the software component is intentionally only prepared for intra partition
communication.
In response to these conflicting objectives [TPS_SWCT_01688] is written as a recom-
mendation as opposed to a binding constraint.
[TPS_SWCT_01688] initValue should exist in an RPortPrototype d The op-
tional attribute initValue should exist if the enclosing NonqueuedReceiverCom-
Spec is owned by an RPortPrototype. c()
[constr_1129] swImplPolicy and NonqueuedReceiverComSpec d The attribute
swImplPolicy of a dataElement referenced by a NonqueuedReceiverComSpec
shall not be set to the value queued. c()
[constr_1130] swImplPolicy and QueuedReceiverComSpec d The attribute
swImplPolicy of a dataElement referenced by a QueuedReceiverComSpec
shall be set to the value queued. c()
[constr_1188] Existence of ReceiverComSpec.replaceWith d The aggregation
of VariableAccess in the role ReceiverComSpec.replaceWith shall exist if and
only if at least one of the following conditions is fulfilled:
• Attribute ReceiverComSpec.handleOutOfRange is set to the value exter-
nalReplacement.
• Attribute SenderReceiverInterface.invalidationPolicy.handleIn-
valid is set to the value externalReplacement.
c()
[TPS_SWCT_01753] Application of compatibility rules for ReceiverCom-
Spec.replaceWith d Compatibility rules as formulated by [constr_1068] and [con-
str_1187] shall be applicable for the reference ReceiverComSpec.replaceWith. c
()
[constr_1131] swImplPolicy and NonqueuedSenderComSpec d The attribute
swImplPolicy of a dataElement referenced by a NonqueuedSenderComSpec
shall not be set to the value queued. c()
[constr_1132] swImplPolicy and QueuedSenderComSpec d The attribute swIm-
plPolicy of a dataElement referenced by a QueuedSenderComSpec shall be set
to the value queued. c()

175 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[TPS_SWCT_01220] initValue defines an initial value that shall be taken if the

corresponding dataElement has not yet been received d The aggregation of Val-
ueSpecification in the role initValue defines an initial value that shall be taken
if the corresponding dataElement has not yet been received but the application soft-
ware is attempting to access its value.
This is the only relevant definition of an initial value for data transmission. That is, any
initValue defined in the context of VariableDataPrototype is ignored! c()
The communication attributes on the sender side are sketched in Figure 4.34.
DataFilter «enumeration»
DataFilterTypeEnum
+ dataFilterType: DataFilterTypeEnum
+ 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 4.33: DataFilter and its communication attributes.

Figure 4.33 shows the model of the communication attributes relevant for defining data
filters.
[TPS_SWCT_01221] DataFilter d For every RPortPrototype typed by a
SenderReceiverInterface a DataFilter can be defined given that non-queued
communication is foreseen. c()
Fifteen filter algorithms formally described by the enumeration type DataFilter-
TypeEnum in the meta-model are taken from the ISO 17356-4 specification [18] that is
referenced by the RTE specification [2].
[TPS_SWCT_01222] Applicability of DataFilter d This ISO 17356-4 specifica-
tion states that “filtering is only used for messages that can be interpreted as C lan-
guage unsigned integer types (characters, unsigned integers and enumerations).” c
(RS_SWCT_03221)
[constr_1044] Applicability of DataFilter d According to the origin of DataFil-
ter, i.e. ISO 17356-4 specification [18], DataFilters can only be applied to values
with an integer base type. c()
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 Mul. Kind Note
dataFilterType DataFilterTypeEnum 1 attr This attribute specifies the type of the filter.
5

176 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4
Class DataFilter
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 4.66: 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.EnumerationValue=0
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.EnumerationValue=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.EnumerationValue=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.EnumerationValue=3
never The filter removes all messages.
Tags: atp.EnumerationValue=4
newIsOutside Pass a message if its value is outside a predefined boundary.
(min > new_value) OR (new_value > max)
Tags: atp.EnumerationValue=5
newIsWithin Pass a message if its value is within a predefined boundary.
min <= new_value <= max
Tags: atp.EnumerationValue=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.EnumerationValue=7

Table 4.67: DataFilterTypeEnum

177 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[TPS_SWCT_01593] Semantics of attribute ReceiverComSpec.transforma-

tionComSpecProps d The ReceiverComSpec.transformationComSpecProps
is used to configure PortPrototype-specific properties for data transformation in
case of receiving inter-ECU communication. c()
[TPS_SWCT_01682] The meaning of E2E-related attributes in a ReceiverCom-
Spec if a TransformationComSpecProps of type EndToEndTransformation-
ComSpecProps is defined. d The attributes usesEndToEndProtection, sync-
CounterInit, maxDeltaCounterInit, and maxNoNewOrRepeatedData in Re-
ceiverComSpec have no meaning if a TransformationComSpecProps of type
EndToEndTransformationComSpecProps is defined in the same ReceiverCom-
Spec. c()
DataPrototype
ApplicationCompositeElementDataPrototype

+leafElement 1

«instanceRef»

PortPrototype CompositeNetworkRepresentation
AbstractProvidedPortPrototype

0..* +compositeNetworkRepresentation

+providedComSpec 0..* +networkRepresentation 1

PPortComSpec «atpVariation»
SwDataDefProps

0..1 +networkRepresentation

«enumeration» DataPrototype
SenderComSpec
HandleOutOfRangeEnum AutosarDataPrototype
+dataElement
+ handleOutOfRange: HandleOutOfRangeEnum
none
«atpVariation» 0..1
ignore
+ usesEndToEndProtection: Boolean [0..1]
saturate
default
invalid
externalReplacement

QueuedSenderComSpec NonqueuedSenderComSpec VariableDataPrototype

+transmissionAcknowledge 0..1 +initValue 1

TransmissionAcknowledgementRequest ValueSpecification

+ timeout: TimeValue + shortLabel: Identifier [0..1]

Figure 4.34: Communication attributes of PPortPrototype with respect to sender-

receiver communication.

178 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[TPS_SWCT_01751] The meaning of E2E-related attributes in a SenderComSpec

if a TransformationComSpecProps of type EndToEndTransformationCom-
SpecProps is defined d The attribute usesEndToEndProtection has no mean-
ing if a TransformationComSpecProps of type EndToEndTransformationCom-
SpecProps is defined in the same SenderComSpec. c()
Please note:
• SenderComSpec.usesEndToEndProtection does not have any influence on
code generation.
It could be used, for example, by a validation framework to make sure that, if set
to True the dataElement meets a transformer configuration for all respective
SwConnectors connecting to the PortPrototype that owns the SenderCom-
Spec.
• SenderComSpec.usesEndToEndProtection could be used as a statement
from the application developer that the given dataElement shall be end-to-end
protected.
However, it seems far-fetched for an application developer to expressly state that
a dataElement shall not be end-to-end protected. This goes beyond the re-
sponsibility of an application developer.
Therefore, two relevant states for SenderComSpec.usesEndToEndProtec-
tion can be expected:
– attribute exists and is set to True (application developer asserts the neces-
sity to end-to-end protect the dataElement)
– attribute does not exist (application developer doesn’t care)
• The application developer may not have enough oversight to envision how the
dataElement is communicated, i.e. local vs. network communication. Setting
usesEndToEndProtection to True and then deploy the enclosing software-
component such that it communicates only locally on the respective PortProto-
type also seems unusual for the current situation regarding transformer-based
communication.
[constr_1539] Restriction for SenderComSpec.dataElement d The reference
SenderComSpec.dataElement shall not refer to an ArgumentDataPrototype or
ParameterDataPrototype. c()

179 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Class SenderComSpec (abstract)

Package M2::AUTOSARTemplates::SWComponentTemplate::Communication
Note Communication attributes for a sender port (PPortPrototype typed by SenderReceiverInterface).
Base ARObject, PPortComSpec
Subclasses NonqueuedSenderComSpec, QueuedSenderComSpec
Attribute Type Mul. Kind Note
composite CompositeNetwork * aggr This represents a CompositeNetworkRepresentation
Network Representation defined in the context of a SenderComSpec.
Representation
dataElement AutosarDataPrototype 0..1 ref Data element these quality of service attributes apply to.
handleOutOf HandleOutOfRange 1 attr This attribute controls how out-of-range values shall be
Range Enum dealt with.
network SwDataDefProps 0..1 aggr A networkRepresentation is used to define how the data
Representation Element is mapped to a communication bus.
transmission Transmission 0..1 aggr Requested transmission acknowledgement for data
Acknowledge Acknowledgement element.
Request
usesEndToEnd Boolean 0..1 attr This indicates whether the corresponding dataElement
Protection shall be transmitted using end-to-end protection.
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime

Table 4.68: SenderComSpec

Class QueuedSenderComSpec
Package M2::AUTOSARTemplates::SWComponentTemplate::Communication
Note Communication attributes specific to distribution of events (PPortPrototype, SenderReceiverInterface and
dataElement carries an "event").
Base ARObject, PPortComSpec, SenderComSpec
Attribute Type Mul. Kind Note
– – – – –
Table 4.69: QueuedSenderComSpec

Class NonqueuedSenderComSpec
Package M2::AUTOSARTemplates::SWComponentTemplate::Communication
Note Communication attributes for non-queued sender/receiver communication (sender side)
Base ARObject, PPortComSpec, SenderComSpec
Attribute Type Mul. Kind Note
initValue ValueSpecification 1 aggr Initial value to be sent if sender component is not yet fully
initialized, but receiver needs data already.

Table 4.70: NonqueuedSenderComSpec

180 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Class TransmissionAcknowledgementRequest
Package M2::AUTOSARTemplates::SWComponentTemplate::Communication
Note Requests transmission acknowledgement that data has been sent successfully. Success/failure is
reported via a SendPoint of a RunnableEntity.
Base ARObject
Attribute Type Mul. Kind Note
timeout TimeValue 1 attr Number of seconds before an error is reported or in case
of allowed redundancy, the value is sent again.

Table 4.71: TransmissionAcknowledgementRequest

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.EnumerationValue=0
external This indicates that the value replacement is sourced from the attribute replaceWith.
Replacement
Tags: atp.EnumerationValue=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.EnumerationValue=2
invalid The RTE will use the invalidValue if the value is out of the specified bounds.
Tags: atp.EnumerationValue=3
none A range check is not required.
Tags: atp.EnumerationValue=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.EnumerationValue=5

Table 4.72: HandleOutOfRangeEnum

[TPS_SWCT_01223] networkRepresentation defines how a specific dataEle-

ment is represented on a communication bus d For sender-receiver communication,
it is possible to specify how dataElements are represented given that the communi-
cation requires the usage of a dedicated communication bus.
That is, by means of the networkRepresentation it is possible to define how a
specific dataElement is represented on a communication bus. For this purpose the
networkRepresentation is implemented as an aggregation of SwDataDefProps.
c()
[TPS_SWCT_01224] CompuMethods of dataElement and the networkRepre-
sentation are used for conversion purposes d The attached CompuMethods of
both the dataElement and the networkRepresentation can be used to identify
the conversion between the two. The advantage of this approach is that this can also be
used without any modifications in combination with a general remapping and rescaling
of dataElements between different SwComponentTypes, regardless whether they
are located on the same or on different ECUs. c()

181 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Please note that the decision whether or not to take the networkRepresentation
for data mapping is done in the context of the AUTOSAR System Template [10]. Please
find more detailed information about this aspect in the applicable specification.
[TPS_SWCT_01452] Applicability of networkRepresentation for Applica-
tionCompositeDataType d The aggregation of networkRepresentation at the
ReceiverComSpec or SenderComSpec only applies for dataElements typed by
ApplicationPrimitiveDataTypes. For the case of using an ApplicationCom-
positeDataType an additional mechanism shall be used.
In particular, compositeNetworkRepresentation shall be used to define the net-
workRepresentation of leaf elements of ApplicationCompositeDataTypes. c
()
[constr_1196] Existence of networkRepresentation vs. compositeNet-
workRepresentation d If a ReceiverComSpec or SenderComSpec aggregates
networkRepresentation it shall not aggregate compositeNetworkRepresen-
tation at the same time (and vice versa). c()
[constr_1197] Existence of compositeNetworkRepresentation shall be com-
prehensive d If at least one compositeNetworkRepresentation exists then for
each leaf ApplicationCompositeElementDataPrototype of the affected Ap-
plicationCompositeDataType exactly one compositeNetworkRepresenta-
tion shall be defined. c()
Granted, the definition of [constr_1197] to some extent has a recursive character. The
meaning is that if it is actually intended to define a compositeNetworkRepresen-
tation then the definition shall be completely covering the entire set of leaf elements
of the corresponding ApplicationCompositeDataType. In other words, it’s all or
nothing.
Class CompositeNetworkRepresentation
Package M2::AUTOSARTemplates::SWComponentTemplate::Communication
Note This meta-class is used to define the network representation of leaf elements of composite application
data types.
Base ARObject
Attribute Type Mul. Kind Note
leafElement ApplicationComposite 1 iref This represents that leaf element of an application
ElementDataPrototype composite data type.
network SwDataDefProps 1 aggr The SwDataDefProps owned by the CompositeNetwork
Representation Representation are used to define the network
representation of the leaf element of an Application
CompositeDataType.

Table 4.73: CompositeNetworkRepresentation

182 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4.5.2 Communication Specification for Client-Server Communication

The communication aspects relevant for client communication are sketched in Fig-
ure 4.35.
PortPrototype
AbstractRequiredPortPrototype

+requiredComSpec 0..*

RPortComSpec

ClientComSpec

+operation 0..1 +transformationComSpecProps 0..*

AtpStructureElement Describable
Identifiable
TransformationComSpecProps
ClientServerOperation

Figure 4.35: Communication attributes of RPortPrototype with respect to client-server

communication.

Class ClientComSpec
Package M2::AUTOSARTemplates::SWComponentTemplate::Communication
Note Client-specific communication attributes (RPortPrototype typed by ClientServerInterface).
Base ARObject, RPortComSpec
Attribute Type Mul. Kind Note
operation ClientServerOperation 0..1 ref This represents the corresponding ClientServerOperation.
transformation TransformationCom * aggr This references the TransformationComSpecProps which
ComSpecProps SpecProps define port-specific configuration for data transformation.

Table 4.74: ClientComSpec

[constr_1540] Existence of ClientComSpec.operation d The reference Client-

ComSpec.operation shall exist if the AbstractRequiredPortPrototype that
owns the ClientComSpec is typed by a ClientServerInterface. c()
Note: on the AUTOSAR adaptive platform the ClientComSpec can also be used in
the context of RPortPrototypes typed by PortInterfaces that are not available
on the AUTOSAR classic platform. This is the motivation for the existence of [con-
str_1540].

183 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

The server side looks very similar but provides an attribute for specifying the queue
length.
PortPrototype
AbstractProvidedPortPrototype

+providedComSpec 0..*

PPortComSpec

ServerComSpec

+ queueLength: PositiveInteger

+operation 0..1 +transformationComSpecProps 0..*

AtpStructureElement Describable
Identifiable TransformationComSpecProps
ClientServerOperation

Figure 4.36: Communication attributes of PPortPrototype with respect to client-server

communication.

Class ServerComSpec
Package M2::AUTOSARTemplates::SWComponentTemplate::Communication
Note Communication attributes for a server port (PPortPrototype and ClientServerInterface).
Base ARObject, PPortComSpec
Attribute Type Mul. Kind Note
operation ClientServerOperation 0..1 ref Operation these communication attributes apply to.
queueLength PositiveInteger 1 attr Length of call queue on the server side. The queue is
implemented by the RTE. The value shall be greater or
equal to 1. Setting the value of queueLength to 1 implies
that incoming requests are rejected while another request
that arrived earlier is being processed.
transformation TransformationCom * aggr This references the TransformationComSpecProps which
ComSpecProps SpecProps define port-specific configuration for data transformation.

Table 4.75: ServerComSpec

[constr_1541] Existence of ServerComSpec.operation d The reference Server-

ComSpec.operation shall exist if the AbstractProvidedPortPrototype that
owns the ServerComSpec is typed by a ClientServerInterface. c()
Note: on the AUTOSAR adaptive platform the ServerComSpec can also be used in
the context of RPortPrototypes typed by PortInterfaces that are not available
on the AUTOSAR classic platform. This is the motivation for the existence of [con-
str_1541].

184 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[TPS_SWCT_01225] RunnableEntity implements the functionality of more than

one ClientServerOperations d A single RunnableEntity can implement the
functionality of more than one ClientServerOperations.
For this purpose, one OperationInvokedEvent for each affected ClientServer-
Operation shall reference the respective RunnableEntity.
The attribute ServerComSpec.queueLength shall be taken for the determination of
the resulting queue length, [constr_1128] applies. c()
[constr_1128] Queue length of ClientServerOperations associated with the
same RunnableEntity d If two or more OperationInvokedEvents reference a
single RunnableEntity the value of the ServerComSpec attribute queueLength
shall be identical for all ServerComSpecs owned by PPortPrototypes of the en-
closing SwComponentType that reference one of the ClientServerOperations
that are also referenced by the OperationInvokedEvents. c()
[TPS_SWCT_01595] Semantics of attribute ClientComSpec.transformation-
ComSpecProps d The attribute ClientComSpec.transformationComSpecProps
shall be used to configure PortPrototype-specific properties for data transforma-
tion in case of Client/Server inter-ECU communication for the reception of the server’s
response. c(RS_SWCT_03221)
[TPS_SWCT_01596] Semantics of attribute ServerComSpec.transformation-
ComSpecProps d The attribute ServerComSpec.transformationComSpecProps
shall be used to configure PortPrototype-specific properties for data transforma-
tion in case of Client/Server inter-ECU communication for the reception of the client’s
request. c(RS_SWCT_03221)
See chapter 4.5.6 for details.

4.5.3 Communication Specification for Mode Switch Communication

In analogy to the previous section, Figure 4.37 shows the meta-model elements rel-
evant for a mode switch communication. On the sender side it is possible to specify
that an acknowledgement is supposed to be returned that indicates the successful
processing of the mode switch request.

185 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

PortPrototype
AbstractProvidedPortPrototype

+providedComSpec 0..*

PPortComSpec

AtpPrototype
ModeSwitchSenderComSpec
+modeGroup ModeDeclarationGroupPrototype
+ enhancedModeApi: Boolean [0..1]
+ queueLength: PositiveInteger 1 + swCalibrationAccess: SwCalibrationAccessEnum [0..1]

+modeSwitchedAck 0..1

ModeSwitchedAckRequest

+ timeout: TimeValue

Figure 4.37: Communication attributes of PPortPrototype with respect to mode switch

communication.

PortPrototype
AbstractRequiredPortPrototype

+requiredComSpec 0..*

RPortComSpec

AtpPrototype
ModeSwitchReceiverComSpec +modeGroup ModeDeclarationGroupPrototype
+ enhancedModeApi: Boolean [0..1] 0..1 +
+ supportsAsynchronousModeSwitch: Boolean swCalibrationAccess: SwCalibrationAccessEnum [0..1]

  
  


Figure 4.38: Communication attributes of PPortPrototype with respect to mode switch

communication.

[TPS_SWCT_01514] Duplicate existence of enhancedModeApi in the context

of a PRPortPrototype d If the attribute enhancedModeApi is defined in a Mod-
eSwitchReceiverComSpec owned by a PRPortPrototype its value shall be ig-
nored. c(RS_SWCT_03250)

186 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Class ModeSwitchSenderComSpec
Package M2::AUTOSARTemplates::SWComponentTemplate::Communication
Note Communication attributes of PPortPrototypes with respect to mode communication
Base ARObject, PPortComSpec
Attribute Type Mul. Kind Note
enhancedMode Boolean 0..1 attr This controls the creation of the enhanced mode API that
Api returns information about the previous mode and the next
mode. If set to "true" the enhanced mode API is
supposed to be generated. For more details please refer
to the SWS_RTE.
modeGroup ModeDeclarationGroup 1 ref ModeDeclarationGroupPrototype (of the same Port
Prototype Interface) to which these communication attributes apply.
modeSwitched ModeSwitchedAck 0..1 aggr If this aggregation exists an acknowledgement for the
Ack Request successful processing of the mode switch request is
required.
queueLength PositiveInteger 1 attr Length of call queue on the mode user side. The queue is
implemented by the RTE. The value shall be greater or
equal to 1. Setting the value of queueLength to 1 implies
that incoming requests are rejected while another request
that arrived earlier is being processed.

Table 4.76: ModeSwitchSenderComSpec

Class ModeSwitchedAckRequest
Package M2::AUTOSARTemplates::SWComponentTemplate::Communication
Note Requests acknowledgements that a mode switch has been proceeded successfully
Base ARObject
Attribute Type Mul. Kind Note
timeout TimeValue 1 attr Number of seconds before an error is reported or in case
of allowed redundancy, the value is sent again.

Table 4.77: ModeSwitchedAckRequest

Class ModeSwitchReceiverComSpec
Package M2::AUTOSARTemplates::SWComponentTemplate::Communication
Note Communication attributes of RPortPrototypes with respect to mode communication
Base ARObject, RPortComSpec
Attribute Type Mul. Kind Note
enhancedMode Boolean 0..1 attr This controls the creation of the enhanced mode API that
Api returns information about the previous mode and the next
mode. If set to "true" the enhanced mode API is
supposed to be generated. For more details please refer
to the SWS_RTE.
modeGroup ModeDeclarationGroup 0..1 ref ModeDeclarationGroupPrototype (of the same Port
Prototype Interface) to which these communication attributes apply.
Tags: atp.Status=shallBecomeMandatory
5

187 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4
Class ModeSwitchReceiverComSpec
supports Boolean 1 attr This attribute controls the behavior of the corresponding
Asynchronous RPortPrototype with respect to the question whether it
ModeSwitch can deal with asynchronous mode switch requests, i.e. if
set to true, the RPortPrototype is able to deal with an
asynchronous mode switch request.

Table 4.78: ModeSwitchReceiverComSpec

4.5.4 Communication Specification for Parameters

Granted, the definition of a ComSpec for ParameterDataPrototypes looks strange

on first sight. A ParameterDataPrototype owned by a PPortPrototype typed by
a ParameterInterface is not actually transmitted over any communication medium.
Therefore, the term communication should in this case be taken with a grain of salt.
However, it is generally necessary to be able to define role-specific initial values for Pa-
rameterDataPrototypes aggregated in a ParameterInterface. In other words,
the actual problem closely resembles the definition of initial values in the case of
sender-receiver communication.
[TPS_SWCT_01226] initValue on the level of a ComSpec is relevant for connec-
tions to the corresponding PortPrototype d Please note that (along the example
of sender-receiver communication) only the initValue defined in the context of a
ParameterProvideComSpec or ParameterRequireComSpec is relevant for con-
nections to the corresponding PortPrototype. An initValue defined in the scope
of a ParameterDataPrototype is ignored. c()
Therefore, it is only reasonable to apply the existing and well-known pattern to the
definition of initial values for ParameterDataPrototypes aggregated in a Parame-
terInterface. The actual modeling is sketched in Figure 4.39 for provided Parame-
terDataPrototypes and in Figure 4.40 for required ParameterDataPrototypes.

188 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

PortPrototype
AbstractProvidedPortPrototype

+providedComSpec 0..*

PPortComSpec

AutosarDataPrototype
ParameterProvideComSpec
+parameter ParameterDataPrototype

+initValue 0..1

ValueSpecification

+ shortLabel: Identifier [0..1]

Figure 4.39: Communication attributes of ParameterDataPrototypes with respect to

PPortPrototype

Class ParameterProvideComSpec
Package M2::AUTOSARTemplates::SWComponentTemplate::Communication
Note "Communication" specification that applies to parameters on the provided side of a connection.
Base ARObject, PPortComSpec
Attribute Type Mul. Kind Note
initValue ValueSpecification 0..1 aggr The initial value applicable for the corresponding
ParameterDataPrototype.
parameter ParameterData 1 ref The ParameterDataPrototype to which the Parameter
Prototype ComSpec applies.

Table 4.79: ParameterProvideComSpec

189 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

PortPrototype
AbstractRequiredPortPrototype

+requiredComSpec 0..*

RPortComSpec

AutosarDataPrototype
ParameterRequireComSpec
+parameter ParameterDataPrototype

+initValue 0..1

ValueSpecification

+ shortLabel: Identifier [0..1]

Figure 4.40: Communication attributes of ParameterDataPrototypes with respect to

RPortPrototype

Class ParameterRequireComSpec
Package M2::AUTOSARTemplates::SWComponentTemplate::Communication
Note "Communication" specification that applies to parameters on the required side of a connection.
Base ARObject, RPortComSpec
Attribute Type Mul. Kind Note
initValue ValueSpecification 0..1 aggr The initial value applicable for the corresponding
ParameterDataPrototype.
parameter ParameterData 1 ref The ParameterDataPrototype to which the Parameter
Prototype RequireComSpec applies.

Table 4.80: ParameterRequireComSpec

4.5.5 Communication Specification for NV Data

[TPS_SWCT_01141] AtomicSwComponentType may have AbstractRequired-

PortPrototypes typed by an NvDataInterface d An AtomicSwComponent-
Type may have AbstractRequiredPortPrototypes typed by an NvDataInter-
face. If such an AbstractRequiredPortPrototype remains unconnected the
nvData still need to have reasonable value7 . c(RS_SWCT_03225)
7
Note that it is assumed that only a subset of meta-classes that inherit from AtomicSwComponent-
Type will actually apply for the definition of initial values for nvData. Most likely the Application-
SwComponentType and the SensorActuatorSwComponentType will be candidates for using this
feature but it will obviously not be reasonable for e.g. NvBlockSwComponentType.

190 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[TPS_SWCT_01227] Unconnected AbstractRequiredPortPrototype typed by

NvDataInterface d For this purpose it is possible to let the AbstractRequired-
PortPrototype own an NvRequireComSpec that in turn owns a ValueSpecifi-
cation in the role of initValue.
It is therefore possible to provide an nvData with a reasonable value even if
the corresponding AbstractRequiredPortPrototype remains unconnected. c
(RS_SWCT_03225)
PortPrototype
AbstractRequiredPortPrototype

+requiredComSpec 0..*

RPortComSpec

AutosarDataPrototype
NvRequireComSpec
+variable VariableDataPrototype

+initValue 0..1

ValueSpecification

+ shortLabel: Identifier [0..1]

Figure 4.41: Communication attributes of a required VariableDataPrototypes used in

the context of an NvDataInterface

[TPS_SWCT_01754] initValue defined in the context of a ComSpec d Unless

[TPS_SWCT_01755] applies, only the initValue defined in the context of a NvRe-
quireComSpec is relevant for connections to the corresponding PortPrototype.
An initValue defined in the scope of a VariableDataPrototype shall be ignored
anyway. c(RS_SWCT_03225)
[TPS_SWCT_01755] Duplicate existence of initValue in the context of a PR-
PortPrototype typed by an NvDataInterface d If an initValue is defined in
a NvRequireComSpec owned by a PRPortPrototype its value shall be ignored.
Instead, the initValue shall be taken from the NvProvideComSpec.ramBlock-
InitValue. c(RS_SWCT_03225)

191 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Class NvRequireComSpec
Package M2::AUTOSARTemplates::SWComponentTemplate::Communication
Note Communication attributes of RPortPrototypes with respect to Nv data communication on the required
side.
Base ARObject, RPortComSpec
Attribute Type Mul. Kind Note
initValue ValueSpecification 0..1 aggr The initial value owned by the NvComSpec
variable VariableDataPrototype 1 ref The VariableDataPrototype the ComSpec applies for.

Table 4.81: NvRequireComSpec

[TPS_SWCT_01228] NvProvideComSpec d As communication with an NvBlock-

SwComponentType is in most cases bi-directional it is also necessary to consider role-
specific communication attributes for AbstractProvidedPortPrototypes typed
by an NvDataInterface. For this purpose the NvProvideComSpec is defined.
The main purpose of this kind of ComSpec is the definition of initial values for the RAM
Block and the ROM Block that corresponds to an nvData defined in the context
of the NvDataInterface used to type the given AbstractProvidedPortProto-
type. c(RS_SWCT_03225)
More information about NvProvideComSpec please refer to Figure 4.42.
Note that these initial values can be taken as an input for designing an NvBlock-
SwComponentType, in particular the ramBlocks and romBlocks of NvBlockDe-
scriptors owned by the NvBlockSwComponentType. Further details are explained
in Figure 11.9.
Further note that the romBlockInitValue provided in the NvProvideComSpec
does not necessarily have to be identical to the respective section within romBlock
in the NvBlockDescriptor.
This could happen if an NvBlockSwComponentType is already existing and an Ap-
plicationSwComponentType is connected to it. Finally, the romBlock inside the
NvBlockDescriptor is the only relevant information for the RTE generation.

192 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

PortPrototype
AbstractProvidedPortPrototype

+providedComSpec 0..*

PPortComSpec

AutosarDataPrototype
NvProvideComSpec
+variable VariableDataPrototype

+romBlockInitValue 0..1 +ramBlockInitValue 0..1

ValueSpecification

+ shortLabel: Identifier [0..1]

Figure 4.42: Communication attributes of a provided VariableDataPrototypes used

in the context of an NvDataInterface

In other words, by means of the NvProvideComSpec the author of an Applica-

tionSwComponentType can express detailed requirements on the later design of a
corresponding NvBlockSwComponentType.
Class NvProvideComSpec
Package M2::AUTOSARTemplates::SWComponentTemplate::Communication
Note Communication attributes of PPortPrototypes with respect to Nv data communication on the provided
side.
Base ARObject, PPortComSpec
Attribute Type Mul. Kind Note
ramBlockInit ValueSpecification 0..1 aggr This represents the initial value of the RAM Block that
Value corresponds to the referenced variable.
romBlockInit ValueSpecification 0..1 aggr This represents the initial value of the ROM block that
Value corresponds to the referenced variable.
variable VariableDataPrototype 1 ref This represents the variable for which the ComSpec is
specified.

Table 4.82: NvProvideComSpec

4.5.6 Configuration of Data Transformation

Using the TransformationComSpecProps it is possible to define configuration op-

tions for specific transformers of inter-ecu communication which is subject to data
transformation.

193 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[TPS_SWCT_01594] Semantics of TransformationComSpecProps d The defini-

tion of a TransformationComSpecProps can always be provided in the SWC de-
scription but the configuration shall only have an effect if
1. the actual communication involves at least two EcuInstances
2. the respective data transformer (given by the used TransformationCom-
SpecProps) is used during data transformation (see DataTransformation)
c(RS_SWCT_03221)
For clarification, the configuration given in TransformationComSpecProps will sim-
ply be ignored if the conditions defined by [TPS_SWCT_01594] do not apply.
[TPS_SWCT_01597] PortPrototype-specific data transformation configuration
d Meta-class TransformationComSpecProps shall be used for the specification of
PortPrototype-specific configuration options for data transformation of inter-ECU
communication. c(RS_SWCT_03221)
Please note that only some transformers offer PortPrototype-specific configuration
(e.g. SOME/IP transformer doesn’t have TransformationComSpecProps).
RPortComSpec PPortComSpec RPortComSpec
ReceiverComSpec ServerComSpec ClientComSpec

+transformationComSpecProps 0..* +transformationComSpecProps 0..* +transformationComSpecProps 0..*

Describable
TransformationComSpecProps

UserDefinedTransformationComSpecProps EndToEndTransformationComSpecProps

+ disableEndToEndCheck: Boolean
+ 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]
+ syncCounterInit: PositiveInteger [0..1]
+ windowSize: PositiveInteger [0..1]

Figure 4.43: Specification of data transformation properties within ReceiverComSpec,

ServerComSpec, and ClientComSpec

194 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Class TransformationComSpecProps (abstract)

Package M2::AUTOSARTemplates::SWComponentTemplate::Communication
Note TransformationComSpecProps holds all the attributes for transformers that are port specific.
Base ARObject, Describable
Subclasses EndToEndTransformationComSpecProps, UserDefinedTransformationComSpecProps
Attribute Type Mul. Kind Note
– – – – –
Table 4.83: TransformationComSpecProps

It can be determined by the specific TransformationComSpecProps to which trans-

former this configuration is applicable:
• The configuration in EndToEndTransformationComSpecProps is applicable
to E2E transformer (protocol of TransformationTechnology is set to End-
ToEnd).
• The configuration in UserDefinedTransformationComSpecProps is appli-
cable to a user-defined transformer.
[TPS_SWCT_01598] More than one user-defined transformer is used within
one transformer chain d If more than one user-defined transformer is used
within one transformer chain (defined by meta-class TransformationTechnol-
ogy), the UserDefinedTransformationComSpecProps shall be assigned to
the correct user-defined custom transformer in TransformationTechnology. c
(RS_SWCT_03221)

195 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

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: Integer
asymmetricToByteArray

+transformationISignalProps 0..* +transformationISignalProps 0..*

Describable
«atpVariation»
TransformationISignalProps

+ csErrorReaction: CSTransformerErrorReactionEnum [0..1]

1..* +transformer
0..* +transformationTechnology {ordered} +transformerChain 1

Identifiable
TransformationTechnology

+ hasInternalState: Boolean [0..1]

+ needsOriginalData: Boolean [0..1]
+ protocol: String
+ transformerClass: TransformerClassEnum
+ version: String

  
«atpVariation»
   

+transformationDescription 0..1 +bufferProperties 1

Describable
BufferProperties
TransformationDescription
+ headerLength: Integer
+ inPlace: Boolean

+bufferComputation 0..1

«enumeration» CompuScale
TransformerClassEnum
+ mask: PositiveInteger [0..1]
serializer + shortLabel: Identifier [0..1]
safety + symbol: CIdentifier [0..1]
security
«atpVariation»
custom
+ lowerLimit: Limit [0..1]
+ upperLimit: Limit [0..1]

Figure 4.44: Big picture of data transformation in the AUTOSAR meta-model

196 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[constr_1400] Reference to a specific DataTransformation d A specific Data-

Transformation shall only be referenced by either
• a DataPrototypeMapping in the role firstToSecondDataTransforma-
tion (and potentially secondToFirstDataTransformation) or
• an ISignal in the role dataTransformation or
• an ISignalGroup in the role comBasedSignalGroupTransformation or
• a ClientServerOperationMapping in the role firstToSecondData-
Transformation
c()
[constr_1401] Restrictions on the relation between DataPrototypeMapping and
DataTransformation d A VariableDataPrototype in the context of a Port-
Prototype shall not be referenced by a DataPrototypeMapping that references a
DataTransformation while a DataMapping exists that points to this Variable-
DataPrototype (via the SystemSignal) that also refers to an ISignal that in turn
references a DataTransformation. c()
In other words: a VariableDataPrototype can either become a part of a Dat-
aPrototypeMapping-based data transformation or of an ISignal-based data trans-
formation.
Please note that in a composite software structure the VariableDataProto-
type can be delegated throughout the CompositionSwComponentType and [con-
str_1401] still applies.
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 Mul. 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.
5

197 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4
Class TransformationTechnology
version String 1 attr Version of the implemented protocol.

Table 4.84: TransformationTechnology

Based on the user defined attributes inside UserDefinedTransformationCom-

SpecProps (which are, of course, not standardized), the generator of the user-
defined transformer shall determine to which user-defined transformer a UserDe-
finedTransformationComSpecProps belongs to.
Class UserDefinedTransformationComSpecProps
Package M2::AUTOSARTemplates::SWComponentTemplate::Communication
Note The UserDefinedTransformationComSpecProps is used to specify port specific configuration properties
for custom transformers.
Base ARObject, Describable, TransformationComSpecProps
Attribute Type Mul. Kind Note
– – – – –
Table 4.85: UserDefinedTransformationComSpecProps

[TPS_SWCT_01599] PortPrototype-specific configuration for custom trans-

formers d Meta-class UserDefinedTransformationComSpecProps shall be used
for the specification of PortPrototype-specific configuration options for custom
transformers. c(RS_SWCT_03221)
Please note that it is possible to add custom configuration items in UserDefined-
TransformationComSpecProps by means of the attribute adminData.sdg.
Class EndToEndTransformationComSpecProps
Package M2::AUTOSARTemplates::SystemTemplate::Transformer
Note The class EndToEndTransformationIComSpecProps specifies port specific
configuration properties for EndToEnd transformer attributes.
Base ARObject, Describable, TransformationComSpecProps
Attribute Type Mul. Kind Note
disableEndTo Boolean 1 attr Disables/Enables the E2E check. The E2Eheader is
EndCheck removed from the payload independent from the setting of
this attribute.
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.
The minimum value is 0.
5

198 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4
Class EndToEndTransformationComSpecProps
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.
The minimum value is 0.
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.
The minimum value is 0.
maxNoNewOr PositiveInteger 0..1 attr EndToEndTransformationDescription holds these
RepeatedData attributes which are profile specific and have the same
value for all E2E transformers.
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.
The minimum value is 1.
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.
The minimum value is 1.
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.
The minimum value is 1.
syncCounterInit PositiveInteger 0..1 attr EndToEndTransformationDescription holds these
attributes which are profile specific and have the same
value for all E2E transformers.
windowSize PositiveInteger 0..1 attr Size of the monitoring window for the E2E state machine.
The meaning is the number of correct cycles
(E2E_P_OK) that are required in E2E_SM_INITCOM
before the transition to E2E_SM_VALID.
The minimum allowed value is 1.
Table 4.86: EndToEndTransformationComSpecProps

[TPS_SWCT_01600] PortPrototype-specific configuration for data transform-

ers related to end-to-end protection d Meta-class EndToEndTransformation-
ComSpecProps shall be used for the specification of PortPrototype-specific
configuration options for data transformers related to end-to-end protection. c
(RS_SWCT_03221)

4.6 Port Groups within Component Types

[TPS_SWCT_01063] PortGroup d A SwComponentType can declare that some of
its PortPrototypes belong to a PortGroup.
Such a port group defines a logical grouping of PortPrototypes which is used as
input to configure the implementation of mode managers in the basic software, for
example the communication of bus signals associated with the grouped ports maybe
suppressed in a certain mode. c(RS_SWCT_03200, RS_SWCT_03201)

199 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

ARElement
AtpBlueprint AtpBlueprintable
+port AtpPrototype
AtpBlueprintable
AtpType PortPrototype
«atpVariation,atpSplitable» 0..*
SwComponentType

+outerPort 0..*

  
    «atpVariation»
 

AtpStructureElement
+portGroup Identifiable

«atpVariation» PortGroup
0..*

+innerGroup
0..*

«instanceRef»

Figure 4.45: Declaration of PortGroups

Class PortGroup
Package M2::AUTOSARTemplates::SWComponentTemplate::Components
Note Group of ports which share a common functionality, e.g. need specific network resources. This
information shall be available on the VFB level in order to delegate it properly via compositions. When
propagated into the ECU extract, this information is used as input for the configuration of Services like
the Communication Manager. A PortGroup is defined locally in a component (which can be a
composition) and refers to the "outer" ports belonging to the group as well as to the "inner" groups which
propagate this group into the components which are part of a composition. A PortGroup within an atomic
SWC cannot be linked to inner groups.
Base ARObject, AtpClassifier , AtpFeature, AtpStructureElement, Identifiable, MultilanguageReferrable,
Referrable
Attribute Type Mul. Kind Note
innerGroup PortGroup * iref Links a PortGroup in a composition to another PortGroup,
that is defined in a component which is part of this
CompositionSwComponentType.
outerPort PortPrototype * ref Outer PortPrototype of this AtomicSwComponentType
which belongs to the group. A port can belong to several
groups or to no group at all.
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime

Table 4.87: PortGroup

[TPS_SWCT_01064] PortGroups have to be defined on the VFB level d Though

the declaration PortGroups is not relevant for the RTE, they have to be defined on the
VFB level, because they represent design decisions taken on this level. Accordingly,
PortGroups can be defined for CompositionSwComponentTypes as well as for
AtomicSwComponentTypes. c(RS_SWCT_03200, RS_SWCT_03201)
[TPS_SWCT_01065] PortPrototype may belong to more than one PortGroups
d A PortPrototype may belong to more than one PortGroups and PortGroups
can be associated with the “inner” PortGroups of SwComponentPrototypes which
are aggregated by the same SwComponentType as the PortGroup. By this, Port-
Groups can be locally defined but still traced down the component hierarchy. c
(RS_SWCT_03200, RS_SWCT_03201)

200 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[TPS_SWCT_01066] PortGroups can be associated with certain ServiceNeeds

d PortGroups can be associated with certain ServiceNeeds in order to trace the
information down to the configuration of the basic software. c(RS_SWCT_03200,
RS_SWCT_03201)
For more details, see chapter 7.11.2.
[constr_1147] Standardized values for the attribute category of meta-class
PortGroup d
The following values of the attribute category of meta-class PortGroup are reserved
by the AUTOSAR standard:
• MODE_MANAGEMENT: This represents the usage of the PortGroup for the pur-
pose of mode management
• PARTIAL_NETWORKING: This represents the usage of the PortGroup for the
purpose of partial networking
c()

4.7 End to End Protection

The aspect of end-to-end protection has seen different support by the AUTOSAR meta-
model.
On the one hand, there is the definition of dedicated meta-classes, e.g. EndToEnd-
Description, which aim at an implementation that uses a so-called E2E wrapper
(an approach with a software component above RTE invoking the E2E library) or
AUTOSAR Com module callout mechanism (with Com callouts used to invoke E2E
library).
This approach is documented in chapter 4.7 of this document.
As an alternative approach, it is possible to implement end-to-end protection using
so-called data transformers.
The detailed description of how this approach can be configured is beyond the scope
of this document. Please refer to the TPS System Template [10] where the details of
the alternative approach are explained.
In contrast to the approach based on the EndToEndProtection and EndToEnd-
Description (which partly involves technologies that are not subjected to the
AUTOSAR standard), the second approach is fully standardized by AUTOSAR.
As described in [19] there are cases where safety-related software-components pro-
tect the data exchanged between each other. For this purpose modeling support is
provided by the software-component template.

201 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Note that several end-to-end profiles are selectable for a specific application. The spe-
cific end-to-end profile is represented by the attribute category of meta-class End-
ToEndDescription.
Semantically, the category value represents an identification of the specific end-to-
end profile applicable for the communication of the corresponding data element. Ac-
cording to [19] there are two pre-defined profiles that can be used.
[TPS_SWCT_01089] end-to-end communication protection d The information
specific to each profile is expressed by the set of attributes of EndToEndDe-
scription owned by EndToEndProtection in the role endToEndProfile. c
(RS_SWCT_03240)
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 Mul. Kind Note
category NameToken 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
5

202 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4
Class EndToEndDescription
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.
• 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 4.88: EndToEndDescription

[TPS_SWCT_01090] EndToEndProtection d EndToEndProtection is the Iden-

tifiable class that owns specific elements for referencing the to-be-protected data
elements and signals

203 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

• EndToEndProtectionVariablePrototype: a specific dataElement

owned by a specific PortPrototype
• EndToEndProtectionISignalIPdu: a specific ISignalGroup in the con-
text of an ISignalIPdu. For more details please refer to [10]
c(RS_SWCT_03240)
[TPS_SWCT_01091] Two cases for end-to-end protection d In order to protect
a VariableDataPrototype the EndToEndProtectionVariablePrototype shall be
defined. If communication is defined between ECUs using AUTOSAR COM the End-
ToEndProtectionISignalIPdu shall be defined as well. c(RS_SWCT_03240)
The following features apply:
• [constr_1000] End-to-end protection is limited to sender/receive communi-
cation d end-to-end protection applies for sender/receiver communication only c
()
• The value of the dataId is assigned by a central authority rather than by the
developer of the software-component.
• The information about the dataId shall be available at both the sender and the
receiver(s).
• [constr_1001] Value of dataId shall be unique d The value of the dataId
shall be unique within the scope of the System. c()
• [TPS_SWCT_01508] Scope of end-to-end protection d End-to-end protection
applies to local (i.e. within the ECU) as well as remote (i.e. ECU to ECU) com-
munication. c(RS_SWCT_03240)
[TPS_SWCT_01092] EndToEndProtectionSet d The meta-class EndToEndPro-
tectionSet provides a container for EndToEndProtection. The aggregation is
stereotyped atpSplitable because the information about end-to-end protection
is added at a later step in the development workflow. c(RS_SWCT_03240)
It also has the stereotype atpVariation because this allows for implementing
the software-component in two variants, one that uses end-to-end protection and one
that does not use it. It also might happen that the communication ends themselves are
variant.
EndToEndProtection maintains InstanceRefs to one dataElement in the role
of sender and to one or many dataElements in the role of receiver. By this means
it is possible to support a 1:n communication scenario.
[TPS_SWCT_01093] Definition of end-to-end protection is splitable d End-
ToEndProtection aggregates EndToEndDescription using stereotype
atpSplitable. By this means it is for the integrator of an ECU possible
to generally specify the nature of a specific end-to-end protection but leave the actual
assignment of values (e.g. for dataId) to a later process step. c(RS_SWCT_03240)

204 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

ARElement
EndToEndProtectionSet

«atpVariation,atpSplitable»

EndToEndDescription
0..* +endToEndProtection
+ category: NameToken
Identifiable + counterOffset: PositiveInteger [0..1]

   EndToEndProtection +endToEndProfile + crcOffset: PositiveInteger [0..1]
    + dataId: PositiveInteger [0..*] {ordered}
  «atpSplitable» 1 + dataIdMode: PositiveInteger [0..1]
+ dataIdNibbleOffset: PositiveInteger [0..1]
+ dataLength: PositiveInteger [0..1]
+ maxDeltaCounterInit: PositiveInteger [0..1]
+ maxNoNewOrRepeatedData: PositiveInteger [0..1]
+ syncCounterInit: PositiveInteger [0..1]
«atpVariation,atpSplitable»

+endToEndProtectionVariablePrototype 0..*
+sender
AtpInstanceRef
EndToEndProtectionVariablePrototype
0..1 VariableDataPrototypeInSystemInstanceRef
+ shortLabel: Identifier [0..1] +receiver

0..*

1
{redefines
+targetDataPrototype atpTarget}
+sender
AutosarDataPrototype
«instanceRef» 0..1 VariableDataPrototype
+receiver

«instanceRef» 0..*

Figure 4.46: Details of the modeling of end-to-end protection

According to [19] the following constraints apply on the attributes of EndToEndPro-

tection (note that additional M1 constraints apply as described in [19]):
[constr_1110] Value of category in EndToEndDescription d The attribute cat-
egory of EndToEndDescription can have the following values:
• NONE
• PROFILE_01
• PROFILE_02
c()
[TPS_SWCT_01094] category of EndToEndDescription d The values for the
category of EndToEndDescription mentioned in [constr_1110] 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 category. c
(RS_SWCT_03240)
This aspect will be clarified in more detail in later revisions of the AUTOSAR standard.
For the time being, it shall be noted that the usage of other than the standardized values
shall not create name clashes with future standardized values. This can be achieved
by using e.g. a company-specific prefix or suffix to the value of category.

205 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

The semantics of the categorys is:

NONE this indicates that the E2E framework shall be enabled for the given
sender/receiver respectively the given iSignalIPdu. The wrapper code
shall be generated but it shall not invoke E2E library protection routines. E2E
wrapper works as pass-through.
This may be used when a profile selection or profile options are not yet selected
in a given system but it is required that the system can be built successfully
under consideration of the E2E library. This would also be applicable for migrating
from/to a system with/without E2E protection.
[TPS_SWCT_01095] category set to NONE d If attributes exist in the pres-
ence of the category being set to NONE the attributes shall be ignored. c
(RS_SWCT_03240)
PROFILE_01 This indicates that the settings of E2E profile 1 (that uses a SAE CRC8,
implicit 16 bit data ID, and a 4 bit alive counter) apply.
[constr_1113] Existence of attributes in PROFILE_01 d In PROFILE_01, the
following attributes shall exist:
• dataLength
• dataId
c()
Please note that the attribute maxDeltaCounterInit is also part of PRO-
FILE_01 but it does not necessarily have to exist provided that ReceiverCom-
Spec.maxDeltaCounterInit exists.
[constr_1170] Interpretation of attribute maxDeltaCounterInit owned
by EndToEndDescription d If EndToEndProtection.endToEndPro-
tectionVariablePrototype.receiver is identical to the RPortProto-
type.requiredComSpec.dataElement and RPortPrototype.required-
ComSpec.maxDeltaCounterInit is defined then the value of RPort-
Prototype.requiredComSpec.maxDeltaCounterInit shall be preferred
over the value of EndToEndProtection.endToEndProfile.maxDelta-
CounterInit.
If the value of category of EndToEndDescription is set to PROFILE_01
and either the described correspondence rule concerning the referenced
VariableDataPrototype is not fulfilled or RPortPrototype.required-
ComSpec.maxDeltaCounterInit is not defined then EndToEndProtec-
tion.endToEndProfile.maxDeltaCounterInit shall exist. c()
[constr_1111] Constraints of dataId in PROFILE_01 d In PROFILE_01, there
shall be only one element in the set and the applicable range of values is
[0 .. 65535]. c()

206 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[constr_1112] Constraints of dataIdMode in PROFILE_01 d In PROFILE_01,

the applicable range of values for dataIdMode is [0 .. 3]. c()
[constr_1114] Constraints of crcOffset in PROFILE_01 d In PROFILE_01,
the applicable range of values for crcOffset is [0 .. 65535]. For the value of
this attribute the constraint value mod 4 = 0 applies. c()
[constr_1115] Constraints of counterOffset in PROFILE_01 d In PRO-
FILE_01, the applicable range of values for counterOffset is [0 .. 65535]. For
the value of this attribute the constraint value mod 4 = 0 applies. c()
[constr_1116] Constraints of dataLength in PROFILE_01 d In PROFILE_01,
the applicable range of values for dataLength is [0 .. 240]. For the value of this
attribute the constraint value mod 8 = 0 applies. c()
[constr_1117] Constraints of maxDeltaCounterInit in PROFILE_01
d In PROFILE_01, the applicable range of values for EndToEndDescrip-
tion.maxDeltaCounterInit and ReceiverComSpec.maxDeltaCoun-
terInit is [0 .. 14]. c()
[constr_1211] Constraints of maxNoNewOrRepeatedData in PROFILE_01
d In PROFILE_01, the applicable range of values for EndToEndDescrip-
tion.maxNoNewOrRepeatedData and ReceiverComSpec.maxNoNewOrRe-
peatedData is [0 .. 14]. c()
[constr_1212] Constraints of syncCounterInit in PROFILE_01 d In PRO-
FILE_01, the applicable range of values for EndToEndDescription.sync-
CounterInit and ReceiverComSpec.syncCounterInit is [0 .. 14]. c()
[constr_1215] Interpretation of attribute maxNoNewOrRepeatedData
owned by EndToEndDescription in PROFILE_01 d If EndToEndProtec-
tion.endToEndProtectionVariablePrototype.receiver is identical to
the RPortPrototype.requiredComSpec.dataElement and RPortPro-
totype.requiredComSpec.maxNoNewOrRepeatedData is defined then the
value of RPortPrototype.requiredComSpec.maxNoNewOrRepeatedData
shall be preferred over the value of EndToEndProtection.endToEndPro-
file.maxNoNewOrRepeatedData.
If the value of category of EndToEndDescription is set to PROFILE_01
and either the described correspondence rule concerning the referenced
VariableDataPrototype is not fulfilled or RPortPrototype.required-
ComSpec.maxNoNewOrRepeatedData is not defined then EndToEndProtec-
tion.endToEndProfile.maxNoNewOrRepeatedData shall exist. c()

207 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[constr_1216] Interpretation of attribute syncCounterInit owned by End-

ToEndDescription in PROFILE_01 d If EndToEndProtection.endToEnd-
ProtectionVariablePrototype.receiver is identical to the RPort-
Prototype.requiredComSpec.dataElement and RPortPrototype.re-
quiredComSpec.syncCounterInit is defined then the value of RPortPro-
totype.requiredComSpec.syncCounterInit shall be preferred over the
value of EndToEndProtection.endToEndProfile.syncCounterInit.
If the value of category of EndToEndDescription is set to PROFILE_01
and either the described correspondence rule concerning the referenced Vari-
ableDataPrototype is not fulfilled or RPortPrototype.requiredCom-
Spec.syncCounterInit is not defined then EndToEndProtection.end-
ToEndProfile.syncCounterInit shall exist. c()
[constr_1261] Applicability for EndToEndDescription.dataIdNibble-
Offset d EndToEndDescription.dataIdNibbleOffset shall be used only
if EndToEndDescription.dataIdMode is set to the value 3 and at the same
time EndToEndDescription.category is set to PROFILE_01. c()
[TPS_SWCT_01529] Default value for EndToEndDescription.dataIdNib-
bleOffset d If EndToEndDescription.dataIdMode is set to the value 3 and
at the same time EndToEndDescription.category is set to the value PRO-
FILE_01 and EndToEndDescription.dataIdNibbleOffset is not specified,
then the default value of 12 (bits) shall be assumed for the attribute EndToEnd-
Description.dataIdNibbleOffset. c(RS_SWCT_03240)
PROFILE_02 this indicates that the settings of E2E profile 2 apply.
[constr_1118] Existence of attributes in PROFILE_02 d In PROFILE_02, only
the following attributes shall exist:
• dataLength
• dataId
c()
Please note that the attribute maxDeltaCounterInit is also part of PRO-
FILE_01 but it does not necessarily have to exist provided that ReceiverCom-
Spec.maxDeltaCounterInit exists.
[constr_1171] Interpretation of attribute maxDeltaCounterInit of End-
ToEndDescription d If EndToEndProtection.endToEndProtection-
VariablePrototype.receiver is identical to the RPortPrototype.re-
quiredComSpec.dataElement and RPortPrototype.requiredCom-
Spec.maxDeltaCounterInit is defined then the value of RPortProto-
type.requiredComSpec.maxDeltaCounterInit shall be preferred over
the value of EndToEndProtection.endToEndProfile.maxDeltaCoun-
terInit.

208 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

If the value of category of EndToEndDescription is set to PROFILE_02

and either the described correspondence rule concerning the referenced
VariableDataPrototype is not fulfilled or RPortPrototype.required-
ComSpec.maxDeltaCounterInit is not defined then EndToEndProtec-
tion.endToEndProfile.maxDeltaCounterInit shall exist. c()
[constr_1119] Constraints of dataLength in PROFILE_02 d In PROFILE_02,
the applicable range of values for dataLength is [0 .. 65535]. For the value of
this attribute the constraint value mod 8 = 0 applies. c()
[constr_1120] Constraints of dataId in PROFILE_02 d In PROFILE_02, there
shall be exactly ordered 16 elements in the set and the applicable range of values
is [0 .. 255]. c()
[constr_1121] Constraints of maxDeltaCounterInit in PROFILE_02
d In PROFILE_02, the applicable range of values for EndToEndDescrip-
tion.maxDeltaCounterInit and ReceiverComSpec.maxDeltaCoun-
terInit is [0 .. 15]. c()
[constr_1213] Constraints of maxNoNewOrRepeatedData in PROFILE_02
d In PROFILE_02, the applicable range of values for EndToEndDescrip-
tion.maxNoNewOrRepeatedData and ReceiverComSpec.maxNoNewOrRe-
peatedData is [0 .. 15]. c()
[constr_1214] Constraints of syncCounterInit in PROFILE_02 d In PRO-
FILE_02, the applicable range of values for EndToEndDescription.sync-
CounterInit and ReceiverComSpec.syncCounterInit is [0 .. 15]. c()
[constr_1217] Interpretation of attribute maxNoNewOrRepeatedData
owned by EndToEndDescription in PROFILE_02 d If EndToEndProtec-
tion.endToEndProtectionVariablePrototype.receiver is identical to
the RPortPrototype.requiredComSpec.dataElement and RPortPro-
totype.requiredComSpec.maxNoNewOrRepeatedData is defined then the
value of RPortPrototype.requiredComSpec.maxNoNewOrRepeatedData
shall be preferred over the value of EndToEndProtection.endToEndPro-
file.maxNoNewOrRepeatedData.
If the value of category of EndToEndDescription is set to PROFILE_02
and either the described correspondence rule concerning the referenced
VariableDataPrototype is not fulfilled or RPortPrototype.required-
ComSpec.maxNoNewOrRepeatedData is not defined then EndToEndProtec-
tion.endToEndProfile.maxNoNewOrRepeatedData shall exist. c()
[constr_1218] Interpretation of attribute syncCounterInit owned by End-
ToEndDescription in PROFILE_02 d If EndToEndProtection.endToEnd-
ProtectionVariablePrototype.receiver is identical to the RPort-
Prototype.requiredComSpec.dataElement and RPortPrototype.re-
quiredComSpec.syncCounterInit is defined then the value of RPortPro-
totype.requiredComSpec.syncCounterInit shall be preferred over the
value of EndToEndProtection.endToEndProfile.syncCounterInit.

209 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

If the value of category of EndToEndDescription is set to PROFILE_02

and either the described correspondence rule concerning the referenced Vari-
ableDataPrototype is not fulfilled or RPortPrototype.requiredCom-
Spec.syncCounterInit is not defined then EndToEndProtection.end-
ToEndProfile.syncCounterInit shall exist. c()
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 Mul. Kind Note
endToEnd EndToEndProtection * aggr This is one particular EndToEndProtection.
Protection
Stereotypes: atpSplitable; atpVariation
Tags: atp.Splitkey=shortName, variationPoint.shortLabel
vh.latestBindingTime=preCompileTime

Table 4.89: 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
Attribute Type Mul. Kind Note
endToEnd EndToEndDescription 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=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.
Stereotypes: atpSplitable; atpVariation
Tags: atp.Splitkey=shortLabel, variationPoint.shortLabel
vh.latestBindingTime=preCompileTime

Table 4.90: EndToEndProtection

210 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Class EndToEndProtectionVariablePrototype
Package M2::AUTOSARTemplates::SWComponentTemplate::EndToEndProtection
Note It is possible to protect the data exchanged between software components. For this purpose, for each
communication to be protected, the user defines a separate EndToEndProtection (specifying a set of
protection settings) and refers to a variableDataPrototype in the role of sender and to one or many
variableDataPrototypes in the role of receiver. For details, see EndToEnd Library.
Base ARObject
Attribute Type Mul. Kind Note
receiver VariableDataPrototype * iref This represents the receiver. Note that 1:n
communication is supported for this use case.
sender VariableDataPrototype 0..1 iref This represents the sender.
Can be optional if an ecu extract is provided and the
sender is part of the extract.
shortLabel Identifier 0..1 attr This serves as part of the split key in case of more than
one EndToEndProtectionVariablePrototype is aggregated
in the bound model.
Table 4.91: EndToEndProtectionVariablePrototype

Please note that using end-to-end protection it is explicitly supported that one sender
may correspond to one or more receivers.
[constr_1183] EndToEndProtectionVariablePrototypes aggregated by End-
ToEndProtection d All EndToEndProtectionVariablePrototypes aggre-
gated by the same EndToEndProtection shall refer to the identical sender. c()

4.8 Partial Networking

[TPS_SWCT_01169] Support for partial networking d On the level of the Software
Component Template, partial networking is supported by means of the concept of a
“Virtual Function Cluster” (VFC).
The latter groups all communication on the VFB with respect to a given function. How-
ever, the conceptual idea of a Virtual Function Cluster is not represented in the meta-
model as such.
Instead, PortGroups are used to specify the grouping of PortPrototypes to
the higher conceptual level of a Virtual Function Cluster. c(RS_SWCT_03241,
RS_SWCT_03201)
Please note that more information regarding the semantics of PortGroups can be
found in chapter 4.6.
There are no restrictions regarding the structure of PortGroup definitions on M1. One
PortPrototype may become a member of several PortGroups, thereby creating
overlapping PortGroups.
[TPS_SWCT_01170] Purpose of Virtual Function Cluster d The purpose of Virtual
Function Cluster within the Software Component Template mainly has three aspects:

211 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

1. assign PortPrototypes (non service related) of Sender Receiver or Client

Server communication to Virtual Function Clusters.
2. control the behavior of the corresponding function in terms of whether or not it is
required at a given point in time. This aspect is implemented by the concept of
a control port. Software-components that implement control ports of a Virtual
Function Cluster conceptually become VFC Controllers.
3. allow for the application software to retrieve the status of a given Virtual Function
Cluster. This aspect is implemented by the concept of a status port.
c(RS_SWCT_03241)
The usage of the generic concept of PortGroups for the purpose of partial networks
shall be indicated by setting the value of the attribute category of PortGroup to
PARTIAL_NETWORKING, see [constr_1147].

4.8.1 VFC Control Ports

[TPS_SWCT_01171] Purpose of a control port d The purpose of a control port is

to request or release a VFC. Requesting means that the VFC is actively using com-
munication resources while release boils down to the VFC being inactive, i.e. the
corresponding partial network may be shut down until further notice.
As the requesting and releasing semantics is implemented by means of interfacing the
BSW the corresponding control ports need to be typed by a PortInterface that has
the attribute isService set to true. c(RS_SWCT_03241)
[TPS_SWCT_01172] Requesting and releasing partial networks d For requesting
and releasing partial networks, the BSW can be interfaced in two alternative (i.e. either
one or the other) ways:
• ComM: ClientServerInterface using the standardized ComM_UserRe-
quest.RequestComMode [20]
• BswM: SenderReceiverInterface using the standardized AppModeRe-
questInterface.requestedMode [14]
c(RS_SWCT_03241)
[TPS_SWCT_01173] Control port shall not become a part of the PortGroup d
Please note that the control port shall not become a part of the PortGroup that de-
fines the particular VFC the control port is going to service.
The relationship is implemented by means of a specific SwcServiceDependency
that owns a RoleBasedPortAssignment to the intended control port and refers
to a PortGroup (that comprises the VFC) in the role representedPortGroup. c
(RS_SWCT_03241, RS_SWCT_03201)
For further information, please refer to [TPS_SWCT_01126].

212 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4.8.2 VFC Status Ports

[TPS_SWCT_01175] Actively query the status of a partial network d Very much like
mode management, the concept of partial networking supports the ability to actively
query the status of a partial network.
This can be done by means of interfacing the BSW in three alternative (as in “one of”)
ways:
• ComM: ClientServerInterface using the standardized ComM_UserRe-
quest.GetCurrentComMode [20]
• ComM: ModeSwitchInterface using the standardized ComM_CurrentMode.
currentMode [20]
• BswM: ModeSwitchInterface using the standardized AppModeInter-
face.currentMode [14]
c(RS_SWCT_03241)
As mentioned above, the status of the ComM can be retrieved by either a
ClientServerInterface or a SenderReceiverInterface. Which of the two
alternatives applies in a specific case is up to the author of a software-component8 .
When using one of the possible SenderReceiverInterfaces, the correspondence
of the status port concept with mode management extends to the point that the status
of the partial network is returned as an actual ModeDeclaration.
This implies that all mechanisms foreseen by the Software Component Template to
react on mode changes are in place and can be used within the application software.
To assure that the communication via PortPrototypes that belong to a partial net-
work is valid the software component shall consider the status of the partial network
before communicating in order to assert its activity.
[TPS_SWCT_01174] Status port shall not become a member of the PortGroup d
A status port shall not become a member of the PortGroup that corresponds to the
partial network subject to the status port.
The relationship is implemented by means of a specific SwcServiceDependency
that owns a RoleBasedPortAssignment to the intended status port and refers
to a PortGroup (that comprises the VFC) in the role representedPortGroup. c
(RS_SWCT_03241, RS_SWCT_03201)
For further information, please refer to [TPS_SWCT_01126].
8
The usage of the ClientServerInterface effectively implements a “pull” approach for the mode
information while the usage of the SenderReceiverInterface resembles a “push” approach if it is
used in combination with a SwcModeSwitchEvent.

213 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4.9 Formal Definition of implicit Communication Behavior

[TPS_SWCT_01509] Implicit communication behavior d The purpose of the formal
definition of the behavior of a SwComponentType with respect to the implicit commu-
nication can conceptually condensed to two basic aspects:
• Stable data during the execution of a group of RunnableEntitys. This means
that all data values read by different RunnableEntitys are from the same
age. Therefore the value is not changing during the execution of the chain of
RunnableEntitys.
• Coherent data consumption and propagation for a group of DataProto-
types. This means that a set of interdependent data values are from the
same calculation iteration. Therefore the set of values has to be propagated
at once to RunnableEntitys requiring the complete result of the calculation.
RunnableEntitys which are part of the calculation chain may still consume
partly updated values.
c(RS_SWCT_03065)
[TPS_SWCT_01481] The meaning of the term stability with respect to Consis-
tencyNeeds d The meaning of the term stability is that the values of a group of Vari-
ableDataPrototypes shall not change values during the execution of a group of
RunnableEntitys. c(RS_SWCT_03065)
[TPS_SWCT_01482] The meaning of the term coherence with respect to Consis-
tencyNeeds d The meaning of the term coherence means that the values of a group of
VariableDataPrototypes shall not be read by receiving RunnableEntitys until
all the producing RunnableEntitys are terminated. c(RS_SWCT_03065)
In response to these goals the meta-model provides means to express the correlation
between a group of RunnableEntitys and a group of DataPrototypes. These
groups might be defined hierarchically.
The information (in terms of ConsistencyNeeds) can be defined primarily during the
design of an AtomicSwComponentType but it is just as well possible to specify this
ConsistencyNeeds during the definition of CompositionSwComponentTypes.
For example, the existence of stable data is typically expected for the execution of
RunnableEntitys of several AtomicSwComponentTypes.

214 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

ARElement
AtpBlueprint
AtpBlueprintable
AtpType
SwComponentType

  
   
  «atpVariation,atpSplitable»

+consistencyNeeds 0..*

AtpBlueprint
AtpBlueprintable
Identifiable
ConsistencyNeeds

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

+regRequiresStability 0..* +regDoesNotRequireStability 0..* +dpgRequiresCoherency 0..* +dpgDoesNotRequireCoherency 0..*

AtpStructureElement AtpStructureElement
«instanceRef» Identifiable Identifiable
«instanceRef»
RunnableEntityGroup DataPrototypeGroup

+runnableEntityGroup 0..* +dataPrototypeGroup 0..*

«instanceRef» «instanceRef»

+runnableEntity 0..* +implicitDataAccess 0..*

AtpStructureElement AutosarDataPrototype
ExecutableEntity VariableDataPrototype
RunnableEntity

+ canBeInvokedConcurrently: Boolean
+ symbol: CIdentifier

+dataElement 1..* +nvData 1..*

DataInterface DataInterface
SenderReceiverInterface NvDataInterface

Figure 4.47: Formal definition of implicit communication behavior

Please note that the two aspects stability and coherence are not necessarily con-
nected to each other. It is possible to require stability without coherence and vice
versa. For this purpose the roles dpgDoesNotRequireCoherency and regDoes-
NotRequireStability are needed.
[TPS_SWCT_01480] Stability and/or coherence is not required d In order to be
able to clearly separate the aspect of stability from coherence it is possible to use the
roles dpgDoesNotRequireCoherency to express that a group of VariableDat-
aPrototypes explicitly does not require consistency.
Likewise, regDoesNotRequireStability can be used to express that for a group
of RunnableEntitys stability with respect to data access is not required. c()

215 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[TPS_SWCT_01479] Applicability of ConsistencyNeeds d ConsistencyNeeds

can only be applied to RunnableEntitys that make use of “implicit” communication.
c(RS_SWCT_03065)
[TPS_SWCT_01466] ConsistencyNeeds applied on RunnableEntitys that
do not use implicit communication d If a ConsistencyNeeds is applied on
RunnableEntitys that do not use implicit communication it shall be ignored. c
(RS_SWCT_03065)
The formal definition of the implicit communication behavior foresees the grouping of
model elements in order to indicate their relevance for consistent implicit communica-
tion.
[TPS_SWCT_01470] RunnableEntityGroup d A RunnableEntitys belongs to
a specific RunnableEntityGroup if it is associated either directly with the given
RunnableEntityGroup or if the RunnableEntityGroup the RunnableEntity
belongs to is eventually (there can be more than one nesting level) referenced by the
given RunnableEntityGroup. c(RS_SWCT_03065)
[TPS_SWCT_01471] DataPrototypeGroup d A VariableDataPrototypes be-
longs to a specific DataPrototypeGroup if it is associated either directly with the
given DataPrototypeGroup or if the DataPrototypeGroup the VariableDat-
aPrototype belongs to is eventually (there can be more than one nesting level) ref-
erenced by the given DataPrototypeGroup. c(RS_SWCT_03065)
[constr_1231] ConsistencyNeeds aggregated by CompositionSwComponent-
Type d If ConsistencyNeeds are aggregated by a CompositionSwComponent-
Type the associations stereotyped instanceRef may only refer to context and
target elements within the context of this CompositionSwComponentType. c()
For clarification, [constr_1231] includes VariableDataPrototypes owned by del-
egation PortPrototypes of the owning CompositionSwComponentType, Vari-
ableDataPrototypes in delegation PortPrototypes of CompositionSwCompo-
nentType instantiated in the enclosing CompositionSwComponentType, or Vari-
ableDataPrototypes in PortPrototypes owned by AtomicSwComponentTypes
instantiated inside the context of the enclosing CompositionSwComponentType.
[constr_1232] ConsistencyNeeds aggregated by AtomicSwComponentType d If
ConsistencyNeeds are aggregated by a AtomicSwComponentType the associa-
tions stereotyped instanceRef may only refer to context and target elements
within the context of this AtomicSwComponentType. c()
Strictly speaking, these are the RunnableEntitys and PortPrototypes of this
particular AtomicSwComponentType or RunnableEntityGroups and DataPro-
totypeGroups which are owned by the same AtomicSwComponentType.
Please note that pre-defined values for the category of RunnableEntityGroup
and DataPrototypeGroup are described in [1].

216 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Class ConsistencyNeeds
Package M2::AUTOSARTemplates::SWComponentTemplate::ImplicitCommunicationBehavior
Note This meta-class represents the ability to define requirements on the implicit communication behavior.
Base ARObject, AtpBlueprint, AtpBlueprintable, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mul. Kind Note
dpgDoesNot DataPrototypeGroup * aggr This group of VariableDataPrototypes does not require
Require coherency with respect to the implicit communication
Coherency behavior.
Stereotypes: atpSplitable; atpVariation
Tags: atp.Splitkey=shortName, variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
dpgRequires DataPrototypeGroup * aggr This group of VariableDataPrototypes requires coherency
Coherency with respect to the implicit communication behavior, i.e.
all read and write access to VariableDataPrototypes in the
DataPrototypeGroup by the RunnableEntitys of the
RunnableEntityGroup need to be handled in a coherent
manner.
Stereotypes: atpSplitable; atpVariation
Tags: atp.Splitkey=shortName, variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
regDoesNot RunnableEntityGroup * aggr This group of RunnableEntities does not require stability
RequireStability with respect to the implicit communication behavior.
Stereotypes: atpSplitable; atpVariation
Tags: atp.Splitkey=shortName, variationPoint.shortLabel
vh.latestBindingTime=preCompileTime
regRequires RunnableEntityGroup * aggr This group of RunnableEntities requires stability with
Stability respect to the implicit communication behavior, i.e. all
read and write access to VariableDataPrototypes in the
DataPrototypeGroup by the RunnableEntitys of the
RunnableEntityGroup need to be handled in a stable
manner.
Stereotypes: atpSplitable; atpVariation
Tags: atp.Splitkey=shortName, variationPoint.shortLabel
vh.latestBindingTime=preCompileTime

Table 4.92: ConsistencyNeeds

Class RunnableEntityGroup
Package M2::AUTOSARTemplates::SWComponentTemplate::ImplicitCommunicationBehavior
Note This meta-class represents the ability to define a collection of RunnableEntities. The collection can be
nested.
Base ARObject, AtpClassifier , AtpFeature, AtpStructureElement, Identifiable, MultilanguageReferrable,
Referrable
Attribute Type Mul. Kind Note
runnableEntity RunnableEntity * iref This represents a collection of RunnableEntitys that
belong to the enclosing RunnableEntityGroup.
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime
runnableEntity RunnableEntityGroup * iref This represents the ability to define nested groups of
Group RunnableEntitys.
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime

Table 4.93: RunnableEntityGroup

217 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Class DataPrototypeGroup
Package M2::AUTOSARTemplates::SWComponentTemplate::ImplicitCommunicationBehavior
Note This meta-class represents the ability to define a collection of DataPrototypes that are subject to the
formal definition of implicit communication behavior. The definition of the collection can be nested.
Base ARObject, AtpClassifier , AtpFeature, AtpStructureElement, Identifiable, MultilanguageReferrable,
Referrable
Attribute Type Mul. Kind Note
dataPrototype DataPrototypeGroup * iref This represents the ability to define nested groups of
Group VariableDataPrototypes.
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime
implicitData VariableDataPrototype * iref This represents a collection of VariableDataPrototypes
Access that belong to the enclosing DataPrototypeGroup
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime

Table 4.94: DataPrototypeGroup

4.9.1 Consistency Needs on Receiver Side

[TPS_SWCT_01472] Receiving SwComponentType owns a DataPrototype-

Group in the role dpgRequiresCoherency d If a receiving SwComponentType
owns a DataPrototypeGroup in the role dpgRequiresCoherency for one or sev-
eral of its RunnableEntitys it is required that VariableDataPrototypes be-
longing to the same DataPrototypeGroup are produced coherently. This means
that the values of the VariableDataPrototypes shall be of the same age. c
(RS_SWCT_03065)
[TPS_SWCT_01473] Receiving SwComponentType owns a RunnableEntity-
Group in the role regRequiresStability d If a receiving SwComponentType
owns a RunnableEntityGroup in the role regRequiresStability for one or sev-
eral of its RunnableEntitys it is required that the values of implicitly communicated
VariableDataPrototypes are kept stable over the execution of all RunnableEn-
titys belonging to the given RunnableEntityGroup. c(RS_SWCT_03065)
[TPS_SWCT_01474] Receiving SwComponentType owns a RunnableEntity-
Group in the role regRequiresStability and also owns one or several Dat-
aPrototypeGroups in the role dpgRequiresCoherency d If a receiving SwCom-
ponentType owns a RunnableEntityGroup in the role regRequiresStability
and also owns one or several DataPrototypeGroups in the role dpgRequiresCo-
herency it is required that values of VariableDataPrototypes belonging to the
same DataPrototypeGroup are produced coherently.
This means that the values of the VariableDataPrototypes shall be of the same
age and are kept stable over the execution of all RunnableEntitys belonging to the
given RunnableEntityGroup. c()

218 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4.9.2 Consistency Needs on Sender Side

[TPS_SWCT_01475] Sending SwComponentType owns a DataPrototypeGroup

in the role dpgRequiresCoherency d If a sending SwComponentType owns a
DataPrototypeGroup in the role dpgRequiresCoherency for one or several
of its RunnableEntitys it is required that VariableDataPrototypes belonging
to the same DataPrototypeGroup are propagated at the same point of time to
RunnableEntitys which are not belonging to the group of producing RunnableEn-
titys (which may, but don’t have to be formally described as a RunnableEntity-
Group). c(RS_SWCT_03065)
The coherence is created at the point in time when the RunnableEntitys of the
producing group of RunnableEntitys terminate (and the implicit data get updated).
If those RunnableEntitys are reading the data also, those read accesses will not
read the coherent values but the intermediary values written by RunnableEntitys of
the same group.
For all other RunnableEntitys that are not member of the producing group of
RunnableEntitys it appears as if the data have been updated at this very point
coherently.
In order to avoid incorrect configurations its possible to explicitly define the group of
RunnableEntitys for which the coherency does not apply.
[TPS_SWCT_01625] Sending SwComponentType owns a DataPrototypeGroup
in the role dpgRequiresCoherency and also RunnableEntityGroups d If
a sending SwComponentType owns a DataPrototypeGroup in the role dp-
gRequiresCoherency, RunnableEntityGroups in the role regDoesNotRe-
quireStability may exist.
Read accesses from RunnableEntitys in those RunnableEntityGroups will not
read the coherent values but the intermediary values written by RunnableEntitys of
the same group. c(RS_SWCT_03065)

4.9.3 Consistency Needs for Senders and receivers of the same Data inside on
RunnableEntityGroup

[TPS_SWCT_01476] Sender and receiver of the same implicitly communicated

VariableDataPrototypes are associated with the same RunnableEntity-
Group d For the case of sender and receiver of the same implicitly communi-
cated VariableDataPrototypes are associated with the same RunnableEnti-
tyGroup [TPS_SWCT_01472], [TPS_SWCT_01473], [TPS_SWCT_01475] as well
as [TPS_SWCT_01475] apply with the exception that updates of the values of im-
plicitly communicated VariableDataPrototypes inside the given RunnableEn-
tityGroup become visible immediately after the producing RunnableEntity was
terminated. c(RS_SWCT_03065)

219 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

5 Data Description

5.1 Introduction
[TPS_SWCT_01229] Three different levels of abstraction regarding the definition
of data types d In the context of defining data types and prototypes, the AUTOSAR
concept distinguishes between three different levels of abstraction as depicted in Ta-
ble 5.1. c(RS_SWCT_03215, RS_SWCT_03216, RS_SWCT_03217)

Application Data Level

Implementation Data Level

Base Type Level

Table 5.1: Abstraction Levels for Describing Data

[TPS_SWCT_01230] Application Data Level d The Application Data Level is the

common level at which ApplicationSwComponentTypes specify a data type or pro-
totype. This level allows to define all the data attributes which are needed from the
application point of view, in order to exchange data between software components or
between a software component and a measurement and calibration tool. It is possible
to specify data communication of a complete Virtual Function Bus based on this
level only.
This level includes among other things the numerical range of values, the data structure
as well as the physical semantics. Data semantics (e.g. physical units) is not in the
focus1 for the RTE in order to make communication technically possible. However,
it is important for a unique interpretation of data in the application software and in
measurement and calibration systems. c(RS_SWCT_03216)
Please note that ApplicationDataTypes – by virtue of being platform-independent
by definition – do not become visible as data types in the code implementation of
software-components.
In former version of this specification, this level was not clearly separated from the
implementation level. These had the following drawbacks which are now solved:
• The model of primitive types (like integer, boolean, real, opaque) was anticipating
implementation aspects already on a very high level of design.
• The data type model used within ports, focusing on communication via the RTE,
was not sufficient to model all type-aspects of variables and parameters which are
visible within an AUTOSAR system for other purposes than RTE-communication,
namely NvM-data access, calibration, measurement, diagnostics, BSW-module
1
There are some aspects that affect the RTE, e.g. scaling of dataElements

220 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

interfaces. Using a uniform type system covering all these aspects is now fa-
vored.
• Calibration parameters were not completely incorporated into the data type con-
cept. Some of their attributes (especially for curves and maps) could be spec-
ified only on the level of prototypes or were not completely formalized within
AUTOSAR (like SwRecordLayout).
• The data type system was not compatible with the usage in calibration standards
like ASAM-MCD (namely the usage of categorys).
• Adding implementation specific elements like a base type, was not possible with-
out formally changing the data type used in a VFB design. A mapping mecha-
nism that could be used in later project phases and is common in other parts of
AUTOSAR (e.g. for mapping components to ECUs) was missing.
• The RTE Specification contained many default rules and assumptions on how to
implement certain data types or prototypes in C. With a more formal description
of all relevant implementation aspects, the generation of C-interfaces is better
determined. But these aspects should be separated from the application level
design.
• Since there could be many data types on the application level in a big system, the
probability of name clashes in the interfaces to the RTE was rather high. Using a
separate set of types to implement the RTE interfaces solves this issue.
[TPS_SWCT_01231] Application level may impose strong requirements on the
design of the corresponding implementation level d It should be pointed out, that
with the specification of computation methods and record layouts, the application level
imposes strong requirements on the design of the corresponding implementation level.
It might even be the case, that when anticipating different implementations, these ele-
ments might be chosen differently.
This is due to the nature of these elements which form a bridge from the physical
world to the numerical representation (and vice versa). Nonetheless we consider the
specification of these elements as belonging to the application level.
On the one hand, this information is required by MCD-tools and thus shall be part
of a rather high-level design. On the other hand, this approach will allow to use
a limited set of implementation data types. c(RS_SWCT_03215, RS_SWCT_03216,
RS_SWCT_03217)
Further information about the compatibility requirements between application level and
implementation level can be found in section 6.2.5.
[TPS_SWCT_01232] Implementation Data Level d The Implementation Data Level
is closer to the actual code implementation in a programming language like C, though
it is still an abstraction of the code.

221 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Its values correspond to the actual binary numbers handled by the programming lan-
guage on the CPU. It contains concepts like pointers and unions which relate to the
organization of data in memory and are not relevant for the application level.
This level also defines structure, but it can be more granular. For example, the appli-
cation level may define a text to be transferred to an instrument cluster as a primitive
type (if the structure is not relevant for the application), whereas on the implementation
level it could be modeled as an array of bytes. c(RS_SWCT_03217)
[TPS_SWCT_01233] Use case for the Implementation Data Level d There are sev-
eral use cases for this level in AUTOSAR:
• First of all, the Implementation Data level can be used in the description of in-
terfaces, and data (e.g. debug data) within the basic software, see [6] for more
details on these use cases.
• ImplementationDataTypes should also be used to describe the interfaces of
libraries which operate on a purely numerical level.
• Implementation Data is also used for the description of interfaces between
software-components and and the basic software (namely AUTOSAR Services),
because these typically cover implementation aspects only.
• It is possible to define communication in a VFB system directly on this level if the
physical and semantical abstraction is not of interest.
• Last not least the input for the RTE generator is defined by data descriptions on
this level. This means that in case a SWC defines its data only on application level
a corresponding set of implementation data types shall be created (or generated)
as part of the ECU extract before the RTE can be generated.
c(RS_SWCT_03217)
[TPS_SWCT_01234] Base Level d The Base Type Level is used to describe the
primitive elements in terms of bits and bytes from which the implementation data is
built up. It is considered as a separate level in order to allow for reuse of the basic
types defined on this level.
These base types still do not completely determine the actual implementation on a
programming language, but they impose strong restrictions for this as they define for
example the number of bits and bytes to be used.
Depending on the use case, the base types can be defined as platform independent or
can also contain platform specific attributes (namely endianess and alignment). c()
[TPS_SWCT_01235] Mapping of data defined on the Application level to the Im-
plementation and Base Type level d It is important to understand, that the mapping
of data defined on the Application level to the Implementation and Base Type level
depends on the medium on which the data is transported.
For example, if a physical value can be expressed with sufficient accuracy and range
by a 16-bit unsigned integer, it still might look very different when sent over CAN, when

222 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

seen by a software-component on a big-endian 32-bit machine or when seen by a

software-component on a little-endian 16-bit processor.
Conversion between several data implementations of the same application data type
might be necessary in case of communication between components on different ECUs.
AUTOSAR COM [21] is responsible for this.
It implies that the configuration depends on the definition of the data that
are transmitted between components2 . c(RS_SWCT_03215, RS_SWCT_03216,
RS_SWCT_03217)
AUTOSAR COM might need to convert a 16-bit integer between little-endian and big-
endian representations; whereas an array of 16 bytes does not need to be swapped
even if the endianess changes. In case of intra-ECU communication byte order con-
version is not necessary, since the software-components reside on the same machine.
[TPS_SWCT_01236] Big picture of data types d Another way of approaching the
concept of data types in AUTOSAR (especially with respect to the question of what
“kind” of data type in related to which modeling meta-level) is to sketch the following
“big picture” of data types:
ApplicationDataType Defined on M2 - provides the meta model for data types on
application level. It covers the application-relevant aspects of a data type.
An ApplicationDataType shall finally be mapped to an Implementation-
DataType.
ImplementationDataType Defined on M2 - provides the meta-model for data types
on implementation level. With respect to C source code, an Implementation-
DataType finally boils down to a typedef.
BaseType Defined on M2 - provides the platform-dependent part of an Implementa-
tionDataType. the dependency on the platform covers the following aspects:
• Definition on the level of the C language - using nativeDeclaration
• Technical representation on the target platform (byte order, alignment, en-
coding) as required for the support of MCD systems.
Platform Data Type Defined on M1 - provided by AUTOSAR. Platform types shall be
available on each platform on which an AUTOSAR-System can run.
The name of the Platform Data Type and the properties with respect to the
interface between modules / components is the same on every platform.
The particular representation varies from platform to platform.
Platform Data Types shall be modeled using Implementation-
DataTypes.
2
More exactly speaking, the data shall be converted to and from a so-called SystemSignal.

223 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Note that in AUTOSAR R3.x the platform types are implemented manually and
could even not be expressed on ARXML model (see [SRS_Rte_00150]). In
AUTOSAR R4.1 the Platform Data Types can be represented in the ARXML
model. Subsequent releases of AUTOSAR may generate the Platform Data
Types directly from the ARXML Model.
Standard Type Defined on M1 - provided by AUTOSAR. Standard types are defined
by referring to platform types.
c(RS_SWCT_03215, RS_SWCT_03216, RS_SWCT_03217)
[TPS_SWCT_01237] SwDataDefProps d The properties of data are summarized in
the meta-class SwDataDefProps. This meta-class itself is the superset of all applica-
ble properties. c(RS_SWCT_03216, RS_SWCT_03217)
Subsets of SwDataDefProps are applicable in specific case, for a summary please
refer to the following tables:
• The data categorys are summarized in table 5.6.
• Properties for ApplicationDataTypes are summarized in table 5.7.
• Properties for ImplementationDataTypes are summarized in table 5.17.
• Properties for DataPrototypes typed by ApplicationDataTypes are sum-
marized in table 5.31.
• Properties for DataPrototypes typed by ImplementationDataTypes are
summarized in table 5.32.
• Applicability of SwDataDefProps is summarized in table 5.39.

5.2 Data Types

5.2.1 Overview

As explained in section 5.1 it is possible to describe data provided by a software-

component from the application as well as from the implementation point of view.
[TPS_SWCT_01072] ApplicationDataType and ImplementationDataType d
The common concept behind this is expressed by the abstract meta-class Autosar-
DataType, from which an ApplicationDataType and an Implementation-
DataType is derived. c(RS_SWCT_03215, RS_SWCT_03216, RS_SWCT_03217)
Figure 5.1 shows a summary of the basic meta-classes used for the definition of
AutosarDataTypes.

224 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

ARElement «atpVariation»
AtpType +swDataDefProps SwDataDefProps
AutosarDataType
0..1

AtpBlueprint AtpBlueprint ARElement

AtpBlueprintable AtpBlueprintable AtpBlueprint
ApplicationDataType AbstractImplementationDataType AtpBlueprintable
AtpType
ModeDeclarationGroup

1 +type +applicationDataType 1 +implementationDataType 1 1 +implementationDataType +modeGroup 1

{redefines
atpType}
«isOfType»

DataPrototype
DataTypeMap ModeRequestTypeMap
ApplicationCompositeElementDataPrototype

+dataTypeMap 0..* +modeRequestTypeMap 0..*

      ARElement

   
  


   AtpBlueprint

    AtpBlueprintable
DataTypeMappingSet

Figure 5.1: Summary of AutosarDataType

Class AutosarDataType (abstract)

Package M2::AUTOSARTemplates::SWComponentTemplate::Datatype::Datatypes
Note Abstract base class for user defined AUTOSAR data types for ECU software.
Base ARElement, ARObject, AtpClassifier , AtpType, CollectableElement, Identifiable, Multilanguage
Referrable, PackageableElement, Referrable
Subclasses AbstractImplementationDataType, ApplicationDataType
Attribute Type Mul. Kind Note
swDataDef SwDataDefProps 0..1 aggr The properties of this AutosarDataType.
Props

Table 5.2: AutosarDataType

Class ApplicationDataType (abstract)

Package M2::AUTOSARTemplates::SWComponentTemplate::Datatype::Datatypes
Note ApplicationDataType defines a data type from the application point of view. Especially it should be used
whenever something "physical" is at stake.
An ApplicationDataType represents a set of values as seen in the application model, such as
measurement units. It does not consider implementation details such as bit-size, endianess, etc.
It should be possible to model the application level aspects of a VFB system by using ApplicationData
Types only.
Base ARElement, ARObject, AtpBlueprint, AtpBlueprintable, AtpClassifier , AtpType, AutosarDataType,
CollectableElement, Identifiable, MultilanguageReferrable, PackageableElement, Referrable
5

225 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4
Class ApplicationDataType (abstract)
Subclasses ApplicationCompositeDataType, ApplicationPrimitiveDataType
Attribute Type Mul. Kind Note
– – – – –
Table 5.3: ApplicationDataType

[TPS_SWCT_01073] Composite ApplicationDataType d An Application-

DataType can be composed (in form of a record or an array) of elements which
themselves are typed by another ApplicationDataType. c(RS_SWCT_03215,
RS_SWCT_03216)
h [TPS_SWCT_01074] Composite ImplementationDataType d An Implementa-
tionDataType can also be composed of elements but in this case no type/prototype
concept (see [11]) has been applied. Both concepts will be explained in the following
chapters in more detail. c(RS_SWCT_03215, RS_SWCT_03217)

5.2.2 Data Type Mapping

As explained above, the concept of application data types as well as that of implemen-
tation data types can be used to instantiate a data prototype in an M1 model. However
there are use cases, especially in order to generate the RTE contract for Applica-
tionSwComponentTypes, where it is required to consider both levels for one given
data prototype.
[TPS_SWCT_01189] DataTypeMap d This is supported by the meta-class
DataTypeMap by which an ApplicationDataType and an Implementation-
DataType can be mapped to each others in order to describe both aspects of one
dataElement. c(RS_SWCT_03216, RS_SWCT_03217, RS_SWCT_03215)
Class DataTypeMap
Package M2::AUTOSARTemplates::SWComponentTemplate::Datatype::Datatypes
Note This class represents the relationship between ApplicationDataType and its implementing Abstract
ImplementationDataType.
Base ARObject
Attribute Type Mul. Kind Note
applicationData ApplicationDataType 1 ref This is the corresponding ApplicationDataType
Type
implementation AbstractImplementation 1 ref This is the corresponding AbstractImplementationData
DataType DataType Type.

Table 5.4: DataTypeMap

If, for example, a dataElement in a SenderReceiverInterface is typed by an

ApplicationDataType it shall additionally be associated to an Implementation-
DataType in order to be able to generate the RTE.

226 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[TPS_SWCT_01190] ModeRequestTypeMap d Another mapping class, Mod-

eRequestTypeMap, has been introduced in order to allow the transport of mode re-
lated information via “normal” sender-receiver communication. Apart from this, mode
information is not handled by the usual type system but needs special meta-classes. c
(RS_SWCT_03110)
This aspect is explained in more detail in chapter 4.2.5.
Note that the mapping classes instead of direct associations have been introduced
for process reasons: It allows to maintain application and implementation types in
separate M1 artifacts without direct links.
For example, if a software component is moved to another hardware platform the map-
ping between application and implementation types might be changed in the scope of
the specific component without changing the overall VFB model.
[TPS_SWCT_01191] mapped ApplicationDataType and Implementation-
DataType shall be compatible d In order to set up a valid DataTypeMap between
an ApplicationDataType and an ImplementationDataType the two types shall
be compatible.
Of course, if ImplementationDataTypes are generated from existing Appli-
cationDataTypes it is expected that they will be automatically compatible. c
(RS_SWCT_03216, RS_SWCT_03217)
Please note that the compatibility between an ApplicationDataType and an Im-
plementationDataType mapped onto each other is clarified in chapter 6.2.5.
Furthermore, the various mappings are aggregated in a container DataTypeMap-
pingSet for easier maintenance in artifacts.
Class DataTypeMappingSet
Package M2::AUTOSARTemplates::SWComponentTemplate::Datatype::Datatypes
Note This class represents a list of mappings between ApplicationDataTypes and ImplementationDataTypes.
In addition, it can contain mappings between ImplementationDataTypes and ModeDeclarationGroups.
Tags: atp.recommendedPackage=DataTypeMappingSets
Base ARElement, ARObject, AtpBlueprint, AtpBlueprintable, CollectableElement, Identifiable, Multilanguage
Referrable, PackageableElement, Referrable
Attribute Type Mul. Kind Note
dataTypeMap DataTypeMap * aggr This is one particular association between an Application
DataType and its AbstractImplementationDataType.
modeRequest ModeRequestTypeMap * aggr This is one particular association between an Mode
TypeMap DeclarationGroup and its AbstractImplementationData
Type.

Table 5.5: DataTypeMappingSet

Note that the meta-classes AutosarDataType, ModeDeclarationGroup and

DataTypeMappingSet are derived from ARElement. This means that these and
the meta-classes derived from them can be declared on the M1 level as part of an
ARPackage and thus can be used in several different Software Component or Basic
Software Module Descriptions.

227 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

How to organize DataTypeMappingSets for a software system, for example whether

there is a separate mapping set for each ECU or even for each software component,
is considered as project specific. However, the RTE generator needs a well defined
DataTypeMappingSet as input in relation those artifacts which might define data
typed as ApplicationDataTypes.
[TPS_SWCT_01192] Meta-classes that have an association to a DataTypeMap-
pingSet d Therefore, the following meta-classes in the scope of this document have
an association to a DataTypeMappingSet:
• InternalBehavior, because it represents the interface between the software
component’s code and the RTE and all data types belonging to the particular
component type have to be uniquely provided on implementation level.
• ParameterSwComponentType, for the same reason (this component type
doesn’t have an InternalBehavior).
• NvBlockDescriptor, because this meta-class also leads to generation of code
from data types and is not associated to an InternalBehavior.
• CompositionSwComponentType, to support the definition of ComSpecs in the
context of a CompositionSwComponentType. Please note that this definition
of a data type mapping is informal (i.e. it shall be taken as a hint for delegation
PortPrototypes that are not yet referenced by a DelegationSwConnector
or PassThroughSwConnector) and shall not be regarded as a binding contract
towards the inner elements of the CompositionSwComponentType.
c()
For more details about this aspect please refer to figure 5.79.
[TPS_SWCT_01193] Mappings between application and implementation types do
not necessarily have to form a 1:1 relation d In general, it is not required that the sum
of all mappings between ApplicationDataType and ImplementationDataType
in a given system form a 1:1 relation. Depending on the use case and on the scope,
1:n as well as n:1 mappings are possible :
• Several different ApplicationDataTypes may be mapped to the same Im-
plementationDataType in the scope of a system, an ECU, or even a single
InternalBehavior of an atomic software component.
Of course, this requires that the different ApplicationDataTypes are used for
different DataPrototypes and thus that the DataPrototypes are typed by
them (and not by the ImplementationDataTypes). This allows to establish
a more simple type system on the implementation level, than on the application
model level.
• The same ApplicationDataTypes may be mapped to different Implemen-
tationDataTypes for different ECUs. This scenario allows to chose the imple-
mentation data types according to the needs of specific ECUs.

228 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

• The same ApplicationDataTypes may be mapped to different Implemen-

tationDataTypes even in the scope of a single ECU (more exactly speak-
ing, a single RTE), but only for different AtomicSwComponentTypes (see [con-
str_1004]).
This improves the portability of software components which were developed in-
dependently or are ported between ECUs.
c()
[constr_1004] Mapping of ApplicationDataTypes in the scope of single Atom-
icSwComponentTypes d In the scope of AtomicSwComponentType.internalBe-
havior.dataTypeMapping, each ApplicationDataType shall be mapped to ex-
actly one ImplementationDataType. c()
[constr_1005] Compatibility of ImplementationDataTypes mapped to the same
ApplicationDataType d It is required that ImplementationDataTypes which are
taken for connecting corresponding elements of PortInterfaces and thus refer to
compatible ApplicationDataTypes are also compatible among each other (so that
RTE is able to cope with possible connections by converting the data accordingly). c()
This constraint is visualized in figure 5.2.

compatible and connected

ApplicationDataType ApplicationDataType

compatible and mapped

compatible and mapped

ImplementationDataType ImplementationDataType

shall also be
compatible

Figure 5.2: Compatibility of Data Types

229 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[constr_1636]{DRAFT} Mapping of data types that represent an Optional Ele-

ment Structure d An ApplicationRecordDataType with at least one element
where attribute isOptional is set to True shall only be mapped to an Implemen-
tationDataType that fulfills the structural requirements to represent an Optional
Element Structure (see [TPS_SWCT_01774]). c()

5.2.3 Data Categories

An AutosarDataType is derived from Identifiable, thus having a longName, a

shortName, a category, and several further attributes for administrative and docu-
mentation purposes (for details see [11]).
[TPS_SWCT_01238] Attribute category used in the context of Autosar-
DataType d The category attribute is used to set constraints for the various proper-
ties which can be specified for an AutosarDataType. These properties are defined
by aggregating the meta-class SwDataDefProps which contains several attributes
and references. c()
Detailed explanations about the semantics of meta-class SwDataDefProps can be
found in chapter 5.4.
[constr_1143] category of AutosarDataType shall not be extended d In contrast
to the general rule that category can be extended by user-specific values it is not
allowed to extend the meaning of the attribute category of meta-class Autosar-
DataType c()
This approach avoids a very deep and complicated inheritance tree which otherwise
would be needed on the M2 level for AutosarDataType. There is to some extend a
redundancy between setting the category and defining the attributes of Autosar-
DataType.swDataDefProps. This redundancy is intended and allows to for a tool to
rule out senseless configurations via simple rules.
In former version of this specification the categories were only used for calibration
parameters. Due to several extensions the categories are now applicable for all use
cases of the AutosarDataType.
An overview on all valid categorys defined for AutosarDataType is shown in ta-
ble 5.6. Some of the categorys are also applied to sub-elements of the type system
(column “Applicable to ...” in table 5.6). This is explained in more detail in the following
sections.
Please note that the column “RTE + BSW” of table 5.6 is only applicable for cate-
gorys that are relevant either for ImplementationDataTypes and/or the aspect of
measurement and calibration in McDataInstance.
[constr_1006] applicable data categories d Table 5.6 defines the applicable cate-
gorys depending on specific model elements related to data definition properties. c
()

230 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Category Applicable to ... Use Case Description

ApplicationValueSpecification

ImplementationDataTypeElement
ApplicationPrimitiveDataType
ApplicationRecordDataType
ApplicationArrayDataType

ApplicationRecordElement
ApplicationArrayElement

Communication Port Interfaces

ImplementationDataType

McDataInstance
SwSystemconst
SwServiceArg

Measurement

RTE + BSW
Calibration

VALUE x x x x x x x x x x x x Contains a single value.

A value block defines values stored together within one cali-
bration parameter object.
VAL_BLK x x x x x x x It is similar to an value array but it stores the values by means
of an axis instead (only important for calibration data han-
dling).
Contains an address of another DataPrototype (whose
DATA_REF-
x x x x3 x type is given via SwDataDefProps.swPointerTarget-
ERENCE
Props).
Contains an address of a function prototype (whose sig-
FUNCTION_
x x x x nature is given via SwDataDefProps.swPointerTarget-
REFERENCE
Props.functionPointerSignature).
TYPE_REF- The element is defined via reference to another data type (via
x x x x x
ERENCE SwDataDefProps.implementationDataType).
Holds one or several further elements which can have differ-
ent AutosarDataTypes.
The underlying elements are defined in the same manner as
STRUCTURE x x x x x x x x x x
normal data except for the association to SwAddrMethod:
This has to be the same for all underlying elements.
Corresponds to a Record if used in the application domain.
Can hold values of different data types. It is similar to STRUC-
TURE except that all of its members start at the same location
in memory.
UNION x x x x x x x A UNION data prototype can contain only one of its elements
at a time. The size of the UNION is at least the size of the
largest member.
Please find more information in [TPS_SWCT_01700].
ARRAY x x x x x x x x x x An array of sub-elements which are of the same type.
One or several bits within a host variable, which are treated
BIT x x x x
as an own data object.
A HOST data type is like a simple VALUE, but it is used for
packed bit definition.
HOST x x x x
That means it can host several BIT variables which have their
own description and measurement access.
Contains a single value interpreted as a text string (note that
STRING x x x x x x x x it appears as a single value for the application domain; the
internal representation can be an array).
5

3
[constr_1295] applies!

231 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4
Category Applicable to ... Use Case Description

ApplicationValueSpecification

ImplementationDataTypeElement
ApplicationPrimitiveDataType
ApplicationRecordDataType
ApplicationArrayDataType

ApplicationRecordElement
ApplicationArrayElement

Communication Port Interfaces

ImplementationDataType

McDataInstance
SwSystemconst
SwServiceArg

Measurement

RTE + BSW
Calibration

Contains one boolean state. Depending on the CPU direct

addressing of single bits may not be available.
BOOLEAN x x x x x x x x
So a byte or a word can be used to store only one logical
state.
An axis definition as separate calibration parameter which can
be referenced by any CURVE, MAP, CUBOID, CUBE_4, and
CUBE_5.
COM_AXIS x x x x x x x
The benefits by using a common axis is that it saves memory
space; because it is stored only one time and can be used in
multiple CURVEs, MAPs, CUBOIDs, CUBE_4s, and CUBE_5s.
A RES_AXIS (rescale axis) is also a shared axis like
COM_AXIS, the difference is that this kind of axis can be used
for rescaling.
Note that the RES_AXIS is by nature a CURVE which is used
RES_AXIS x x x x x x x
to implement a non linear scaling (rescale) of the axis.
In addition to saving memory space via the shared usage like
a COM_AXIS, it can compress a huge range to a non-linear
distributed axis points thus retaining the required accuracy.
Calibration parameter with one input value and one output
value. That means output values can be defined depending
on the input value. The granularity of implemented functional-
ity can be changed by using different number of axis points.
CURVE x x x x x x x
A CURVE has always one input axis and one output axis. The
output axis is a characteristic of the curve and every time
present but the input axis can be defined within the curve def-
inition or separately.
Calibration parameter with two input values and one output
value. That means output values can be defined depending
on the input values.
The granularity of implemented functionality can be changed
MAP x x x x x x x by using different number of axis points for y- and x-axis. A
MAP has always two input axes and one output axis.
The output axis is a characteristic of the MAP and every time
present but the input axes can be defined within the MAP defi-
nition or separately.
5

232 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4
Category Applicable to ... Use Case Description

ApplicationValueSpecification

ImplementationDataTypeElement
ApplicationPrimitiveDataType
ApplicationRecordDataType
ApplicationArrayDataType

ApplicationRecordElement
ApplicationArrayElement

Communication Port Interfaces

ImplementationDataType

McDataInstance
SwSystemconst
SwServiceArg

Measurement

RTE + BSW
Calibration

Calibration parameter with three input values and one output

value. That means output values can be defined depending
on the input values.
The granularity of implemented functionality can be changed
CUBOID x x x x x x x by using different number of axis points for the input axes. A
CUBOID has always three input axes and one output axis.
The output axis is a characteristic of the CUBOID and every
time present but the input axes can be defined within the
CUBOID definition or separately.
Calibration parameter with four input values and one output
value. That means output values can be defined depending
on the input values.
The granularity of implemented functionality can be changed
CUBE_4 x x x x x x x by using different number of axis points for the input axes. A
CUBE_4 has always four input axes and one output axis.
The output axis is a characteristic of the CUBE_4 and every
time present but the input axes can be defined within the
CUBE_4 definition or separately.
Calibration parameter with five input values and one output
value. That means output values can be defined depending
on the input values.
The granularity of implemented functionality can be changed
CUBE_5 x x x x x x x by using different number of axis points for the input axes. A
CUBE_5 has always five input axes and one output axis.
The output axis is a characteristic of the CUBE_5 and every
time present but the input axes can be defined within the
CUBE_5 definition or separately.
MACRO x x This represents an argument to a C macro.

Table 5.6: Usage of category for Data Types

[TPS_SWCT_01239] default value for attribute category used in the context of

SwSystemconst d The default value for the category of a SwSystemconst shall be
VALUE. This has to be applied if no explicit definition of the category can be found. c
()

233 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

5.2.4 Application Data Type

[TPS_SWCT_01240] Subclasses of ApplicationDataType d The abstract meta-

class ApplicationDataType is further derived into an ApplicationPrimitive-
DataType and an ApplicationCompositeDataType which are further explained
in the following sub-chapters. c(RS_SWCT_03216)
This aspect is further explained in Figure 5.3.
ARElement «atpVariation»
AtpType SwDataDefProps
+swDataDefProps
AutosarDataType
0..1

AtpBlueprint
AtpBlueprintable
ApplicationDataType

ApplicationCompositeDataType

ApplicationPrimitiveDataType ApplicationRecordDataType ApplicationArrayDataType

+ dynamicArraySizeProfile: String [0..1]

Figure 5.3: Basic Meta-Model for ApplicationDataType

234 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Attributes of SwDataDefProps Root Elem. Attribute Existence per Category

ApplicationRecordElement

ApplicationArrayElement
ApplicationDataType

STRUCTURE

COM_AXIS

RES_AXIS
VAL_BLK

BOOLEAN
STRING

CUBOID

CUBE_4

CUBE_5
VALUE

ARRAY

CURVE

MAP
additionalNativeTypeQualifier
annotation x x x * * * * * * * * * * * * *
baseType
compuMethod x 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1
dataConstr.dataConstr-
x x x 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1
Rule.physConstrs
dataConstr.dataConstrRule.in-
ternalConstrs
x x x d/c4 d/c d/c d/c d/c d/c d/c d/c d/c

displayFormat x x x 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1
displayPresentation x x x 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1
implementationDataType
invalidValue x 0..1 0..1 0..1
stepSize x x x 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1
swAddrMethod x 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1
swAlignment
swBitRepresentation
swCalibrationAccess x x 0..1 0..1 0..1 0..1 0..1 0..1 1 1 1 1 1 1 1
swCalprmAxisSet x 1 1 1 1 1 1 1
swComparisonVariable
swDataDependency
swHostVariable
swImplPolicy x 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1
swIntendedResolution x x x 0..1
swInterpolationMethod x 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1
swIsVirtual
swPointerTargetProps
swRecordLayout x 0..1 0..15 0..1 1 1 1 1 1 1 1
swRefreshTiming x 0..1 0..1 0..1 0..1
swTextProps x 1
swValueBlockSize x 1
swValueBlockSizeMult x 1
unit x 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1
valueAxisDataType x 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1
Other Attributes below the Root Element
5

4
don’t care
5
This is required by [TPS_SWCT_01179].

235 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4
element:
x x x 1..*
ApplicationRecordElement
element:
x x x 1
ApplicationArrayElement
ApplicationArrayElement.array-
x 0..1
SizeSemantics
ApplicationArrayEle-
x 1
ment.maxNumberOfElements

Table 5.7: Allowed Attributes vs. category for ApplicationDataTypes

Class ApplicationPrimitiveDataType
Package M2::AUTOSARTemplates::SWComponentTemplate::Datatype::Datatypes
Note A primitive data type defines a set of allowed values.
Tags: atp.recommendedPackage=ApplicationDataTypes
Base ARElement, ARObject, ApplicationDataType, AtpBlueprint, AtpBlueprintable, AtpClassifier , AtpType,
AutosarDataType, CollectableElement, Identifiable, MultilanguageReferrable, PackageableElement,
Referrable
Attribute Type Mul. Kind Note
– – – – –
Table 5.8: ApplicationPrimitiveDataType

Class ApplicationCompositeDataType (abstract)

Package M2::AUTOSARTemplates::SWComponentTemplate::Datatype::Datatypes
Note Abstract base class for all application data types composed of other data types.
Base ARElement, ARObject, ApplicationDataType, AtpBlueprint, AtpBlueprintable, AtpClassifier , AtpType,
AutosarDataType, CollectableElement, Identifiable, MultilanguageReferrable, PackageableElement,
Referrable
Subclasses ApplicationArrayDataType, ApplicationRecordDataType
Attribute Type Mul. Kind Note
– – – – –
Table 5.9: ApplicationCompositeDataType

[TPS_SWCT_01241] Applicable categorys for subclasses of Application-

DataType d Like any AutosarDataType, also the primitive and composite types
on application level are characterized by their category and their SwDataDefProps.
For a given category, only a limited set of attributes of the SwDataDefProps makes
sense. c(RS_SWCT_03216)
[constr_1007] Allowed attributes of SwDataDefProps for Application-
DataTypes d The allowed attributes of SwDataDefProps for Application-
DataTypes and their allowed multiplicities are listed as an overview in table 5.7. c
()
This list makes use of the SwDataDefProps and other meta-model elements which
are explained in detail in the further sections of this chapter.
[constr_1008] Applicability of categorys STRUCTURE and ARRAY d The cate-
gories STRUCTURE and ARRAY correspond to ApplicationCompositeDataTypes

236 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

whereas all other categorys can be applied only for ApplicationPrimitive-

DataTypes. c()

5.2.4.1 Application Primitive Data Types

5.2.4.1.1 Data Types for Single Values

In contrast to prior versions (R3.x) of the AUTOSAR standard, the primitive application
data types on M2 level are no longer specified. Instead of this, the meta-class Appli-
cationPrimitiveDataType in combination with the attached swDataDefProps is
used on the level of the M2 (meta-) model to specify the details on M1 modeling level.
[TPS_SWCT_01242] category characterizes the nature of a data type on appli-
cation level d The category is used in addition to characterize the nature of a data
type on application level. c(RS_SWCT_03216)
For example, the IntegerType as of AUTOSAR R3.x allows for specifying lower and
upper ranges that constrain the applicable value interval. That aspect is still supported
by this version of AUTOSAR, but the meta-model is different from the former approach.
Especially it is no more considered of importance to specify that an Application-
PrimitiveDataType is actually represented by “integer” numbers.
Figure 5.4 provides a sketch of how limits are defined now. The key feature is the ag-
gregation of SwDataDefProps at AutosarDataType. The meta-class SwDataDef-
Props allows for creating a reference to a DataConstr that in turn aggregates a
DataConstrRule.
The latter aggregates PhysConstrs and this meta-class finally owns two Limits in
the roles lowerLimit and upperLimit.

237 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

ARElement
AtpType
AutosarDataType

+swDataDefProps 0..1

«atpVariation» AtpBlueprint
SwDataDefProps AtpBlueprintable
ApplicationDataType

+dataConstr 0..1

ARElement
ApplicationPrimitiveDataType
AtpBlueprint
AtpBlueprintable
DataConstr

+dataConstrRule 0..*

DataConstrRule

+ constrLevel: Integer [0..1]

+physConstrs 0..1

PhysConstrs

+ maxDiff: Numerical [0..1]

+ maxGradient: Numerical [0..1]
+ monotony: MonotonyEnum [0..1]
«atpVariation»
+ lowerLimit: Limit [0..1]
+ upperLimit: Limit [0..1]

Figure 5.4: Specification of Physical Limits

Another example is shown in Figure 5.5. By making again use of SwDataDefProps,

this figure shows how semantics in form of a CompuMethod and a Unit can be at-
tached.
Also an initValue can be defined which is used by the RTE in order to initialize
values of VariableDataPrototypes/ParameterDataPrototypes defined locally
in a software-component.

238 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

ARElement AtpBlueprint
AtpType AtpBlueprintable
AutosarDataType ApplicationDataType

ApplicationPrimitiveDataType

+swDataDefProps 0..1

«atpVariation» ARElement
+compuMethod
SwDataDefProps AtpBlueprint
0..1 AtpBlueprintable
CompuMethod

+unit 0..1

ARElement
+unit
Unit
0..1

+invalidValue 0..1

ValueSpecification

Figure 5.5: Some Properties of ApplicationPrimitiveDataTypes

Figure 5.6 illustrates the relationship between the data constraints for Application-
DataType, CompuMethod, ImplementationDataType, BaseType and also the
invalidValue for the case of an entirely linear or rational conversion.

239 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Invalid Value
InvalidValue outside the scope of InvalidValue inside the scope of the
the CompuMethod is transparent CompuMethod is known to the
to the software-component software-component

Application
DataType Lower [unit] Upper [unit]
physConstrs of
ApplicationDataType

limits of CompuMethod
CompuMethod

computed internalConstrs of
ApplicationDataType

Implementation
DataType
internalConstrs of
ImplementationDataType

range by BaseType
BaseType
0 2n

Figure 5.6: Value ranges and invalid values for linear and rational CompuMethod

Please note that Figure 5.6 is only applicable for linear and rational CompuMethods.
Figure 5.7 and Figure 5.8 depict a similar situation for the case of mixed Com-
puMethods where the invalidValue is defined in the discrete part of a Com-
puMethod.

240 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Invalid Value
InvalidValue appears in the textual
part of the CompuMethod and is
therefore known to the component

Application
DataType Lower [unit] Upper [unit]
physConstrs of
ApplicationDataType

limits of CompuMethod
CompuMethod
Textual Value defined as
computed internalConstrs of
part of the CompuMethod
ApplicationDataType

Implementation
DataType
internalConstrs of
ImplementationDataType

range by BaseType
BaseType
0 2n

Figure 5.7: Value ranges and invalid values with discrete invalidValue defined inside
the scope of the CompuMethod

Figure 5.7 sketches a case where a CompuMethod has a linear and a discrete part and
the invalidValue is defined by means of one value that is defined in the discrete part
of the CompuMethod.
As mentioned by [constr_1281], the invalidValue shall be defined in the physical
domain in this case. In other words, the invalidValue shall be defined by a symbol
according to [TPS_SWCT_01432].
As a consequence of the definition of an invalidValue inside the scope of a mixed
CompuMethod the invalidValue is visible to the software-component.

241 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Invalid Value
InvalidValue does not appear in
the textual part of the
CompuMethod and is therefore
not known to the component

Application
DataType Lower [unit] Upper [unit]
physConstrs of
ApplicationDataType

limits of CompuMethod
CompuMethod
Textual Value defined as
computed internalConstrs of
part of the CompuMethod
ApplicationDataType

Implementation
DataType
internalConstrs of
ImplementationDataType

range by BaseType
BaseType
0 2n

Figure 5.8: Value ranges and invalid values with discrete invalidValue defined outside
the scope of the CompuMethod

Figure 5.8, on the other hand, sketches a case where a CompuMethod has a linear
and a discrete part and the invalidValue is not within the defined linear interval and
not defined by means of one value out of the discrete part of the CompuMethod.
As mentioned by [constr_1283], the invalidValue shall be defined in the internal
domain in this case. In other words, the invalidValue shall be defined by a Numer-
icalValueSpecification.
As a consequence of the definition of an invalidValue outside the scope of a mixed
CompuMethod the invalidValue is visible to the software-component.
If an ApplicationPrimitiveDataType does not define dataConstr then implicit
constraints can be derived from physical meaning of the ApplicationDataType.
For example, if the data type represents a temperature the lower bound will not be able
to exceed 0K.
For other physical meanings, it could be possible that the implicitly assumed limits go
from -INF to +INF.
In order to avoid ambiguity regarding the values of limits it is strongly recommended
to define a reasonable limit for ApplicationPrimitiveDataTypes.
[constr_2544] Limits need to be consistent d

242 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

• The limits of ApplicationDataType shall be inside of the definition range of

the CompuMethod
The CompuMethod needs to be applicable for limits of an Application-
DataType. The reason is that the internal representation of the limits for the
ApplicationDataType are calculated by applying the CompuMethod.
• The such defined internal limits of the ApplicationDataType shall be within
or equal the internalConstrs of the mapped ImplementationDataType.
• The limits of the ImplementationDataType shall be within or equal to the
limits defined by the size of the BaseType.
c()
[constr_1281] invalidValue is inside the scope of the compuMethod d If the
value of the invalidValue of an ApplicationPrimitiveDataType of cate-
gory VALUE is supposed to be inside the scope of the applicable CompuMethod an
ApplicationValueSpecification is used to describe the invalidValue of the
ApplicationPrimitiveDataType. c()
[constr_1281] means that the value of the ApplicationValueSpecification shall
be within the bounds defined by swDataDefProps.compuMethod.compuPhysToIn-
ternal.compuContent.compuScale.lowerLimit or upperLimit or the inverse
case that is based on the bounds defined by swDataDefProps.compuMethod.com-
puInternalToPhys.compuContent.compuScale.lowerLimit or upperLimit.
[constr_1283] invalidValue is outside the scope of the compuMethod d If the
value of the invalidValue of an ApplicationPrimitiveDataType of cate-
gory VALUE is supposed to be outside the scope of the applicable CompuMethod
a NumericalValueSpecification shall be used to describe the invalidValue
of the ApplicationPrimitiveDataType. c()
The handling of invalidValue for ApplicationPrimitiveDataType of cate-
gory STRING is defined by [constr_1242].
For a more detailed description of the properties that can be defined for data types
(and data prototypes as well) see sections 5.4 and 5.4.2.
[TPS_SWCT_01760] Defining the dimension of an ApplicationPrimitive-
DataType of category VAL_BLK d An ApplicationPrimitiveDataType of
category VAL_BLK that has only one dimension shall be described using the attribute
SwDataDefProps.swValueBlockSize.
An ApplicationPrimitiveDataType of category VAL_BLK that has more than
one dimension shall be described using the attribute SwDataDefProps.swValue-
BlockSizeMult. c()
[constr_1610] Existence of SwDataDefProps.swValueBlockSize and Sw-
DataDefProps.swValueBlockSizeMult d Attributes SwDataDefProps.swVal-
ueBlockSize and SwDataDefProps.swValueBlockSizeMult shall not exist at
the same time in the context of a given SwDataDefProps. c()

243 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

5.2.4.1.2 About Enumerations

[TPS_SWCT_01243] Definition of enumeration types d In the AUTOSAR meta-

model, an enumeration is not implemented by means of an ApplicationCompos-
iteDataType.
Instead, a range of integer numbers can be used as a structural description for a single
ApplicationPrimitiveDataType or an ImplementationDataType of cate-
gory VALUE or TYPE_REFERENCE that boils down to an ImplementationDataType
of category VALUE.
The mapping of the integer numbers to labels in the scope of the definition of an enu-
meration is considered part of the semantical definition via an attached CompuMethod
rather than part of the structural description. c(RS_SWCT_03216)
[TPS_SWCT_01562] Specification of values of an enumeration d For the specifi-
cation of values of an enumeration on the basis of the labels defined in the applicable
CompuMethod it is necessary to distinguish two approaches based on the used Au-
tosarDataType:
• ImplementationDataType: as mentioned by [constr_1225], the definition of
the labels of an enumeration shall only be done by using TextValueSpecifi-
cation.
• ApplicationPrimitiveDataType: use the ApplicationValueSpecifi-
cation.swValueCont.swValuesPhys.vt or ApplicationRuleBasedVal-
ueSpecification.swValueCont.ruleBasedValues.arguments.vt.
c()
The relevant meta-classes in the context of SwDataDefProps are sketched in Fig-
ure 5.9. This includes all meta-classes that may contribute to the definition of the
symbol of a CompuScale in C code, see [TPS_SWCT_01431].

244 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

«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}

+compuMethod 0..1

ARElement
CompuContent
AtpBlueprint
AtpBlueprintable
CompuMethod

+ displayFormat: DisplayFormatString [0..1]

+compuContent 1

+compuPhysToInternal 0..1 +compuInternalToPhys 0..1

Compu CompuScales

«atpVariation»

  
    0..*
   +compuScale {ordered}
 
+compuDefaultValue 0..1  !"! #$!! CompuScale
 %&'($&
+ mask: PositiveInteger [0..1]
CompuConst + shortLabel: Identifier [0..1]
+compuInverseValue + symbol: CIdentifier [0..1]

0..1 «atpVariation»
+ lowerLimit: Limit [0..1]
1 + upperLimit: Limit [0..1]
+compuConst

+compuConstContentType 1 +compuScaleContents 0..1

CompuConstContent CompuScaleConstantContents CompuScaleContents

CompuConstTextContent

+ vt: VerbatimString

Figure 5.9: Relevant meta-classes for the specification of enumerations

An example of how an enumeration looks like in ARXML is contained in section 5.5.1.4.

245 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

5.2.4.1.3 Data Types for Calibration Parameters

[TPS_SWCT_01244] Data types for calibration parameters are also described as

primitive types d Data types for calibration parameters are from the application per-
spective also described as primitive types. This is obvious, if they are simple values (
category VALUE). Also the category STRING is treated as a primitive type on ap-
plication level.
Less obvious is the fact that ApplicationDataTypes of the categories VAL_BLK,
COM_AXIS, RES_AXIS, CURVE, MAP, CUBOID, CUBE_4, and CUBE_5 are not described
as composite data types (as far as the application level is concerned) although they
admittedly possess some kind of internal structure.
In contrast to ApplicationCompositeDataTypes, they are not composed in a self-
similar way of other AutosarDataTypes. Their substructure needs a special descrip-
tion in oder to be compatible with existing calibration techniques. c()
[TPS_SWCT_01245] SwDataDefProps control the structure of calibration param-
eters d The substructure of these types is attached to the SwDataDefProps. By this
means it is possible to define on the level of DataPrototypes or other artifacts, where
the SwDataDefProps come into play. c()
For details on these part of the SwDataDefProps see chapters 5.4.4 and 5.5.5.

5.2.4.1.4 Data Types for Textual Strings

[constr_1093] Definition of textual strings d An ApplicationPrimitive-

DataType of category STRING shall have a swTextProps which determines the
arraySizeSemantics and swMaxTextSize. c()
[TPS_SWCT_01488] ApplicationPrimitiveDataType shall be interpreted as
a string of a particular encoding d To indicate that an ApplicationPrimitive-
DataType shall be interpreted as a string of a particular encoding it shall reference
swDataDefProps.swTextProps.baseType and the only attribute of the referenced
SwBaseType relevant for this purpose is the BaseTypeDirectDefinition.base-
TypeEncoding. c()

246 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

ARElement «atpVariation»
AtpType +swDataDefProps
SwDataDefProps
AutosarDataType
0..1 + additionalNativeTypeQualifier:
NativeDeclarationString [0..1]
+ displayFormat: DisplayFormatString [0..1]
+ displayPresentation: DisplayPresentationEnum
[0..1]
+ stepSize: Float [0..1]
AtpBlueprint + swAlignment: AlignmentType [0..1]
AtpBlueprintable + swCalibrationAccess:
ApplicationDataType SwCalibrationAccessEnum [0..1]
+ swImplPolicy: SwImplPolicyEnum [0..1]
+ swIntendedResolution: Numerical [0..1]
+ swInterpolationMethod: Identifier [0..1]
+ swIsVirtual: Boolean [0..1]
«atpVariation»
+ swValueBlockSize: Numerical [0..1]
ApplicationPrimitiveDataType
+ swValueBlockSizeMult: Numerical [0..*]
{ordered}

ARElement
SwRecordLayout +swRecordLayout

0..1

ValueSpecification
+invalidValue
+ shortLabel: Identifier [0..1]
0..1

+swTextProps 0..1

ApplicationValueSpecification SwTextProps

+ category: Identifier + arraySizeSemantics: ArraySizeSemanticsEnum

+ swFillCharacter: Integer [0..1]
«atpVariation»
+ swMaxTextSize: Integer

+baseType 0..1

AtpBlueprint
AtpBlueprintable
BaseType
SwBaseType

Figure 5.10: Specification of textual strings

Class SwTextProps
Package M2::MSR::DataDictionary::DataDefProperties
Note This meta-class expresses particular properties applicable to strings in variables or calibration
parameters.
Base ARObject
Attribute Type Mul. Kind Note
5

247 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4
Class SwTextProps
arraySize ArraySizeSemantics 1 attr This attribute controls the semantics of the arraysize for
Semantics Enum the array representing the string in an Implementation
DataType.
It is there to support a safe conversion between
ApplicationDatatype and ImplementationDatatype, even
for variable length strings as required e.g. for Support of
SAE J1939.
baseType SwBaseType 0..1 ref This is the base type of one character in the string. In
particular this baseType denotes the intended encoding of
the characters in the string on level of ApplicationData
Type.
Tags: xml.sequenceOffset=30
swFillCharacter Integer 0..1 attr Filler character for text parameter to pad up to the
maximum length swMaxTextSize.
The value will be interpreted according to the encoding
specified in the associated base type of the data object,
e.g. 0x30 (hex) represents the ASCII character zero as
filler character and 0 (dec) represents an end of string as
filler character.
The usage of the fill character depends on the arraySize
Semantics.
Tags: xml.sequenceOffset=40
swMaxTextSize Integer 1 attr Specifies the maximum text size in characters. Note the
size in bytes depends on the encoding in the
corresponding baseType.
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime
xml.sequenceOffset=20

Table 5.10: SwTextProps

[TPS_SWCT_01127] Byte array with variable size d SwTextProps can be used to

define byte arrays of variable size. c(RS_SWCT_03182, RS_SWCT_03181)
[TPS_SWCT_01246] SwRecordLayout may also be required for A2L generation
d A SwRecordLayout may also be required for the generation of A2L if the string is
part of calibration data. c()
As stated by [TPS_SWCT_01128], the definition of SwDataDefProps.swRecord-
Layout is considered mandatory anyway for ApplicationPrimitiveDataTypes
of category STRING.
The following series of XML fragments exemplifies the definition of a data type for the
representation of a textual string. First, the applicable ApplicationPrimitive-
DataType is defined (see Figure 5.10):
Listing 5.1: Example for the definition of a string ApplicationPrimitiveDataType
<AR-PACKAGE>
<SHORT-NAME>ApplicationDataTypes</SHORT-NAME>
<ELEMENTS>
<APPLICATION-PRIMITIVE-DATA-TYPE>
<SHORT-NAME>MyApplicationStringType</SHORT-NAME>
<CATEGORY>STRING</CATEGORY>
<SW-DATA-DEF-PROPS>

248 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

<SW-DATA-DEF-PROPS-VARIANTS>
<SW-DATA-DEF-PROPS-CONDITIONAL>
<SW-TEXT-PROPS>
<ARRAY-SIZE-SEMANTICS>VARIABLE-SIZE</ARRAY-SIZE-SEMANTICS>
<SW-MAX-TEXT-SIZE>50</SW-MAX-TEXT-SIZE>
<BASE-TYPE-REF BASE="default" DEST="SW-BASE-TYPE">BaseTypes/
MyTextBaseType</BASE-TYPE-REF>
</SW-TEXT-PROPS>
<INVALID-VALUE>
<APPLICATION-VALUE-SPECIFICATION>
<CATEGORY>STRING</CATEGORY>
<SW-VALUE-CONT>
<SW-VALUES-PHYS>
<VT>inv</VT>
</SW-VALUES-PHYS>
</SW-VALUE-CONT>
</APPLICATION-VALUE-SPECIFICATION>
</INVALID-VALUE>
<SW-RECORD-LAYOUT-REF BASE="default" DEST="SW-RECORD-LAYOUT">
RecordLayouts/StringDescriptor</SW-RECORD-LAYOUT-REF>
</SW-DATA-DEF-PROPS-CONDITIONAL>
</SW-DATA-DEF-PROPS-VARIANTS>
</SW-DATA-DEF-PROPS>
</APPLICATION-PRIMITIVE-DATA-TYPE>
</ELEMENTS>
</AR-PACKAGE>

Note that the category is set to the value STRING. Also the ApplicationPrimi-
tiveDataType.swDataDefProps.swTextProps indicate the width of the string and
also define (by means of the reference to baseType) the encoding this string data type
is supposed to utilize.
Note further that the fact that an ApplicationDataType directly references (across
the implementation level) to a SwBaseType represents an exception to the rule that
ApplicationDataType should not be concerned about the lowest level of data
type definition in AUTOSAR.
If the bridging of the implementation level were accepted as a general pattern for the
modeling of ApplicationDataType it would easily be possible to bypass the imple-
mentation level to some extent and this would render ApplicationDataTypes less
versatile.
[TPS_SWCT_01128] SwRecordLayout needed for ApplicationPrimitive-
DataType of category STRING d As mentioned in [TPS_SWCT_01179], an Ap-
plicationPrimitiveDataType of category STRING is considered a Compound
Primitive Data Type.
Therefore, it needs a reference to the definition of a SwRecordLayout that presets
the approach for creating a matching ImplementationDataType. c()
In this specific example the definition of the SwRecordLayout foresees the Applica-
tionPrimitiveDataType of category STRING to be implemented as a structured
data type that consists of:

249 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

1. the size of an instance of the string data type in terms of the number of characters
plus
2. an array that can be used to store the individual characters contained in an in-
stance of the string data type.
Depending on the used encoding the array may need to be bigger (in terms of the
number of elements) than the corresponding value of the size. Furthermore, the defi-
nition of the SwRecordLayout already takes into account that the implementation of
an array data type by means of an ImplementationDataType requires the definition
of an ImplementationDataTypeElement.
The meaning of the standardized values of SwRecordLayoutV.swRecordLay-
outVProp are documented in [TPS_SWCT_01489]. In the scope of this example
the values COUNT and VALUE are used.
The fact that the swRecordLayoutGroupTo contains the value -1 means that the
iteration ends at the last element of the array.
Listing 5.2: Example for the definition of a SwRecordLayout for an ApplicationPrim-
itiveDataType of category STRING
<AR-PACKAGE>
<SHORT-NAME>RecordLayouts</SHORT-NAME>
<ELEMENTS>
<SW-RECORD-LAYOUT>
<SHORT-NAME>StringDescriptor</SHORT-NAME>
<LONG-NAME>
<L-4 L="EN">String by descriptor</L-4>
</LONG-NAME>
<INTRODUCTION>
<VERBATIM>
<L-5 L="EN" xml:space="default">
struct{
size,
char[]
}
</L-5>
</VERBATIM>
</INTRODUCTION>
<SW-RECORD-LAYOUT-GROUP>
<SW-RECORD-LAYOUT-V>
<SHORT-LABEL>size</SHORT-LABEL>
<SW-RECORD-LAYOUT-V-AXIS>STRING</SW-RECORD-LAYOUT-V-AXIS>
<SW-RECORD-LAYOUT-V-PROP>COUNT</SW-RECORD-LAYOUT-V-PROP>
</SW-RECORD-LAYOUT-V>
<SW-RECORD-LAYOUT-GROUP>
<SHORT-LABEL>chars</SHORT-LABEL>
<SW-RECORD-LAYOUT-GROUP-AXIS>STRING</SW-RECORD-LAYOUT-GROUP-AXIS>
<SW-RECORD-LAYOUT-GROUP-FROM>0</SW-RECORD-LAYOUT-GROUP-FROM>
<SW-RECORD-LAYOUT-GROUP-TO>-1</SW-RECORD-LAYOUT-GROUP-TO>
<SW-RECORD-LAYOUT-V>
<SHORT-LABEL>char</SHORT-LABEL>
<SW-RECORD-LAYOUT-V-PROP>VALUE</SW-RECORD-LAYOUT-V-PROP>
</SW-RECORD-LAYOUT-V>

250 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

</SW-RECORD-LAYOUT-GROUP>
</SW-RECORD-LAYOUT-GROUP>
</SW-RECORD-LAYOUT>
</ELEMENTS>
</AR-PACKAGE>

Please note further that the discussed example of an ApplicationPrimitive-

DataType of category STRING also contains the definition of an invalidValue
for the string data type.
The next step is the definition of an ImplementationDataType that represents the
string type on the implementation level. The definition of the Implementation-
DataType can be derived from the definition of the applicable SwRecordLayout.
Please note that the ImplementationDataType also defines an invalidValue.
As mentioned in [TPS_SWCT_01487], the consistency of the invalidValue defined
in the scope of the ApplicationPrimitiveDataType of category STRING and
the invalidValue defined in the scope of the corresponding Implementation-
DataType cannot formally be checked.
Listing 5.3: Example for the definition of a string ImplementationDataType
<AR-PACKAGE>
<SHORT-NAME>ImplementationDataTypes</SHORT-NAME>
<ELEMENTS>
<IMPLEMENTATION-DATA-TYPE>
<SHORT-NAME>uint8</SHORT-NAME>
<CATEGORY>VALUE</CATEGORY>
<SW-DATA-DEF-PROPS>
<SW-DATA-DEF-PROPS-VARIANTS>
<SW-DATA-DEF-PROPS-CONDITIONAL>
<BASE-TYPE-REF DEST="SW-BASE-TYPE">BaseTypes/uint8BaseType</
BASE-TYPE-REF>
</SW-DATA-DEF-PROPS-CONDITIONAL>
</SW-DATA-DEF-PROPS-VARIANTS>
</SW-DATA-DEF-PROPS>
</IMPLEMENTATION-DATA-TYPE>
<IMPLEMENTATION-DATA-TYPE>
<SHORT-NAME>MyImplementationStringType</SHORT-NAME>
<CATEGORY>STRUCTURE</CATEGORY>
<SUB-ELEMENTS>
<IMPLEMENTATION-DATA-TYPE-ELEMENT>
<SHORT-NAME>size</SHORT-NAME>
<CATEGORY>TYPE_REFERENCE</CATEGORY>
<SW-DATA-DEF-PROPS>
<SW-DATA-DEF-PROPS-VARIANTS>
<SW-DATA-DEF-PROPS-CONDITIONAL>
<IMPLEMENTATION-DATA-TYPE-REF DEST="IMPLEMENTATION-DATA-
TYPE">ImplementationDataTypes/uint8</IMPLEMENTATION-DATA
-TYPE-REF>
<INVALID-VALUE>
<NUMERICAL-VALUE-SPECIFICATION>
<VALUE>3</VALUE>
</NUMERICAL-VALUE-SPECIFICATION>
</INVALID-VALUE>

251 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

</SW-DATA-DEF-PROPS-CONDITIONAL>
</SW-DATA-DEF-PROPS-VARIANTS>
</SW-DATA-DEF-PROPS>
</IMPLEMENTATION-DATA-TYPE-ELEMENT>
<IMPLEMENTATION-DATA-TYPE-ELEMENT>
<SHORT-NAME>string</SHORT-NAME>
<CATEGORY>ARRAY</CATEGORY>
<SUB-ELEMENTS>
<IMPLEMENTATION-DATA-TYPE-ELEMENT>
<SHORT-NAME>character</SHORT-NAME>
<CATEGORY>TYPE_REFERENCE</CATEGORY>
<ARRAY-SIZE>200</ARRAY-SIZE>
<ARRAY-SIZE-SEMANTICS>FIXED-SIZE</ARRAY-SIZE-SEMANTICS>
<SW-DATA-DEF-PROPS>
<SW-DATA-DEF-PROPS-VARIANTS>
<SW-DATA-DEF-PROPS-CONDITIONAL>
<IMPLEMENTATION-DATA-TYPE-REF DEST="IMPLEMENTATION-DATA
-TYPE">ImplementationDataTypes/uint8</IMPLEMENTATION
-DATA-TYPE-REF>
<INVALID-VALUE>
<ARRAY-VALUE-SPECIFICATION>
<ELEMENTS>
<NUMERICAL-VALUE-SPECIFICATION>
<VALUE>105</VALUE>
</NUMERICAL-VALUE-SPECIFICATION>
<NUMERICAL-VALUE-SPECIFICATION>
<VALUE>110</VALUE>
</NUMERICAL-VALUE-SPECIFICATION>
<NUMERICAL-VALUE-SPECIFICATION>
<VALUE>118</VALUE>
</NUMERICAL-VALUE-SPECIFICATION>
</ELEMENTS>
</ARRAY-VALUE-SPECIFICATION>
</INVALID-VALUE>
</SW-DATA-DEF-PROPS-CONDITIONAL>
</SW-DATA-DEF-PROPS-VARIANTS>
</SW-DATA-DEF-PROPS>
</IMPLEMENTATION-DATA-TYPE-ELEMENT>
</SUB-ELEMENTS>
</IMPLEMENTATION-DATA-TYPE-ELEMENT>
</SUB-ELEMENTS>
</IMPLEMENTATION-DATA-TYPE>
</ELEMENTS>
</AR-PACKAGE>

Please note that the size of the payload array in the the definition of the Implementa-
tionDataType in Listing 5.3 has been set to the value 200 in order to accommodate
for the definition of swMaxTextSize in the definition of the corresponding Applica-
tionDataType in combination with the fact that the value of baseTypeEncoding
has been set to UTF-8.
For background, the value of attribute SwTextProps.swMaxTextSize shall be spec-
ified as the number of code points in the string.

252 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Each code point will be encoded by a sequence of bytes, depending on the applicable
encoding. In the case of UTF-8, for example, each code point will be encoded by up
to four bytes.
On the level of ImplementationDataType, an array designed to hold a string con-
sisting of code points encoded using UTF-8 needs to be big enough to carry the num-
ber of code points (which may have been described by SwTextProps.swMaxText-
Size) times 4 bytes.
The interesting part about this definition is the fact that on the implementation level, it
was (driven by the definition of the SwRecordLayout) decided to implement the string
as a structure of a size element (that goes by the shortName “size”) and a value
element (that goes by the shortName “string”) which in turn is defined as an array
data type and therefore has a sub-element that goes by the shortName “character”.
The latter references (in the role swDataDefProps.implementationDataType)
the Platform Data Type “uint8” (that, according to the rules of Platform Data
Types, is realized by an ImplementationDataType “uint8”).
Please note that the ApplicationPrimitiveDataType named “MyApplication-
StringType” references the SwBaseType named “MyTextBaseType” which is defined
in the following XML fragment:
Listing 5.4: Example for the definition of a string SwBaseType
<AR-PACKAGE>
<SHORT-NAME>BaseTypes</SHORT-NAME>
<ELEMENTS>
<SW-BASE-TYPE>
<SHORT-NAME>MyTextBaseType</SHORT-NAME>
<CATEGORY>FIXED_LENGTH</CATEGORY>
<BASE-TYPE-SIZE>8</BASE-TYPE-SIZE>
<BASE-TYPE-ENCODING>UTF-8</BASE-TYPE-ENCODING>
</SW-BASE-TYPE>
<SW-BASE-TYPE>
<SHORT-NAME>uint8BaseType</SHORT-NAME>
<CATEGORY>FIXED_LENGTH</CATEGORY>
<BASE-TYPE-SIZE>8</BASE-TYPE-SIZE>
</SW-BASE-TYPE>
</ELEMENTS>
</AR-PACKAGE>

The contribution of this definition of SwBaseType to the overall definition of a string

data type is represented by the definition of the encoding (which is set to UTF-8). How-
ever, there is still one important part missing, i.e. the definition of the mapping of Ap-
plicationPrimitiveDataType to ImplementationDataType (and vice versa):
Listing 5.5: Example for the definition of the applicable DataTypeMappingSet
<AR-PACKAGE>
<SHORT-NAME>DataTypeMappingSets</SHORT-NAME>
<ELEMENTS>
<DATA-TYPE-MAPPING-SET>
<SHORT-NAME>theExample</SHORT-NAME>

253 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

<DATA-TYPE-MAPS>
<DATA-TYPE-MAP>
<APPLICATION-DATA-TYPE-REF BASE="default" DEST="APPLICATION-
PRIMITIVE-DATA-TYPE">ApplicationDataTypes/
MyApplicationStringType</APPLICATION-DATA-TYPE-REF>
<IMPLEMENTATION-DATA-TYPE-REF BASE="default" DEST="IMPLEMENTATION
-DATA-TYPE">ImplementationDataTypes/MyImplementationStringType
</IMPLEMENTATION-DATA-TYPE-REF>
</DATA-TYPE-MAP>
</DATA-TYPE-MAPS>
</DATA-TYPE-MAPPING-SET>
</ELEMENTS>
</AR-PACKAGE>

As mentioned before, the definition of an ImplementationDataType that corre-

sponds to an ApplicationPrimitiveDataType of category STRING can be
to some extent derived from the ApplicationPrimitiveDataType.swDataDef-
Props.swRecordLayout.
[TPS_SWCT_01570] DataTypeMap is mandatory in the presence of Applica-
tionPrimitiveDataType.swDataDefProps.swRecordLayout d The definition of
a DataTypeMap is mandatory even if an ImplementationDataType has been de-
rived from an ApplicationPrimitiveDataType that defines a SwRecordLayout.
c()
One motivation for the existence of [TPS_SWCT_01570] is that the integrator of an
AUTOSAR ECU may rightfully decide to take a different ImplementationDataType
other than the one that has been generated on the basis of the SwRecordLayout.

5.2.4.2 Application Composite Data Types

[TPS_SWCT_01247] ApplicationArrayDataType and ApplicationRecord-

DataType d The meta-classes ApplicationArrayDataType and Application-
RecordDataType provide the means to define composite data types.
Such a composite data type is required if the application software wants to have ac-
cess to the individual elements of the composite as well as to do operations with the
whole composite, e.g. wants to communicate the complete record or array in a single
transaction.
It is possible to use a combination of ApplicationArrayDataType and Applica-
tionRecordDataType, so that an ApplicationArrayDataType could be defined
as ApplicationRecordElement of a ApplicationRecordDataType and in the
same manner a ApplicationRecordDataType could be used as the base type of
an ApplicationArrayDataType. The creation of nested ApplicationCompos-
iteDataTypes is also possible. c()
Details about meta-class ApplicationRecordDataType are depicted in Fig-
ure 5.11.

254 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

ARElement
AtpType
AutosarDataType

AtpBlueprint
AtpBlueprintable
ApplicationDataType

ApplicationCompositeDataType

ApplicationArrayDataType ApplicationRecordDataType

+ dynamicArraySizeProfile: String [0..1]

  
«atpVariation»    
 
1..*
+element 1 +element {ordered}

ApplicationCompositeElementDataPrototype ApplicationCompositeElementDataPrototype
ApplicationArrayElement ApplicationRecordElement

+ arraySizeHandling: ArraySizeHandlingEnum [0..1] + isOptional: Boolean [0..1]

+ arraySizeSemantics: ArraySizeSemanticsEnum [0..1]
«atpVariation»
+ maxNumberOfElements: PositiveInteger [0..1]

«enumeration» «enumeration»
ArraySizeHandlingEnum ArraySizeSemanticsEnum

allIndicesSameArraySize fixedSize
allIndicesDifferentArraySize variableSize
inheritedFromArrayElementTypeSize

Figure 5.11: Summary of ApplicationCompositeDataType

5.2.4.2.1 ApplicationArrayDataType

[TPS_SWCT_01078] Configurable array size d An ApplicationArrayDataType

may6 contain maxNumberOfElements ApplicationArrayElements.
Each of these ApplicationArrayElements has the same data type.
When referring to an element of an ApplicationArrayDataType within a software-
component description, the element-index runs from 0 to the value of maxNumberO-
fElements-1. c(RS_SWCT_03144)
6
This applies although the multiplicity in the meta-model is 1. In fact, it would be possible to model
ApplicationArrayDataType without ApplicationArrayElement. The latter exists only so that
it can be the target of a reference within an AUTOSAR XML file

255 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Class ApplicationArrayDataType
Package M2::AUTOSARTemplates::SWComponentTemplate::Datatype::Datatypes
Note An application data type which is an array, each element is of the same application data type.
Tags: atp.recommendedPackage=ApplicationDataTypes
Base ARElement, ARObject, ApplicationCompositeDataType, ApplicationDataType, AtpBlueprint, Atp
Blueprintable, AtpClassifier , AtpType, AutosarDataType, CollectableElement, Identifiable, Multilanguage
Referrable, PackageableElement, Referrable
Attribute Type Mul. Kind Note
dynamicArray String 0..1 attr Specifies the profile which the array will follow if it is a
SizeProfile variable size array.
element ApplicationArray 1 aggr This association implements the concept of an array
Element element. That is, in some cases it is necessary to be able
to identify single array elements, e.g. as input values for
an interpolation routine.

Table 5.11: ApplicationArrayDataType

Class ApplicationArrayElement
Package M2::AUTOSARTemplates::SWComponentTemplate::Datatype::DataPrototypes
Note Describes the properties of the elements of an application array data type.
Base ARObject, ApplicationCompositeElementDataPrototype, AtpFeature, AtpPrototype, DataPrototype,
Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mul. Kind Note
arraySize ArraySizeHandling 0..1 attr The way how the size of the array is handled.
Handling Enum
arraySize ArraySizeSemantics 0..1 attr This attribute controls how the information about the array
Semantics Enum size shall be interpreted.
indexDataType ApplicationPrimitive 0..1 ref This reference can be taken to assign a CompuMethod of
DataType category TEXTTABLE to the array. The texttable entries
associate a textual value to an index number such that
the element with that index number is represented by a
symbolic name.
maxNumberOf PositiveInteger 0..1 attr The maximum number of elements that the array can
Elements contain.
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime

Table 5.12: ApplicationArrayElement

Please note that the information about the number of elements of a specific Appli-
cationArrayDataType is not absolute but allows for further interpretation.
[TPS_SWCT_01076] Number of elements of a specific ApplicationArray-
DataType might vary at run-time d That is, there are cases where the number of
elements of a specific ApplicationArrayDataType might vary at run-time.
To be precise, the number of elements might vary between 0 and the value denoted by
maxNumberOfElements.
For this purpose an additional attribute arraySizeSemantics is available that can
be used to clarify the meaning of maxNumberOfElements.

256 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

For clarification, it might indeed happen that the actual number of elements in a specific
ApplicationArrayDataType yields 0 simply because the respective DataProto-
type is part of a higher-level protocol where under certain circumstances the Dat-
aPrototype of ApplicationArrayDataType is simply not required for expressing
a given semantics. c(RS_SWCT_03180, RS_SWCT_03181, RS_SWCT_03144)
[TPS_SWCT_01752] Initialization of a variable-size array d If a DataProto-
type typed by an ApplicationArrayDataType where attribute arraySizeSe-
mantics set to the value variableSize is initialized by an ArrayValueSpecifi-
cation that does not aggregate an element then the semantics shall be that the
DataPrototype is initialized as empty. c(RS_SWCT_03180, RS_SWCT_03181,
RS_SWCT_03144)
Enumeration ArraySizeSemanticsEnum
Package M2::AUTOSARTemplates::CommonStructure::ImplementationDataTypes
Note This type controls how the information about the number of elements in an ApplicationArrayDataType
is to be interpreted.
Literal Description
fixedSize This means that the ApplicationArrayDataType will always have a fixed number of elements.
Tags: atp.EnumerationValue=0
variableSize This implies that the actual number of elements in the ApplicationArrayDataType might vary at
run-time. The value of arraySize represents the maximum number of elements in the array.
Tags: atp.EnumerationValue=1

Table 5.13: ArraySizeSemanticsEnum

Please note that the ability to define the semantic meaning of maxNumberOfEle-
ments is not only limited to the application data type level. The same approach also
applies for ImplementationDataType.
[constr_1152] category of ApplicationArrayElement and AutosarDataType
referenced in the role type shall be kept in sync d The value of category of an
ApplicationArrayElement shall always be identical to the value of category of
the AutosarDataType referenced by the ApplicationArrayElement. c()
[TPS_SWCT_01601] Size Indicator shall be updated by software-component
d If a software-component changes the number of valid elements in a variable size
array, it shall also update the Size Indicator in the ImplementationDataType.
c(RS_SWCT_03181)
[TPS_SWCT_01602] Size Indicator shall be read by the software-component
d If a software-component receives a variable size array, it shall use the Size Indi-
cator in the ImplementationDataType to determine the number of valid elements
in the array. c(RS_SWCT_03181)

257 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Enumeration ArraySizeHandlingEnum
Package M2::AUTOSARTemplates::SWComponentTemplate::Datatype::Datatypes
Note This enumeration defines different ways to handle the sizes of variable size arrays.
Literal Description
allIndicesDifferent All elements of the variable size array may have different sizes.
ArraySize
Tags: atp.EnumerationValue=0
allIndicesSame All elements of the variable size array have the same size.
ArraySize
Tags: atp.EnumerationValue=1
inheritedFromArray The size of all dimensions of the variable size array is determined by the size of the contained array
ElementTypeSize element.
Tags: atp.EnumerationValue=2

Table 5.14: ArraySizeHandlingEnum

5.2.4.2.1.1 Variable Size Array

[TPS_SWCT_01604] Enable Size Indicator d To enable the RTE’s ability to

consider the number of valid elements inside a Variable-Size Array Data
Type the ApplicationArrayDataType.dynamicArraySizeProfile of Appli-
cationArrayDataType and ApplicationArrayElement.arraySizeHandling
shall be set. c(RS_SWCT_03181)
[TPS_SWCT_01605] Semantics of ApplicationArrayElement.arraySizeHan-
dling d The attribute ApplicationArrayElement.arraySizeHandling speci-
fies how the size is determined in case of multi-dimensional variable size array. c
(RS_SWCT_03181)
This allows to specify coherencies between the sizes of the nested variable size arrays
in case of multiple dimensions.
With a suitable ImplementationDataType, it is possible to enable other software-
components, RTE, and other BSW modules to make use of the Size Indicator and
only transfer the valid data elements from the sender to the receiver.
[TPS_SWCT_01606] Internal structure of mapped ImplementationDataType d
The attribute dynamicArraySizeProfile specifies which internal structure the Im-
plementationDataType that is mapped to the ApplicationDataType shall fol-
low. c(RS_SWCT_03181)
[TPS_SWCT_01607] Profiles for internal structure of mapped Implementa-
tionDataType d For the structure of the ImplementationDataType that is
mapped to the ApplicationDataType the following profiles are defined for dy-
namicArraySizeProfile: VSA_LINEAR, VSA_SQUARE, VSA_RECTANGULAR, and
VSA_FULLY_FLEXIBLE. c(RS_SWCT_03181)
[TPS_SWCT_01608] Custom profiles for internal structure of mapped Implemen-
tationDataType d Custom profiles can be added to dynamicArraySizeProfile.
They shall have a company-specific prefix. c(RS_SWCT_03181)

258 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

As it is a general rule for the definition of custom profiles or values of category, the
custom value should start with a company-specific prefix in order to avoid clashes with
later extensions of the AUTOSAR standard.
dynamicArraySizeProfile is used to specify how the number of elements of the
multiple dimensions of a variable size array correlate. They could be totally indepen-
dent (VSA_FULLY_FLEXIBLE) on the one hand or each dimension has the same num-
ber of valid elements (VSA_SQUARE).
[TPS_SWCT_01623] Justification for the existence of attributes Application-
ArrayDataType.dynamicArraySizeProfile and ApplicationArrayEle-
ment.arraySizeHandling d At the first glance, the two attributes Application-
ArrayDataType.dynamicArraySizeProfile and ApplicationArrayEle-
ment.arraySizeHandling seem equivalent.
However, both are needed because they have to be used if multi dimensional variable
size arrays have to be described. In this case, multiple combinations of sizes could
occur which cannot be specified beforehand. c(RS_SWCT_03181)
The ImplementationDataType has to follow certain rules depending on the chosen
profile. See chapter 5.2.5 for details.
[constr_1314] Profile VSA_LINEAR for ApplicationArrayDataType d If
the dynamicArraySizeProfile of ApplicationArrayDataType is set to
VSA_LINEAR, the contained ApplicationArrayElement shall fulfill all of the fol-
lowing conditions:
• The attribute ApplicationArrayElement.arraySizeSemantics shall set
to the value variableSize.
• The attribute ApplicationArrayElement.maxNumberOfElements shall be
defined.
• The attribute ApplicationArrayElement.arraySizeHandling shall be set
to the value allIndicesSameArraySize.
• The ApplicationArrayElement shall be typed by an Application-
DataType that is not an ApplicationArrayDataType where the attribute
dynamicArraySizeProfile exists.
c()
The part of [constr_1314] that demands that the ApplicationArrayElement
shall be typed by an ApplicationDataType that is not an ApplicationArray-
DataType where the attribute dynamicArraySizeProfile exists basically boils
down to the simple explanation that the “leaf” data type of the Variable-Size Ar-
ray Data Type can be anything but a Variable-Size Array Data Type.
[constr_1315] Profile VSA_SQUARE for ApplicationArrayDataType d If
the dynamicArraySizeProfile of ApplicationArrayDataType is set to
VSA_SQUARE, the contained ApplicationArrayElement shall fulfill all of the fol-
lowing conditions:

259 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

• The attribute ApplicationArrayElement.arraySizeSemantics shall be

set to the value variableSize.
• The attribute ApplicationArrayElement.maxNumberOfElements shall not
be defined.
• The attribute ApplicationArrayElement.arraySizeHandling shall be set
to the value inheritedFromArrayElementTypeSize.
• The ApplicationArrayElement shall be typed by an ApplicationArray-
DataType.
The referred ApplicationArrayDataType shall refer over a chain (under consid-
eration of the number of dimensions of the “root” ApplicationArrayDataType) of
nested ApplicationArrayDataTypes with ApplicationArrayElements to an
ApplicationDataType that is not an ApplicationArrayDataType where the
attribute dynamicArraySizeProfile exists.
The last ApplicationArrayDataType in that chain shall have an Application-
ArrayElement that fulfills all of the following conditions:
• The attribute ApplicationArrayElement.arraySizeSemantics shall be
set to the value variableSize.
• The attribute ApplicationArrayElement.maxNumberOfElements shall be
defined.
• The attribute ApplicationArrayElement.arraySizeHandling set to the
value allIndicesSameArraySize.
All ApplicationArrayDataTypes before shall have an ApplicationArrayEle-
ment that fulfills all of the following conditions:
• The attribute ApplicationArrayElement.arraySizeSemantics shall be
set to the value variableSize.
• The attribute ApplicationArrayElement.maxNumberOfElements shall not
be defined.
• The attribute ApplicationArrayElement.arraySizeHandling shall be set
to the value inheritedFromArrayElementTypeSize.
• The ApplicationArrayElement shall be typed by an ApplicationArray-
DataType.
c()
The part of [constr_1315], [constr_1316], and [constr_1317] that demands that the re-
ferred ApplicationArrayDataType shall refer over a chain (under consideration
of the number of dimensions of the “root” ApplicationArrayDataType) of nested
ApplicationArrayDataTypes with ApplicationArrayElements to an Appli-
cationDataType that is not an ApplicationArrayDataType where the attribute
dynamicArraySizeProfile exists basically boils down to the simple explanation

260 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

that the “leaf” data type of the Variable-Size Array Data Type can be anything
but a Variable-Size Array Data Type.
[constr_1316] Profile VSA_RECTANGULAR for ApplicationArrayDataType d
If the dynamicArraySizeProfile of ApplicationArrayDataType is set to
VSA_RECTANGULAR the contained ApplicationArrayElement shall fulfill all of the
following conditions:
• The attribute ApplicationArrayElement.arraySizeSemantics shall be
set to the value variableSize.
• The attribute ApplicationArrayElement.maxNumberOfElements shall be
defined.
• The attribute ApplicationArrayElement.arraySizeHandling shall be set
to the value allIndicesSameArraySize.
• The ApplicationArrayElement shall be typed by an ApplicationArray-
DataType.
The referred ApplicationArrayDataType shall refer over a chain (under consid-
eration of the number of dimensions of the “root” ApplicationArrayDataType) of
nested ApplicationArrayDataTypes with ApplicationArrayElements to an
ApplicationDataType that is not an ApplicationArrayDataType where the
attribute dynamicArraySizeProfile exists.
The last ApplicationArrayDataType in that chain shall have an Application-
ArrayElement that fulfills all of the following conditions:
• The attribute ApplicationArrayElement.arraySizeSemantics shall be
set to the value variableSize.
• The attribute ApplicationArrayElement.maxNumberOfElements shall be
defined.
• The attribute ApplicationArrayElement.arraySizeHandling shall be set
to the value allIndicesSameArraySize.
All ApplicationArrayDataTypes before shall have an ApplicationArrayEle-
ment that fulfills all of the following conditions:
• The attribute ApplicationArrayElement.arraySizeSemantics shall set
to the value variableSize
• The attribute ApplicationArrayElement.maxNumberOfElements shall be
defined.
• The attribute ApplicationArrayElement.arraySizeHandling shall be set
to the value allIndicesSameArraySize.
• The ApplicationArrayElement shall be typed by an ApplicationArray-
DataType.

261 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

c()
[constr_1317] Profile VSA_FULLY_FLEXIBLE for ApplicationArrayDataType
d If the dynamicArraySizeProfile of ApplicationArrayDataType is set to
VSA_FULLY_FLEXIBLE, the contained ApplicationArrayElement shall fulfill all
of the following conditions:
• The attribute ApplicationArrayElement.arraySizeSemantics shall be
set to the value variableSize.
• The attribute ApplicationArrayElement.maxNumberOfElements shall be
defined.
• The attribute ApplicationArrayElement.arraySizeHandling shall be set
to the value allIndicesDifferentArraySize.
• The ApplicationArrayElement shall be typed by an ApplicationArray-
DataType.
The referred ApplicationArrayDataType shall refer over a chain (under consid-
eration of the number of dimensions of the “root” ApplicationArrayDataType) of
nested ApplicationArrayDataTypes with ApplicationArrayElements to an
ApplicationDataType that is not an ApplicationArrayDataType where the
attribute dynamicArraySizeProfile exist.
The last ApplicationArrayDataType in that chain shall have an Application-
ArrayElement that fulfills all of the following conditions:
• The attribute ApplicationArrayElement.arraySizeSemantics shall be
set to the value variableSize.
• The attribute ApplicationArrayElement.maxNumberOfElements shall be
defined.
• The attribute ApplicationArrayElement.arraySizeHandling shall be set
to the value allIndicesSameArraySize.
All ApplicationArrayDataTypes before shall have an ApplicationArrayEle-
ment that fulfills all of the following conditions:
• The attribute ApplicationArrayElement.arraySizeSemantics shall be
set to the value variableSize.
• The attribute ApplicationArrayElement.maxNumberOfElements shall be
defined.
• The attribute ApplicationArrayElement.arraySizeHandling shall be set
to the value allIndicesDifferentArraySize.
• The ApplicationArrayElement shall be typed by an ApplicationArray-
DataType.
c()

262 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

For examples see Appendix E.1.

5.2.4.2.1.2 Multi-Dimensional Arrays

[TPS_SWCT_01256] Definition of multi-dimensional array data types d In order

to describe multi dimensional arrays an ApplicationArrayElement references
again another ApplicationArrayDataType. Hereby, one ApplicationArray-
DataType per dimension is required.
This multiple dimensions do have a well-defined correlation to the individual dimen-
sions of an ImplementationDataType of category ARRAY when the Applica-
tionArrayDataType is mapped to an ImplementationDataType.
The ApplicationArrayElements are mapping in the order of the Applica-
tionArrayElement to ApplicationArrayDataType references to Implemen-
tationDataTypeElements in the order of first ImplementationDataTypeEle-
ment of the ImplementationDataType to leaf ImplementationDataTypeEle-
ment.
In other words the ApplicationArrayElement of the top level ApplicationAr-
rayDataType relates to the first ImplementationDataTypeElement of the Im-
plementationDataType.
The ApplicationArrayElement of the referenced ApplicationArray-
DataTypes relates to the sub ImplementationDataTypeElements in the order of
the ApplicationArrayElement -> ApplicationArrayDataType references. c
(RS_SWCT_03216)

263 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

BOOLEAN_true_false_SysConDim1_SysConDim2_SysConDim3: boolean_NcNrDim1_NcNrDim2_NcNrDim3: ImplementationDataType

ApplicationArrayDataType
category = ARRAY
category = ARRAY
+implementationDataType
+applicationDataType
+element +subElement

Dim1: ApplicationArrayElement Dim1: ImplementationDataTypeElement

SysConDim1:
category = ARRAY SwSystemconst category = ARRAY
arraySizeSemantics = FIXED-SIZE arraySizeSemantics = FIXED-SIZE
maxNumberOfElements = SysConDim1 arraySize = SysConDim1

+type

BOOLEAN_true_false_SysConDim2_SysConDim3:
ApplicationArrayDataType

category = ARRAY

+element +subElement

Dim2: ApplicationArrayElement Dim2: ImplementationDataTypeElement

SysConDim2:
category = ARRAY SwSystemconst category = ARRAY
arraySizeSemantics = FIXED-SIZE arraySizeSemantics = FIXED-SIZE
maxNumberOfElements = SysConDim2 arraySize = SysConDim2

+type

BOOLEAN_true_false_SysConDim3: ApplicationArrayDataType

category = ARRAY

+element +subElement

Dim3: ApplicationArrayElement Dim3: ImplementationDataTypeElement

SysConDim3:
category = BOOLEAN SwSystemconst category = TYPE_REFERENCE
arraySizeSemantics = FIXED-SIZE arraySizeSemantics = FIXED-SIZE
maxNumberOfElements = SysConDim3 arraySize = SysConDim3

+swDataDefProps

«atpVariation»
:SwDataDefProps

+type +implementationDataType

BOOLEAN_true_false: boolean:
ApplicationPrimitiveDataType ImplementationDataType
DefaultDataTypeMapping:
category = BOOLEAN DataTypeMappingSet category = VALUE

+dataTypeMap

:DataTypeMap

Figure 5.12: Example of a three dimensional array type

Figure 5.12 shows a three dimensional array described with a set of Application-
ArrayDataTypes on the left hand side. The array element is typed by an Applica-
tionPrimitiveDataType of category BOOLEAN. On the right hand side the im-
plementation of the three dimensional array is described with an Implementation-
DataType which contains three nested ImplementationDataTypeElements.

264 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Matching ApplicationArrayElements and ImplementationDataTypeEle-

ments are shown on the same layer. For the sake of clarity correlating maxNumberO-
fElements and arraySize attributes are described with the identical instance of a
SwSystemconst instead of a value. Further details of variant rich M1 models are not
in the scope of this example.
The data type of the array element is described by the ApplicationArrayDataType
with the means of a ApplicationPrimitiveDataType of category BOOLEAN. In
order to fulfill [constr_1152] the category of ApplicationArrayElement “Dim3”
is set to BOOLEAN.
This ApplicationPrimitiveDataType “BOOLEAN” correlates to the Implemen-
tationDataType “boolean” of category VALUE which is typically the boolean type
of the AUTOSAR Platform Types. Please note here [constr_1063].

5.2.4.2.1.3 Index Data Type

The usage of an array represents an elegant way to group data with identical proper-
ties. This allows for an easy processing of the same functionality by iterating over the
array elements.
From a functional point of view, however, each array element may have a distinct mean-
ing that could be visible to the application software. To create this visibility, it is possible
to take advantage of an existing mechanism: CompuMethods of category TEXT-
TABLE.
[TPS_SWCT_01699] Usage of ApplicationArrayElement.indexDataType d
The primary use case of the attribute ApplicationArrayElement.index-
DataType is the creation of composite data type mappings or the description of mea-
surement and calibration. Furthermore, the information could be used for documenta-
tion purposes. c(RS_SWCT_03230)

265 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

«atpVariation»
SwDataDefProps

+ additionalNativeTypeQualifier: NativeDeclarationString [0..1]

+ displayFormat: DisplayFormatString [0..1]
+ displayPresentation: DisplayPresentationEnum [0..1]
+ stepSize: Float [0..1]
+ swAlignment: AlignmentType [0..1] ARElement
+ swCalibrationAccess: SwCalibrationAccessEnum [0..1] AtpType
+swDataDefProps
+ swImplPolicy: SwImplPolicyEnum [0..1]
+ swIntendedResolution: Numerical [0..1] AutosarDataType
0..1
+ swInterpolationMethod: Identifier [0..1]
+ swIsVirtual: Boolean [0..1]
«atpVariation»
+ swValueBlockSize: Numerical [0..1]
+ swValueBlockSizeMult: Numerical [0..*] {ordered}

+compuMethod 0..1

ARElement AtpBlueprint
AtpBlueprint AtpBlueprintable
AtpBlueprintable ApplicationDataType
CompuMethod

+ displayFormat: DisplayFormatString [0..1]

ApplicationCompositeDataType
ApplicationArrayDataType

+ dynamicArraySizeProfile: String [0..1]

+element 1

ApplicationCompositeElementDataPrototype
ApplicationPrimitiveDataType
ApplicationArrayElement
+indexDataType
+ arraySizeHandling: ArraySizeHandlingEnum [0..1]
+ arraySizeSemantics: ArraySizeSemanticsEnum [0..1] 0..1
«atpVariation»
+ maxNumberOfElements: PositiveInteger [0..1]

Figure 5.13: Modeling of the ApplicationArrayElement.indexDataType

[constr_1438] ApplicationArrayElement.indexDataType needs to refer to a

CompuMethod of category TEXTTABLE d The reference ApplicationArrayEle-
ment.indexDataType shall only point to an ApplicationPrimitiveDataType
that in turn refers to a CompuMethod of category TEXTTABLE. c()
[constr_1440] Size of the CompuMethod of category TEXTTABLE referenced by
ApplicationArrayElement.indexDataType d The interval defined by the Com-
puScales contained in the CompuMethod referenced by ApplicationArrayEle-
ment.indexDataType shall start at 0 and include all integer values until Applica-
tionArrayElement.maxNumberOfElements - 1. c()
[constr_1439] Requirements on ApplicationArrayElement if attribute index-
DataType exists d If ApplicationArrayElement.indexDataType exists then the
attribute ApplicationArrayElement.arraySizeSemantics shall be set to the
value fixedSize and attribute arraySizeHandling shall not exist. c()

266 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Listing 5.6 exemplifies the definition of an indexDataType.

Listing 5.6: Example for array index data type
<APPLICATION-ARRAY-DATA-TYPE>
<SHORT-NAME>CylinderArray</SHORT-NAME>
<ELEMENT>
<SHORT-NAME>CylinderArrayElement</SHORT-NAME>
<ARRAY-SIZE-SEMANTICS>FIXED-SIZE</ARRAY-SIZE-SEMANTICS>
<INDEX-DATA-TYPE-REF DEST="APPLICATION-PRIMITIVE-DATA-TYPE">
myIndexDataType</INDEX-DATA-TYPE-REF>
</ELEMENT>
</APPLICATION-ARRAY-DATA-TYPE>
<APPLICATION-PRIMITIVE-DATA-TYPE>
<SHORT-NAME>myIndexDataType</SHORT-NAME>
<SW-DATA-DEF-PROPS>
<SW-DATA-DEF-PROPS-VARIANTS>
<SW-DATA-DEF-PROPS-CONDITIONAL>
<COMPU-METHOD-REF DEST="COMPU-METHOD">cylinders</COMPU-METHOD-REF>
</SW-DATA-DEF-PROPS-CONDITIONAL>
</SW-DATA-DEF-PROPS-VARIANTS>
</SW-DATA-DEF-PROPS>
</APPLICATION-PRIMITIVE-DATA-TYPE>

Listing 5.7 contains a example of a CompuMethod eligible for an indexDataType.

Listing 5.7: Example for a compu method used by an array index data type
<COMPU-METHOD>
<SHORT-NAME>cylinders</SHORT-NAME>
<CATEGORY>TEXTTABLE</CATEGORY>
<COMPU-INTERNAL-TO-PHYS>
<COMPU-SCALES>
<COMPU-SCALE>
<LOWER-LIMIT INTERVAL-TYPE="CLOSED">0</LOWER-LIMIT>
<UPPER-LIMIT INTERVAL-TYPE="CLOSED">0</UPPER-LIMIT>
<COMPU-CONST>
<VT>Cylinder1</VT>
</COMPU-CONST>
</COMPU-SCALE>
<COMPU-SCALE>
<LOWER-LIMIT INTERVAL-TYPE="CLOSED">1</LOWER-LIMIT>
<UPPER-LIMIT INTERVAL-TYPE="CLOSED">1</UPPER-LIMIT>
<COMPU-CONST>
<VT>Cylinder2</VT>
</COMPU-CONST>
</COMPU-SCALE>
<COMPU-SCALE>
<LOWER-LIMIT INTERVAL-TYPE="CLOSED">2</LOWER-LIMIT>
<UPPER-LIMIT INTERVAL-TYPE="CLOSED">2</UPPER-LIMIT>
<COMPU-CONST>
<VT>Cylinder3</VT>
</COMPU-CONST>
</COMPU-SCALE>
<COMPU-SCALE>
<LOWER-LIMIT INTERVAL-TYPE="CLOSED">3</LOWER-LIMIT>
<UPPER-LIMIT INTERVAL-TYPE="CLOSED">3</UPPER-LIMIT>

267 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

<COMPU-CONST>
<VT>Cylinder4</VT>
</COMPU-CONST>
</COMPU-SCALE>
</COMPU-SCALES>
</COMPU-INTERNAL-TO-PHYS>
</COMPU-METHOD>

5.2.4.2.2 ApplicationRecordDataType

[TPS_SWCT_01249] ApplicationRecordDataType d A declaration of Applica-

tionRecordDataType describes a non-empty set of objects, each of which has a
unique identifier with respect to the ApplicationRecordDataType and each has
an own ApplicationDataType.
The shortName of each ApplicationRecordElement within the scope of an Ap-
plicationRecordDataType shall be unique. c(RS_SWCT_03216)
Class ApplicationRecordDataType
Package M2::AUTOSARTemplates::SWComponentTemplate::Datatype::Datatypes
Note An application data type which can be decomposed into prototypes of other application data types.
Tags: atp.recommendedPackage=ApplicationDataTypes
Base ARElement, ARObject, ApplicationCompositeDataType, ApplicationDataType, AtpBlueprint, Atp
Blueprintable, AtpClassifier , AtpType, AutosarDataType, CollectableElement, Identifiable, Multilanguage
Referrable, PackageableElement, Referrable
Attribute Type Mul. Kind Note
element (or- ApplicationRecord 1..* aggr Specifies an element of a record.
dered) Element
The aggregation of ApplicationRecordElement is subject
to variability with the purpose to support the conditional
existence of elements inside a ApplicationrecordData
Type.
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime

Table 5.15: ApplicationRecordDataType

Class ApplicationRecordElement
Package M2::AUTOSARTemplates::SWComponentTemplate::Datatype::DataPrototypes
Note Describes the properties of one particular element of an application record data type.
Base ARObject, ApplicationCompositeElementDataPrototype, AtpFeature, AtpPrototype, DataPrototype,
Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mul. Kind Note
isOptional Boolean 0..1 attr This attribute represents the ability to declare the
enclosing ApplicationRecordElement as optional. This
means the that, at runtime, the ApplicationRecord
Element may or may not have a valid value and shall
therefore be ignored.
5
5

268 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4
Class ApplicationRecordElement
4
The underlying runtime software provides means to set
the ApplicationRecordElement as not valid at the sending
end of a communication and determine its validity at the
receiving end.
Tags: atp.Status=draft

Table 5.16: ApplicationRecordElement

[TPS_SWCT_01771]{DRAFT} Definition of optional elements on the level of Ap-

plicationDataType d The modeling approach for the definition of optional ele-
ments on the level of ApplicationDataType is to set the attribute Application-
RecordElement.isOptional to the value True.
If the attribute is not set or set to the value False then the respective Application-
RecordElement shall be considered mandatory. c(RS_SWCT_03320)

5.2.5 Implementation Data Type

[TPS_SWCT_01250] ImplementationDataType has been introduced to opti-

mize the formal support for data type handling on the implementation level d
The concept of an ImplementationDataType has been introduced to optimize the
formal support for data type handling on the implementation level.
That is, an ImplementationDataType conceptually corresponds to the level of (C)
source code. For example, ImplementationDataTypes have a direct impact on the
contract (please find an explanation of this term in [2]) of a software-component and
the RTE. c(RS_SWCT_03217)

269 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Attributes of SwDataDefProps Root Element Attribute Existence per Category

ImplementationDataTypeElement
ImplementationDataType

SwPointerTargetProps

FUNCTION_REFERENCE
DATA_REFERENCE

TYPE_REFERENCE
SwServiceArg

STRUCTURE
VALUE

UNION

ARRAY
additionalNativeTypeQualifier x x x x 0..1 0..1 0..1 0..1 0..1 0..1 0..1
annotation x x x x * * * * * * *
baseType x x x x 1
compuMethod x x x x 0..1 0..1
dataConstr.dataConstrRule.physConstrs x x x x d/c7 d/c d/c
dataConstr.dataConstrRule.internalConstrs x x x x 0..1 0..1 0..1
displayFormat x x 0..1 0..1 0..1 0..1
displayPresentation x x 0..1 0..1
implementationDataType x x x x 1
invalidValue x x x 0..1 0..1 0..18 0..19
stepSize x x 0..1
swAddrMethod x x x 0..1 0..1 0..1 0..1 0..1 0..1 0..1
swAlignment x 0..1 0..1 0..1 0..1 0..1 0..1
swBitRepresentation
swCalibrationAccess x x 0..1 0..1 0..1 0..1 0..1
swCalprmAxisSet
swComparisonVariable
swDataDependency
swHostVariable
swImplPolicy x x x 0..1 0..1 0..1 0..1 0..1 0..1 0..1
swIntendedResolution
swInterpolationMethod
swIsVirtual
swPointerTargetProps x x x x 1 1
swPointerTargetProps
x x x x 1
.swDataDefProps
swPointerTargetProps
x x x x 1
.functionPointerSignature
swRecordLayout
swRefreshTiming x x x x 0..1 0..1 0..1 0..1
5

7
don’t care
8
There is a use case for the definition of an invalidValue for category ARRAY and therefore
category STRUCTURE is also supported for the sake of symmetry.
9
This represents an exception such that it would make sense to use an entire ArrayValueSpeci-
fication as the invalidValue because a string semantically is more than just a bunch of characters
in a row.

270 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4
Attributes of SwDataDefProps Root Element Attribute Existence per Category

ImplementationDataTypeElement
ImplementationDataType

SwPointerTargetProps

FUNCTION_REFERENCE
DATA_REFERENCE

TYPE_REFERENCE
SwServiceArg

STRUCTURE
VALUE

UNION

ARRAY
swTextProps
swValueBlockSize
swValueBlockSizeMult
unit
valueAxisDataType
Other Attributes
subElement: ImplementationDataTypeElement x x 1..* 1..* 1
subElement.arraySizeSemantics x x 0..1
subElement.arraySize x x 1

Table 5.17: Allowed Attributes vs. category for ImplementationDataType

[TPS_SWCT_01251] Limited set of values for category are applicable for Im-
plementationDataType d Like any AutosarDataType, also the data types on im-
plementation level are characterized by its category and its SwDataDefProps. For
a given category, only a limited set of attributes of the SwDataDefProps makes
sense. c(RS_SWCT_03217)
[constr_1009] SwDataDefProps applicable to ImplementationDataTypes d A
complete list of the SwDataDefProps and other attributes and their multiplicities which
are allowed for a given category is shown in table 5.17. c()
This list makes use of the SwDataDefProps and other meta-model elements which
are explained in detail in the further sections of this chapter.
Regulations regarding the applicable categorys for attribute Implementation-
DataType.swDataDefProps.compuMethod can be found in [constr_1158] inside
section 5.5.1.3.2.
[constr_1383] Existence of CompuMethod and DataConstr for Implementa-
tionDataTypes of category TYPE_REFERENCE d The existence of Imple-
mentationDataType.swDataDefProps.compuMethod and Implementation-
DataType.swDataDefProps.dataConstr for ImplementationDataTypes of
category TYPE_REFERENCE is only allowed if the respective Implementation-
DataType, after all type references are resolved, ends up in an Implementation-
DataType of category VALUE. c()

271 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Please note that, as a consequence of the existence of [constr_1383], it is possible

that the elements of a composite ImplementationDataType define individual Com-
puMethods. However, the definition of one CompuMethod that applies to the entire
composite ImplementationDataType is not supported.
[TPS_SWCT_01252] ImplementationDataType can express concepts not avail-
able on application level d As a consequence of the specific focus, it is possible to
express concepts with an ImplementationDataType that are not supported on the
application level, i.e. by ApplicationDataType:
• ImplementationDataType supports the definition of pointers
• It is possible to define “alias” names just as in a typedef
• It is possible to define nested ImplementationDataTypes but in contrast to
the concept implemented for ApplicationDataType these implement a direct
aggregation of sub-elements rather than applying the type-prototype pattern.
c(RS_SWCT_03217)
The general structure of ImplementationDataType is sketched in Figure 5.14. If a
specific ImplementationDataType is supposed to define a composite data type the
ImplementationDataType aggregates ImplementationDataTypeElements.
AtpBlueprint
AtpBlueprintable
AutosarDataType
AbstractImplementationDataType

ImplementationProps
ImplementationDataType
+symbolProps SymbolProps
+ dynamicArraySizeProfile: String [0..1]
+ isStructWithOptionalElement: Boolean [0..1] «atpSplitable» 0..1
+ typeEmitter: NameToken [0..1]

AtpStructureElement
Identifiable
  
AbstractImplementationDataTypeElement «atpVariation»    
 

0..*
{ordered} +subElement
+subElement
ImplementationDataTypeElement 0..* {ordered}
+ arraySizeHandling: ArraySizeHandlingEnum [0..1]
+ arraySizeSemantics: ArraySizeSemanticsEnum [0..1]
+ isOptional: Boolean [0..1] «atpVariation»
«atpVariation»
+ arraySize: PositiveInteger [0..1]

«enumeration» «enumeration»
ArraySizeHandlingEnum ArraySizeSemanticsEnum

allIndicesSameArraySize fixedSize
allIndicesDifferentArraySize variableSize
inheritedFromArrayElementTypeSize

Figure 5.14: ImplementationDataType overview

272 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Class ImplementationDataType
Package M2::AUTOSARTemplates::CommonStructure::ImplementationDataTypes
Note Describes a reusable data type on the implementation level. This will typically correspond to a typedef in
C-code.
Tags: atp.recommendedPackage=ImplementationDataTypes
Base ARElement, ARObject, AbstractImplementationDataType, AtpBlueprint, AtpBlueprintable, AtpClassifier ,
AtpType, AutosarDataType, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mul. Kind Note
dynamicArray String 0..1 attr Specifies the profile which the array will follow in case this
SizeProfile data type is a variable size array.
isStructWith Boolean 0..1 attr This attribute is only valid if the attribute category is set to
Optional STRUCTURE.
Element
If set to True, this attribute indicates that the
ImplementationDataType has been created with the
intention to define at least one element of the structure as
optional.
Tags: atp.Status=draft
subElement (or- ImplementationData * aggr Specifies an element of an array, struct, or union data
dered) TypeElement type.
The aggregation of ImplementionDataTypeElement is
subject to variability with the purpose to support the
conditional existence of elements inside a Implementation
DataType representing a structure.
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime
symbolProps SymbolProps 0..1 aggr This represents the SymbolProps for the Implementation
DataType.
Stereotypes: atpSplitable
Tags: atp.Splitkey=shortName
typeEmitter NameToken 0..1 attr This attribute is used to control which part of the
AUTOSAR toolchain is supposed to trigger data type
definitions.
Table 5.18: ImplementationDataType

[TPS_SWCT_01253] Rules apply for the usage of the attribute Implementation-

DataType.typeEmitter d The following set of rules applies for the usage of the at-
tribute ImplementationDataType.typeEmitter:
• If the value of attribute typeEmitter is NOT defined and a nativeDeclara-
tion is provided the RTE generator shall generate the corresponding data type
definition10 .
• If the value of attribute typeEmitter is set to “RTE” and a nativeDeclara-
tion is provided the RTE generator shall generate the corresponding data type
definition.
• If the value of the attribute typeEmitter is set to “RTE” and no nativeDec-
laration is provided the RTE generator shall issue an error message.
10
This rule represents the behavior before the attribute typeEmitter was introduced. The rule has
specifically been added in order to support a backwards-compatible behavior.

273 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

• If the value of attribute typeEmitter is set to anything else but “RTE” the RTE
generator shall silently not generate the corresponding data type definition re-
gardless of the existence of nativeDeclaration attribute.
c(RS_SWCT_03217)
Note that the rules listed above imply that the allowed values of the attribute type-
Emitter are not constrained with the singular exception that the definition of the be-
havior in case of “RTE” is claimed by AUTOSAR. Other values can be provided; the
consequences of this provision are implementation-dependent and outside the scope
of the definition of the AUTOSAR standard.
The usage of ImplementationDataTypes within an AnyInstanceRef is described
in detail in [11].
[TPS_SWCT_01248] Nested definition of ImplementationDataType d If an Im-
plementationDataTypeElement also represents a composite data type it can ag-
gregate ImplementationDataTypeElements in the role of subElement. Again,
the type-prototype pattern does not apply in this case. c(RS_SWCT_03217)
[constr_1106] Structure shall have at least one element d An Implementation-
DataType or ImplementationDataTypeElement of category STRUCTURE shall
own at least one ImplementationDataTypeElement. c()
[constr_1107] Union shall have at least one element d An Implementation-
DataType or ImplementationDataTypeElement of category UNION shall own
at least one ImplementationDataTypeElement. c()
Class ImplementationDataTypeElement
Package M2::AUTOSARTemplates::CommonStructure::ImplementationDataTypes
Note Declares a data object which is locally aggregated. Such an element can only be used within the scope
where it is aggregated.
This element either consists of further subElements or it is further defined via its swDataDefProps.
There are several use cases within the system of ImplementationDataTypes fur such a local declaration:
• It can represent the elements of an array, defining the element type and array size
• It can represent an element of a struct, defining its type
• It can be the local declaration of a debug element.
Base ARObject, AbstractImplementationDataTypeElement, AtpClassifier , AtpFeature, AtpStructureElement,
Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mul. Kind Note
arraySize PositiveInteger 0..1 attr The existence of this attributes (if bigger than 0) defines
the size of an array and declares that this Implementation
DataTypeElement represents the type of each single
array element.
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime
arraySize ArraySizeHandling 0..1 attr The way how the size of the array is handled in case of a
Handling Enum variable size array.
5

274 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4
Class ImplementationDataTypeElement
arraySize ArraySizeSemantics 0..1 attr This attribute controls the meaning of the value of the
Semantics Enum array size.
isOptional Boolean 0..1 attr This attribute represents the ability to declare the
enclosing ImplementationDataTypeElement as optional.
This means that, at runtime, the ImplementationDataType
Element may or may not have a valid value and shall
therefore be ignored.
The underlying runtime software provides means to set
the CppImplementationDataTypeElement as not valid at
the sending end of a communication and determine its
validity at the receiving end.
Tags: atp.Status=draft
subElement (or- ImplementationData * aggr Element of an array, struct, or union in case of a nested
dered) TypeElement declaration (i.e. without using "typedefs").
The aggregation of ImplementionDataTypeElement is
subject to variability with the purpose to support the
conditional existence of elements inside a Implementation
DataType representing a structure.
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime
swDataDef SwDataDefProps 0..1 aggr The properties of this ImplementationDataTypeElement.
Props

Table 5.19: ImplementationDataTypeElement

[TPS_SWCT_01254] ImplementationDataType with array semantics d Of

course, it is also possible to define an ImplementationDataType that provides array
semantics. c(RS_SWCT_03217)
[TPS_SWCT_01006] ImplementationDataType.subElement.arraySize shall
be used to define the size of the array d The primitive attribute Implementation-
DataType.subElement.arraySize shall be used to define the size of the array. c
()
[TPS_SWCT_01007] Semantics of array index d For an Implementation-
DataType that implements an array data type, the semantics of the array index is
such that
• it shall start with the value 0
• it shall run to the value of arraySize -1
c()
[constr_1105] Value of arraySize d The value of the attribute arraySize of an
ImplementationDataTypeElement owned by an ImplementationDataType or
ImplementationDataTypeElement of category ARRAY shall be greater than 0
unless attribute ImplementationDataTypeElement.arraySizeHandling exists
and is set to the value inheritedFromArrayElementTypeSize. c()

275 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[TPS_SWCT_01478] Array size is defined as an attribute of the Implementa-

tionDataTypeElement d Please note that the array size is not defined as an at-
tribute of the ImplementationDataType which stands for the whole array. It is ac-
tually defined as an attribute of the ImplementationDataTypeElement which is
describing the array element (note that the same pattern is used in ApplicationAr-
rayDataType). c()
Consequently, if a “struct” element represents an array this specific struct-element is
given by an ImplementationDataTypeElement of category ARRAY which in turn
aggregates another ImplementationDataTypeElement of e.g. category VALUE
representing the array element and containing the size.
[TPS_SWCT_01255] Indicate whether the array is supposed to have a fixed size
or whether the actual size might change during run-time d It is also possible to
indicate whether the array is supposed to have a fixed size or whether the actual size
might change during run-time. c(RS_SWCT_03217)
In the same way as for ApplicationDataTypes, it is also possible to specific a Size
Indicator of a variable size array which holds the number of valid elements of the
array in the ImplementationDataType.
Please find more information about this topic in section 5.2.4.2.
[TPS_SWCT_01622] Modeling of a Variable-Size Array Data Type only
with ImplementationDataType d The modeling of a Variable-Size Ar-
ray Data Type does not require the existence of an ApplicationComposite-
DataType and a DataTypeMap. A Variable-Size Array Data Type can be
created by just setting up an ImplementationDataType. c(RS_SWCT_03181)
[TPS_SWCT_01610] Modeling of a Variable-Size Array Data Type with
Size Indicator enabled d An ImplementationDataType with category
STRUCTURE where the attribute ImplementationDataType.dynamicArray-
SizeProfile exists represents a Variable-Size Array Data Type with Size
Indicator enabled.
For the sake of a proper definition of terminology, this ImplementationDataType shall
be called the VSA ImplementationDataType. c(RS_SWCT_03181)
[TPS_SWCT_01650] Structure of the VSA ImplementationDataType d The VSA
ImplementationDataType shall consist of
• an ImplementationDataTypeElement representing the Size Indicator
and
• an ImplementationDataTypeElement representing the Payload of the
Variable-Size Array Data Type.
For the sake of a proper definition of terminology, these ImplementationDataType-
Elements shall be called the VSA Size Indicator ImplementationDataType-
Element and the VSA Payload ImplementationDataTypeElement respectively.
c(RS_SWCT_03181)

276 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[TPS_SWCT_01612] arraySizeHandling specifies how the size is determined

d arraySizeHandling specifies how the size is determined in case of multi-
dimensional variable size array. c(RS_SWCT_03181)
The statement made by [TPS_SWCT_01612] allows the specification of coherency
between the sizes of the nested variable size arrays in case of multiple dimensions.
[TPS_SWCT_01613] Internal structure of mapped ImplementationDataType d
The attribute dynamicArraySizeProfile specifies which internal structure the Im-
plementationDataType shall follow. c(RS_SWCT_03181)
[TPS_SWCT_01614] Profiles for internal structure of mapped Implementation-
DataType d For the structure of the ImplementationDataType the following pro-
files are defined for dynamicArraySizeProfile: VSA_LINEAR, VSA_SQUARE,
VSA_RECTANGULAR and VSA_FULLY_FLEXIBLE. c(RS_SWCT_03181)
[TPS_SWCT_01615] Custom profiles for internal structure of mapped Implemen-
tationDataType d Custom profiles can be added to dynamicArraySizeProfile.
They shall have a company-specific prefix. c(RS_SWCT_03181)
For reasons of readability and comprehensibility the following constraints focus on the
payload of the Variable-Size Array Data Type only. For the Size Indica-
tor additional individual constraints do apply.
[constr_1318] Profile VSA_LINEAR for ImplementationDataType d If the value
of attribute ImplementationDataType.dynamicArraySizeProfile is set to
VSA_LINEAR, the ImplementationDataType shall aggregate a VSA Payload Im-
plementationDataTypeElement that fulfills all of the following conditions:
• The attribute ImplementationDataTypeElement.arraySizeSemantics
shall not be defined.
• The attribute ImplementationDataTypeElement.category shall be set to
ARRAY.
• The attribute ImplementationDataTypeElement.arraySize shall not be
defined.
• The attribute ImplementationDataTypeElement.arraySizeHandling
shall not be defined.
The VSA Payload ImplementationDataTypeElement shall immediately aggre-
gate another ImplementationDataTypeElement that shall fulfill all of the following
conditions:
• The attribute ImplementationDataTypeElement.arraySizeSemantics
shall be set to the value variableSize.
• The attribute ImplementationDataTypeElement.arraySize shall be de-
fined.

277 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

• The attribute ImplementationDataTypeElement.arraySizeHandling

shall be set to the value allIndicesSameArraySize.
c()
Please note that the ImplementationDataTypeElement aggregated by the VSA
Payload ImplementationDataTypeElement can basically have any possible
value of the attribute category.
[constr_1319] Profile VSA_SQUARE for ImplementationDataType d If the value
of attribute ImplementationDataType.dynamicArraySizeProfile is set to
VSA_SQUARE, the ImplementationDataType shall aggregate a VSA Payload Im-
plementationDataTypeElement that fulfills all of the the following conditions:
• The attribute ImplementationDataTypeElement.arraySizeSemantics
shall not be defined.
• The attribute ImplementationDataTypeElement.category shall be set to
the value ARRAY.
• The attribute ImplementationDataTypeElement.arraySize shall not be
defined.
• The attribute ImplementationDataTypeElement.arraySizeHandling
shall not be defined.
The VSA Payload ImplementationDataTypeElement shall immediately aggre-
gate another ImplementationDataTypeElement (representing the first dimension)
that shall fulfill all of the following conditions:
• The attribute ImplementationDataTypeElement.arraySizeSemantics
shall be set to the value variableSize.
• The attribute ImplementationDataTypeElement.category shall be set to
the value ARRAY.
• The attribute ImplementationDataTypeElement.arraySize shall not be
defined.
• The attribute ImplementationDataTypeElement.arraySizeHandling
shall be set to the value inheritedFromArrayElementTypeSize.
All intermediate ImplementationDataTypeElements in the aggregation chain
that do not terminate the chain shall fulfill all of the following conditions:
• The attribute ImplementationDataTypeElement.arraySizeSemantics
shall be set to the value variableSize.
• The attribute ImplementationDataTypeElement.category shall be set to
the value ARRAY.
• The attribute ImplementationDataTypeElement.arraySize shall not be
defined.

278 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

• The attribute ImplementationDataTypeElement.arraySizeHandling

shall be set to the value inheritedFromArrayElementTypeSize.
The terminating ImplementationDataTypeElement in the aggregation chain shall
fulfill all of the following conditions:
• The attribute ImplementationDataTypeElement.arraySizeSemantics
shall be set to the value variableSize.
• The attribute ImplementationDataTypeElement.arraySize shall be de-
fined.
• The attribute ImplementationDataTypeElement.arraySizeHandling
shall be set to the value allIndicesSameArraySize.
c()
[constr_1320] Profile VSA_RECTANGULAR for ImplementationDataType d If the
value of attribute ImplementationDataType.dynamicArraySizeProfile is set
to VSA_RECTANGULAR, the ImplementationDataType shall aggregate a VSA
Payload ImplementationDataTypeElement that fulfills all of the following con-
ditions:
• The attribute ImplementationDataTypeElement.arraySizeSemantics
shall not be defined.
• The attribute ImplementationDataTypeElement.category shall be set to
the value ARRAY.
• The attribute ImplementationDataTypeElement.arraySize shall not be
defined.
• The attribute ImplementationDataTypeElement.arraySizeHandling
shall not be defined.
The VSA Payload ImplementationDataTypeElement shall immediately aggre-
gate another ImplementationDataTypeElement (representing the first dimension)
that shall fulfill all of the following conditions:
• The attribute ImplementationDataTypeElement.category shall be set to
the value ARRAY.
• The attribute ImplementationDataTypeElement.arraySizeSemantics
shall be set to the value variableSize.
• The attribute ImplementationDataTypeElement.arraySize shall be de-
fined.
• The attribute ImplementationDataTypeElement.arraySizeHandling
shall be set to the value allIndicesSameArraySize.
All intermediate ImplementationDataTypeElements in the aggregation chain
that do not terminate the chain shall fulfill all of the following conditions:

279 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

• The attribute ImplementationDataTypeElement.category shall be set to

the value ARRAY.
• The attribute ImplementationDataTypeElement.arraySizeSemantics
shall be set to the value variableSize.
• The attribute ImplementationDataTypeElement.arraySize shall be de-
fined.
• The attribute ImplementationDataTypeElement.arraySizeHandling
shall be set to the value allIndicesSameArraySize.
The terminating ImplementationDataTypeElement in the aggregation chain shall
fulfill all of the following conditions:
• The attribute ImplementationDataTypeElement.arraySizeSemantics
shall be set to the value variableSize.
• The attribute ImplementationDataTypeElement.arraySize shall be de-
fined.
• The attribute ImplementationDataTypeElement.arraySizeHandling
shall be set to the value allIndicesSameArraySize.
c()
[constr_1321] Profile VSA_FULLY_FLEXIBLE for ImplementationDataType d If
the value of attribute ImplementationDataType.dynamicArraySizeProfile is
set to the value VSA_FULLY_FLEXIBLE, the ImplementationDataType shall ag-
gregate a VSA Payload ImplementationDataTypeElement that fulfills all of the
following conditions:
• The attribute ImplementationDataTypeElement.arraySizeSemantics
shall not be defined.
• The attribute ImplementationDataTypeElement.category shall be set to
the value ARRAY.
• The attribute ImplementationDataTypeElement.arraySize shall not be
defined
• The attribute ImplementationDataTypeElement.arraySizeHandling
shall not be defined.
The VSA Payload ImplementationDataTypeElement shall immediately aggre-
gate another ImplementationDataTypeElement (representing the first dimension)
that shall fulfill all of the following conditions:
• The attribute ImplementationDataTypeElement.category shall be set to
STRUCTURE
• The attribute ImplementationDataTypeElement.arraySizeSemantics
shall be set to the value variableSize.

280 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

• The attribute ImplementationDataTypeElement.arraySize shall be de-

fined.
• The attribute ImplementationDataTypeElement.arraySizeHandling
shall be set to the value allIndicesDifferentArraySize.
The ImplementationDataTypeElement shall aggregate another Implementa-
tionDataTypeElement that fulfills the following conditions:
• The attribute ImplementationDataTypeElement.arraySizeSemantics
shall not be defined.
• The attribute ImplementationDataTypeElement.category shall be set to
the value ARRAY.
• The attribute ImplementationDataTypeElement.arraySize shall not be
defined.
• The attribute ImplementationDataTypeElement.arraySizeHandling
shall not be defined.
The aggregation chain is continued by a (possible empty) sequence of a pair of
ImplementationDataTypeElements with the following characteristics:
• The first ImplementationDataTypeElement in the pair shall fulfill all of the
following conditions:
– The attribute ImplementationDataTypeElement.category shall be
set to STRUCTURE.
– The attribute ImplementationDataTypeElement.arraySizeSeman-
tics shall be set to the value variableSize.
– The attribute ImplementationDataTypeElement.arraySize shall be
defined.
– The attribute ImplementationDataTypeElement.arraySizeHan-
dling shall be set to the value allIndicesDifferentArraySize.
• The second ImplementationDataTypeElement in the pair shall fulfill all of
the following conditions:
– The attribute ImplementationDataTypeElement.arraySizeSeman-
tics shall not be defined.
– The attribute ImplementationDataTypeElement.category shall be
set to the value ARRAY.
– The attribute ImplementationDataTypeElement.arraySize shall not
be defined.
– The attribute ImplementationDataTypeElement.arraySizeHan-
dling shall not be defined.

281 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

The terminating ImplementationDataTypeElement in the aggregation chain shall

fulfill all of the following conditions:
• The attribute ImplementationDataTypeElement.arraySizeSemantics
shall be set to the value variableSize.
• The attribute ImplementationDataTypeElement.arraySize shall be de-
fined.
• The attribute ImplementationDataTypeElement.arraySizeHandling
shall be set to the value allIndicesSameArraySize.
c()
[constr_1396] Restriction for the value of attribute category for non-terminating
ImplementationDataTypeElements taken to model a Variable-Size Array
Data Type d The value of attribute category for non-terminating Implementa-
tionDataTypeElements taken to model a Variable-Size Array Data Type
shall not be set to TYPE_REFERENCE. c()
[constr_1322] Size Indicator for undefined dynamicArraySizeProfile d If
the ImplementationDataType.dynamicArraySizeProfile does not exists but
the ImplementationDataType is mapped to an ApplicationArrayDataType
where the attribute ApplicationArrayDataType.dynamicArraySizeProfile
exists, then the ImplementationDataType shall have the category STRUCTURE,
representing a Variable-Size Array Data Type with Size Indicator en-
abled. c()
[TPS_SWCT_01617] Structure of an ImplementationDataType that represents
a variable-sized array data type d The ImplementationDataType that represents
a Variable-Size Array Data Type shall have the category STRUCTURE that
has two subElements.
The role of the subElements with the definition of a Variable-Size Array Data
Type is defined by [TPS_SWCT_01618], [TPS_SWCT_01619], [TPS_SWCT_01620],
and [TPS_SWCT_01621]. c(RS_SWCT_03181)
[TPS_SWCT_01618] Size Indicator for dynamicArraySizeProfile set to
VSA_LINEAR, VSA_SQUARE, or VSA_FULLY_FLEXIBLE d If an Implementa-
tionDataType is mapped to an ApplicationArrayDataType which has at-
tribute dynamicArraySizeProfile set to the value VSA_LINEAR, VSA_SQUARE
or VSA_FULLY_FLEXIBLE, the first ImplementationDataType.subElement shall
be an integer large enough to hold the maximum number of valid elements of the vari-
able size array (according to maxNumberOfElements).
This is the Size Indicator which holds the current number of valid elements of the
variable size array. c(RS_SWCT_03181)

282 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[TPS_SWCT_01647] Size Indicator for dynamicArraySizeProfile set to

VSA_LINEAR, VSA_SQUARE, or VSA_FULLY_FLEXIBLE if only Implementation-
DataType is present d For each ImplementationDataType which has at-
tribute dynamicArraySizeProfile set to the value VSA_LINEAR, VSA_SQUARE, or
VSA_FULLY_FLEXIBLE, the first ImplementationDataType.subElement shall be
an integer large enough to hold the maximum number of valid elements of the variable
size array (according to arraySize).
This is the Size Indicator which holds the current number of valid elements of the
Variable-Size Array Data Type. c(RS_SWCT_03181)
[TPS_SWCT_01619] Size Indicator for dynamicArraySizeProfile set to
VSA_RECTANGULAR d If an ImplementationDataType is mapped to an Applica-
tionArrayDataType where the attribute ApplicationArrayDataType.dynami-
cArraySizeProfile exists and is set to the value VSA_RECTANGULAR, the first
ImplementationDataType.subElement shall be a ImplementationDataType-
Element with the category set to ARRAY and the attribute arraySize set to a value
equal to the number of the according dimension of the corresponding Application-
DataType. c(RS_SWCT_03181)
[TPS_SWCT_01648] Size Indicator for dynamicArraySizeProfile set to
VSA_RECTANGULAR if only ImplementationDataType is present d For each
ImplementationDataType where the attribute ImplementationDataType.dy-
namicArraySizeProfile exists and is set to the value VSA_RECTANGULAR,
the first ImplementationDataType.subElement shall be a Implementation-
DataTypeElement with the category set to ARRAY and the attribute arraySize
set to a value equal to the size of the according dimension of the rectangular array. c
(RS_SWCT_03181)
[TPS_SWCT_01620] Size Indicator for dynamicArraySizeProfile set to
VSA_RECTANGULAR d The elements of this Size Indicator array shall consist of
integers large enough to hold the maximum number of valid elements (according to
maxNumberOfElements). c(RS_SWCT_03181)
This array holds the Size Indicators of all dimensions.
[TPS_SWCT_01621] Payload for dynamicArraySizeProfile d If an Imple-
mentationDataType is mapped to an ApplicationArrayDataType where
the attribute dynamicArraySizeProfile exists, the second Implementation-
DataType.subElement shall be an array which can hold the data of the variable size
array with all dimensions defined for the ApplicationDataType.
The category shall be set to ARRAY and arraySize shall be set to
maxNumberOfElements of the corresponding ApplicationArrayDataType. c
(RS_SWCT_03181)
[TPS_SWCT_01649] Payload for dynamicArraySizeProfile if only Implemen-
tationDataType is present d Each ImplementationDataType where the at-
tribute dynamicArraySizeProfile exists shall aggregate a second Implementa-
tionDataType.subElement with the category set to ARRAY. c(RS_SWCT_03181)

283 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

For examples, see Appendix E.1.

An ImplementationDataType is also allowed to have SwDataDefProps (this fea-
ture is inherited from AutosarDataType), i.e. it can define various specific structural
and semantical attributes. Table 5.39 shows which SwDataDefProps will be typically
used here.
[TPS_SWCT_01257] ImplementationDataType or the aggregated Implemen-
tationDataTypeElements do not form closed sets d An Implementation-
DataType or the aggregated ImplementationDataTypeElements do not form
closed sets but refer to further type definitions in one of four distinctive ways, depend-
ing on whether the type is implemented via a base type, a data or function pointer, or
a reference to another implementation data type:
1. Reference to an underlying SwBaseType corresponds to category VALUE.
2. Reference to BswModuleEntry in SwPointerTargetProps corresponds to
category FUNCTION_REFERENCE.
3. SwDataDefProps in SwPointerTargetProps corresponds to category
DATA_REFERENCE.
4. Reference to another ImplementationDataType corresponds to category
TYPE_REFERENCE.
c(RS_SWCT_03217)
At the end, all the “leafs” of the complete tree formed by these references shall end up
in SwBaseTypes. Figures 5.15, 5.16, and Figure 5.17 illustrate more examples about
Typedefs and references.

284 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

   
 
   


MySimpleType: MyPointerType:
ImplementationDataType ImplementationDataType

category = VALUE category = DATA_REFERENCE

:SwDataDefProps

:SwPointerTargetProps

targetCategory = TYPE_REFERENCE

:SwDataDefProps :SwDataDefProps

uint16: SwBaseType

category = FIXED_LENGTH

:BaseTypeDirectDefinition

baseTypeEncoding = NONE
nativeDeclaration = unsigned short

Figure 5.15: Example (1) for TypeDefs

[TPS_SWCT_01258] Definition of a pointer to data d The definition of a data pointer

requires a special meta-class SwPointerTargetProps which aggregates another
SwDataDefProps. This mechanism allows to describe the category and properties
of the pointer object itself as well as the category and properties of its target data
type. c(RS_SWCT_03217)
[constr_1177] Allowed targetCategory for SwPointerTargetProps d The
value of targetCategory for SwPointerTargetProps can only be one of
TYPE_REFERENCE or FUNCTION_REFERENCE. The only exception from this rule ap-
plies if the swDataDefProps owned by the SwPointerTargetProps refers to a
SwBaseType with native type declaration void, in this case the value VALUE is also
permitted. c()

285 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

 

  



 

 
 



MyStructType: ImplementationDataType

category = STRUCTURE

C1:: ImplementationDataTypeElement C2: ImplementationDataTypeElement

category = VALUE category = TYPE_REFERENCE

:SwDataDefProps :SwDataDefProps

uint16: SwBaseType OtherStructType: ImplementationDataType

category = FIXED_LENGTH category = STRUCTURE

:BaseTypeDirectDefinition

baseTypeEncoding = NONE
nativeDeclaration = unsigned short

Figure 5.16: Example (2) for TypeDefs

As far as the AUTOSAR meta-model is concerned, a pointer to a pointer could in

principle be implemented in two ways:
1. by defining an ImplementationDataType of category DATA_REFERENCE
that aggregates SwDataDefProps in the role swDataDefProps that in turn
aggregate SwPointerTargetProps in the role swPointerTargetProps
with attribute targetCategory set to TYPE_REFERENCE that aggregates Sw-
DataDefProps in the role swDataDefProps that references an Implementa-
tionDataType of category DATA_REFERENCE.
2. by defining an ImplementationDataType of category DATA_REFERENCE
that aggregates SwDataDefProps in the role swDataDefProps that in turn ag-
gregate SwPointerTargetProps in the role swPointerTargetProps with
attribute targetCategory set to DATA_REFERENCE (which is not allowed
according to [constr_1177]) that in turn aggregates SwDataDefProps in the
role swDataDefProps that aggregates SwPointerTargetProps in the role
swPointerTargetProps that references an ImplementationDataType of
category e.g. VALUE.

286 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[constr_1254] Definition of a pointer to a pointer d AUTOSAR does not support

the definition of a pointer to a pointer by defining an ImplementationDataType
of category DATA_REFERENCE that aggregates SwDataDefProps in the role sw-
DataDefProps that in turn aggregate SwPointerTargetProps in the role sw-
PointerTargetProps with attribute targetCategory set to DATA_REFERENCE
that in turn aggregates SwDataDefProps in the role swDataDefProps that ag-
gregates SwPointerTargetProps in the role swPointerTargetProps that ref-
erences an ImplementationDataType of category e.g. VALUE. c()
For clarification, The AUTOSAR RTE does not support a definition of a pointer to a
pointer by way of option 2 anyway. For all intents and purposes, [constr_1254] merely
reflects this restriction on the level of AUTOSAR models. Option 1 (which is also fea-
tured in Figure 5.17) is the only viable way that is positively supported by the AUTOSAR
RTE [2].

 
  
  

   


Foo: ImplementationDataType Foo: ImplementationDataType Foo: ImplementationDataType

category = DATA_REFERENCE category = DATA_REFERENCE category = DATA_REFERENCE

:SwDataDefProps :SwDataDefProps :SwDataDefProps

swImplPolicy = const swImplPolicy = const

:SwPointerTargetProps :SwPointerTargetProps :SwPointerTargetProps

targetCategory = VALUE targetCategory = VALUE targetCategory = TYPE_REFERENCE

:SwDataDefProps :SwDataDefProps :SwDataDefProps

swImplPolicy = const

VOID: SwBaseType VOID: SwBaseType bar: ImplementationDataType

category = FIXED_LENGTH category = FIXED_LENGTH category = DATA_REFERENCE

:BaseTypeDirectDefinition :BaseTypeDirectDefinition

baseTypeEncoding = VOID baseTypeEncoding = VOID

nativeDeclaration = void nativeDeclaration = void

Figure 5.17: Example (3) for TypeDefs

[TPS_SWCT_01259] Definition of a pointer to a function d An Implementation-

DataType or one of its sub-elements can also describe a function pointer. This com-
pletes its ability to declare all kinds of local data and of possible arguments used in
library calls.

287 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

A function pointer is defined by the category FUNCTION_REFERENCE and the as-

sociation SwPointerTargetProps.functionPointerSignature that refers to a
BswModuleEntry. The latter essentially describes the signature of a function as ex-
plained in [6]. c(RS_SWCT_03217)
Class SwPointerTargetProps
Package M2::MSR::DataDictionary::DataDefProperties
Note This element defines, that the data object (which is specified by the aggregating element) contains a
reference to another data object or to a function in the CPU code. This corresponds to a pointer in the
C-language.
The attributes of this element describe the category and the detailed properties of the target which is
either a data description or a function signature.
Base ARObject
Attribute Type Mul. Kind Note
functionPointer BswModuleEntry 0..1 ref The referenced BswModuleEntry serves as the signature
Signature of a function pointer definition. Primary use case: function
pointer passed as argument to other function.
Tags: xml.sequenceOffset=40
swDataDef SwDataDefProps 0..1 aggr The properties of the target data type.
Props
Tags: xml.sequenceOffset=30
targetCategory Identifier 0..1 attr This specifies the category of the target:
• In case of a data pointer, it shall specify the
category of the referenced data.
• In case of a function pointer, it could be used to
denote the category of the referenced Bsw
ModuleEntry. Since currently no categories for
BswModuleEntry are defined it will be empty.
Tags: xml.sequenceOffset=5

Table 5.20: SwPointerTargetProps

The allowed existence and multiplicity of all the attributes of SwDataDefProps and
other properties depend on the category of the ImplementationDataType.

288 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

ARElement
AtpType
AutosarDataType

AtpBlueprint
AtpBlueprintable
AbstractImplementationDataType

0..1 +implementationDataType

  
   
  ImplementationDataType

+ dynamicArraySizeProfile: String [0..1]

+ isStructWithOptionalElement: Boolean [0..1]
+ typeEmitter: NameToken [0..1]
«atpVariation»

«atpVariation» «atpSplitable»
+subElement 0..*
0..* {ordered} +subElement {ordered} +symbolProps 0..1

AbstractImplementationDataTypeElement ImplementationProps
ImplementationDataTypeElement SymbolProps

+ arraySizeHandling: ArraySizeHandlingEnum [0..1]

+ arraySizeSemantics: ArraySizeSemanticsEnum [0..1]
+ isOptional: Boolean [0..1]
«atpVariation»
+ arraySize: PositiveInteger [0..1]

+swDataDefProps 0..1 +swDataDefProps 0..1

ARElement «atpVariation»
AtpBlueprint +swAddrMethod SwDataDefProps
AtpBlueprintable
SwAddrMethod 0..1 + additionalNativeTypeQualifier: NativeDeclarationString [0..1]
+ displayFormat: DisplayFormatString [0..1]
+ displayPresentation: DisplayPresentationEnum [0..1]
+ stepSize: Float [0..1]
+ swAlignment: AlignmentType [0..1]
+ swCalibrationAccess: SwCalibrationAccessEnum [0..1]
SwBitRepresentation +swBitRepresentation + swImplPolicy: SwImplPolicyEnum [0..1]
+ swIntendedResolution: Numerical [0..1]
+ bitPosition: Integer [0..1] 0..1 + swInterpolationMethod: Identifier [0..1]
+ numberOfBits: Integer [0..1]
+ swIsVirtual: Boolean [0..1]
«atpVariation»
+ swValueBlockSize: Numerical [0..1]
+ swValueBlockSizeMult: Numerical [0..*] {ordered}
AtpBlueprint
AtpBlueprintable +baseType
BaseType
0..1
SwBaseType

0..1 +swDataDefProps

+swPointerTargetProps 0..1
ARElement
SwPointerTargetProps
AtpBlueprint
+functionPointerSignature
AtpBlueprintable + targetCategory: Identifier [0..1]
BswModuleEntry 0..1
A

Figure 5.18: SwDataDefProps used in the context of ImplementationDataType

[constr_1178] Existence of attributes of SwDataDefProps in the context of Im-

plementationDataType d For the sake of removing possible sources of ambiguity,
SwDataDefProps used in the context of ImplementationDataType can only have
one of

289 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

• baseType
• swPointerTargetProps
• implementationDataType
c()
Please note that an ImplementationDataType manifests itself in the source code
of an RTE into which a DataPrototype typed by the ImplementationDataType
is deployed. This implies potential naming conflicts if ImplementationDataTypes
that have identical shortNames are deployed into a specific RTE.
[TPS_SWCT_01194] Symbolic name of an ImplementationDataType d To mit-
igate this potential hazard it is possible to provide the ImplementationDataType
along with an accompanying symbolic name that can be used for resolving the name
clash. The symbolic name is provided by means of the attribute symbol of the
meta-class SymbolProps owned by ImplementationDataType in the role sym-
bolProps. c()
For more information about symbolProps, please refer to Figure 5.14.
[TPS_SWCT_01441] Nature of a TYPE_REFERENCE d A type reference (formally rep-
resented by an ImplementationDataType of category TYPE_REFERENCE) imple-
ments a redirection to common ImplementationDataTypes. c()
[TPS_SWCT_01442] ImplementationDataType of category TYPE_REFERENCE
does not define own properties d As long as an ImplementationDataType of
category TYPE_REFERENCE does not define own properties the properties of the
refined ImplementationDataType apply. c()
[TPS_SWCT_01443] ImplementationDataType of category TYPE_REFERENCE
overwrites properties of refined ImplementationDataType d If an implementa-
tion data types of category TYPE_REFERENCE defines own properties (e.g. Com-
puMethod) this properties overwrite the properties of the refined Implementation-
DataType. c()
As explained by [constr_1050], Compatibility checks of ImplementationDataType
require a prior resolution of possible type references, i.e. the compatibility shall be
checked on the resolved ImplementationDataType.
Referrable
ImplementationProps

+ symbol: CIdentifier

BswSchedulerNamePrefix SectionNamePrefix SymbolProps SymbolicNameProps

Figure 5.19: ImplementationProps and its subclasses

290 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Class ImplementationProps (abstract)

Package M2::AUTOSARTemplates::CommonStructure::Implementation
Note Defines a symbol to be used as (depending on the concrete case) either a complete replacement or a
prefix when generating code artifacts.
Base ARObject, Referrable
Subclasses BswSchedulerNamePrefix, ExecutableEntityActivationReason, SectionNamePrefix, SymbolProps,
SymbolicNameProps
Attribute Type Mul. Kind Note
symbol CIdentifier 1 attr The symbol to be used as (depending on the concrete
case) either a complete replacement or a prefix.

Table 5.21: ImplementationProps

Class SymbolProps
Package M2::AUTOSARTemplates::SWComponentTemplate::Components
Note This meta-class represents the ability to attach with the symbol attribute a symbolic name that is conform
to C language requirements to another meta-class, e.g. AtomicSwComponentType, that is a potential
subject to a name clash on the level of RTE source code.
Base ARObject, ImplementationProps, Referrable
Attribute Type Mul. Kind Note
– – – – –
Table 5.22: SymbolProps

[TPS_SWCT_01759] Use cases for unions d There are different use cases for the
definition of a union data type:
1. The DataPrototypes derived from the union data type shall be transported
over a communication network. For this purpose, it is necessary to apply a
special modeling in the form of a wrapped union data type, as explained by
[TPS_SWCT_01700].
2. The DataPrototypes created from the union data type are used internally
within the same ECU, e.g. as a PerInstanceMemory, romBlock, or ram-
Block. In this case the modeling of the union data type does not depend on
specific constraints.
c()
In summary, there are cases where unions can be used in PortInterfaces, but
these are restricted to the fulfillment of certain conditions that are explained in [con-
str_1607].
[constr_1607] Only Wrapped Union Data Types in PortInterface d Within the
scope of a PortInterface the usage of a Union data type is only supported
• for Wrapped Union Data Types.
• for a PortInterface that is used to type a PortPrototype that does not
appear as a context in an instanceRef owned by a DataMapping. See also
[1441].

291 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

c()

5.2.5.1 Modeling of Optional Element Structure with ImplementationDataType

Please note that the content of this chapter has draft character
The definition of an ImplementationDataType that represents an Optional El-
ement Structure shall not only rely on the existence of optional elements.
Also the definition of the enclosing ImplementationDataType shall clearly signal
the intention by means of the dedicated attribute ImplementationDataType.is-
StructWithOptionalElement.
[TPS_SWCT_01772]{DRAFT} Semantics of attribute Implementation-
DataType.isStructWithOptionalElement d If attribute Implementation-
DataType.isStructWithOptionalElement is set to True then the Implemen-
tationDataType advertises the intention to represent an Optional Element
Structure such that the fulfillment of structural requirements for the existence of
optional elements can be formally checked.
Again, this attribute represents a formal specification that optionality is intended as
opposed to an ImplementationDataType that fulfills the structural requirements
out of different motivations. c(RS_SWCT_03320)
[TPS_SWCT_01773]{DRAFT} Definition of Optional Element Structure on
the level of ImplementationDataType d The modeling approach for the definition
of an Optional Element Structure on the level of ImplementationDataType
is to set the attribute ImplementationDataTypeElement.isOptional to the value
True.
If the attribute is not set or set to the value False then the respective Implementa-
tionDataTypeElement shall be considered mandatory. c(RS_SWCT_03320)
[constr_1637]{DRAFT} Existence of ImplementationDataTypeElement.isOp-
tional vs. ImplementationDataType.isStructWithOptionalElement d If
one ImplementationDataType.subElement sets attribute isOptional to the
value True then the enclosing ImplementationDataType shall also set attribute
isStructWithOptionalElement to True. c()
In order to be able to generate a proper RTE API for the access to optional elements of
data types in general it is necessary to impose structural requirements on the definition
of ImplementationDataType.
In particular, it is necessary at runtime to store the information about the availability
of a specific ImplementationDataTypeElement where attribute isOptional has
been set to the value True in the context of an ImplementationDataType of cat-
egory STRUCTURE.

292 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

An ImplementationDataType that represents an Optional Element Struc-

ture shall contain a special element which represents an availability bitfield.
This bitfield is implemented as an array of uint8 and shall hold one bit for each optional
element contained in the structured data type.
In particular, the applicable structural requirements for an Implementation-
DataType that represents an Optional Element Structure are described in the
following specification items.
[TPS_SWCT_01774]{DRAFT} Modeling of ImplementationDataType with op-
tional elements d
The following approach shall be taken to model an ImplementationDataType that
represents an Optional Element Structure:
• The first ImplementationDataTypeElement of Implementation-
DataType where attribute isStructWithOptionalElement is set to
True shall have the shortName availabilityBitfield. [constr_1638]
applies.
• This ImplementationDataTypeElement shall be of category ARRAY
• The ImplementationDataTypeElement shall set attribute arraySizeSe-
mantics to the value fixedSize.
• The ImplementationDataTypeElement shall aggregate a further Imple-
mentationDataTypeElement in the role subElement for which the following
requirements apply:
– The ImplementationDataTypeElement shall be of category
TYPE_REFERENCE that eventually refers to an Implementation-
DataType that - one way or the other - implements an array of unsigned
bytes, e.g. take the Platform Data Type named uint8 as the element
type11 .
– The ImplementationDataTypeElement shall set the value of attribute
arraySize to max(1,ceil(numberOfOptionalElements / 8)).
c(RS_SWCT_03320)
[constr_1638]{DRAFT} First ImplementationDataTypeElement of Implemen-
tationDataType that represents an Optional Element Structure d The first
ImplementationDataTypeElement of ImplementationDataType that repre-
sents an Optional Element Structure, i.e. the availabilityBitfield ac-
cording to [TPS_SWCT_01774], shall not set attribute isOptional to True. c()
A further structural requirement applies.
11
this relation could be expressed in a more formal way. But it would be a very expansive formal way
in an already complicated specification item. It is assumed that it is sufficient to convey the general idea.

293 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[constr_1639]{DRAFT} ImplementationDataTypeElement with attribute

isOptional set to True d ImplementationDataTypeElement with attribute
isOptional set to True shall not be of category STRUCTURE. c()
Instead, nested structures shall be created by modeling Implementation-
DataTypeElements of category TYPE_REFERENCE that in turn refer to Imple-
mentationDataTypes of category STRUCTURE.
Rationale: the existence of [constr_1639] simplifies the concept of the availability bit-
field.
The bitfield shall only contain information of the availability of the direct child elements
and not of elements of sub-structures.
By using the category TYPE_REFERENCE it is assured that a separate Implemen-
tationDataType of category STRUCTURE is generated for the sub-structure.
Since the AUTOSAR RTE provides the APIs to access the availability information on
the basis of an ImplementationDataType of category STRUCTURE the usage of
anonymous structures with optional elements is not possible.

5.2.6 Base Type

[TPS_SWCT_01260] SwBaseType d BaseType is used to specify the basic data type

level. AUTOSAR uses the meta-class SwBaseType which is derived from the abstract
class BaseType due to other use cases for BaseType in ASAM HDO. c()
[TPS_SWCT_01261] Use case for SwBaseType d One use case for SwBaseType is
to serve as input for the RTE generator. It will always appear at the “leaves” of data
the types definitions which are relevant for RTE generation. It is used to generate
the corresponding C-code typedefs in case the attribute BaseTypeDirectDefini-
tion.nativeDeclaration exists. c()
[constr_1010] If nativeDeclaration does not exist d If nativeDeclaration
does not exist in the SwBaseType it is required that the shortName (e.g. “uint8”)
of the corresponding ImplementationDataType is equal to a name of one of the
Platform or Standard Types predefined in AUTOSAR code. c()
The consequence of [constr_1010] is that if the nativeDeclaration does not exist
the RTE generator will not consider the ImplementationDataType for the genera-
tion of data type definitions.
Still, the compiler will positively be able to resolve the data type because it can fall back
to the data type definitions contained in the header file for platform and standard data
types that has to be included by regulation of the AUTOSAR standard.

294 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Please note that nativeDeclaration shall yield a valid C data type symbol, whether
this is done by a typedef or a by using the symbol12 of an integral data type is princi-
pally all the same.
Of course, using the symbol of an integral data type as the value of nativeDeclara-
tion increases the odds that the enclosing SwBaseType can be used independently
of the availability of the definition of a typedef that may or may not be available in a
given context.
[TPS_SWCT_01563] Applicable values for nativeDeclaration d For the purpose
of avoiding portability issues the value nativeDeclaration should only consist of
the symbol of an integral C data type. c()
For more information on this refer to [22].
[TPS_SWCT_01263] Further use cases for SwBaseType d Within the basic software
description, SwBaseType can be used (together with ImplementationDataTypes)
for documentation or to specify variables for debugging. Furthermore, SwBaseTypes
are required in the generation of support data for measurement and calibration tools.
Please refer to [6] for details on these use cases. c()
A more detailed description of BaseTypes can also be found in ASAM MCD 2 Harmo-
nized Data Objects.13
Class BaseType (abstract)
Package M2::MSR::AsamHdo::BaseTypes
Note This abstract meta-class represents the ability to specify a platform dependant base type.
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Subclasses SwBaseType
Attribute Type Mul. Kind Note
baseType BaseTypeDefinition 1 aggr This is the actual definition of the base type.
Definition
Tags: xml.roleElement=false
xml.roleWrapperElement=false
xml.sequenceOffset=20
xml.typeElement=false
xml.typeWrapperElement=false

Table 5.23: BaseType

12
The symbol does not necessarily have to consist of a single token, i.e. for all intents and purposes
(for example) unsigned char is also considered the symbol of an integral C data type.
13
The definition of Harmonized Data Objects can be retrieved from ASAM at www.asam.net. Access
is limited to ASAM members.

295 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Class SwBaseType
Package M2::MSR::AsamHdo::BaseTypes
Note This meta-class represents a base type used within ECU software.
Tags: atp.recommendedPackage=BaseTypes
Base ARElement, ARObject, AtpBlueprint, AtpBlueprintable, BaseType, CollectableElement, Identifiable,
MultilanguageReferrable, PackageableElement, Referrable
Attribute Type Mul. Kind Note
– – – – –
Table 5.24: SwBaseType

Class BaseTypeDefinition (abstract)

Package M2::MSR::AsamHdo::BaseTypes
Note This meta-class represents the ability to define a basetype.
Base ARObject
Subclasses BaseTypeDirectDefinition
Attribute Type Mul. Kind Note
– – – – –
Table 5.25: BaseTypeDefinition

Class BaseTypeDirectDefinition
Package M2::MSR::AsamHdo::BaseTypes
Note This BaseType is defined directly (as opposite to a derived BaseType)
Base ARObject, BaseTypeDefinition
Attribute Type Mul. Kind Note
baseType BaseTypeEncoding 1 attr This specifies, how an object of the current BaseType is
Encoding String encoded, e.g. in an ECU within a message sequence.
Tags: xml.sequenceOffset=90
baseTypeSize PositiveInteger 0..1 attr Describes the length of the data type specified in the
container in bits.
Tags: xml.sequenceOffset=70
byteOrder ByteOrderEnum 0..1 attr This attribute specifies the byte order of the base type.
Tags: xml.sequenceOffset=110
memAlignment PositiveInteger 0..1 attr This attribute describes the alignment of the memory
object in bits. E.g. "8" specifies, that the object in
question is aligned to a byte while "32" specifies that it is
aligned four byte. If the value is set to "0" the meaning
shall be interpreted as "unspecified".
Tags: xml.sequenceOffset=100
native NativeDeclarationString 0..1 attr This attribute describes the declaration of such a base
Declaration type in the native programming language, primarily in the
Programming language C. This can then be used by a
code generator to include the necessary declarations into
a header file. For example
BaseType with

shortName: "MyUnsignedInt"
nativeDeclaration: "unsigned short"
5
5

296 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4
Class BaseTypeDirectDefinition
4
Results in

typedef unsigned short MyUnsignedInt;

If the attribute is not defined the referring Implementation
DataTypes will not be generated as a typedef by RTE.
If a nativeDeclaration type is given it shall fulfill the
characteristic given by basetypeEncoding and baseType
Size.
This is required to ensure the consistent handling and
interpretation by software components, RTE, COM and
MCM systems.
Tags: xml.sequenceOffset=120

Table 5.26: BaseTypeDirectDefinition

ARElement
BaseType

+baseTypeDefinition 1

AtpBlueprint
BaseTypeDefinition
AtpBlueprintable
SwBaseType

BaseTypeDirectDefinition

+ baseTypeEncoding: BaseTypeEncodingString
+ baseTypeSize: PositiveInteger [0..1]
+ byteOrder: ByteOrderEnum [0..1]
+ memAlignment: PositiveInteger [0..1]
+ nativeDeclaration: NativeDeclarationString [0..1]

Figure 5.20: BaseType

Some additional hints to the properties of SwBaseType:

• [constr_1011] category of SwBaseType d For the attribute SwBase-
Type.category only the values FIXED_LENGTH and VOID are supported. c
()
• [constr_1422] Value of category is VOID d If the value of the attribute
SwBaseType.category is set to VOID then the attribute baseTypeSize shall
not exist. c()
• [constr_1012] Value of category is FIXED_LENGTH d If the value of the
attribute SwBaseType.category is set to FIXED_LENGTH then the attribute
baseTypeSize shall be filled with content. c()
• [TPS_SWCT_01444] Size of SwBaseType is specified in bits d In both cases
(mentioned in [constr_1012]) the size of SwBaseType is specified in bits. c()

297 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

• The attribute baseTypeEncoding specifies how the values of the base type are
encoded.
[constr_1014] Supported value encodings for SwBaseType d The supported
values for attribute BaseTypeDirectDefinition.baseTypeEncoding are:
– 1C: One’s complement
– 2C: Two’s complement
– BCD-P: Packed Binary Coded Decimals
– BCD-UP: Unpacked Binary Coded Decimals
– DSP-FRACTIONAL: Digital Signal Processor
– SM: Sign Magnitude
– IEEE754: floating point numbers
– ISO-8859-1: single-byte coded character
– ISO-8859-2: single-byte coded character
– WINDOWS-1252: single-byte coded character
– UTF-8: UCS Transformation Format 8
– UTF-16: Character encoding for Unicode code points based on 16 bit code
units [15]
– UCS-2: Universal Character Set 2
– NONE: Unsigned Integer
– VOID: corresponds to a void in C. The encoding is not formally specified
here.
– BOOLEAN: This represents an unsigned integer to be interpreted as boolean.
The value shall be interpreted as true if the value of the unsigned integer
is 1 and it shall be interpreted as false if the value of the unsigned integer
is 0.
A CompuMethod shall be referenced by the corresponding Autosar-
DataType that implements the common sense behind the boolean concept,
i.e. define a TEXTTABLE with two CompuScales: e.g. true –> 1, false
–> 0.
c()
• [TPS_SWCT_01262] memAlignment and byteOrder are platform-specific
d The value of attributes BaseTypeDirectDefinition.memAlignment and
BaseTypeDirectDefinition.byteOrder is platform-specific and therefore
should be set only in use cases where this is really needed.
These attributes shall be considered as optional.

298 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

If a SwBaseType is platform-specific then also the ImplementationDataType

and software-component descriptions build on top of it become platform-specific.
c()
However, there are use cases for SwBaseType where this does not matter: es-
pecially the calibration support format which is generated in ECU-specific scope
(and also contains SwBaseType, see [6]) could well be platform-specific.
Further regulations apply for the case that the value UTF-16 is used for setting the
attribute BaseTypeDirectDefinition.baseTypeEncoding:
[constr_1398] Existence of attributes of BaseTypeDirectDefinition d If the
value of attribute BaseTypeDirectDefinition.baseTypeEncoding is set to UTF-
16 then the attribute BaseTypeDirectDefinition.byteOrder shall exist.
The only allowed values of BaseTypeDirectDefinition.byteOrder in this case
are mostSignificantByteFirst and mostSignificantByteLast c()
There is already predefined terminology (see [15]) existing that describes the two pos-
sible cases of byte orientation in a UTF-16-encoded string. The connection to this
terminology is defined by [TPS_SWCT_01651] and [TPS_SWCT_01652].
Enumeration ByteOrderEnum
Package M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::PrimitiveTypes
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.EnumerationValue=0
mostSignificantByte Most significant byte shall come highest address (also known as LittleEndian or as Intel-Format)
Last
Tags: atp.EnumerationValue=1
opaque For opaque data endianness conversion has to be configured to Opaque. See AUTOSAR COM
Specification for more details.
Tags: atp.EnumerationValue=2

Table 5.27: ByteOrderEnum

[TPS_SWCT_01651] UTF-16BE d If the value of attribute BaseTypeDirectDefi-

nition.baseTypeEncoding is set to UTF-16 and the attribute BaseTypeDirect-
Definition.byteOrder in this case are mostSignificantByteFirst then the
SwBaseType corresponds to the definition of UTF-16BE according to the Unicode
standard [15]. c()
[TPS_SWCT_01652] UTF-16LE d If the value of attribute BaseTypeDirectDefi-
nition.baseTypeEncoding is set to UTF-16 and the attribute BaseTypeDirect-
Definition.byteOrder in this case are mostSignificantByteLast then the
SwBaseType corresponds to the definition of UTF-16LE according to the Unicode
standard [15]. c()

299 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

A further question that needs clarification is the usage of the so-called Byte Order
Mark which allows (at run-time) for determining the actual byte order directly from the
payload of a unicode string.
As AUTOSAR has means to formally and comprehensively define the byte order of any
given DataPrototype that can hold a string at run time it is not necessary to support
a further instrument that pretty much takes care of the same purpose.
[TPS_SWCT_01653] UTF-16-encoded strings are not allowed to start with a BOM
d If the value of attribute BaseTypeDirectDefinition.baseTypeEncoding is set
to UTF-16 then the value of a DataPrototype (which is effectively representing a
string) is not allowed to start with a Byte Order Mark (BOM). c()
Please note that [TPS_SWCT_01653] removes a possible redundancy in the definition
and execution of UTF-16-encoded strings.
The redundancy is not only regarded unnecessary but also potentially dangerous be-
cause it is not possible to check whether the definition is consistent with the execution
at configuration time.
From the formal point of view, [TPS_SWCT_01653] does not represent an actual con-
straint although it is formulated as such.
However, an AUTOSAR tool would not be able to properly check the condition at con-
figuration time and therefore this rule is published as a specification item.

5.2.7 Data Type Terminology

There are uses of data types that on the one hand need a handy term (because this
kind of data type is used a lot) but on the other hand cannot easily be expressed in
simple terms of meta-model elements (like ApplicationDataType).
Therefore, it is not an option to fully describe the characteristics of these kinds of data
types precisely every time one of these is used. A definition of terminology is supposed
to associate the mentioned kinds of data types with the term under which their use shall
be paraphrased.

5.2.7.1 Primitive Type

In some cases it is necessary to constrain that applicability of data types to primitive C

data types. It would be possible to describe the characteristics of eligible Autosar-
DataTypes at every single place in an AUTOSAR specification where this specific
limitation applies.
However, this may end up in lengthy and potentially inconsistent descriptions at differ-
ent places within AUTOSAR specifications. Therefore, this chapter provides a canoni-
cal definition of a primitive data type that can be referred to from other places.

300 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[TPS_SWCT_01564] Non-recursive definition of a primitive data type d An Au-

tosarDataType is considered a primitive data type if the following conditions apply:
• it is an ApplicationPrimitiveDataType of category VALUE or BOOLEAN
• it is an ImplementationDataType of category VALUE
c()
[TPS_SWCT_01565] Recursive definition of a primitive data type d An Autosar-
DataType is considered a primitive data type if the following conditions apply:
• it is an AutosarDataType according to [TPS_SWCT_01564]
• it is an AutosarDataType of category TYPE_REFERENCE that, after all type
references have been resolved, boils down an AutosarDataType according to
[TPS_SWCT_01564].
c()

5.2.7.2 Compound Primitive Data Type

[TPS_SWCT_01179] Compound Primitive Data Type d For clarification, a “com-

pound primitive data type” is an ApplicationPrimitiveDataType of cate-
gory STRING, CURVE, MAP, CUBOID, CUBE_4, CUBE_5, COM_AXIS, RES_AXIS, and
VAL_BLK.
This implies the existence of a swRecordLayout owned by the swDataDefProps of
the ApplicationPrimitiveDataType that defines the mapping to a corresponding
ImplementationDataType.
The main characteristic of the “compound primitive data type” is that with respect to the
application data type layer its data type is considered a primitive data type but when it
comes to the implementation data type layer the type is implemented as a composite
data type according to the applicable SwRecordLayout. c(RS_SWCT_03216)
[TPS_SWCT_01486] ApplicationPrimitiveDataType of category STRING
may have invalidValue d The only kind of Compound Primitive Data Type
that is allowed to define an invalidValue is an ApplicationPrimitive-
DataType of category STRING. c(RS_SWCT_03216)
[constr_1241] Compound Primitive Data Types and invalidValue d Com-
pound Primitive Data Types that have set the value of category other than
STRING shall not define invalidValue. c()

5.2.7.3 Integral Primitive Type

The SenderReceiverToSignalMapping (see [10]) allows for the integral mapping

of a piece of data to a single SystemSignal. The specification of AUTOSAR COM

301 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[21] imposes certain requirements on the characteristics of data that apply for the inte-
gral mapping.
[TPS_SWCT_01477] Integral Primitive Types d Data types that qualify for be-
ing used in the context of a The SenderReceiverToSignalMapping shall be called
Integral Primitive Types. c(RS_SWCT_03218)
[constr_1229] category of ImplementationDataType boils down to VALUE d
An ImplementationDataType qualifies as an Integral Primitive Type if and
only if either
• its category is VALUE or TYPE_REFERENCE that eventually boils down to
VALUE or
• its category is ARRAY and it has only one subElement and one of the following
conditions applies:
– subElement.category is set to VALUE or TYPE_REFERENCE that even-
tually boils down to VALUE and the subElement refers to a SwBaseType
where baseTypeSize is set to the value 8 and the baseTypeEncoding
is set to NONE.
– subElement.category is set to TYPE_REFERENCE and the swDataDef-
Props.implementationDataType literally represents the Platform
Data Type named “uint8”.
– subElement.category is set to TYPE_REFERENCE and the attribute sw-
DataDefProps.implementationDataType.shortName is set to “uint8”
and swDataDefProps.baseType.baseTypeDefinition.nativeDec-
laration does not exist.
c()
[constr_1230] ApplicationDataType that qualifies for Integral Primitive
Type d An ApplicationDataType qualifies as an Integral Primitive Type if
and only if all of the following conditions apply:
• ApplicationDataType.category is set to BOOLEAN, VALUE, STRING, or AR-
RAY
• in the applicable scope a DataTypeMap is available that refers to the given Ap-
plicationDataType
• the found DataTypeMap refers to an ImplementationDataType that fulfills
the requirements of [constr_1229]
c()

302 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

5.2.7.4 Variable-Size Array Data Type

The definition of and further explanation regarding the term Variable-Size Array
Data Type can be found in chapter 2.8.

5.2.7.5 Wrapped Union Data Type

There are use cases for sending a DataPrototype that is effectively typed by a union
data type over a communication network. In this case, however, it is necessary to
not only send the DataPrototype itself but add an information about the applicable
member of the union as a form of “meta-data” to the transmission.
By this means the sender can identify the applicable member of the union and the
receiver can accordingly access the proper union element.
It is the nature of union data types that executable code shall symmetrically access
the union, i.e. the member that was written needs to be read, the usage of a union as a
“type converter” is heavily frowned upon (because it causes unspecified behavior from
ISO-C:90 [23] point of view) and shall be discouraged by AUTOSAR.
Thus, AUTOSAR needs to take this condition into account and define a specific mod-
eling for the handling of union data types.
[TPS_SWCT_01700] Definition of unions that can be transmitted over a commu-
nication network d If it is intended to send a data object typed by a union data type
over a communication bus then a specific modeling is required for this purpose.
• The union data type shall never be used as such, it shall always be enclosed in an
ImplementationDataType of category STRUCTURE that aggregates exactly
two ImplementationDataTypeElements:
– The first ImplementationDataTypeElement shall be used to identify
the applicable element of the actual union data type.
The shortName of this element shall be set to “memberSelector”, it shall
be of category VALUE, or of category TYPE_REFERENCE that finally
boils down to category VALUE.
Furthermore, it shall refer to a SwBaseType with attribute baseTypeEn-
coding set to NONE and attribute baseTypeSize set to the value 8, 16, or
32.
This ImplementationDataTypeElement shall be called the Member
Selector.
– The second ImplementationDataTypeElement shall be of category
UNION, it represents the actual union “payload”.
• The purpose of the Member Selector is to identify the element of the union
data type that applies for a given access to the union.

303 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

If the value of the Member Selector is set to 1 then the first subElement of
the ImplementationDataType of category UNION is applicable.
If the value of the Member Selector is set to 2 then the second subElement
is applicable and so on.
• The value of the Member Selector shall range between the value 1 and the
number of subElements of the ImplementationDataTypeElement of cat-
egory UNION. Once again, the index counting is 1-based!
• Obviously, the actual data type used to hold the Member Selector shall be
capable of storing a value that corresponds to the number of subElements of
the ImplementationDataTypeElement of category UNION.
• Constraint [constr_1441] applies.
c(RS_SWCT_03217)
[TPS_SWCT_01701] Wrapped Union Data Type d Data types that fulfill the require-
ments of [TPS_SWCT_01700] shall be called Wrapped Union Data Types. c
(RS_SWCT_03217)
[constr_1442] category TYPE_REFERENCE shall not be used for modeling the
“payload” of a Wrapped Union Data Type d For the modeling of the “payload”
part of a Wrapped Union Data Type it shall not be possible to use an Implemen-
tationDataTypeElement of category TYPE_REFERENCE that finally (i.e. after all
possible indirections are resolved) boils down to category UNION. c()
The definition of the Wrapped Union Data Type represents the canonical way of
how union data types shall be used in AUTOSAR on the application and communication
level. Consequentially, the usage of the category value UNION is effectively limited
to an ImplementationDataTypeElement.
[constr_1444] Limited applicability of Wrapped Union Data Type d There is
no support for the usage of Wrapped Union Data Type in PortInterfaceMap-
pings, and Diagnostics. c()
In response to existing constraints that are out of the control of AUTOSAR, the initial-
ization of a Wrapped Union Data Type is somehow complicated.
C90 [23], which is the standard language basis for AUTOSAR (see [RS_Main_00220]),
allows only for the initialization of the first member of a union.
Granted, this restriction may not be sufficient to cover all use cases connected with the
deployment of Wrapped Union Data Types in AUTOSAR, but that’s all that can be
reasonably supported for the time being.
One obvious consequence of this restriction is that for any given ValueSpecifi-
cation taken to initialize a Wrapped Union Data Type the value of the Member
Selector is strictly locked to 1.

304 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[constr_1445] Initialization of the Member Selector of a Wrapped Union Data

Type d The initValue for the Member Selector shall never be set to any value
other than 1. c()
Another aspect of the initialization of a Wrapped Union Data Type is that the “pay-
load” part cannot be treated as a composite data type unless the first element of the
“payload” part is typed by a composite data type.
In other words, it is not possible to initialize the first subElement of an Implementa-
tionDataTypeElement of category UNION. It is only possible to assign an initial
value to the “payload” part itself.
[TPS_SWCT_01702] Initialization of the “payload” of a Wrapped Union Data
Type d The initValue for the ImplementationDataTypeElement of category
UNION shall be assigned to the ImplementationDataTypeElement of category
UNION but it shall reflect the structure of the first subElement of the Implementa-
tionDataTypeElement of category UNION. c(RS_SWCT_03217)
In other words, if the first subElement of the ImplementationDataTypeElement
of category UNION is of a primitive type then a NumericalValueSpecification
shall be used to initialize the ImplementationDataTypeElement of category
UNION.
If the subElement is typed by a composite data type then a a CompositeValue-
Specification shall be used to initialize the ImplementationDataTypeElement
of category UNION.
To summarize the initialization issue, a Wrapped Union Data Type is modeled as
a structure of two elements and requires a RecordValueSpecification that in turn
aggregates two ValueSpecifications, one for the Member Selector that shall
have no other value than 1, and one for the “payload”.
The structure of the second ValueSpecification depends on the data type used
for the first element of the “payload”.
The following example shows a simplified and stripped-down (e.g. without the Sw-
DataDefProps required to make the model complete) model of a Wrapped Union
Data Type.
Listing 5.8: Simplified example of a Wrapped Union Data Type
<IMPLEMENTATION-DATA-TYPE>
<SHORT-NAME>UnionExample</SHORT-NAME>
<CATEGORY>STRUCTURE</CATEGORY>
<SUB-ELEMENTS>
<IMPLEMENTATION-DATA-TYPE-ELEMENT>
<SHORT-NAME>memberSelector</SHORT-NAME>
<CATEGORY>VALUE</CATEGORY>
</IMPLEMENTATION-DATA-TYPE-ELEMENT>
<IMPLEMENTATION-DATA-TYPE-ELEMENT>
<SHORT-NAME>payload</SHORT-NAME>
<CATEGORY>UNION</CATEGORY>
<SUB-ELEMENTS>

305 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

<IMPLEMENTATION-DATA-TYPE-ELEMENT>
<SHORT-NAME>primitive</SHORT-NAME>
<CATEGORY>VALUE</CATEGORY>
</IMPLEMENTATION-DATA-TYPE-ELEMENT>
<IMPLEMENTATION-DATA-TYPE-ELEMENT>
<SHORT-NAME>array</SHORT-NAME>
<CATEGORY>ARRAY</CATEGORY>
<SUB-ELEMENTS>
<IMPLEMENTATION-DATA-TYPE-ELEMENT>
<SHORT-NAME>arraySub</SHORT-NAME>
<CATEGORY>VALUE</CATEGORY>
<ARRAY-SIZE>4</ARRAY-SIZE>
<ARRAY-SIZE-SEMANTICS>FIXED-SIZE</ARRAY-SIZE-SEMANTICS>
</IMPLEMENTATION-DATA-TYPE-ELEMENT>
</SUB-ELEMENTS>
</IMPLEMENTATION-DATA-TYPE-ELEMENT>
</SUB-ELEMENTS>
</IMPLEMENTATION-DATA-TYPE-ELEMENT>
</SUB-ELEMENTS>
</IMPLEMENTATION-DATA-TYPE>

5.2.7.6 Optional Element Structure

As already mentioned in section 2.9, there are use cases for structured data types that
contain optional elements that may or may not exist at a given time.
These data types require a specific modeling on both the level of Application-
DataType and the level of ImplementationDataType.
[TPS_SWCT_01775]{DRAFT} Structured data types with optional elements d A
structured data type that contains at least one optional element shall be called an
Optional Element Structure. c(RS_SWCT_03320)
On the level of ApplicationDataType, the existence of optional elements is sig-
naled by setting the attribute ApplicationRecordElement.isOptional to True.
For more details, please refer to section 5.2.4.2.2.
The description of how an Optional Element Structure shall be modeled using
ImplementationDataType can be found in section 5.2.5.1.

5.3 Data Prototypes

5.3.1 Overview

[TPS_SWCT_01264] Data prototypes implement a role of a data type d Generally

speaking, a data prototype represents the implementation of a role of a data type within
the definition of another data type, e.g. a “typed” data object declared within a software
component or a port interface.

306 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

This means formally that it has an is-of-type relation to a data type and is usually
aggregated by another element, e.g. the internal behavior or a port interface. c()
In the meta-model, various kinds of data prototypes are derived from the abstract Dat-
aPrototype as shown in figure 5.21.
The reason for the introduction of this hierarchy was the distinction between Autosar-
DataPrototype (which can be used for the application and implementation types as
well) and ApplicationCompositeElementDataPrototype (which is restricted to
be used within the application types).
ARElement AtpBlueprint
AtpType AtpBlueprintable
AutosarDataType ApplicationDataType

1 +type 1 +type
{redefines atpType} {redefines atpType}

0..1 +swDataDefProps
«atpVariation» AtpPrototype
«isOfType»
SwDataDefProps +/swDataDefProps DataPrototype

0..1

«isOfType»

AutosarDataPrototype ApplicationCompositeElementDataPrototype

VariableDataPrototype ParameterDataPrototype ApplicationRecordElement ApplicationArrayElement

+ isOptional: Boolean [0..1] + arraySizeHandling:

ArraySizeHandlingEnum [0..1]
+ arraySizeSemantics:
ArraySizeSemanticsEnum [0..1]
«atpVariation»
ArgumentDataPrototype + maxNumberOfElements:
PositiveInteger [0..1]
+ direction: ArgumentDirectionEnum
+ serverArgumentImplPolicy: ServerArgumentImplPolicyEnum [0..1]

Figure 5.21: Data Prototypes Overview

Class DataPrototype (abstract)

Package M2::AUTOSARTemplates::SWComponentTemplate::Datatype::DataPrototypes
Note Base class for prototypical roles of any data type.
Base ARObject, AtpFeature, AtpPrototype, Identifiable, MultilanguageReferrable, Referrable
Subclasses ApplicationCompositeElementDataPrototype, AutosarDataPrototype
Attribute Type Mul. Kind Note
5

307 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4
Class DataPrototype (abstract)
swDataDef SwDataDefProps 0..1 aggr This property allows to specify data definition properties
Props which apply on data prototype level.

Table 5.28: DataPrototype

Class AutosarDataPrototype (abstract)

Package M2::AUTOSARTemplates::SWComponentTemplate::Datatype::DataPrototypes
Note Base class for prototypical roles of an AutosarDataType.
Base ARObject, AtpFeature, AtpPrototype, DataPrototype, Identifiable, MultilanguageReferrable, Referrable
Subclasses ArgumentDataPrototype, ParameterDataPrototype, VariableDataPrototype
Attribute Type Mul. Kind Note
type AutosarDataType 1 tref This represents the corresponding data type.
Stereotypes: isOfType

Table 5.29: AutosarDataPrototype

Class ApplicationCompositeElementDataPrototype (abstract)

Package M2::AUTOSARTemplates::SWComponentTemplate::Datatype::DataPrototypes
Note This class represents a data prototype which is aggregated within a composite application data type
(record or array). It is introduced to provide a better distinction between target and context in instance
Refs.
Base ARObject, AtpFeature, AtpPrototype, DataPrototype, Identifiable, MultilanguageReferrable, Referrable
Subclasses ApplicationArrayElement, ApplicationRecordElement
Attribute Type Mul. Kind Note
type ApplicationDataType 1 tref This represents the corresponding data type.
Stereotypes: isOfType

Table 5.30: ApplicationCompositeElementDataPrototype

Because these DataPrototypes are modeled as own meta-classes it is possible

to define own attributes for them (on M2) which (in the M1 model) could extend or
constrain the attribute values already set via the corresponding data type.
[TPS_SWCT_01265] DataPrototype aggregates an own set of SwDataDef-
Props d This mechanism is used here in the way that DataPrototype aggregates
an own set of SwDataDefProps. Thus each kind of DataPrototype has the ability
to extend or even overwrite the SwDataDefProps already defined by its Applica-
tionDataType or ImplementationDataType.
This mechanism, if carefully applied, allows for a better reuse of data types because
they can be kept free of the properties which vary according to the context or are
defined in later project phases. c()
Chapter 5.4 describes more details about this aspect of the meta-model.
[TPS_SWCT_01445] Applicability of SwDataDefProps for DataPrototypes d
The applicability of SwDataDefProps for DataPrototypes shall follow the same
rules as for the categorys of the corresponding AutosarDataTypes. c()

308 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

The applicability of SwDataDefProps for DataPrototypes is documented in Ta-

ble 5.7.
Further information can be found in table 5.31 and table 5.32.
Please note that table 5.31 does not include the ApplicationRecordElement and
ApplicationArrayElement because these specializations of ApplicationCom-
positeElementDataPrototype are already part of table 5.7. The same applies for
table 5.32 which does not include the ImplementationDataTypeElement.
Attributes of SwDataDefProps Root El. Attribute Existence per Category

InstantiationDataDefProps
ParameterAccess
DataPrototype

STRUCTURE

COM_AXIS

RES_AXIS
VAL_BLK

BOOLEAN
STRING

CUBOID

CUBE_4

CUBE_5
VALUE

ARRAY

CURVE

MAP
additionalNativeTypeQualifier
annotation x x x * * * * * * * * * * * * *
baseType
compuMethod
dataConstr.dataConstrRule.physCon-
x x 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1
strs
dataConstr.dataConstrRule.internal-
Constrs
x x d/c14 d/c d/c d/c d/c d/c d/c d/c d/c

displayFormat x x 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1
displayPresentation x x 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1
implementationDataType
invalidValue
stepSize x x x 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1
swAddrMethod x x 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1
swAlignment x x 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1
swBitRepresentation
swCalibrationAccess x x 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1
swCalprmAxisSet
swCalprmAxisSet.swCalprmAxis/SwAxis-
x x 0..1 0..1 0..1 0..1 0..1 0..1
Grouped.swCalprmRef
swCalprmAxisSet.swCalprmAxis/SwAx-
x x 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1
isIndividual.swVariableRef
swCalprmAxisSet.swCalprmAxis/SwAxis-
Grouped.sharedAxisType
swCalprmAxisSet.swCalprmAxis/SwAx-
isIndividual.inputVariableType
swCalprmAxisSet.swCalprmAxis/SwAx-
isIndividual.unit
5

14
don’t care

309 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4
Attributes of SwDataDefProps Root El. Attribute Existence per Category

InstantiationDataDefProps
ParameterAccess
DataPrototype

STRUCTURE

COM_AXIS

RES_AXIS
VAL_BLK

BOOLEAN
STRING

CUBOID

CUBE_4

CUBE_5
VALUE

ARRAY

CURVE

MAP
swCalprmAxisSet.swCalprmAxis.base-
Type
swComparisonVariable x 0..1 0..1 0..1 0..1 0..1
swDataDependency x x 0..1 0..1 0..1 0..1 0..1 0..1
swHostVariable
swImplPolicy x 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1
swIntendedResolution
swInterpolationMethod x x x 0..1 0..1 0..1 0..1 0..1 0..1 0..1 0..1
swIsVirtual x x 0..1 0..1 0..1 0..1 0..1 0..1 0..1
swPointerTargetProps
swRecordLayout
swRefreshTiming x x 0..1 0..1 0..1 0..1
swTextProps
swValueBlockSize
swValueBlockSizeMult
unit
valueAxisDataType

Table 5.31: Allowed Attributes vs. category for DataPrototypes typed by Application
Data Types

[constr_1289] Allowed Attributes vs. category for DataPrototypes typed by

ApplicationDataTypes d The allowed values of Attributes per category for Dat-
aPrototypes typed by ApplicationDataTypes are documented in table 5.31. c
()
Attributes of SwDataDefProps Root Element Attribute Existence per Category
InstantiationDataDefProps

FUNCTION_REFERENCE
ParameterAccess

DATA_REFERENCE

TYPE_REFERENCE
DataPrototype

STRUCTURE
VALUE

UNION

ARRAY

310 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4
Attributes of SwDataDefProps Root Element Attribute Existence per Category
additionalNativeTypeQualifier
annotation x x * * * * * * * *
baseType
compuMethod
dataConstr.dataConstrRule.physConstrs x x d/c15 d/c d/c
dataConstr.dataConstrRule.internalConstrs x x 0..1 0..1 0..1
displayFormat x x 0..1 0..1 0..1 0..1 0..1
displayPresentation x x 0..1 0..1 0..1
implementationDataType
invalidValue
stepSize x x 0..1 0..1
swAddrMethod x x 0..1 0..1 0..1 0..1 0..1 0..1 0..1
swAlignment x x 0..1 0..1 0..1 0..1 0..1 0..1 0..1
swBitRepresentation
swCalibrationAccess x x 0..1 0..1 0..1 0..1 0..1
swCalprmAxisSet
swComparisonVariable
swDataDependency
swHostVariable
swImplPolicy x 0..1 0..1 0..1 0..1 0..1 0..1 0..1
swIntendedResolution
swInterpolationMethod
swIsVirtual
swPointerTargetProps
swPointerTargetProps.swDataDefProps
swPointerTargetProps.functionPointerSignature
swRecordLayout
swRefreshTiming x x 0..1 0..1 0..1 0..1 0..1
swTextProps
swValueBlockSize
swValueBlockSizeMult
unit
valueAxisDataType

Table 5.32: Allowed Attributes vs. category for DataPrototypes typed by Imple-
mentationDataTypes

[constr_1288] Allowed Attributes vs. category for DataPrototypes typed by

ImplementationDataTypes d The allowed values per category for DataProto-
types typed by ImplementationDataTypes are documented in table 5.32. c()
[TPS_SWCT_01266] Three non-abstract classes derived from AutosarDataPro-
totype d There are three non-abstract classes derived from AutosarDataProto-
type which reflect the main use cases in the SWC-Template:
• Operation arguments (ArgumentDataPrototype) in a client-server interface.
• Variables (VariableDataPrototype) which are changed by the application
software at runtime.
15
don’t care

311 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

• Parameters (ParameterDataPrototype) which are constant (except for cali-

bration access) from the application point of view.
c()
Class VariableDataPrototype
Package M2::AUTOSARTemplates::SWComponentTemplate::Datatype::DataPrototypes
Note A VariableDataPrototype is used to contain values in an ECU application. This means that most likely a
VariableDataPrototype allocates "static" memory on the ECU. In some cases optimization strategies
might lead to a situation where the memory allocation can be avoided.
In particular, the value of a VariableDataPrototype is likely to change as the ECU on which it is used
executes.
Base ARObject, AtpFeature, AtpPrototype, AutosarDataPrototype, DataPrototype, Identifiable, Multilanguage
Referrable, Referrable
Attribute Type Mul. Kind Note
initValue ValueSpecification 0..1 aggr Specifies initial value(s) of the VariableDataPrototype

Table 5.33: VariableDataPrototype

Class ParameterDataPrototype
Package M2::AUTOSARTemplates::SWComponentTemplate::Datatype::DataPrototypes
Note A parameter element used for parameter interface and internal behavior, supporting signal like parameter
and characteristic value communication patterns and parameter and characteristic value definition.
Base ARObject, AtpFeature, AtpPrototype, AutosarDataPrototype, DataPrototype, Identifiable, Multilanguage
Referrable, Referrable
Attribute Type Mul. Kind Note
initValue ValueSpecification 0..1 aggr Specifies initial value(s) of the ParameterDataPrototype

Table 5.34: ParameterDataPrototype

[TPS_SWCT_01267] DataPrototype can be aggregated in different roles d Note

that even though the meta-classes VariableDataPrototype and ParameterDat-
aPrototype already express specific use cases of the underlying data type the same
DataPrototype can still be aggregated in different roles, e.g. in the SwcInternal-
Behavior to express different methods how to access it. c()
An example is the aggregation of VariableDataPrototype by SwcInternalBe-
havior in the roles of either implicitInterRunnableVariable or explicit-
InterRunnableVariable. Find more information concerning these use cases in
chapter 7.
[TPS_SWCT_01268] Definition of initValue for a VariableDataPrototype or
a ParameterDataPrototype d It is possible to assign an initValue for both a
VariableDataPrototype and a ParameterDataPrototype. c()
This aspect is sketched in Figure 5.22.
[TPS_SWCT_01269] In PortInterfaces, initial values defined for DataProto-
types are ignored d These initValues have no meaning for DataPrototypes
within PortInterfaces because in this case a more specific definition of initial val-
ues via the so-called ComSpec is required. c()

312 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

For more information, please refer to chapter 4.5.

AutosarDataPrototype AutosarDataPrototype
VariableDataPrototype ParameterDataPrototype

+initValue 0..1 +initValue 0..1

ValueSpecification

+ shortLabel: Identifier [0..1]

Figure 5.22: Initial value for AutosarDataPrototypes

Find more information about the interpretation of initValue in section 5.7.

[constr_1416] Existence of ApplicationArrayElement.maxNumberOfEle-
ments d The attribute ApplicationArrayElement.maxNumberOfElements shall
exist for all ApplicationArrayElements defined in the scope of an Application-
ArrayDataType where the attribute ApplicationArrayDataType.dynamicAr-
raySizeProfile does not exist. c()
This means that for fixed-size array data types the attribute ApplicationArrayEle-
ment.maxNumberOfElements shall be defined for every dimension of the fixed-size
array data.

5.3.2 Data Constraints for DataPrototypes typed by Array DataTypes

There are cases where it should be possible to reference different DataConstrs

from DataPrototypes of category ARRAY typed by either an ApplicationAr-
rayDataType or an ImplementationDataType of category ARRAY.
AUTOSAR supports this use case under the following conditions:
[constr_1407] Definition of SwDataDefProps.dataConstr depending on the ca-
pabilities of the data type d The definition of a SwDataDefProps.dataConstr ac-
cording to [constr_1288] and [constr_1289] is only supported for a DataPrototype
of category ARRAY if the corresponding ApplicationArrayDataType or Imple-
mentationDataType of category ARRAY also supports the specification of a Sw-
DataDefProps.dataConstr. c()
[constr_1408] Definition of SwDataDefProps.displayFormat depending on the
capabilities of the data type d The definition of a SwDataDefProps.displayFor-
mat according to [constr_1288] and [constr_1289] is only supported for a DataPro-
totype of category ARRAY if the corresponding ApplicationArrayDataType or
ImplementationDataType of category ARRAY also supports the specification of
a SwDataDefProps.displayFormat. c()

313 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[constr_1413] Definition of SwDataDefProps.stepSize depending on the capa-

bilities of the data type d The definition of a SwDataDefProps.stepSize accord-
ing to [constr_1288] and [constr_1289] is only supported for a DataPrototype of
category ARRAY if the corresponding ApplicationArrayDataType or Imple-
mentationDataType of category ARRAY also supports the specification of a Sw-
DataDefProps.stepSize. c()
[constr_1409] Definition of SwDataDefProps.dataConstr depending on the ca-
pabilities of the element data type d The definition of a SwDataDefProps.data-
Constr according to [constr_1007] and [constr_1009] is only supported for an Appli-
cationArrayDataType or an ImplementationDataType of category ARRAY
if the aggregated ApplicationArrayDataType.element or Implementation-
DataType.subElement also supports the specification of a SwDataDefProps.dat-
aConstr. c()
[constr_1410] Definition of SwDataDefProps.displayFormat depending on the
capabilities of the element data type d The definition of a SwDataDefProps.dis-
playFormat according to [constr_1007] and [constr_1009] is only supported for
an ApplicationArrayDataType or an ImplementationDataType of category
ARRAY if the aggregated ApplicationArrayDataType.element or Implemen-
tationDataType.subElement also supports the specification of a SwDataDef-
Props.displayFormat. c()
[constr_1414] Definition of SwDataDefProps.stepSize depending on the ca-
pabilities of the element data type d The definition of a SwDataDefProps.step-
Size according to [constr_1007] and [constr_1009] is only supported for an Ap-
plicationArrayDataType or an ImplementationDataType of category AR-
RAY if the aggregated ApplicationArrayDataType.element or Implementa-
tionDataType.subElement also supports the specification of a SwDataDef-
Props.stepSize. c()

5.3.3 Reference to Data Prototypes

This chapter explains the various patterns for referencing DataPrototypes.

[TPS_SWCT_01446] References to a DataPrototype may or may not imply the
necessity for using an instanceRef d As references to a DataPrototype may
or may not imply the necessity for using an instanceRef this would mean that in
some places the meta-model would have to implement both variants depending on
the use case. To avoid this, AUTOSAR defines a unified reference implementation for
VariableDataPrototypes and ParameterDataPrototypes. c()

314 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

5.3.3.1 AUTOSAR Variable Ref

[TPS_SWCT_01270] AutosarVariableRef d With the advent of AutosarVari-

ableRef it is possible to implement a uniform reference to a VariableDataProto-
type that covers all foreseen use cases:
• Reference to a localVariable, no AtpInstanceRef required.
• Reference to an autosarVariable (which involves an AtpInstanceRef).
• Reference to the internal structure of a VariableDataPrototype implemented
using a composite ImplementationDataType.
c()
Class AutosarVariableRef
Package M2::AUTOSARTemplates::SWComponentTemplate::SwcInternalBehavior::DataElements
Note This class represents a reference to a variable within AUTOSAR which can be one of the following use
cases:
localVariable:
• localVariable which is used as whole (e.g. InterRunnableVariable, inputValue for curve)
autosarVariable:
• a variable provided via Port which is used as whole (e.g. dataAccesspoints)
• an element inside of a composite local variable typed by ApplicationDatatype (e.g. inputValue for
a curve)
• an element inside of a composite variable provided via Port and typed by ApplicationDatatype
(e.g. inputValue for a curve)
autosarVariableInImplDatatype:
• an element inside of a composite local variable typed by ImplementationDatatype (e.g. nvram
Data mapping)
• an element inside of a composite variable provided via Port and typed by Implementation
Datatype (e.g. inputValue for a curve)
Base ARObject
Attribute Type Mul. Kind Note
autosarVariable DataPrototype 0..1 iref This references a variable which is provided by a port
and/or which is part of a CompositeDataType.
autosarVariable ArVariableIn 0..1 aggr This is used if the target variable is inside of variableData
InImplDatatype ImplementationData Prototype typed by an ImplementationDataType.
InstanceRef
localVariable VariableDataPrototype 0..1 ref This reference is used if the variable is local to the current
component. It would also be possible to use the instance
refence here.
Such an instance ref would not have a contextElement,
since the current instance is the context.
But the local instance is a special case which may provide
further optimization. Therefore an expclicit reference is
provided for this case.

Table 5.35: AutosarVariableRef

315 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

AutosarVariableRef

+autosarVariable 0..1

AtpInstanceRef
VariableInAtomicSWCTypeInstanceRef

+localVariable 0..1 +autosarVariableInImplDatatype 0..1

AutosarDataPrototype
ArVariableInImplementationDataInstanceRef
VariableDataPrototype +rootVariableDataPrototype

0..1

Figure 5.23: Implementation of AutosarVariableRef

Rules for the modeling and semantics of an AtpInstanceRef are defined in general
in [11].
[constr_2536] Target of an autosarVariable in AutosarVariableRef shall re-
fer to a variable d The target of autosarVariable (which in fact is an instance
ref) in AutosarVariableRef shall either be or be nested in VariableDataPro-
totype. This means that the target shall either be a VariableDataPrototype or
an ApplicationCompositeElementDataPrototype that in turn is owned by a
VariableDataPrototype. c()

5.3.3.2 AUTOSAR Parameter Ref

[TPS_SWCT_01271] AutosarParameterRef d With the advent of AutosarParam-

eterRef it is possible to implement a uniform reference to a ParameterDataPro-
totype that covers all foreseen use cases:
• Reference to a localParameter, no AtpInstanceRef required.
• Reference to an autosarParameter (which involves an AtpInstanceRef).
c()
Please note that there is a very limited amount of use-cases available where the Au-
tosarParameterRef can (with the active consent of the AUTOSAR standard) refer-
ence a VariableDataPrototype.
[constr_1173] Applicability of AutosarParameterRef referencing a Variable-
DataPrototype d A reference from AutosarParameterRef to VariableDat-
aPrototype is only applicable if the AutosarParameterRef is used in the context
of SwAxisGrouped. c()
For example, the use case referenced in [constr_1173] applies if it is required to store
a grouped axis in a variable in order to adapt the axis during run-time of the ECU

316 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

by a dedicated algorithm. Note that in all cases where [constr_1173] does not apply
[constr_2535] shall be fulfilled.
Class AutosarParameterRef
Package M2::AUTOSARTemplates::SWComponentTemplate::SwcInternalBehavior::DataElements
Note This class represents a reference to a parameter within AUTOSAR which can be one of the following use
cases:
localParameter:
• localParameter which is used as whole (e.g. sharedAxis for curve)
autosarVariable:
• a parameter provided via PortPrototype which is used as whole (e.g. parameterAccess)
• an element inside of a composite local parameter typed by ApplicationDatatype (e.g. sharedAxis
for a curve)
• an element inside of a composite parameter provided via Port and typed by ApplicationDatatype
(e.g. sharedAxis for a curve)
autosarParameterInImplDatatype:
• an element inside of a composite local parameter typed by ImplementationDatatype
• an element inside of a composite parameter provided via PortPrototype and typed by
ImplementationDatatype
Base ARObject
Attribute Type Mul. Kind Note
autosar DataPrototype 0..1 iref This instance reference is used if the callibration
Parameter parameter is either imported via a port or is part of a
composite data structure.
localParameter DataPrototype 0..1 ref In the majority of cases this reference goes to Parameter
DataPrototypes rather than VariableDataPrototypes.
Pointing the reference to a VariableDataPrototype is
limited to special use cases, e.g. if the AutosarParameter
Ref is used in the context of an SwAxisGrouped.
This reference is used if the arParameter is local to the
current component.
Of course, it would technically also be feasible to use an
InstanceRef for this case. However, the InstanceRef
would not have a contextElement (because the current
instance is the context).
Hence, the local instance is a special case which may
provide further optimization. Therefore an explicit
reference is provided for this case.

Table 5.36: AutosarParameterRef

[constr_2535] Target of an autosarParameter in AutosarParameterRef shall

refer to a parameter d Except for the specifically described cases where [constr_1173]
applies the target of autosarParameter (which in fact is an instance ref) in Au-
tosarParameterRef shall either be or be nested in ParameterDataPrototype.
This means that the target shall either be a ParameterDataPrototype or an Ap-
plicationCompositeElementDataPrototype that in turn is owned by a Param-
eterDataPrototype. c()

317 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

5.3.3.3 Modeling Approach

[constr_1161] Applicability of the index attribute of Ref d The index attribute of

Ref is limited to a given set if use cases as there are:
• McDataInstance.instanceInMemory
• AutosarVariableRef
• AutosarParameterRef
• FlatInstanceDescriptor / AnyInstanceRef
c()
The implementation of the AtpInstanceRefs for AutosarVariableRef and Au-
tosarParameterRef probably needs some clarification regarding the references to
DataPrototypes.
[TPS_SWCT_01374] Implementation of AutosarParameterRef d The reference to
rootParameterDataPrototype is not redundant. It is required for identifying the
autosarParameter itself in a ParameterInterface for the case that the tar-
getDataPrototype is an ApplicationCompositeElementDataPrototype. c
()
As explained before, the implementation of AutosarParameterRef in a specific case
is subject to [constr_1173].
[constr_1608] Existence of rootParameterDataPrototype d The reference
rootParameterDataPrototype shall exist if and only if
• AutosarDataType of the autosarParameter is a composite data type and
• targetDataPrototype refers to a DataPrototype inside the rootParam-
eterDataPrototype.
c()
Note: If the target of the AtpInstanceRef is an AutosarDataPrototype then the
rootParameterDataPrototype shall not exist.

318 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

SwComponentType AtpBlueprintable
AutosarParameterRef
AtomicSwComponentType AtpPrototype
PortPrototype

+base 1 +portPrototype 0..1

{redefines {subsets
atpBase} atpContextElement}
«atpDerived»
+autosarParameter 0..1

AtpInstanceRef
ParameterInAtomicSWCTypeInstanceRef

«instanceRef»

1
{subsets
+localParameter +autosarParameter
0..1 0..1 +targetDataPrototype atpTarget} 0..1
{subsets
AtpPrototype atpContextElement}
DataPrototype
+rootParameterDataPrototype

ApplicationCompositeElementDataPrototype +contextDataPrototype

0..*
{ordered,
subsets
atpContextElement}

Figure 5.24: Implementation of the InstanceRef for AutosarParameterRef

[TPS_SWCT_01375] Implementation of AutosarVariableRef d The reference to

rootVariableDataPrototype is not redundant. It is required for identifying the
autosarVariable itself in a SenderReceiverInterface or NvDataInterface
for the case that the targetDataPrototype is an ApplicationCompositeEle-
mentDataPrototype. c()
[constr_1609] Existence of rootVariableDataPrototype d The reference
rootVariableDataPrototype shall exist if and only if
• the AutosarDataType of the autosarVariable is a composite data type and
• the targetDataPrototype refers to a DataPrototype inside the root-
VariableDataPrototype.
c()
Note: If the target of the AtpInstanceRef is an AutosarDataPrototype then the
rootVariableDataPrototype shall not exist.

319 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

SwComponentType AtpBlueprintable
AutosarVariableRef
AtomicSwComponentType AtpPrototype
PortPrototype

+base 1 +portPrototype 0..1

{subsets {subsets
atpBase} atpContextElement}
«atpDerived»

+autosarVariable 0..1

AtpInstanceRef
VariableInAtomicSWCTypeInstanceRef

«instanceRef»

1
{subsets
+autosarVariable 0..1 +targetDataPrototype atpTarget}

AtpPrototype
DataPrototype

0..*
{ordered,
subsets
+contextDataPrototype atpContextElement}

AutosarDataPrototype ApplicationCompositeElementDataPrototype

+localVariable 0..1

VariableDataPrototype
+rootVariableDataPrototype

0..1
{subsets
atpContextElement}

Figure 5.25: Implementation of the InstanceRef for AutosarVariableRef

5.3.3.4 Access into VariableDataPrototype typed by an Implementation-

DataType

The meta-class ArVariableInImplementationDataInstanceRef, despite the

name, has formally no relationship to AtpInstanceRef. Therefore the following defi-
nition applies:
[TPS_SWCT_01681] Context path in ArVariableInImplementationDataIn-
stanceRef d The references in the roles
• portPrototype
• rootVariableDataPrototype
• ordered collection of contextDataPrototype
• targetDataPrototype

320 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

constitute the path leading from the root to the specified inner instance of a
dataElement inside of a VariableDataPrototype typed by an Implementa-
tionDataType. c()
This relation is also depicted in Figure 5.26.
ArVariableInImplementationDataInstanceRef

0..*
+portPrototype 0..1 +contextDataPrototype {ordered} +targetDataPrototype 1
AtpBlueprintable AtpPrototype AbstractImplementationDataTypeElement
AtpPrototype DataPrototype ImplementationDataTypeElement
PortPrototype
+ arraySizeHandling: ArraySizeHandlingEnum [0..1]
+ arraySizeSemantics: ArraySizeSemanticsEnum [0..1]
+ isOptional: Boolean [0..1]
«atpVariation»
+ arraySize: PositiveInteger [0..1]

+subElement 0..* {ordered}

ARElement
  
AutosarDataPrototype
«isOfType» +type AtpType    
AutosarDataType  
«atpVariation»
1
{redefines atpType}

+rootVariableDataPrototype 0..1
AbstractImplementationDataType
VariableDataPrototype ImplementationDataType

+ dynamicArraySizeProfile: String [0..1]

+ isStructWithOptionalElement: Boolean [0..1]
+ typeEmitter: NameToken [0..1]

Figure 5.26: Implementation of ArVariableInImplementationDataInstanceRef

[constr_1423] Completeness of references ArVariableInImplementation-

DataInstanceRef.contextDataPrototype d The reference ArVariableInIm-
plementationDataInstanceRef.contextDataPrototype shall be defined for
• each leaf (i.e. the end of a chain of aggregating elements) Implementation-
DataTypeElement of category TYPE_REFERENCE in a chain of referencing
ImplementationDataTypes which is not the targetDataPrototype
• and each ImplementationDataTypeElement owned by an Implementa-
tionDataType or ImplementationDataTypeElement of category ARRAY
in a chain of referencing ImplementationDataTypes
starting from the ImplementationDataTypes of the rootVariableDataProto-
type down to the leaf ImplementationDataTypeElement which is typed (directly
or indirectly via ImplementationDataType of category TYPE_REFERENCE) by the
ImplementationDataType of the targetDataPrototype. c()

321 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Figure 5.27 contains an example of a nested ImplementationDataType along with

the application of ArVariableInImplementationDataInstanceRef. The exam-
ple contains both cases for the definition of a contextDataPrototype mentioned in
[constr_1423].
:ArVariableInImplementationDataInstanceRef +rootVariableDataPrototype :VariableDataPrototype

+type

:ImplementationDataType

   
  
 !"#$% &'#
category = ARRAY

+subElement
+contextDataPrototype
:ImplementationDataTypeElement  

   
  
{index = 1} category = ARRAY   
   
 
  

+subElement

+contextDataPrototype :ImplementationDataTypeElement   

   
  
{index = 2} category = TYPE_REFERENCE  
  

   
  
   (


+implementationDataType        
 


   
   

:ImplementationDataType )*+,-. /    

         0
category = TYPE_REFERENCE

+implementationDataType

:ImplementationDataType

category = STRUCTURE

+subElement +subElement

: :
ImplementationDataTypeElement ImplementationDataTypeElement

category = VALUE category = STRUCTURE

+subElement +subElement

+targetDataPrototype :ImplementationDataTypeElement :ImplementationDataTypeElement

category = TYPE_REFERENCE category = VALUE

+implementationDataType

:ImplementationDataType

  
  
        
category = VALUE

+baseType

:SwBaseType

category = FIXED_LENGTH

Figure 5.27: Example for the usage of ArVariableInImplementationDataIn-

stanceRef

322 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[constr_1424] Existence of ArVariableInImplementationDataIn-

stanceRef.contextDataPrototype d The attribute ArVariableInImple-
mentationDataInstanceRef.contextDataPrototype shall only exist for an
ImplementationDataTypeElement category TYPE_REFERENCE or ARRAY. c()
Technically, it would be possible to avoid the context for a one-dimensional array in
the hierarchy. The context is still required because then the rule for the existence of
contexts becomes much simpler.
Class ArVariableInImplementationDataInstanceRef
Package M2::AUTOSARTemplates::SWComponentTemplate::SwcInternalBehavior::DataElements
Note This class represents the ability to navigate into a data element inside of an VariableDataPrototype which
is typed by an ImplementationDatatype.
Note that it shall not be used if the target is the VariableDataPrototype itself (e.g. if its a primitive).
Note that this class follows the pattern of an InstanceRef but is not implemented based on the abstract
classes because the ImplementationDataType isn’t either, especially because ImplementationDataType
Element isn’t derived from AtpPrototype.
Base ARObject
Attribute Type Mul. Kind Note
contextDataPro- ImplementationData * ref This is a context in case there are subelements with
totype (ordered) TypeElement explicit types. The reference has to be ordered to
properly reflect the nested structure.
Tags: xml.sequenceOffset=30
portPrototype PortPrototype 0..1 ref This is the port providing/receiving the root of the variable
Tags: xml.sequenceOffset=10
rootVariable VariableDataPrototype 0..1 ref This refers to the VariableDataPrototype typed by the
DataPrototype ImplementationDatatype in which the target can be found.
Tags: xml.sequenceOffset=20
targetData ImplementationData 1 ref This reference points to the target ImplementationData
Prototype TypeElement TypeElement.
Tags: xml.sequenceOffset=40

Table 5.37: ArVariableInImplementationDataInstanceRef

5.3.3.5 Access into ParameterDataPrototype typed by an Implementation-

DataType

Please note that it is also possible to access the inside of a nested ParameterDat-
aPrototype typed by an ImplementationDataType in pretty much the same way
as this is possible for a VariableDataPrototype typed by an Implementation-
DataType.
[TPS_SWCT_01738] Context path in ArParameterInImplementationDataIn-
stanceRef d The references in the roles
• portPrototype
• rootParameterDataPrototype
• ordered collection of contextDataPrototype

323 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

• targetDataPrototype
constitute the path leading from the root to the specified inner instance of a parameter
inside of a ParameterDataPrototype typed by an ImplementationDataType. c
()
This relation is also depicted in Figure 5.28.
ArParameterInImplementationDataInstanceRef

0..*
+portPrototype 0..1 +contextDataPrototype {ordered} +targetDataPrototype 1

AtpBlueprintable AtpPrototype AbstractImplementationDataTypeElement

AtpPrototype DataPrototype ImplementationDataTypeElement
PortPrototype
+ arraySizeHandling: ArraySizeHandlingEnum [0..1]
+ arraySizeSemantics: ArraySizeSemanticsEnum [0..1]
+ isOptional: Boolean [0..1]
«atpVariation»
+ arraySize: PositiveInteger [0..1]

+subElement 0..* {ordered}

ARElement
AutosarDataPrototype
+type AtpType
AutosarDataType
«isOfType» «atpVariation»
1
{redefines atpType}

+rootParameterDataPrototype 0..1 AbstractImplementationDataType

ImplementationDataType
ParameterDataPrototype
+ dynamicArraySizeProfile: String [0..1]
+ isStructWithOptionalElement: Boolean [0..1]
+ typeEmitter: NameToken [0..1]

Figure 5.28: Implementation of ArParameterInImplementationDataInstanceRef

[constr_1516] Completeness of references ArParameterInImplementation-

DataInstanceRef.contextDataPrototype d The reference ArParameterIn-
ImplementationDataInstanceRef.contextDataPrototype shall be defined
for
• each leaf (i.e. the end of a chain of aggregating elements) Implementation-
DataTypeElement of category TYPE_REFERENCE in a chain of referencing
ImplementationDataTypes which is not the targetDataPrototype
• and each ImplementationDataTypeElement owned by an Implementa-
tionDataType or ImplementationDataTypeElement of category ARRAY
in a chain of referencing ImplementationDataTypes
starting from the ImplementationDataTypes of the rootParameterDataProto-
type down to the leaf ImplementationDataTypeElement which is typed (directly
or indirectly via ImplementationDataType of category TYPE_REFERENCE) by the
ImplementationDataType of the targetDataPrototype. c()

324 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[constr_1517] Existence of ArParameterInImplementationDataIn-

stanceRef.contextDataPrototype d The attribute ArParameterInIm-
plementationDataInstanceRef.contextDataPrototype shall only exist for an
ImplementationDataTypeElement category TYPE_REFERENCE or ARRAY. c()
Technically, it would be possible to avoid the context for a one-dimensional array in
the hierarchy. The context is still required because then the rule for the existence of
contexts becomes much simpler.
Class ArParameterInImplementationDataInstanceRef
Package M2::AUTOSARTemplates::SWComponentTemplate::SwcInternalBehavior::DataElements
Note This class represents the ability to navigate into an element inside of an ParameterDataPrototype typed
by an ImplementationDatatype.
Note that it shall not be used if the target is the ParameterDataPrototype itself (e.g. if the target is a
primitive data type).
Note that this class follows the pattern of an InstanceRef but is not implemented based on the abstract
classes because the ImplementationDataType isn’t either, especially because ImplementationDataType
Element (intentionally) isn’t derived from AtpPrototype.
Base ARObject
Attribute Type Mul. Kind Note
contextDataPro- ImplementationData * ref This is a context in case there are subelements with
totype (ordered) TypeElement explicit types. The reference has to be ordered to
properly reflect the nested structure.
portPrototype PortPrototype 0..1 ref This reference points to the PortPrototype
providing/receiving the root of the parameter.
rootParameter ParameterData 0..1 ref This refers to the ParameterDataPrototype typed by the
DataPrototype Prototype implementationDataType in which the target can be
found.
targetData ImplementationData 1 ref This reference points to the target ImplementationData
Prototype TypeElement TypeElement.

Table 5.38: ArParameterInImplementationDataInstanceRef

5.4 Properties of Data Definitions

5.4.1 Overview

As it has already been shown in the previous chapters, various properties and asso-
ciations can be attached to the definition of data types as well as prototypes. These
are described by the meta-class SwDataDefProps which covers all properties of a
particular data object under various aspects.
In general, the properties specified within SwDataDefProps may apply to all kind of
data declared within the software-component template and within the basic software
module description template as well, e.g. component local data, data used for commu-
nication, data used for measurement as well as for calibration.
However, there are constraints for the attributes depending on the role of the data:

325 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[constr_1015] Prioritization of SwDataDefProps d The prioritization and usage of

attributes of meta-class SwDataDefProps shall follow the restrictions given in ta-
ble 5.39. c()
Attributes of SwDataDefProps Usage For Place of Setting

InstantiationDataDefProps
ImplementationDataType

FlatInstanceDescriptor
ApplicationDataType

PerInstanceMemory
ParameterAccess

McDataInstance
DataPrototype

SwSystemconst
SwServiceArg
Other Usage

ComSpec
RTE

A2L
additionalNativeTypeQualifier x x NA D I NA NA NA D NA S NA NA
annotation x D A A A A A D NA A D NA
baseType x x x NA D I I I R D NA S M NA
compuMethod x x x D AI I I NA R I AI S D NA
dataConstr x x x D C R R I NA R NA S D NA
displayFormat x D A R R I NA R NA S D NA
displayPresentation x x x D A R R NA NA NA NA S NA NA
implementationDataType x x NA D I I I NA D NA NA NA NA
invalidValue x x D A I I NA D NA NA S NA NA
stepSize x D A A A A NA NA A S NA NA
swAddrMethod x x x D R R R NA NA NA R NA NA D
swAlignment x x NA D R R NA NA NA NA NA NA NA
swBitRepresentation x x NA NA NA NA NA NA NA NA D NA NA
swCalibrationAccess x x D R R R NA NA R R S D NA
swCalprmAxisSet x x D NA I I I NA NA NA S NA NA
swCalprmAxisSet.swCalprmAxis
x NA NA NA D R NA NA NA S NA NA
/SwAxisGrouped.swCalprmRef
swCalprmAxisSet.swCalprmAxis
x NA NA NA D R NA NA NA S NA NA
/SwAxisIndividual.swVariableRef
swCalprmAxisSet.swCalprmAxis
x D NA NA NA NA NA NA NA S NA NA
/SwAxisGrouped.sharedAxisType
swCalprmAxisSet.swCalprmAxis
x D NA NA NA NA NA NA NA S NA NA
/SwAxisIndividual.inputVariableType
swCalprmAxisSet/SwAxisIndividual.unit opt. D NA I I I NA I NA S NA NA
swComparisonVariable x NA NA NA NA D NA NA NA S NA NA
swDataDependency x x NA NA D R NA NA NA NA S NA NA
swHostVariable x x NA NA NA NA NA NA NA NA D NA NA
swImplPolicy x x D A A NA NA NA D NA NA NA NA
swIntendedResolution x D16 NA NA NA NA NA NA NA NA NA NA
swInterpolationMethod x D I R R R NA NA NA S NA NA
swIsVirtual x NA NA D R NA NA NA NA S NA NA
swPointerTargetProps x NA D I NA NA NA D NA NA NA NA
swRecordLayout x x x D NA I I I NA NA NA S NA NA
5

16
swIntendedResolution is used only in an early phase of the definition of data types, namely
in the context of the definition of so-called blueprints. To that extent, swIntendedResolution rep-
resents a non-binding requirement that shall later be considered for the definition of an appropriate
CompuMethod.

326 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4
Attributes of SwDataDefProps Usage For Place of Setting

InstantiationDataDefProps
ImplementationDataType

FlatInstanceDescriptor
ApplicationDataType

PerInstanceMemory
ParameterAccess

McDataInstance
DataPrototype

SwSystemconst
SwServiceArg
Other Usage

ComSpec
RTE

A2L
swRefreshTiming x D R R R NA NA R R R NA NA
swTextProps x x D I I I I NA NA NA S NA NA
swValueBlockSize x x D I I I I NA NA NA S NA NA
swValueBlockSizeMult x x D I I I I NA NA NA S NA NA
unit x x D I I I NA NA I NA S D NA
valueAxisDataType x x D I I I I NA NA NA S NA NA

Table 5.39: Usage of Attributes of SwDataDefProps

Please note that this table is (by reference) a part of [constr_1015]

The following settings apply in table 5.39:

D Define the attribute independent from settings to the left.
R Use or re-define definition from the left in the scope of this element.
A Add attribute if not defined on the left, or as an additional information.
If the attribute has an upper multiplicity > 1 and the attribute is defined on the left
then the attribute is added to the attribute defined on the left.
If the attribute has a upper multiplicity of 1 and the attribute is not defined on the
left then the attribute is defined.
If the attribute has an upper multiplicity of 1 and the attribute is already defined
on the left then the attribute is not redefined but this is considered as invalid
configuration.
I Inherit the definition from the left for usage in the scope of this element.
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.
C This means that the left element constrains right element.
AI If the attribute is already defined on the left then the attribute is not redefined but
adds implementation-related information.

327 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Example: an ApplicationDataType of category BOOLEAN supports the def-

inition of an own CompuMethod to define the semantics of e.g. (ON, OFF) or
(HIGH, LOW) or (PASSED, FAILED) as long as the number of values match
and matching pairs of values on application level and implementation level
exist. In contrast, the corresponding ImplementationDataType uses (true,
false) as the applicable literals in any of the above mentioned cases.
S Create a “Self-contained” artifact based on the left.
Example: A CompuMethod defined in the context of a System of category
ECU_EXTRACT is copied into the separate artifact for the McSupportData and
references need to be updated to the copy.
Use case: Provide a McDataGenerator with a single, self-contained file to do its
job.
Some of the property names contain the term “variable” or “calprm”, this comes from
historical17 reasons and can be taken as some hint where the property most likely
applies to.
Class «atpVariation» SwDataDefProps
Package M2::MSR::DataDictionary::DataDefProperties
Note This class is a collection of properties relevant for data objects under various aspects. One could
consider this class as a "pattern of inheritance by aggregation". The properties can be applied to all
objects of all classes in which SwDataDefProps is aggregated.
Note that not all of the attributes or associated elements are useful all of the time. Hence, the process
definition (e.g. expressed with an OCL or a Document Control Instance MSR-DCI) has the task of
implementing limitations.
SwDataDefProps covers various aspects:
• Structure of the data element for calibration use cases: is it a single value, a curve, or a map, but
also the recordLayouts which specify how such elements are mapped/converted to the Data
Types in the programming language (or in AUTOSAR). This is mainly expressed by properties
like swRecordLayout and swCalprmAxisSet
• Implementation aspects, mainly expressed by swImplPolicy, swVariableAccessImplPolicy, sw
AddrMethod, swPointerTagetProps, baseType, implementationDataType and additionalNative
TypeQualifier
• Access policy for the MCD system, mainly expressed by swCalibrationAccess
• Semantics of the data element, mainly expressed by compuMethod and/or unit, dataConstr,
invalidValue
• Code generation policy provided by swRecordLayout
Tags: vh.latestBindingTime=codeGenerationTime
Base ARObject
Attribute Type Mul. Kind Note
5

17
In the beginning of ASAM and MSR measurements and calibration parameters (characteristics)
were separated and the properties were merged over the time.

328 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4
Class «atpVariation» SwDataDefProps
additionalNative NativeDeclarationString 0..1 attr This attribute is used to declare native qualifiers of the
TypeQualifier programming language which can neither be deduced
from the baseType (e.g. because the data object
describes a pointer) nor from other more abstract
attributes. Examples are qualifiers like "volatile", "strict" or
"enum" of the C-language. All such declarations have to
be put into one string.
Tags: xml.sequenceOffset=235
annotation Annotation * aggr This aggregation allows to add annotations (yellow pads
...) related to the current data object.
Tags: xml.roleElement=true
xml.roleWrapperElement=true
xml.sequenceOffset=20
xml.typeElement=false
xml.typeWrapperElement=false
baseType SwBaseType 0..1 ref Base type associated with the containing data object.
Tags: xml.sequenceOffset=50
compuMethod CompuMethod 0..1 ref Computation method associated with the semantics of
this data object.
Tags: xml.sequenceOffset=180
dataConstr DataConstr 0..1 ref Data constraint for this data object.
Tags: xml.sequenceOffset=190
displayFormat DisplayFormatString 0..1 attr This property describes how a number is to be rendered
e.g. in documents or in a measurement and calibration
system.
Tags: xml.sequenceOffset=210
display DisplayPresentation 0..1 attr This attribute controls the presentation of the related data
Presentation Enum for measurement and calibration tools.
implementation AbstractImplementation 0..1 ref This association denotes the ImplementationDataType of
DataType DataType a data declaration via its aggregated SwDataDefProps. It
is used whenever a data declaration is not directly
referring to a base type. Especially
• redefinition of an ImplementationDataType via a
"typedef" to another ImplementationDatatype
• the target type of a pointer (see SwPointerTarget
Props), if it does not refer to a base type directly
• the data type of an array or record element within
an ImplementationDataType, if it does not refer to
a base type directly
• the data type of an SwServiceArg, if it does not
refer to a base type directly
Tags: xml.sequenceOffset=215
invalidValue ValueSpecification 0..1 aggr Optional value to express invalidity of the actual data
element.
Tags: xml.sequenceOffset=255
stepSize Float 0..1 attr This attribute can be used to define a value which is
added to or subtracted from the value of a DataPrototype
when using up/down keys while calibrating.
swAddrMethod SwAddrMethod 0..1 ref Addressing method related to this data object. Via an
association to the same SwAddrMethod it can be
specified that several DataPrototypes shall be located in
the same memory without already specifying the memory
section itself.
Tags: xml.sequenceOffset=30
5

329 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

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

330 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

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

Table 5.40: SwDataDefProps

331 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Primitive NativeDeclarationString
Package M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::PrimitiveTypes
Note This string contains a native data declaration of a data type in a programming language. It is basically a
string, but white-space must be preserved.
Tags: xml.xsd.customType=NATIVE-DECLARATION-STRING
xml.xsd.type=string
xml.xsd.whiteSpace=preserve

Table 5.41: NativeDeclarationString

Class SwBitRepresentation
Package M2::MSR::DataDictionary::DataDefProperties
Note Description of the structure of a bit variable: Comprises of the bitPosition in a memory object (e.g. sw
HostVariable, which stands parallel to swBitRepresentation) and the numberOfBits . In this way,
interrelated memory areas can be described. Non-related memory areas are not supported.
Base ARObject
Attribute Type Mul. Kind Note
bitPosition Integer 0..1 attr If the "bit data object" is hosted within another data object
(e.g. if the memory can be accessed via byte as well as
bit address), this attribute specifies the position of the
data object. The count starts at zero (0).
Tags: xml.sequenceOffset=20
numberOfBits Integer 0..1 attr Number of bits allocated by a "bit data object" within its
host data object.
Tags: xml.sequenceOffset=30

Table 5.42: SwBitRepresentation

Primitive DisplayFormatString
Package M2::AUTOSARTemplates::GenericStructure::GeneralTemplateClasses::PrimitiveTypes
Note This is a display format specifier for the display of values e.g. in documents or in measurement and
calibration systems.
The display format specifier is a subset of the ANSI C printf specifiers with the following
form:

% [flags] [width] [.prec] type character

For more details refer to "ASAM-HarmonizedDataObjects-V1.1.pdf" chapter 13.3.2 DISPLAY OF DATA.
Due to the numerical nature of value settings, only the following type characters are allowed:
• d: Signed decimal integer
• i: Signed decimal integer
• o: Unsigned octal integer
• u: Unsigned decimal integer
• x: Unsigned hexadecimal integer, using "abcdef"
• X: Unsigned hexadecimal integer, using "ABCDEF"
• e: Signed value having the form [-]d.dddd e [sign]ddd where d is a single decimal digit, dddd is
one or more decimal digits, ddd is exactly three decimal digits, and sign is + or -
• E: Identical to the e format except that E rather than e introduces the exponent
5
5

332 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4
Primitive DisplayFormatString
4
• f: Signed value having the form [-]dddd.dddd, where dddd is one or more decimal digits; the
number of digits before the decimal point depends on the magnitude of the number, and the
number of digits after the decimal point depends on the requested precision
• g: Signed value printed in f or e format, whichever is more compact for the given value and
precision; trailing zeros are truncated, and the decimal point appears only if one or more digits
follow it
• G: Identical to the g format, except that E, rather than e, introduces the exponent (where
appropriate)
Tags: xml.xsd.customType=DISPLAY-FORMAT-STRING
xml.xsd.pattern=%[ \-+#]?[0-9]*(\.[0-9])?[diouxXfeEgGcs]
xml.xsd.type=string

Table 5.43: DisplayFormatString

Class Annotation
Package M2::MSR::Documentation::Annotation
Note This is a plain annotation which does not have further formal data.
Base ARObject, GeneralAnnotation
Attribute Type Mul. Kind Note
– – – – –
Table 5.44: Annotation

[constr_1244] DataPrototypes used in application software shall not be typed

by C enums d A DataPrototype that is used in an AtomicSwComponentType shall
not set swDataDefProps.additionalNativeTypeQualifier to enum. c()
[TPS_SWCT_01272] Semantics of swComparisonVariable d Please note that
swComparisonVariables shall be displayed in the MCD system on the ordinate in
a curve. By showing the input value and the comparison value the calibration engineer
can see if the current working point is above or below a curve provident thresholds.
For example in a curve specifying a temperature depending gear shift threshold en-
gine speed the engine speed can be shown as “comparisonVariable”.
These variables can be used to display the value of a variable on the value axis of a cal-
ibration parameter (characteristic), that is currently displayed in the MCD-System. The
purpose is to compare the appropriate result from the calibration parameter in question,
with a value being calculated or taken from a sensor (the comparison variable).
The sole purpose of this comparison-variable is therefore to serve the calibration pro-
cess. c()
The meaning behind swComparisonVariable is depicted in Figure 5.29. Legend:
tx represents the current temperature and tmot represents the motor temperature. V
represents the current speed as shown in the MCD system for comparison: this is the
swComparisonVariable. Likewise, Vs represents the speed characteristic over the
temperature.

333 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Vs

tx tmot
Figure 5.29: Explanation of swComparisonVariable

Enumeration SwCalibrationAccessEnum
Package M2::MSR::DataDictionary::DataDefProperties
Note Determines the access rights to a data object w.r.t. measurement and calibration.
Literal Description
notAccessible The element will not be accessible via MCD tools, i.e. will not appear in the ASAP file.
Tags: atp.EnumerationValue=0
readOnly The element will only appear as read-only in an ASAP file.
Tags: atp.EnumerationValue=1
readWrite The element will appear in the ASAP file with both read and write access.
Tags: atp.EnumerationValue=2

Table 5.45: SwCalibrationAccessEnum

[TPS_SWCT_01273] Precedence rules for the application of SwDataDefProps d

SwDataDefProps can be specified on various levels, from type over prototype to in-
stantiation, finally data access and calibration support after RTE generation. In general,
properties specified on prototype level override the ones specified on type level.
More formally, the precedence of such properties is:
1. attributes of SwDataDefProps defined on ApplicationDataType which may
be overwritten by
2. attributes of SwDataDefProps defined on ImplementationDataType which
may be overwritten by
3. attributes of SwDataDefProps defined on DataPrototype which may be over-
written by
4. attributes of SwDataDefProps defined on InstantiationDataDefProps
which may be overwritten by
5. attributes of SwDataDefProps defined on ParameterAccess respectively Ar-
gument which may be overwritten by

334 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

6. attributes of SwDataDefProps defined on FlatInstanceDescriptor which

may be overwritten by
7. attributes of SwDataDefProps defined on McDataInstance
c()
Note that details about applicable attributes of SwDataDefProps can be found in Ta-
ble 5.39.
[TPS_SWCT_01274] SwDataDefProps used to support calibration and measure-
ment d The last item in the list of use cases contained in [TPS_SWCT_01273] denotes
that SwDataDefProps are also used as part of McSupportData which is a direct in-
put to the generation of measurement and calibration configuration formats (so-called
A2L-files). This use case is further explained in [6]. Since these data are generated
by the RTE, they will use a copy of the properties according to the precedence given
above.
However, even in this use case which comes after RTE generation it is possible that
properties relevant for the MCD system are added which had been undefined so far.
This for example, applies to the attribute swRefreshTiming which denotes a timing
information relevant for the measurement system; this information may be set rather
late in the process chain. c()
Obviously such an override is not applicable in all cases. In particular, the properties
covering the structure shall not be redefined on DataPrototype. Implementation
policy, semantics and code generation policy may be changed under consideration of
compatibility rules.
Access policy for the MCD system is the most likely subject to be redefined on the
DataPrototype of even on an instantiation level.
Section 5.4.3 describes how SwDataDefProps are used for measuring purposes
while Section 5.4.4 describes the construction of characteristics based on the com-
bination of SwDataDefProps with DataPrototypes.
Section 2.2.2 describes in which context calibration parameters can be defined. Fi-
nally, sections 2.2.3, 7.5.4, and 5.5.4 show how calibration parameters are used in
RunnableEntitys and show the link to an actual ECU implementation.
Enumeration SwImplPolicyEnum
Package M2::MSR::DataDictionary::DataDefProperties
Note Specifies the implementation strategy with respect to consistency mechanisms of variables.
Literal Description
5

335 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4
Enumeration SwImplPolicyEnum
const forced implementation such that the running software within the ECU shall not modify it. For example
implemented with the "const" modifier in C. This can be applied for parameters (not for those in
NVRAM) as well as argument data prototypes.
Tags: atp.EnumerationValue=0
fixed This data element is fixed. In particular this indicates, that it might also be implemented e.g. as in
place data, (#DEFINE).
Tags: atp.EnumerationValue=1
measurementPoint The data element is created for measurement purposes only. The data element is never read directly
within the ECU software. In contrast to a "standard" data element in an unconnected provide port is,
this unconnection is guaranteed for measurementPoint data elements.
Tags: atp.EnumerationValue=2
queued The content of the data element is queued and the data element has ’event’ semantics, i.e. data
elements are stored in a queue and all data elements are processed in ’first in first out’ order.
The queuing is intended to be implemented by RTE Generator.
This value is not applicable for parameters.
Tags: atp.EnumerationValue=3
standard This is applicable for all kinds of data elements. For variable data prototypes the ’last is best’
semantics applies. For parameter there is no specific implementation directive.
Tags: atp.EnumerationValue=4

Table 5.46: SwImplPolicyEnum

[TPS_SWCT_01275] values of the attribute swImplPolicy are restricted depend-

ing on the context d The values of the attribute swImplPolicy are restricted (sum-
marized in table 5.47) depending on the context. This restriction reflects the fact that
not all possible implementation strategies are useful or supported for all kinds of Dat-
aPrototypes. c()
The restrictions summarized in table 5.47 are formalized in a set of constraints below
the table.
Please note that the usage of swImplPolicy is further constraint in the combination
with the attribute value swCalibrationAccess as described in [constr_1017].
Attribute of SwImplPolicyEnum VariableDataPrototype ParameterDataPrototype Misc.
in role implicitInterRunnableVariable

in role explicitInterRunnableVariable

in role arTypedPerInstanceMemory

in role perInstanceParameter
in SenderReceiverInterface

ParameterDataPrototype

ParameterDataPrototype

ParameterDataPrototype

ParameterDataPrototype

ParameterDataPrototype
VariableDataPrototype

VariableDataPrototype

VariableDataPrototype

VariableDataPrototype

VariableDataPrototype

VariableDataPrototype

ArgumentDataPrototype
VariableDataPrototype

in role sharedParameter
in ParameterInterface

in role constantMemory
in role staticMemory
in NvDataInterface

in role ramBlock

in role romBlock

SwServiceArg

336 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4
const NA NA NA NA NA NA NA x NA x x x NA x
fixed NA NA NA NA NA NA NA x NA NA NA x NA NA
measurementPoint x NA NA NA NA x x NA NA NA NA NA NA NA
queued x NA NA NA NA NA NA NA NA NA NA NA NA NA
standard x x x x x x x x x x x x x x

Table 5.47: Allowed attributes values for swImplPolicy vs. DataPrototypes and their
roles

The following settings apply in table 5.47:

x Attribute is applicable for usage in the scope of this element.
NA Attribute is not applicable for usage in the scope of this element.
[constr_2035] swImplPolicy for VariableDataPrototype in Sender-
ReceiverInterface d The overriding swImplPolicy attribute value of a Vari-
ableDataPrototype in SenderReceiverInterface shall be standard,
queued or measurementPoint. c()
[constr_2036] swImplPolicy for VariableDataPrototype in NvDataInter-
face d The overriding swImplPolicy attribute value of a VariableDataProto-
type in NvDataInterface shall be standard. c()
[constr_2037] swImplPolicy for VariableDataPrototype in the role ram-
Block d The overriding swImplPolicy attribute value of a VariableDataProto-
type in the role ramBlock shall be standard. c()
[constr_2038] swImplPolicy for VariableDataPrototype in the role implic-
itInterRunnableVariable d The overriding swImplPolicy attribute value of a
VariableDataPrototype in the role implicitInterRunnableVariable shall
be standard. c()
[constr_2039] swImplPolicy for VariableDataPrototype in the role explic-
itInterRunnableVariable d The overriding swImplPolicy attribute value of a
VariableDataPrototype in the role explicitInterRunnableVariable shall
be standard. c()
[constr_2040] swImplPolicy for VariableDataPrototype in the role arType-
dPerInstanceMemory d The overriding swImplPolicy attribute value of a Vari-
ableDataPrototype in the role arTypedPerInstanceMemory shall be standard
or measurementPoint. c()
[constr_2041] swImplPolicy for VariableDataPrototype in the role stat-
icMemory d The overriding swImplPolicy attribute value of a VariableDataPro-
totype in the role staticMemory shall be standard or measurementPoint. c
()
[constr_2042] swImplPolicy for ParameterDataPrototype in ParameterIn-
terface d The overriding swImplPolicy attribute value of a ParameterDataPro-
totype in ParameterInterface shall be standard, const or fixed. c()

337 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[constr_2043] swImplPolicy for ParameterDataPrototype in the role

romBlock d The overriding swImplPolicy attribute value of a ParameterDat-
aPrototype in the role romBlock shall be standard. c()
[constr_2044] swImplPolicy for ParameterDataPrototype in the role
sharedParameter d The overriding swImplPolicy attribute value of a Parame-
terDataPrototype in the role sharedParameter shall be standard, const. c
()
[constr_2045] swImplPolicy for ParameterDataPrototype in the role perIn-
stanceParameter d The overriding swImplPolicy attribute value of a Param-
eterDataPrototype in the role perInstanceParameter shall be standard,
const. c()
[constr_2046] swImplPolicy for ParameterDataPrototype in the role con-
stantMemory d The overriding swImplPolicy attribute value of a ParameterDat-
aPrototype in the role constantMemory shall be standard, const or fixed. c
()
[constr_2047] swImplPolicy for ArgumentDataPrototype d The overriding
swImplPolicy attribute value of a ArgumentDataPrototype shall be standard.
c()
[constr_2048] swImplPolicy for SwServiceArg d The overriding swImplPolicy
attribute value of a SwServiceArg shall be standard or const. c()
[TPS_SWCT_02000] Default value for attribute swImplPolicy d If the attribute
swImplPolicy is not explicitly set at any of the locations listed in “Place of Setting”
for SwDataDefProps the default value standard applies. c()
Please note that the locations listed in “Place of Setting” for SwDataDefProps are
described in Table 5.39.

5.4.2 Invalid Value

The diagram 5.5 shows that in addition to the semantics defined through the com-
puMethod (explained below in chapter 5.5.1), also an invalidValue can be spec-
ified. This is a requirement of the VFB [3], allowing to express which specific value is
used to indicate invalidation.

338 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

ARElement AtpPrototype
AtpType
DataPrototype
AutosarDataType

+swDataDefProps 0..1 +/swDataDefProps 0..1

«atpVariation»
SwDataDefProps

+invalidValue 0..1

ValueSpecification

Figure 5.30: Invalid value

The invalidValue can be used in different flavors (also illustrated in Figure 5.6:
• [TPS_SWCT_01432] Keep the invalidValue transparent to the sending
and receiving software components d On the one hand it is possible to keep
the invalidValue transparent to the sending and receiving software compo-
nents. In this case the invalidation API of the RTE on the sender side has to be
used.
The receiving software component can either use the data receive status or the
DataReceiveErrorEvent respectively DataReceivedEvent to decide about
the validity of the received data or the receiving software component can rely on
the reception of an initValue as a default value in case of data invalidation.
In this case the invalid value should (and usually will) be outside of the range
limits defined by the compuMethod. c()
• [TPS_SWCT_01434] Sender and receiver have knowledge of invalid value d
On the other hand it is possible that the communicating software components do
have knowledge about the invalidValue and the invalidValue is visible for
them.
This is in particular the case if the sender and receiver are calculating a checksum
over a larger data structure to implement an end to end communication protec-
tion. To ensure the integrity of the checksums it is required to set invalid values
by the sending component directly and to receive invalid values unchanged.
In this case the invalid value should (and usually will) be inside of the range
limits defined by the compuMethod. c()
• [TPS_SWCT_01436] Different receivers require different handling of data
invalidation d It is possible that in case of 1:n communication different receivers
requiring a different handling of data invalidation depending on the criticality of
its functionality. For instance, one receiver applies the checksum based end to

339 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

end communication protection and another receiver relies on the substitution of

invalid values by invalidValues. c()
A typical use case for putting the invalidValue inside the boundaries of the appli-
cable CompuMethod is a composite data type that contains the values of all individual
wheel speeds. If one of the sensors fails and starts to send invalidValue it would
probably not make sense to consider the whole composite data element invalid.
It may very likely still be possible to make sense of the remaining intact wheel speed
values and carry on with whatever business the receiving software-component has with
that data.
From this perspective, it would obviously be OK for the sending software-component to
actively send the invalidValue that is then processed as a “regular” value without
applying additional semantics by the RTE/Com.
[TPS_SWCT_01646] Sending invalidValue without invalidation applied by
RTE/Com d For intentionally sending invalidValue without invalidation ap-
plied by RTE/Com the SenderReceiverInterface.invalidationPolicy.han-
dleInvalid shall be set to the value HandleInvalidEnum.dontInvalidate. c
()
[constr_1390] Restriction to the value of SenderReceiverInterface.in-
validationPolicy.handleInvalid d If the value of SenderReceiverInter-
face.invalidationPolicy.handleInvalid is set to any value other than Han-
dleInvalidEnum.dontInvalidate then the invalidValue shall not be within the
interval defined by the CompuMethod of the applicable dataElement. c()
Please note that ApplicationPrimitiveDataTypes of category VALUE in prin-
ciple can have an invalidValue provided by a NumericalValueSpecification
because the value of the attribute invalidValue can be outside the range of the
applicable CompuMethod (see [TPS_SWCT_01432]).
[TPS_SWCT_01437] invalidValue can also be specified without setting a
compuMethod d An invalidValue can also be specified without setting a com-
puMethod. c()
Figure 5.6 illustrates the relationship between ApplicationDataType, Com-
puMethod, ImplementationDataType, invalidValue, BaseType.
[constr_2545] invalidValue shall fit in the specified ranges d The invalid-
Value shall be in the range of the ImplementationDataType. c()
Please note that the invalidValue is a ValueSpecification. Of course, it would
technically be possible to use any subclass of ValueSpecification at this place.
[constr_1016] Restriction of invalidValue for ImplementationDataType and
ImplementationDataTypeElement d invalidValue for Implementation-
DataType and ImplementationDataTypeElement is restricted to to be either a

340 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

compatible NumericalValueSpecification, TextValueSpecification (cau-

tion, [constr_1284] applies) or a ConstantReference that in turn points to a compat-
ible ValueSpecification. c()
[constr_1384] Definition of invalidValue for DataPrototype typed by Ap-
plicationPrimitiveDataType of category CURVE, MAP, CUBOID, CUBE_4,
CUBE_5, COM_AXIS, RES_AXIS, and VAL_BLK d An invalidValue shall not be
specified for a DataPrototype typed by ApplicationPrimitiveDataType of
category CURVE, MAP, CUBOID, CUBE_4, CUBE_5, COM_AXIS, RES_AXIS, and
VAL_BLK c()
Rationale for [constr_1384]: there is no use case for sending a DataPrototype
typed by ApplicationPrimitiveDataType of category CURVE, MAP, CUBOID,
CUBE_4, CUBE_5, COM_AXIS, RES_AXIS, and VAL_BLK over a communication bus.
[constr_1242] Restriction of invalidValue for ApplicationPrimitive-
DataType of category STRING d invalidValue for ApplicationPrimitive-
DataType of category STRING ([constr_1241] applies) is restricted to be either a
compatible ApplicationValueSpecification or a ConstantReference that in
turn points to a compatible ApplicationValueSpecification. c()
[TPS_SWCT_01487] Correspondence of invalidValue for ApplicationPrim-
itiveDataType and ImplementationDataType d The invalidValue specified
on the level of an ApplicationPrimitiveDataType shall correspond to the in-
validValue specified on the level of a compatible ImplementationDataType. The
terms “corresponds” boils down to:
• category VALUE or BOOLEAN: application of CompuMethod
• category STRING: mapping of the encoding on the ApplicationPrimi-
tiveDataType side to the numerical values on the level of the Implementa-
tionDataType (shall reference SwBaseType with baseTypeEncoding set to
NONE). There is no formal support defined to check that the values of invalid-
Value really correspond to each other.
c()
[constr_1225] DataPrototype is typed by an ImplementationDataType that
references a CompuMethod of category TEXTTABLE or BITFIELD_TEXTTABLE d
If a DataPrototype is typed by an ImplementationDataType that references
a CompuMethod of category TEXTTABLE or BITFIELD_TEXTTABLE the applicable
ValueSpecification shall be a TextValueSpecification.
In this case the value provided shall match to one of the applicable text values (vt,
shortLabel, symbol) defined by the applicable CompuScales. c()
Please note that several attributes of meta-class CompuScale can be taken to describe
the actual value. It is therefore necessary to clarify what happens if several of these
attributes exist within the context of one CompuScale. This clarification can be found
in [TPS_SWCT_01696].

341 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[TPS_SWCT_01467] ImplementationDataType references an SwBaseType with

a string encoding d If an ImplementationDataType references an SwBaseType
with a string encoding the initValue shall still be provided as numerical values ac-
cording to the string encoding. c()
[constr_1302] Restriction of data invalidation d Data invalidation is only applicable
for one of the following cases applicable on the receiving side:
1. VariableDataPrototypes typed by either an ApplicationPrimitive-
DataType or an ImplementationDataType of category VALUE or
TYPE_REFERENCE that boils down to category VALUE that have defined an
invalidValue.
2. VariableDataPrototypes typed by either an ApplicationComposite-
DataType or an ImplementationDataType of category STRUCTURE, or
ARRAY or of category TYPE_REFERENCE that boils down to category STRUC-
TURE, or ARRAY that have at least one primitive element with an invalidValue.
c()
Please note that [constr_1302], in general, leaves room for the definition of an invalid
value for a DataPrototype typed by a Wrapped Union Data Type because it
demands the existence of a primitive element that has an invalidValue. In the
case of a Wrapped Union Data Type, the primitive element could be the Member
Selector, and thus [constr_1302] would technically be fulfilled.
On the one hand, it does not make sense to just define an invalid value for the Member
Selector from the semantic point of view. On the other hand, the actual payload may
not even have an invalid value according to [constr_1009] or [constr_1288], respec-
tively.
In order to simplify the situation and make a clear statement, [constr_1446] has been
defined.
[constr_1446] No definition of invalidValue for a Wrapped Union Data Type
d The definition of an invalidValue for a DataPrototype typed by a Wrapped
Union Data Type is not supported. c()
[constr_1140] Combination of invalidValue with the attribute handleInvalid
d The combination of setting the attribute handleInvalid of the meta-class Inval-
idationPolicy owned by SenderReceiverInterface to value replace and of
setting the value of the attribute initValue owned by a corresponding Nonqueue-
dReceiverComSpec effectively to the value of the invalidValue (owned by a cor-
responding SwDataDefProps) is not supported. c()
The term “corresponding” (as utilized in [constr_1140]) refers to the fact that informa-
tion regarding the fulfillment of [constr_1140] is factually distributed over different areas
of the meta-model. For clarification, the following relationship should be considered:
The SenderReceiverInterface defines how to deal with an invalid value by means
of the attribute handleInvalid on the basis of individual dataElements. The

342 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

SenderReceiverInterface is taken for typing a RPortPrototype that in turn

owns a ReceiverComSpec. [constr_1140] applies if the particular ReceiverCom-
Spec is actually a NonqueuedReceiverComSpec that refers to the same dataEle-
ment.
In this case the invalidValue owned by the SwDataDefProps that in turn is owned
by the respective dataElement is relevant for the fulfillment of [constr_1140]. The
“big picture” of this relationship is sketched in Figure 5.31.
[constr_1219] Invalidation depends on the value of swImplPolicy d Invalidation
of dataElements is only supported for dataElements where the value of swIm-
plPolicy is not set to queued. c()

343 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

AbstractRequiredPortPrototype
RPortPrototype

«isOfType»
1
+requiredInterface {redefines atpType}

ARElement
AtpBlueprint
AtpBlueprintable
AtpType RPortComSpec
PortInterface

+ isService: Boolean
+ serviceKind: ServiceProviderEnum [0..1]

DataInterface ReceiverComSpec

+ handleOutOfRange: HandleOutOfRangeEnum
+ handleOutOfRangeStatus: HandleOutOfRangeStatusEnum [0..1]
+ maxNoNewOrRepeatedData: PositiveInteger [0..1]
+ syncCounterInit: PositiveInteger [0..1]
«atpVariation»
SenderReceiverInterface
+ maxDeltaCounterInit: PositiveInteger [0..1]
+ usesEndToEndProtection: Boolean [0..1]

+dataElement 1..*

AutosarDataPrototype
NonqueuedReceiverComSpec
VariableDataPrototype
+ aliveTimeout: TimeValue
+ enableUpdate: Boolean
+dataElement 1 + handleDataStatus: Boolean [0..1]
+ handleNeverReceived: Boolean
+ handleTimeoutType: HandleTimeoutEnum
+invalidationPolicy 0..*

InvalidationPolicy

+ handleInvalid: HandleInvalidEnum [0..1]

+networkRepresentation 0..1 +timeoutSubstitutionValue 0..1 +initValue 0..1

«enumeration» «atpVariation» ValueSpecification

HandleInvalidEnum SwDataDefProps +invalidValue
+ shortLabel: Identifier [0..1]
keep + additionalNativeTypeQualifier: NativeDeclarationString [0..1] 0..1
replace + displayFormat: DisplayFormatString [0..1]
dontInvalidate + displayPresentation: DisplayPresentationEnum [0..1]
externalReplacement + 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 5.31: Relationships required to consider the invalidValue

[constr_1282] Restriction concerning the usage of RuleBasedValueSpecifi-

cation or a ReferenceValueSpecification for the specification of an in-
validValue d The aggregation of a RuleBasedValueSpecification or a Ref-
erenceValueSpecification for the definition of a ApplicationPrimitive-
DataType.swDataDefProps.invalidValue is not supported. c()

344 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

5.4.3 Properties for Measurement

In embedded automotive software design, measurement means access to memory

locations in an ECU and transferring its contents to the measurement & calibration
system. While in classical software design, variables abstract the memory locations in
the code, AUTOSAR provides for this purpose the DataPrototype with its various
specializations:
• VariableDataPrototype of a SenderReceiverInterface or NvDataIn-
terface used in a PortPrototype (of a SwComponentPrototype), to cap-
ture sender-receiver and non volatile data communication between SwCompo-
nentPrototypes
• ArgumentDataPrototype of a ClientServerOperation in a
ClientServerInterface to capture client-server communication between
SwComponentPrototypes.
• VariableDataPrototype in the context of an SwcInternalBehavior to
– capture communication between RunnableEntitys within a SwCompo-
nentPrototype
– handle data in a non volatile memory block
– provide pure software component internal memory which has to be accessi-
ble for a MCD system
[TPS_SWCT_01440] Measurement is not limited to primitive objects d The ability
of being measured is not restricted to primitive data (category VALUE) but can also
be applied to composite data (category STRUCTURE or ARRAY). c()
The following semantical and structural features from SwDataDefProps are relevant
(among other purposes) for the measurement system:
• swCalibrationAccess
• swImplPolicy
• compuMethod
• unit (if not specified by compuMethod)
• baseType
• swAddrMethod
[TPS_SWCT_01130] Measurement and calibration access to model elements is
defined by swCalibrationAccess d The ability to be accessed by e.g. a calibration
tool is given by setting the swCalibrationAccess attribute. c(RS_SWCT_03152)
The following table shows all valid settings of swCalibrationAccess:

345 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[TPS_SWCT_01559] Default value for attribute SwDataDefProps.swCalibra-

tionAccess d The default value for the attribute SwDataDefProps.swCalibra-
tionAccess is SwCalibrationAccessEnum.notAccessible. c()
[constr_1017] Supported combinations of swImplPolicy and swCalibra-
tionAccess d The table 5.48 defines the supported combinations of swImplPolicy
and swCalibrationAccess attribute setting. c()
swImplPolicy swCalibrationAccess
notAccessible readOnly readWrite
fixed yes not supported not supported
const yes yes not supported
standard yes yes yes
queued yes not supported not supported
measurementPoint not supported yes not supported

Table 5.48: Supported combinations of swImplPolicy and swCalibrationAccess

[constr_1018] measurementPoint shall not be referenced by a VariableAc-

cess aggregated by RunnableEntity in the role dataReadAccess d Due to the
nature of dataElements characterized by setting the swImplPolicy to measure-
mentPoint, such dataElements shall not be referenced by a VariableAccess
aggregated by RunnableEntity in the role dataReadAccess. c()

5.4.4 Properties of Curves and Maps

A characteristic table is defined by setting the category of the corresponding Au-

tosarDataType or DataPrototype to CURVE respectively MAP, CUBOID, CUBE_4,
and CUBE_5.
Its SwDataDefProps determine an axis description. The type of the functional values
is given by the attached SwBaseType and the CompuMethod.
The axis description itself is defined by the meta-model element SwCalprmAxisSet
aggregating the appropriate number of SwCalprmAxisTypeProps.
This is the base class for a so called “individual axis” (formalized by meta-class SwAx-
isIndividual) or a “grouped axis” (formalized by meta-class SwAxisGrouped).
The latter is used to share axis points by several characteristic tables. Figure 5.32
shows an overview on the relevant meta-model elements.
The type of the functional values is given by the attached SwBaseType and the Com-
puMethod or by the referenced ApplicationDataType.
If an ApplicationDataType is referenced (via valueAxisDataType) this super-
sedes CompuMethod, Unit, and BaseType if these are defined in parallel.

346 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

ARElement
SwCalprmAxis SwAxisIndividual +dataConstr AtpBlueprint
AtpBlueprintable
0..1
DataConstr

ARElement
AtpBlueprint
+compuMethod
AtpBlueprintable
0..1 CompuMethod

+unit 0..1

ARElement
+unit Unit

0..1

1 +swCalprmAxisTypeProps

SwCalprmAxisTypeProps

SwAxisGeneric
+swAxisGeneric

0..1

SwVariableRefProxy
+swVariableRef

0..*
{ordered}

ApplicationDataType

+inputVariableType ApplicationPrimitiveDataType

0..1

+sharedAxisType 0..1

SwAxisGrouped

SwCalprmRefProxy
+swCalprmRef

Figure 5.32: Overview on the Meta-Model for Axis Description

347 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

SwAxisGeneric

+swAxisType 1 +swGenericAxisParam 0..*

ARElement
SwGenericAxisParam
SwAxisType
«atpVariation»
+ vf: Numerical [1..*] {ordered}

+swGenericAxisParamType 0..* +swGenericAxisParamType 1

Identifiable
SwGenericAxisParamType

Figure 5.33: Overview on a Generic Axis

Figure 5.34 shows how an individual axis is represented by the meta-model. The corre-
sponding M1 Model is illustrated in Figure 5.35. The SwAxisIndividual references
value-models to account the minimum and the maximum number of axis values as well
as the number of axis points.
Hence, the size of the structure to hold the functional values is determined by the
number of axis values for all axes. The type of the axis values is determined when the
type of the referenced input value (swVariableRef) has been set. For further details
see 5.4.5.
[TPS_SWCT_01107] swMinAxisPoints and swMaxAxisPoints represent varia-
tion points d The value of attributes swMinAxisPoints and swMaxAxisPoints is
subject to variant handling. c(RS_SWCT_03148)

348 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

ARElement ARElement
AtpBlueprint
SwRecordLayout
AtpBlueprintable
SwAddrMethod

+swRecordLayout 0..1 0..1

+swAddrMethod

AtpBlueprint «atpVariation»
AtpBlueprintable +baseType SwDataDefProps
BaseType
SwBaseType 0..1

0..1

+baseType

+swCalprmAxisSet 0..1 +compuMethod 0..1 +dataConstr 0..1

ARElement ARElement
SwCalprmAxisSet
AtpBlueprint AtpBlueprint
AtpBlueprintable AtpBlueprintable
CompuMethod DataConstr

0..1
+dataConstr 0..1
+compuMethod

+swCalprmAxis 0..*

SwCalprmAxis

+swCalprmAxisTypeProps 1 +unit 0..1 +unit 0..1

ARElement
SwCalprmAxisTypeProps
Unit

0..1

+unit

SwAxisGrouped SwAxisIndividual

0..*
+swCalprmRef 1 +swVariableRef {ordered}

SwCalprmRefProxy SwVariableRefProxy

Figure 5.34: Meta-Model Elements used for a Curve

349 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Element: ApplicationDataType

category = CURVE
shortName = MyCurve

swDataDefProps: SwDataDefProps Element: Unit

Element: CompuMethod

Element: SwAddrMethod

Element: SwRecordLayout

swCalprmAxisSet:
SwCalprmAxisSet

swCalprmAxis: SwCalprmAxis

swCalprmAxisTypeProps: Element:
SwAxisIndividual ApplicationPrimitiveDataType

swDataDefProps: SwDataDefProps Element: CompuMethod

   



Element: Unit

Figure 5.35: Illustration of a Curve in M1

Class SwCalprmAxisSet
Package M2::MSR::DataDictionary::CalibrationParameter
Note This element specifies the input parameter axes (abscissas) of parameters (and variables, if these are
used adaptively).
Base ARObject
Attribute Type Mul. Kind Note
5

350 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4
Class SwCalprmAxisSet
swCalprmAxis SwCalprmAxis * aggr One axis belonging to this SwCalprmAxisSet
Tags: xml.roleElement=true
xml.roleWrapperElement=false
xml.sequenceOffset=20
xml.typeElement=false
xml.typeWrapperElement=false

Table 5.49: SwCalprmAxisSet

Class SwCalprmAxis
Package M2::MSR::DataDictionary::CalibrationParameter
Note This element specifies an individual input parameter axis (abscissa).
Base ARObject
Attribute Type Mul. Kind Note
category CalprmAxisCategory 0..1 attr This property specifies the category of a particular axis.
Enum
Tags: xml.sequenceOffset=30
baseType SwBaseType 0..1 ref The SwBaseType to be used for the axis. Note that this is
not applicable for ApplicationDataTypes. The value shall
be ignored.
Tags: atp.Status=removed
xml.sequenceOffset=110
displayFormat DisplayFormatString 0..1 attr This property specifies how the axis values shall be
displayed e.g. in documents or in measurement and
calibration tools.
Tags: xml.sequenceOffset=100
swAxisIndex AxisIndexType 0..1 attr This attribute specifies which axis is specified by the
containing SwCalprmAxis.
For example in a curve this is usually "1". In a map this is
"1" or "2".
Tags: xml.sequenceOffset=20
swCalibration SwCalibrationAccess 0..1 attr Describes the applicability of parameters and variables.
Access Enum
Tags: xml.sequenceOffset=90
swCalprmAxis SwCalprmAxisType 1 aggr specific properties depending on the type of the axis.
TypeProps Props
Tags: xml.roleElement=false
xml.roleWrapperElement=false
xml.sequenceOffset=40
xml.typeElement=true
xml.typeWrapperElement=false

Table 5.50: SwCalprmAxis

Enumeration CalprmAxisCategoryEnum
Package M2::MSR::DataDictionary::CalibrationParameter
Note This enum specifies the possible values of the category property within SwCalprmAxis.
Literal Description
5

351 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4
Enumeration CalprmAxisCategoryEnum
comAxis COM_AXIS is equal to an STD_AXIS, the difference is, that a COM_AXIS is an shared axis, that
means this axis can be used multiple times by different CURVEs, MAPs, CUBOIDs, CUBE_4s, and
CUBE_5s.
Tags: atp.EnumerationValue=0
xml.name=COM_AXIS
fixAXIS FIX_AXIS means that the input axis is not stored. The axis is calculated using parameters and so on
it is also not possible to modify the axis points.
Tags: atp.EnumerationValue=4
xml.name=FIX_AXIS
resAxis RES_AXIS is also an shared axis like COM_AXIS, the difference is that this kind of axis can be used
for rescaling.
Tags: atp.EnumerationValue=6
xml.name=RES_AXIS
stdAxis STD_AXIS means that input and output axis definition are stored within this CURVE, MAP, CUBOID,
CUBE_4, and CUBE_5.
There is no shared or calculated axis.
Tags: atp.EnumerationValue=8
xml.name=STD_AXIS

Table 5.51: CalprmAxisCategoryEnum

Class SwCalprmAxisTypeProps (abstract)

Package M2::MSR::DataDictionary::CalibrationParameter
Note Base class for the type of the calibration axis. This provides the particular model of the specialization. If
the specialization would be the directly from SwCalPrmAxis, the sequence of common properties and the
specializes ones would be different.
Base ARObject
Subclasses SwAxisGrouped, SwAxisIndividual
Attribute Type Mul. Kind Note
maxGradient Float 0..1 attr This attribute defines the maximum permissible gradient
for an adjustable object (curve, map or cuboid) with
respect to a specific axis.
MaxGrad = maximum( absolute((Value i,k - Value
i-1,k)/(Axis Point i - Axis Point i-1)) )
monotony MonotonyEnum 0..1 attr This attribute specifies the monotony constraint for an
adjustable object (curve, map or cuboid) with respect to a
specific axis. This information can be used by MCD
system to verify whether the monotony constraint is
fulfilled and to prevent from changes violating the
constraint.
Table 5.52: SwCalprmAxisTypeProps

Class SwAxisIndividual
Package M2::MSR::DataDictionary::Axis
Note This meta-class describes an axis integrated into a parameter (field etc.). The integration makes this
individual to each parameter. The so-called grouped axis represents the counterpart to this. It is
conceived as an independent parameter (see class SwAxisGrouped).
Base ARObject, SwCalprmAxisTypeProps
5

352 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4
Class SwAxisIndividual
Attribute Type Mul. Kind Note
compuMethod CompuMethod 0..1 ref This is the compuMethod which is expected for the axis. It
is used in early stages if the particular input-value is not
yet available.
Tags: xml.sequenceOffset=30
dataConstr DataConstr 0..1 ref Refers to constraints, e.g. for plausibility checks.
Tags: xml.sequenceOffset=80
inputVariable ApplicationPrimitive 0..1 ref This is the datatype of the input value for the axis. This
Type DataType allows to define e.g. a type of curve, where the input
value is finalized at the access point.
swAxisGeneric SwAxisGeneric 0..1 aggr this specifies the properties of a generic axis if applicable.
Tags: xml.sequenceOffset=90
swMaxAxis Integer 1 attr Maximum number of base points contained in the axis of
Points a map or curve.
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime
xml.sequenceOffset=60
swMinAxis Integer 1 attr Minimum number of base points contained in the axis of a
Points map or curve.
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime
xml.sequenceOffset=70
swVariable SwVariableRefProxy * aggr Refers to input variables of the axis. It is possible to
Ref (ordered) specify more than one variable. Here the following is
valid:
• The variable with the highest priority shall be
given first. It is used in the generation of the code
and is also displayed first in the application
system.
• All variables referenced shall be of the same
physical nature. This is usually detected in that
the conversion formulae affected refer back to
the same SI-units.
In AUTOSAR this ensured by the constraint, that the
referenced input variables shall use a type compatible to
"inputVariableType".
• This multiple referencing allows a base point
distribution for more than one input variable to be
used. One example of this are the temperature
curves which can depend both on the induction
air temperature and the engine temperature.
These variables can be displayed simultaneously by MCD
systems (adjustment systems), enabling operating points
to be shown in the curves.
Tags: xml.roleElement=false
xml.roleWrapperElement=true
xml.sequenceOffset=20
xml.typeElement=false
xml.typeWrapperElement=false
5

353 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4
Class SwAxisIndividual
unit Unit 0..1 ref This represents the physical unit of the input value of the
axis. It is provided to support the case that the particular
input variable is not yet known.
Tags: xml.sequenceOffset=40

Table 5.53: SwAxisIndividual

Class SwAxisGeneric
Package M2::MSR::DataDictionary::Axis
Note This meta-class defines a generic axis. In a generic axis the axispoints points are calculated in the ECU.
The ECU is equipped with a fixed calculation algorithm. Parameters for the algorithm can be stored in the
data component of the ECU. Therefore these parameters are specified in the data declaration, not in the
calibration data.
Base ARObject
Attribute Type Mul. Kind Note
swAxisType SwAxisType 1 ref Associated axis calculation strategy.
Tags: xml.sequenceOffset=20
swGenericAxis SwGenericAxisParam * aggr Specific parameter of a generic axis.
Param
Tags: xml.roleElement=true
xml.roleWrapperElement=true
xml.sequenceOffset=40
xml.typeElement=false
xml.typeWrapperElement=false

Table 5.54: SwAxisGeneric

Class SwAxisType
Package M2::MSR::DataDictionary::Axis
Note This meta-class represents a specific axis calculation strategy. No formal specification is given, due to
the fact that it is possible to use arbitrary algorithms for calculating axis-points.
Instead, the algorithm is described verbally but the parameters are specified formally with respect to their
names and constraints. As a result, SwAxisType mainly reserves appropriate keywords.
Tags: atp.recommendedPackage=SwAxisTypes
Base ARElement, ARObject, CollectableElement, Identifiable, MultilanguageReferrable, Packageable
Element, Referrable
Attribute Type Mul. Kind Note
swGenericAxis DocumentationBlock 0..1 aggr Associated axis description in textual form.
Desc
Tags: xml.sequenceOffset=20
swGenericAxis SwGenericAxisParam * aggr Parameters for this calculation algorithm.
ParamType Type
Tags: xml.roleElement=true
xml.roleWrapperElement=true
xml.sequenceOffset=30
xml.typeElement=false
xml.typeWrapperElement=false

Table 5.55: SwAxisType

354 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Class SwGenericAxisParam
Package M2::MSR::DataDictionary::Axis
Note This meta-class describes a specific parameter of a generic axis. The name of the parameter is defined
through a reference to a parameter type defined on a corresponding axis type.
The value of the parameter is given here in case that it is not changeable during calibration. Example is
shift / offset in a fixed axis.
Base ARObject
Attribute Type Mul. Kind Note
swGenericAxis SwGenericAxisParam 1 ref Parameter type defined on a corresponding axis type.
ParamType Type References can only be made to axis parameters types
which are defined within the referenced axis type.
Tags: xml.sequenceOffset=20
vf (ordered) Numerical 1..* attr This attribute represents the value of the generic axis
parameter.
Stereotypes: atpVariation
Tags: vh.latestBindingTime=preCompileTime
xml.roleElement=true
xml.roleWrapperElement=false
xml.sequenceOffset=30
xml.typeElement=false

Table 5.56: SwGenericAxisParam

Class SwGenericAxisParamType
Package M2::MSR::DataDictionary::Axis
Note This meta-class describes a generic axis parameter type, namely:
• Plausibility checks can be specified via dataConstr.
• Textual description (desc), as a formal description is not of any use, due to the large variety of
possibilities.
• If this parameter contains structures, these can be simulated through the recursive use of Sw
GenericAxisParamTypes.
Base ARObject, Identifiable, MultilanguageReferrable, Referrable
Attribute Type Mul. Kind Note
dataConstr DataConstr 0..1 ref This refernce denoted data constraints applicable to the
generic axis parameter.
Tags: xml.sequenceOffset=20

Table 5.57: SwGenericAxisParamType

Class SwAxisGrouped
Package M2::MSR::DataDictionary::Axis
Note An SwAxisGrouped is an axis which is shared between multiple calibration parameters.
Base ARObject, SwCalprmAxisTypeProps
Attribute Type Mul. Kind Note
sharedAxisType ApplicationPrimitive 0..1 ref This is the datatype of the calibration parameter providing
DataType the shared axis.
5

355 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

4
Class SwAxisGrouped
swAxisIndex AxisIndexType 0..1 attr Describes which axis of the referenced calibration
parameter provides the values for the group axis.
The index satisfies the following convention:
• 0 = value axis. in this case, the interpolation
result of the referenced parameter is used as a
base point index.
• The index should only be specified if the
parameter under swCalprm contains more than
one axis. It is standard practice for the axis index
of parameters with more than one axis, to be set
to 1, if data has not been assigned to swAxis
Index.
Tags: xml.sequenceOffset=20
swCalprmRef SwCalprmRefProxy 1 aggr This property specifes the calibration parameter which
serves as the input axis. In AUTOSAR, the type of the
referenced Calibration parameter shall be compatible to
the type specified by sharedAxisType.
Tags: xml.roleElement=false
xml.roleWrapperElement=false
xml.sequenceOffset=30
xml.typeElement=false
xml.typeWrapperElement=false

Table 5.58: SwAxisGrouped

5.4.4.1 Specification of fix Axes

In most cases the axes of a curve or map are accessible to a calibration software and
it is possible to calibrate axes points and their corresponding values.
There are cases, however, where axes are intentionally declared as fix and where no
intention exists to change the properties of the axis ever18 .
These axes are also known as fix axes. The support for the creation of fix axes in the
meta-model is based upon the usage of SwAxisGeneric as depicted in Figure 5.33.
[TPS_SWCT_01747] Value of category for fix axis d A fix axis shall be modeled as
an SwCalprmAxis with attribute category set to the value FIX_AXIS. c()
[TPS_SWCT_01748] Sub-categories of fix axes d There are different sub-categories
of fix axes:
• Fix axis where the distance between axis points can be computed according to a
standardized algorithm.
In this case, fix axes of arbitrary length can be described by feeding three argu-
ments defined in the context of the axis description into the axis algorithm.
18
Typically, a calibration software does not have the ability to manipulate (or even inspect) the axis’
properties by inspecting the ECU’s memory.

356 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Consequently, the memory footprint of different fix axis of this category is liter-
ally identical, independently of the number of axis points.
The following variations exist:
– Subcategory PAR, i.e. category = FIX_AXIS_PAR: the axis is created
out of a starting value and a shift that creates further axis points as using a
power-of-two algorithm. The details can be found in [24].
– Subcategory PAR_DIST, i.e. category = FIX_AXIS_PAR_DIST: the axis
is created out of a starting value and an offset that adds further axis points
with the distance given by offset. The details can be found in [24].
• Fix axis where the axis points are defined as a list of values directly in the axis
definition. This variety boils down to
– Subcategory PAR_LIST, i.e. category = FIX_AXIS_PAR_LIST: the axis
is created out of a list of numerical values that represent the axis points. The
details can be found in [24].
These values of category shall be used for SwAxisType. c()
As mentioned before, the modeling of a fix axis is based upon the definition of the
SwAxisGeneric. But this statement by itself is not yet sufficient to unambiguously
clarify the details of the modeling.
For this purpose, it is necessary to provide further information about the specifics of the
roles SwAxisGeneric.swAxisType and SwAxisGeneric.swGenericAxisParam.
[TPS_SWCT_01749] Semantics of SwAxisGeneric.swAxisType in the definition
of a fix axis d The role SwAxisGeneric.swAxisType specifies the category of the
fix axis according to [TPS_SWCT_01748]. c()
[TPS_SWCT_01750] Semantics of SwAxisGeneric.swGenericAxisParam in the
definition of a fix axis d The role SwAxisGeneric.swGenericAxisParam provides
the actual numeric values for the definition of the axis.
The semantics of a provided numerical value is clarified by the attribute SwGeneri-
cAxisParamType.category where meta-class SwGenericAxisParamType is ref-
erenced in the role swGenericAxisParamType. c()
category of swAxisType category of SwGenericAxis- Multiplicity of swGenericAxis- Multiplicity of vf
ParamType Param
FIX_AXIS_PAR OFFSET 1 1
SHIFT 1 1
FIX_AXIS_PAR_DIST OFFSET 1 1
DISTANCE 1 1
FIX_AXIS_PAR_LIST LIST 1 1..*
Table 5.59: Modeling of SwAxisGeneric

357 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[constr_1544] Modeling of SwAxisGeneric for the definition of a fix axis d The

standardized values and multiplicities within the model of an SwAxisGeneric accord-
ing to [TPS_SWCT_01479] and [TPS_SWCT_01480] are documented in Table 5.59. c
()
The modeling of an axis of category FIX_AXIS_PAR is sketched in the following ex-
ample model (Figure 5.36).
MyFixAxisDataType:
ApplicationPrimitiveDataType

category = CURVE

swDataDefProps:
SwDataDefProps

swCalprmAxisSet:
SwCalprmAxisSet

swCalprmAxis: SwCalprmAxis

category = FIX_AXIS
swAxisIndex = 1

swCalprmAxisTypeProps:
SwAxisIndividual

swAxisGeneric: SwAxisGeneric

offset: swAxisType: SwAxisType shift:

SwGenericAxisParam SwGenericAxisParam
category = FIX_AXIS_PAR
vf = 0 vf = 2

offset: SwGenericAxisParamType shift: SwGenericAxisParamType

category = OFFSET category = SHIFT

Figure 5.36: Modeling of a fix axis of category FIX_AXIS_PAR

358 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

The modeling of an axis of category FIX_AXIS_PAR_DIST is sketched in the following

example model (Figure 5.37).
MyFixAxisDataType:
ApplicationPrimitiveDataType

category = CURVE

swDataDefProps: SwDataDefProps

swCalprmAxisSet: SwCalprmAxisSet

swCalprmAxis: SwCalprmAxis

category = FIX_AXIS
swAxisIndex = 1

swCalprmAxisTypeProps:
SwAxisIndividual

swAxisGeneric: SwAxisGeneric

offset: swAxisType: SwAxisType distance:

SwGenericAxisParam SwGenericAxisParam
category = FIX_AXIS_PAR_DIST
vf = 3 vf = 5

offset: SwGenericAxisParamType distance: SwGenericAxisParamType

category = OFFSET category = DISTANCE

Figure 5.37: Modeling of a fix axis of category FIX_AXIS_PAR_DIST

The modeling of an axis of category FIX_AXIS_PAR_LIST is sketched in the following

example model (Figure 5.38).

359 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

MyFixAxisDataType:
ApplicationPrimitiveDataType

category = CURVE

swDataDefProps: SwDataDefProps

swCalprmAxisSet: SwCalprmAxisSet

swCalprmAxis: SwCalprmAxis

category = FIX_AXIS
swAxisIndex = 1

swCalprmAxisTypeProps:
SwAxisIndividual

swAxisGeneric: SwAxisGeneric

swAxisType: SwAxisType :SwGenericAxisParam

category = FIX_AXIS_PAR_LIST vf = 1,5,42

axisPoint2: SwGenericAxisParamType

category = LIST

Figure 5.38: Modeling of a fix axis of category FIX_AXIS_PAR_LIST

Please note that the axis points and values of a fix axis are defined in the definition of
the fix axis itself and therefore any initial value assigned to a fix axis would be ignored
anyway.
This might lead to confusion such that the initial value does not make it into the soft-
ware. In order to avoid such confusion AUTOSAR does not support the definition of
an initial value for a fix axis.
This regulation is reflected in the existence of [constr_1545].

360 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

[constr_1545] No initialization for fix axis d An ApplicationValueSpecifica-

tion taken to initialize an ApplicationPrimitiveDataType that contains a fix
axis shall not contain initial values for the axis index of the fix axis inside the Appli-
cationPrimitiveDataType. c()
Please note that the calibration software may have still have access to axis points and
values of the fix axis if these properties are specified in an A2L file.
For this purpose McDataInstance needs to be set up properly. The details are ex-
plained in [6].

5.4.5 Setting an Axis Input Value

When an interpolation routine is called, an input value has to be provided to find the ap-
propriate axis entry in the implementation of a RunnableEntity. However, this input
value cannot be arbitrarily chosen but only be selected from available VariableDat-
aPrototype assigned to it.
In an axis definition attached to an ApplicationPrimitiveDataType, it is possible
to specify the data type of the input values by means of the reference SwAxisIndi-
vidual.inputVariableType.
However, the reference SwAxisIndividual.inputVariableType does not neces-
sarily have to exist.
This leaves the consideration of compatibility between the DataPrototype(s) refer-
enced by means of SwAxisIndividual.swVariableRef and the actual axis speci-
fication to the following attributes:
• SwAxisIndividual.dataConstr
• SwAxisIndividual.compuMethod
• SwAxisIndividual.unit
[TPS_SWCT_01676] Preferred approach to checking the compatibility of input
value and axis d The compatibility in terms of data type between the description of
an SwAxisIndividual and the DataPrototype(s) used as an input variable to the
respective interpolation routine shall preferably be checked alternatively between
• the ApplicationPrimitiveDataType(s) of DataPrototype(s) referenced
by means of SwAxisIndividual.swVariableRef (the provider in terms of
compatibility)
• the ApplicationPrimitiveDataType referenced by means of SwAxisIn-
dividual.inputVariableType (The requester in terms of compatibility).
For compatibility, the compuMethod of SwAxisIndividual.swVariableRef and
the ApplicationPrimitiveDataType referenced by means of SwAxisIndivid-
ual.inputVariableType shall not be considered. c()

361 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Rationale: in many cases the input variable is defined by a float data type to take
benefit from the precision in computations. But the axis data type is an integer data
type to save memory. In this situation, a requirement for compatible compuMethods
would exclude the described scenario.
The implementation of the software-component shall make sure that the float value is
properly converted and rescaled to an integer data type compatible to the axis data
type.
[TPS_SWCT_01677] Fall-back approach to checking the compatibility of input
value and axis d If the reference SwAxisIndividual.inputVariableType does
not exist then the compatibility in terms of data type between the description of an
SwAxisIndividual and the DataPrototype(s) used as an input variable to the re-
spective interpolation routine shall be checked on the basis of the following references:
• SwAxisIndividual.dataConstr
• SwAxisIndividual.unit
respectively
• SwAxisIndividual.dataConstr
• SwAxisIndividual.compuMethod.unit
against their respective counterparts in the ApplicationPrimitiveDataTypes
of the DataPrototype(s) referenced by means of SwAxisIndividual.swVari-
ableRef. c()
[constr_1420] Existence of SwAxisIndividual.inputVariableType d If the ref-
erence SwAxisIndividual.inputVariableType does not exist then either:
• SwAxisIndividual.dataConstr
• SwAxisIndividual.unit
or
• SwAxisIndividual.dataConstr
• SwAxisIndividual.compuMethod.unit
shall exist. c()
The constraint is necessary for the generation of the respective specification of the axis
in A2L.
Every ParameterDataPrototype then allows to specify zero or more input values
(being type compatible to inputVariableType) in its axis description.
This means that at the specification time of an SwcInternalBehavior a list of input
values has to be specified where the implementer of a RunnableEntity can choose
of. The input values are DataPrototype entities either being

362 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

• a VariableDataPrototype in a SenderReceiverInterface or Nv-

DataInterface of a PortPrototype, of the AtomicSwComponentType
where the SwcInternalBehavior is associated to, or an ArgumentDataPro-
totype in a ClientServerOperation of a ClientServerInterface in a
PortPrototype of the AtomicSwComponentType where the InternalBe-
havior is associated to, or
• a VariableDataPrototype within the SwcInternalBehavior.
To achieve this, SwAxisIndividual is aggregating a SwVariableRefProxy.
Originally, MSRSW uses a AutosarVariableRef to set the input value of an axis
appropriately. In AUTOSAR, this has been extended by first introducing a SwVari-
ableRefProxy.
Note that this is a specific use case for the role SwVariableRefProxy.autosar-
Variable.
Note further that the use cases for the existence of the attributes SwVariableRef-
Proxy.autosarVariable and SwVariableRefProxy.mcDataInstanceVar are
entirely disjoint and therefore the simultaneous existence of these two attributes would
not make any sense at all.
Therefore, [constr_1382] has been introduced to clarify this aspect.
[constr_1382] Mutually exclusive existence of attributes SwVariableRef-
Proxy.autosarVariable vs. SwVariableRefProxy.mcDataInstanceVar d In
any given AUTOSAR model, the aggregations SwVariableRefProxy.autosar-
Variable and SwVariableRefProxy.mcDataInstanceVar shall never exist at
the same time. c()
As shown in Figure 5.39, this approach is also used to represent a AutosarVari-
ableRef in all roles, e.g. the result of an interpolation routine applied to an axis, the
input value determination, a list of dependent parameters, and swDataDependency.

363 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

AtpPrototype
DataPrototype

+localParameter 0..1

+/swDataDefProps 0..1

«atpVariation» AutosarDataPrototype
SwDataDefProps

+swCalprmAxisSet 0..1

SwCalprmAxisSet VariableDataPrototype ParameterDataPrototype

+localVariable 0..1

+swCalprmAxis 0..*

SwCalprmAxis AutosarVariableRef AutosarParameterRef

+autosarVariable 0..1 +arParameter 0..1

+swCalprmAxisTypeProps 1

SwCalprmAxisTypeProps SwCalprmRefProxy

+swCalprmRef 1

SwAxisIndividual

0..*
+swVariableRef {ordered}

SwVariableRefProxy SwAxisGrouped

Figure 5.39: Extended Axis Elements and Input Variable Reference

With the means of ApplicationArrayDataTypes it’s possible to define DataPro-

totypes holding a n-dimensional array of Compound Primitive Data Types of
category CURVE, MAP, CUBOID, CUBE_4, CUBE_5, COM_AXIS, or RES_AXIS.
For those DataPrototypes input values for the axes should be described to enable
a display of the working point in the MCD system.
Thereby, typically the whole array of the contained axes is either associated with an
array of a variables or with a single value. In the case of arrays typically the n-th axis is
combined with the n-th input value.

364 of 1069 Document ID 062: AUTOSAR_TPS_SoftwareComponentTemplate

— AUTOSAR CONFIDENTIAL —
 Software Component Template
AUTOSAR CP Release 4.4.0

Figure 5.40: The nth COM_AXIS in the array of COM_AXISs uses the nth VALUE in the array
of VALUEs as working point.

[constr_1425] Definition of swCalprm